| Message ID | 20230207025958.974056-5-eric.snowberg@oracle.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Add CA enforcement keyring restrictions | expand |
On Mon, 2023-02-06 at 21:59 -0500, Eric Snowberg wrote: > Parse the X.509 Key Usage. The key usage extension defines the purpose of > the key contained in the certificate. > > id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } > > KeyUsage ::= BIT STRING { > digitalSignature (0), > contentCommitment (1), > keyEncipherment (2), > dataEncipherment (3), > keyAgreement (4), > keyCertSign (5), > cRLSign (6), > encipherOnly (7), > decipherOnly (8) } > > If the keyCertSign or digitalSignature is set, store it in the > public_key structure. This will be used in a follow on patch that > requires knowing the certificate key usage type. > > Link: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3 > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> Reviewed-by: Mimi Zohar <zohar@linux.ibm.com>
On Mon, Feb 06, 2023 at 09:59:56PM -0500, Eric Snowberg wrote: > Parse the X.509 Key Usage. The key usage extension defines the purpose of > the key contained in the certificate. > > id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } > > KeyUsage ::= BIT STRING { > digitalSignature (0), > contentCommitment (1), > keyEncipherment (2), > dataEncipherment (3), > keyAgreement (4), > keyCertSign (5), > cRLSign (6), > encipherOnly (7), > decipherOnly (8) } > > If the keyCertSign or digitalSignature is set, store it in the > public_key structure. This will be used in a follow on patch that > requires knowing the certificate key usage type. It would be better to shortly explain why we want to know key usage type, rather than give zero information with "follow on patch". > > Link: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3 > Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> > --- > crypto/asymmetric_keys/x509_cert_parser.c | 28 +++++++++++++++++++++++ > include/crypto/public_key.h | 2 ++ > 2 files changed, 30 insertions(+) > > diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c > index 77547d4bd94d..0a7049b470c1 100644 > --- a/crypto/asymmetric_keys/x509_cert_parser.c > +++ b/crypto/asymmetric_keys/x509_cert_parser.c > @@ -579,6 +579,34 @@ int x509_process_extension(void *context, size_t hdrlen, > return 0; > } > > + if (ctx->last_oid == OID_keyUsage) { > + /* > + * Get hold of the keyUsage bit string > + * v[1] is the encoding size > + * (Expect either 0x02 or 0x03, making it 1 or 2 bytes) > + * v[2] is the number of unused bits in the bit string > + * (If >= 3 keyCertSign is missing when v[1] = 0x02) > + * v[3] and possibly v[4] contain the bit string > + * > + * From RFC 5280 4.2.1.3: > + * 0x04 is where keyCertSign lands in this bit string > + * 0x80 is where digitalSignature lands in this bit string > + */ > + if (v[0] != ASN1_BTS) > + return -EBADMSG; > + if (vlen < 4) > + return -EBADMSG; > + if (v[2] >= 8) > + return -EBADMSG; > + if (v[3] & 0x80) > + ctx->cert->pub->key_eflags |= 1 << KEY_EFLAG_DIGITALSIG; > + if (v[1] == 0x02 && v[2] <= 2 && (v[3] & 0x04)) > + ctx->cert->pub->key_eflags |= 1 << KEY_EFLAG_KEYCERTSIGN; > + else if (vlen > 4 && v[1] == 0x03 && (v[3] & 0x04)) > + ctx->cert->pub->key_eflags |= 1 << KEY_EFLAG_KEYCERTSIGN; > + return 0; > + } > + > if (ctx->last_oid == OID_authorityKeyIdentifier) { > /* Get hold of the CA key fingerprint */ > ctx->raw_akid = v; > diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h > index c401762850f2..03c3fb990d59 100644 > --- a/include/crypto/public_key.h > +++ b/include/crypto/public_key.h > @@ -30,6 +30,8 @@ struct public_key { > const char *pkey_algo; > unsigned long key_eflags; /* key extension flags */ > #define KEY_EFLAG_CA 0 /* set if the CA basic constraints is set */ > +#define KEY_EFLAG_DIGITALSIG 1 /* set if the digitalSignature usage is set */ > +#define KEY_EFLAG_KEYCERTSIGN 2 /* set if the keyCertSign usage is set */ > }; > > extern void public_key_free(struct public_key *key); > -- > 2.27.0 > BR, Jarkko
> On Feb 9, 2023, at 8:48 PM, Jarkko Sakkinen <jarkko@kernel.org> wrote: > > On Mon, Feb 06, 2023 at 09:59:56PM -0500, Eric Snowberg wrote: >> Parse the X.509 Key Usage. The key usage extension defines the purpose of >> the key contained in the certificate. >> >> id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } >> >> KeyUsage ::= BIT STRING { >> digitalSignature (0), >> contentCommitment (1), >> keyEncipherment (2), >> dataEncipherment (3), >> keyAgreement (4), >> keyCertSign (5), >> cRLSign (6), >> encipherOnly (7), >> decipherOnly (8) } >> >> If the keyCertSign or digitalSignature is set, store it in the >> public_key structure. This will be used in a follow on patch that >> requires knowing the certificate key usage type. > > It would be better to shortly explain why we want to know key usage > type, rather than give zero information with "follow on patch”. Ok, I will add this in the next round, thanks.
diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c index 77547d4bd94d..0a7049b470c1 100644 --- a/crypto/asymmetric_keys/x509_cert_parser.c +++ b/crypto/asymmetric_keys/x509_cert_parser.c @@ -579,6 +579,34 @@ int x509_process_extension(void *context, size_t hdrlen, return 0; } + if (ctx->last_oid == OID_keyUsage) { + /* + * Get hold of the keyUsage bit string + * v[1] is the encoding size + * (Expect either 0x02 or 0x03, making it 1 or 2 bytes) + * v[2] is the number of unused bits in the bit string + * (If >= 3 keyCertSign is missing when v[1] = 0x02) + * v[3] and possibly v[4] contain the bit string + * + * From RFC 5280 4.2.1.3: + * 0x04 is where keyCertSign lands in this bit string + * 0x80 is where digitalSignature lands in this bit string + */ + if (v[0] != ASN1_BTS) + return -EBADMSG; + if (vlen < 4) + return -EBADMSG; + if (v[2] >= 8) + return -EBADMSG; + if (v[3] & 0x80) + ctx->cert->pub->key_eflags |= 1 << KEY_EFLAG_DIGITALSIG; + if (v[1] == 0x02 && v[2] <= 2 && (v[3] & 0x04)) + ctx->cert->pub->key_eflags |= 1 << KEY_EFLAG_KEYCERTSIGN; + else if (vlen > 4 && v[1] == 0x03 && (v[3] & 0x04)) + ctx->cert->pub->key_eflags |= 1 << KEY_EFLAG_KEYCERTSIGN; + return 0; + } + if (ctx->last_oid == OID_authorityKeyIdentifier) { /* Get hold of the CA key fingerprint */ ctx->raw_akid = v; diff --git a/include/crypto/public_key.h b/include/crypto/public_key.h index c401762850f2..03c3fb990d59 100644 --- a/include/crypto/public_key.h +++ b/include/crypto/public_key.h @@ -30,6 +30,8 @@ struct public_key { const char *pkey_algo; unsigned long key_eflags; /* key extension flags */ #define KEY_EFLAG_CA 0 /* set if the CA basic constraints is set */ +#define KEY_EFLAG_DIGITALSIG 1 /* set if the digitalSignature usage is set */ +#define KEY_EFLAG_KEYCERTSIGN 2 /* set if the keyCertSign usage is set */ }; extern void public_key_free(struct public_key *key);
Parse the X.509 Key Usage. The key usage extension defines the purpose of the key contained in the certificate. id-ce-keyUsage OBJECT IDENTIFIER ::= { id-ce 15 } KeyUsage ::= BIT STRING { digitalSignature (0), contentCommitment (1), keyEncipherment (2), dataEncipherment (3), keyAgreement (4), keyCertSign (5), cRLSign (6), encipherOnly (7), decipherOnly (8) } If the keyCertSign or digitalSignature is set, store it in the public_key structure. This will be used in a follow on patch that requires knowing the certificate key usage type. Link: https://www.rfc-editor.org/rfc/rfc5280#section-4.2.1.3 Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com> --- crypto/asymmetric_keys/x509_cert_parser.c | 28 +++++++++++++++++++++++ include/crypto/public_key.h | 2 ++ 2 files changed, 30 insertions(+)