26 Mar, 2021
3 commits
-
Prepare the x509 parser to accept NIST P384 certificates and add the
OID for ansip384r1, which is the identifier for NIST P384.Summary of changes:
* crypto/asymmetric_keys/x509_cert_parser.c
- prepare x509 parser to load NIST P384* include/linux/oid_registry.h
- add OID_ansip384r1Signed-off-by: Saulo Alessandre
Tested-by: Stefan Berger
Signed-off-by: Herbert Xu -
Add support for parsing of x509 certificates that contain ECDSA keys,
such as NIST P256, that have been signed by a CA using any of the
current SHA hash algorithms.Cc: David Howells
Cc: keyrings@vger.kernel.org
Signed-off-by: Stefan Berger
Signed-off-by: Herbert Xu -
Detect whether a key is an sm2 type of key by its OID in the parameters
array rather than assuming that everything under OID_id_ecPublicKey
is sm2, which is not the case.Cc: David Howells
Cc: keyrings@vger.kernel.org
Signed-off-by: Stefan Berger
Reviewed-by: Tianjia Zhang
Tested-by: Tianjia Zhang
Signed-off-by: Herbert Xu
25 Sep, 2020
1 commit
-
The digital certificate format based on SM2 crypto algorithm as
specified in GM/T 0015-2012. It was published by State Encryption
Management Bureau, China.This patch adds the OID object identifier defined by OSCCA. The
x509 certificate supports SM2-with-SM3 type certificate parsing.
It uses the standard elliptic curve public key, and the sm2
algorithm signs the hash generated by sm3.Signed-off-by: Tianjia Zhang
Tested-by: Xufeng Zhang
Reviewed-by: Vitaly Chikunov
Signed-off-by: Herbert Xu
24 May, 2019
1 commit
-
Based on 1 normalized pattern(s):
this program is free software you can redistribute it and or modify
it under the terms of the gnu general public licence as published by
the free software foundation either version 2 of the licence or at
your option any later versionextracted by the scancode license scanner the SPDX license identifier
GPL-2.0-or-later
has been chosen to replace the boilerplate/reference in 114 file(s).
Signed-off-by: Thomas Gleixner
Reviewed-by: Allison Randal
Reviewed-by: Kate Stewart
Cc: linux-spdx@vger.kernel.org
Link: https://lkml.kernel.org/r/20190520170857.552531963@linutronix.de
Signed-off-by: Greg Kroah-Hartman
18 Apr, 2019
2 commits
-
Add Elliptic Curve Russian Digital Signature Algorithm (GOST R
34.10-2012, RFC 7091, ISO/IEC 14888-3) is one of the Russian (and since
2018 the CIS countries) cryptographic standard algorithms (called GOST
algorithms). Only signature verification is supported, with intent to be
used in the IMA.Summary of the changes:
* crypto/Kconfig:
- EC-RDSA is added into Public-key cryptography section.* crypto/Makefile:
- ecrdsa objects are added.* crypto/asymmetric_keys/x509_cert_parser.c:
- Recognize EC-RDSA and Streebog OIDs.* include/linux/oid_registry.h:
- EC-RDSA OIDs are added to the enum. Also, a two currently not
implemented curve OIDs are added for possible extension later (to
not change numbering and grouping).* crypto/ecc.c:
- Kenneth MacKay copyright date is updated to 2014, because
vli_mmod_slow, ecc_point_add, ecc_point_mult_shamir are based on his
code from micro-ecc.
- Functions needed for ecrdsa are EXPORT_SYMBOL'ed.
- New functions:
vli_is_negative - helper to determine sign of vli;
vli_from_be64 - unpack big-endian array into vli (used for
a signature);
vli_from_le64 - unpack little-endian array into vli (used for
a public key);
vli_uadd, vli_usub - add/sub u64 value to/from vli (used for
increment/decrement);
mul_64_64 - optimized to use __int128 where appropriate, this speeds
up point multiplication (and as a consequence signature
verification) by the factor of 1.5-2;
vli_umult - multiply vli by a small value (speeds up point
multiplication by another factor of 1.5-2, depending on vli sizes);
vli_mmod_special - module reduction for some form of Pseudo-Mersenne
primes (used for the curves A);
vli_mmod_special2 - module reduction for another form of
Pseudo-Mersenne primes (used for the curves B);
vli_mmod_barrett - module reduction using pre-computed value (used
for the curve C);
vli_mmod_slow - more general module reduction which is much slower
(used when the modulus is subgroup order);
vli_mod_mult_slow - modular multiplication;
ecc_point_add - add two points;
ecc_point_mult_shamir - add two points multiplied by scalars in one
combined multiplication (this gives speed up by another factor 2 in
compare to two separate multiplications).
ecc_is_pubkey_valid_partial - additional samity check is added.
- Updated vli_mmod_fast with non-strict heuristic to call optimal
module reduction function depending on the prime value;
- All computations for the previously defined (two NIST) curves should
not unaffected.* crypto/ecc.h:
- Newly exported functions are documented.* crypto/ecrdsa_defs.h
- Five curves are defined.* crypto/ecrdsa.c:
- Signature verification is implemented.* crypto/ecrdsa_params.asn1, crypto/ecrdsa_pub_key.asn1:
- Templates for BER decoder for EC-RDSA parameters and public key.Cc: linux-integrity@vger.kernel.org
Signed-off-by: Vitaly Chikunov
Signed-off-by: Herbert Xu -
Some public key algorithms (like EC-DSA) keep in parameters field
important data such as digest and curve OIDs (possibly more for
different EC-DSA variants). Thus, just setting a public key (as
for RSA) is not enough.Append parameters into the key stream for akcipher_set_{pub,priv}_key.
Appended data is: (u32) algo OID, (u32) parameters length, parameters
data.This does not affect current akcipher API nor RSA ciphers (they could
ignore it). Idea of appending parameters to the key stream is by Herbert
Xu.Cc: David Howells
Cc: Denis Kenzior
Cc: keyrings@vger.kernel.org
Signed-off-by: Vitaly Chikunov
Reviewed-by: Denis Kenzior
Signed-off-by: Herbert Xu
26 Oct, 2018
1 commit
-
Make the X.509 and PKCS7 parsers fill in the signature encoding type field
recently added to the public_key_signature struct.Signed-off-by: David Howells
Tested-by: Marcel Holtmann
Reviewed-by: Marcel Holtmann
Reviewed-by: Denis Kenzior
Tested-by: Denis Kenzior
Signed-off-by: James Morris
26 Jun, 2018
1 commit
-
The signatureValue field of a X.509 certificate is encoded as a BIT STRING.
For RSA signatures this BIT STRING is of so-called primitive subtype, which
contains a u8 prefix indicating a count of unused bits in the encoding.We have to strip this prefix from signature data, just as we already do for
key data in x509_extract_key_data() function.This wasn't noticed earlier because this prefix byte is zero for RSA key
sizes divisible by 8. Since BIT STRING is a big-endian encoding adding zero
prefixes has no bearing on its value.The signature length, however was incorrect, which is a problem for RSA
implementations that need it to be exactly correct (like AMD CCP).Signed-off-by: Maciej S. Szmigiero
Fixes: c26fd69fa009 ("X.509: Add a crypto key parser for binary (DER) X.509 certificates")
Cc: stable@vger.kernel.org
Signed-off-by: James Morris
07 Apr, 2018
1 commit
-
Our convention is to distinguish file types by suffixes with a period
as a separator.*-asn1.[ch] is a different pattern from other generated sources such
as *.lex.c, *.tab.[ch], *.dtb.S, etc. More confusing, files with
'-asn1.[ch]' are generated files, but '_asn1.[ch]' are checked-in
files:
net/netfilter/nf_conntrack_h323_asn1.c
include/linux/netfilter/nf_conntrack_h323_asn1.h
include/linux/sunrpc/gss_asn1.hRename generated files to *.asn1.[ch] for consistency.
Signed-off-by: Masahiro Yamada
08 Dec, 2017
1 commit
-
Adding a specially crafted X.509 certificate whose subjectPublicKey
ASN.1 value is zero-length caused x509_extract_key_data() to set the
public key size to SIZE_MAX, as it subtracted the nonexistent BIT STRING
metadata byte. Then, x509_cert_parse() called kmemdup() with that bogus
size, triggering the WARN_ON_ONCE() in kmalloc_slab().This appears to be harmless, but it still must be fixed since WARNs are
never supposed to be user-triggerable.Fix it by updating x509_cert_parse() to validate that the value has a
BIT STRING metadata byte, and that the byte is 0 which indicates that
the number of bits in the bitstring is a multiple of 8.It would be nice to handle the metadata byte in asn1_ber_decoder()
instead. But that would be tricky because in the general case a BIT
STRING could be implicitly tagged, and/or could legitimately have a
length that is not a whole number of bytes.Here was the WARN (cleaned up slightly):
WARNING: CPU: 1 PID: 202 at mm/slab_common.c:971 kmalloc_slab+0x5d/0x70 mm/slab_common.c:971
Modules linked in:
CPU: 1 PID: 202 Comm: keyctl Tainted: G B 4.14.0-09238-g1d3b78bbc6e9 #26
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-20171110_100015-anatol 04/01/2014
task: ffff880033014180 task.stack: ffff8800305c8000
Call Trace:
__do_kmalloc mm/slab.c:3706 [inline]
__kmalloc_track_caller+0x22/0x2e0 mm/slab.c:3726
kmemdup+0x17/0x40 mm/util.c:118
kmemdup include/linux/string.h:414 [inline]
x509_cert_parse+0x2cb/0x620 crypto/asymmetric_keys/x509_cert_parser.c:106
x509_key_preparse+0x61/0x750 crypto/asymmetric_keys/x509_public_key.c:174
asymmetric_key_preparse+0xa4/0x150 crypto/asymmetric_keys/asymmetric_type.c:388
key_create_or_update+0x4d4/0x10a0 security/keys/key.c:850
SYSC_add_key security/keys/keyctl.c:122 [inline]
SyS_add_key+0xe8/0x290 security/keys/keyctl.c:62
entry_SYSCALL_64_fastpath+0x1f/0x96Fixes: 42d5ec27f873 ("X.509: Add an ASN.1 decoder")
Cc: # v3.7+
Signed-off-by: Eric Biggers
Signed-off-by: David Howells
Reviewed-by: James Morris
09 Jun, 2017
1 commit
-
We forgot to set the error code on this path so it could result in
returning NULL which leads to a NULL dereference.Fixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api")
Signed-off-by: Dan Carpenter
Signed-off-by: David Howells
Signed-off-by: James Morris
25 Nov, 2016
1 commit
-
We shouldn't free cert->pub->key in x509_cert_parse() because
x509_free_certificate() also does this:
BUG: Double free or freeing an invalid pointer
...
Call Trace:
[] dump_stack+0x63/0x83
[] kasan_object_err+0x21/0x70
[] kasan_report_double_free+0x49/0x60
[] kasan_slab_free+0x9d/0xc0
[] kfree+0x8a/0x1a0
[] public_key_free+0x1f/0x30
[] x509_free_certificate+0x24/0x90
[] x509_cert_parse+0x2bc/0x300
[] x509_key_preparse+0x3e/0x330
[] asymmetric_key_preparse+0x6f/0x100
[] key_create_or_update+0x260/0x5f0
[] SyS_add_key+0x199/0x2a0
[] entry_SYSCALL_64_fastpath+0x1e/0xad
Object at ffff880110bd1900, in cache kmalloc-512 size: 512
....
Freed:
PID = 2579
[] save_stack_trace+0x1b/0x20
[] save_stack+0x46/0xd0
[] kasan_slab_free+0x73/0xc0
[] kfree+0x8a/0x1a0
[] x509_cert_parse+0x2a3/0x300
[] x509_key_preparse+0x3e/0x330
[] asymmetric_key_preparse+0x6f/0x100
[] key_create_or_update+0x260/0x5f0
[] SyS_add_key+0x199/0x2a0
[] entry_SYSCALL_64_fastpath+0x1e/0xadFixes: db6c43bd2132 ("crypto: KEYS: convert public key and digsig asym to the akcipher api")
Signed-off-by: Andrey Ryabinin
Cc:
Signed-off-by: David Howells
Signed-off-by: James Morris
06 Apr, 2016
3 commits
-
Extract the signature digest for an X.509 certificate earlier, at the end
of x509_cert_parse() rather than leaving it to the callers thereof since it
has to be called anyway.Further, immediately after that, check the signature on self-signed
certificates, also rather in the callers of x509_cert_parse().We note in the x509_certificate struct the following bits of information:
(1) Whether the signature is self-signed (even if we can't check the
signature due to missing crypto).(2) Whether the key held in the certificate needs unsupported crypto to be
used. We may get a PKCS#7 message with X.509 certs that we can't make
use of - we just ignore them and give ENOPKG at the end it we couldn't
verify anything if at least one of these unusable certs are in the
chain of trust.(3) Whether the signature held in the certificate needs unsupported crypto
to be checked. We can still use the key held in this certificate,
even if we can't check the signature on it - if it is held in the
system trusted keyring, for instance. We just can't add it to a ring
of trusted keys or follow it further up the chain of trust.Making these checks earlier allows x509_check_signature() to be removed and
replaced with direct calls to public_key_verify_signature().Signed-off-by: David Howells
-
Retain the key verification data (ie. the struct public_key_signature)
including the digest and the key identifiers.Note that this means that we need to take a separate copy of the digest in
x509_get_sig_params() rather than lumping it in with the crypto layer data.Signed-off-by: David Howells
-
Allow authentication data to be stored in an asymmetric key in the 4th
element of the key payload and provide a way for it to be destroyed.For the public key subtype, this will be a public_key_signature struct.
Signed-off-by: David Howells
04 Mar, 2016
1 commit
-
Make the identifier public key and digest algorithm fields text instead of
enum.Signed-off-by: David Howells
Acked-by: Herbert Xu
29 Feb, 2016
3 commits
-
The ASN.1 GeneralizedTime object carries an ISO 8601 format date and time.
The time is permitted to show midnight as 00:00 or 24:00 (the latter being
equivalent of 00:00 of the following day).The permitted value is checked in x509_decode_time() but the actual
handling is left to mktime64().Without this patch, certain X.509 certificates will be rejected and could
lead to an unbootable kernel.Note that with this patch we also permit any 24:mm:ss time and extend this
to UTCTime, which whilst not strictly correct don't permit much leeway in
fiddling date strings.Reported-by: Rudolf Polzer
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
cc: David Woodhouse
cc: John Stultz -
The format of ASN.1 GeneralizedTime seems to be specified by ISO 8601
[X.680 46.3] and this apparently supports leap seconds (ie. the seconds
field is 60). It's not entirely clear that ASN.1 expects it, but we can
relax the seconds check slightly for GeneralizedTime.This results in us passing a time with sec as 60 to mktime64(), which
handles it as being a duplicate of the 0th second of the next minute.We can't really do otherwise without giving the kernel much greater
knowledge of where all the leap seconds are. Unfortunately, this would
require change the mapping of the kernel's current-time-in-seconds.UTCTime, however, only supports a seconds value in the range 00-59, but for
the sake of simplicity allow this with UTCTime also.Without this patch, certain X.509 certificates will be rejected,
potentially making a kernel unbootable.Reported-by: Rudolf Polzer
Signed-off-by: David Howells
Acked-by: Arnd Bergmann
cc: David Woodhouse
cc: John Stultz -
There are still a couple of minor issues in the X.509 leap year handling:
(1) To avoid doing a modulus-by-400 in addition to a modulus-by-100 when
determining whether the year is a leap year or not, I divided the year
by 100 after doing the modulus-by-100, thereby letting the compiler do
one instruction for both, and then did a modulus-by-4.Unfortunately, I then passed the now-modified year value to mktime64()
to construct a time value.Since this isn't a fast path and since mktime64() does a bunch of
divisions, just condense down to "% 400". It's also easier to read.(2) The default month length for any February where the year doesn't
divide by four exactly is obtained from the month_length[] array where
the value is 29, not 28.This is fixed by altering the table.
Reported-by: Rudolf Polzer
Signed-off-by: David Howells
Acked-by: David Woodhouse
Acked-by: Arnd Bergmann
cc: stable@vger.kernel.org
10 Feb, 2016
1 commit
-
This patch converts the module verification code to the new akcipher API.
Signed-off-by: Tadeusz Struk
Acked-by: Herbert Xu
Signed-off-by: David Howells
12 Nov, 2015
1 commit
-
This fixes CVE-2015-5327. It affects kernels from 4.3-rc1 onwards.
Fix the X.509 time validation to use month number-1 when looking up the
number of days in that month. Also put the month number validation before
doing the lookup so as not to risk overrunning the array.This can be tested by doing the following:
cat <
Signed-off-by: David Howells
Tested-by: Mimi Zohar
Acked-by: David Woodhouse
Signed-off-by: James Morris
21 Sep, 2015
1 commit
-
hour, min and sec are unsigned int and they can never be less than zero.
Signed-off-by: Sudip Mukherjee
Signed-off-by: Herbert Xu
13 Aug, 2015
2 commits
-
Make the X.509 ASN.1 time object decoder fill in a time64_t rather than a
struct tm to make comparison easier (unfortunately, this makes readable
display less easy) and export it so that it can be used by the PKCS#7 code
too.Further, tighten up its parsing to reject invalid dates (eg. weird
characters, non-existent hour numbers) and unsupported dates (eg. timezones
other than 'Z' or dates earlier than 1970).Signed-off-by: David Howells
Reviewed-by: David Woodhouse -
The key identifiers fabricated from an X.509 certificate are currently:
(A) Concatenation of serial number and issuer
(B) Concatenation of subject and subjectKeyID (SKID)
When verifying one X.509 certificate with another, the AKID in the target
can be used to match the authoritative certificate. The AKID can specify
the match in one or both of two ways:(1) Compare authorityCertSerialNumber and authorityCertIssuer from the AKID
to identifier (A) above.(2) Compare keyIdentifier from the AKID plus the issuer from the target
certificate to identifier (B) above.When verifying a PKCS#7 message, the only available comparison is between
the IssuerAndSerialNumber field and identifier (A) above.However, a subsequent patch adds CMS support. Whilst CMS still supports a
match on IssuerAndSerialNumber as for PKCS#7, it also supports an
alternative - which is the SubjectKeyIdentifier field. This is used to
match to an X.509 certificate on the SKID alone. No subject information is
available to be used.To this end change the fabrication of (B) above to be from the X.509 SKID
alone. The AKID in keyIdentifier form then only matches on that and does
not include the issuer.Signed-off-by: David Howells
Reviewed-By: David Woodhouse
07 Aug, 2015
1 commit
-
Extract both parts of the AuthorityKeyIdentifier, not just the keyIdentifier,
as the second part can be used to match X.509 certificates by issuer and
serialNumber.Signed-off-by: David Howells
Tested-by: Vivek Goyal
06 Oct, 2014
1 commit
-
Earlier KEYS code used pure subject key identifiers (fingerprint)
for searching keys. Latest merged code removed that and broke
compatibility with integrity subsytem signatures and original
format of module signatures.This patch returns back partial matching on SKID.
Reported-by: Dmitry Kasatkin
Signed-off-by: Dmitry Kasatkin
Signed-off-by: David Howells
03 Oct, 2014
1 commit
-
Module signing matches keys by comparing against the key description exactly.
However, the way the key description gets constructed got changed to be
composed of the subject name plus the certificate serial number instead of the
subject name and the subjectKeyId. I changed this to avoid problems with
certificates that don't *have* a subjectKeyId.Instead, if available, use the raw subjectKeyId to form the key description
and only use the serial number if the subjectKeyId doesn't exist.Reported-by: Dmitry Kasatkin
Signed-off-by: David Howells
17 Sep, 2014
1 commit
-
Make use of the new match string preparsing to overhaul key identification
when searching for asymmetric keys. The following changes are made:(1) Use the previously created asymmetric_key_id struct to hold the following
key IDs derived from the X.509 certificate or PKCS#7 message:id: serial number + issuer
skid: subjKeyId + subject
authority: authKeyId + issuer(2) Replace the hex fingerprint attached to key->type_data[1] with an
asymmetric_key_ids struct containing the id and the skid (if present).(3) Make the asymmetric_type match data preparse select one of two searches:
(a) An iterative search for the key ID given if prefixed with "id:". The
prefix is expected to be followed by a hex string giving the ID to
search for. The criterion key ID is checked against all key IDs
recorded on the key.(b) A direct search if the key ID is not prefixed with "id:". This will
look for an exact match on the key description.(4) Make x509_request_asymmetric_key() take a key ID. This is then converted
into "id:" and passed into keyring_search() where match preparsing
will turn it back into a binary ID.(5) X.509 certificate verification then takes the authority key ID and looks
up a key that matches it to find the public key for the certificate
signature.(6) PKCS#7 certificate verification then takes the id key ID and looks up a
key that matches it to find the public key for the signed information
block signature.Additional changes:
(1) Multiple subjKeyId and authKeyId values on an X.509 certificate cause the
cert to be rejected with -EBADMSG.(2) The 'fingerprint' ID is gone. This was primarily intended to convey PGP
public key fingerprints. If PGP is supported in future, this should
generate a key ID that carries the fingerprint.(3) Th ca_keyid= kernel command line option is now converted to a key ID and
used to match the authority key ID. Possibly this should only match the
actual authKeyId part and not the issuer as well.Signed-off-by: David Howells
Acked-by: Vivek Goyal
03 Jul, 2014
1 commit
-
Export certificate parse and free functions for use by modules.
Signed-off-by: David Howells
Acked-by: Vivek Goyal
Reviewed-by: Kees Cook
Reviewed-by: Josh Boyer
01 Jul, 2014
1 commit
-
PKCS#7 validation requires access to the serial number and the raw names in an
X.509 certificate.Signed-off-by: David Howells
Reviewed-by: Kees Cook
Reviewed-by: Josh Boyer
26 Oct, 2013
1 commit
-
This patch makes use of the newly defined common hash algorithm info,
replacing, for example, PKEY_HASH with HASH_ALGO.Changelog:
- Lindent fixes - MimiCC: David Howells
Signed-off-by: Dmitry Kasatkin
Signed-off-by: Mimi Zohar
26 Sep, 2013
2 commits
-
Embed a public_key_signature struct in struct x509_certificate, eliminating
now unnecessary fields, and split x509_check_signature() to create a filler
function for it that attaches a digest of the signed data and an MPI that
represents the signature data. x509_free_certificate() is then modified to
deal with these.Whilst we're at it, export both x509_check_signature() and the new
x509_get_sig_params().Signed-off-by: David Howells
Reviewed-by: Kees Cook
Reviewed-by: Josh Boyer -
Store public key algo ID in public_key struct for reference purposes. This
allows it to be removed from the x509_certificate struct and used to find a
default in public_key_verify_signature().Signed-off-by: David Howells
Reviewed-by: Kees Cook
Reviewed-by: Josh Boyer
22 Apr, 2013
1 commit
-
Per X.509 spec in 4.2.1.1 section, the structure of Authority Key
Identifier Extension is:AuthorityKeyIdentifier ::= SEQUENCE {
keyIdentifier [0] KeyIdentifier OPTIONAL,
authorityCertIssuer [1] GeneralNames OPTIONAL,
authorityCertSerialNumber [2] CertificateSerialNumber OPTIONAL }KeyIdentifier ::= OCTET STRING
When a certificate also provides
authorityCertIssuer and authorityCertSerialNumber then the length of
AuthorityKeyIdentifier SEQUENCE is likely to long form format.
e.g.
The example certificate demos/tunala/A-server.pem in openssl source:X509v3 Authority Key Identifier:
keyid:49:FB:45:72:12:C4:CC:E1:45:A1:D3:08:9E:95:C4:2C:6D:55:3F:17
DirName:/C=NZ/L=Wellington/O=Really Irresponsible Authorisation Authority (RIAA)/OU=Cert-stamping/CN=Jackov al-Trades/emailAddress=none@fake.domain
serial:00Current parsing rule of OID_authorityKeyIdentifier only take care the
short form format, it causes load certificate to modsign_keyring fail:[ 12.061147] X.509: Extension: 47
[ 12.075121] MODSIGN: Problem loading in-kernel X.509 certificate (-74)So, this patch add the parsing rule for support long form format against
Authority Key Identifier.v3:
Changed the size check in "Short Form length" case, we allow v[3] smaller
then (vlen - 4) because authorityCertIssuer and authorityCertSerialNumber
are also possible attach in AuthorityKeyIdentifier sequence.v2:
- Removed comma from author's name.
- Moved 'Short Form length' comment inside the if-body.
- Changed the type of sub to size_t.
- Use ASN1_INDEFINITE_LENGTH rather than writing 0x80 and 127.
- Moved the key_len's value assignment before alter v.
- Fixed the typo of octets.
- Add 2 to v before entering the loop for calculate the length.
- Removed the comment of check vlen.Cc: Rusty Russell
Cc: Josh Boyer
Cc: Randy Dunlap
Cc: Herbert Xu
Cc: "David S. Miller"
Acked-by: David Howells
Signed-off-by: Chun-Yi Lee
Signed-off-by: Rusty Russell
10 Oct, 2012
2 commits
-
Fix printk format warning in x509_cert_parser.c:
crypto/asymmetric_keys/x509_cert_parser.c: In function 'x509_note_OID':
crypto/asymmetric_keys/x509_cert_parser.c:113:3: warning: format '%zu' expects type 'size_t', but argument 2 has type 'long unsigned int'Builds cleanly on i386 and x86_64.
Signed-off-by: Randy Dunlap
Cc: David Howells
Cc: Herbert Xu
Cc: linux-crypto@vger.kernel.org
Signed-off-by: Rusty Russell -
The current choice of lifetime for the autogenerated X.509 of 100 years,
putting the validTo date in 2112, causes problems on 32-bit systems where a
32-bit time_t wraps in 2106. 64-bit x86_64 systems seem to be unaffected.This can result in something like:
Loading module verification certificates
X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 has expired
MODSIGN: Problem loading in-kernel X.509 certificate (-127)Or:
X.509: Cert 6e03943da0f3b015ba6ed7f5e0cac4fe48680994 is not yet valid
MODSIGN: Problem loading in-kernel X.509 certificate (-129)Instead of turning the dates into time_t values and comparing, turn the system
clock and the ASN.1 dates into tm structs and compare those piecemeal instead.Reported-by: Rusty Russell
Signed-off-by: David Howells
Acked-by: Josh Boyer
Signed-off-by: Rusty Russell
08 Oct, 2012
1 commit
-
Add a crypto key parser for binary (DER) encoded X.509 certificates. The
certificate is parsed and, if possible, the signature is verified.An X.509 key can be added like this:
# keyctl padd crypto bar @s
Signed-off-by: Rusty Russell