From: Eric Snowberg <eric.snowberg@oracle.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
Cc: Mimi Zohar <zohar@linux.ibm.com>,
David Howells <dhowells@redhat.com>,
David Woodhouse <dwmw2@infradead.org>,
"herbert@gondor.apana.org.au" <herbert@gondor.apana.org.au>,
"davem@davemloft.net" <davem@davemloft.net>,
"dmitry.kasatkin@gmail.com" <dmitry.kasatkin@gmail.com>,
"paul@paul-moore.com" <paul@paul-moore.com>,
"jmorris@namei.org" <jmorris@namei.org>,
"serge@hallyn.com" <serge@hallyn.com>,
"pvorel@suse.cz" <pvorel@suse.cz>,
"noodles@fb.com" <noodles@fb.com>,
"tiwai@suse.de" <tiwai@suse.de>,
Kanth Ghatraju <kanth.ghatraju@oracle.com>,
Konrad Wilk <konrad.wilk@oracle.com>,
Elaine Palmer <erpalmer@linux.vnet.ibm.com>,
Coiby Xu <coxu@redhat.com>,
"keyrings@vger.kernel.org" <keyrings@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
"linux-integrity@vger.kernel.org"
<linux-integrity@vger.kernel.org>,
"linux-security-module@vger.kernel.org"
<linux-security-module@vger.kernel.org>
Subject: Re: [PATCH v3 04/10] KEYS: X.509: Parse Key Usage
Date: Wed, 4 Jan 2023 21:46:24 +0000 [thread overview]
Message-ID: <B90D2183-4712-4E01-9986-52CB51F968DF@oracle.com> (raw)
In-Reply-To: <Y7VmfLUAacYOjn9y@kernel.org>
> On Jan 4, 2023, at 4:43 AM, Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> On Tue, Dec 13, 2022 at 07:33:55PM -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 is set, store it in the x509_certificate structure.
>> This will be used in a follow on patch that requires knowing the
>> certificate key usage type.
>>
>> Signed-off-by: Eric Snowberg <eric.snowberg@oracle.com>
>> ---
>> crypto/asymmetric_keys/x509_cert_parser.c | 22 ++++++++++++++++++++++
>> crypto/asymmetric_keys/x509_parser.h | 1 +
>> 2 files changed, 23 insertions(+)
>>
>> diff --git a/crypto/asymmetric_keys/x509_cert_parser.c b/crypto/asymmetric_keys/x509_cert_parser.c
>> index b4443e507153..edb22cf04eed 100644
>> --- a/crypto/asymmetric_keys/x509_cert_parser.c
>> +++ b/crypto/asymmetric_keys/x509_cert_parser.c
>> @@ -579,6 +579,28 @@ int x509_process_extension(void *context, size_t hdrlen,
>> return 0;
>> }
>>
>> + if (ctx->last_oid == OID_keyUsage) {
>> + /*
>> + * Get hold of the keyUsage bit string to validate keyCertSign
>> + * 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)
>> + * v[3] and possibly v[4] contain the bit string
>> + * 0x04 is where KeyCertSign lands in this bit string (from
>> + * RFC 5280 4.2.1.3)
>> + */
>> + if (v[0] != ASN1_BTS)
>> + return -EBADMSG;
>> + if (vlen < 4)
>> + return -EBADMSG;
>> + if (v[1] == 0x02 && v[2] <= 2 && (v[3] & 0x04))
>> + ctx->cert->kcs_set = true;
>> + else if (vlen > 4 && v[1] == 0x03 && (v[3] & 0x04))
>> + ctx->cert->kcs_set = true;
>> + return 0;
>
> This is much more easier to follow thanks to explanation.
>
>> + }
>> +
>> if (ctx->last_oid == OID_authorityKeyIdentifier) {
>> /* Get hold of the CA key fingerprint */
>> ctx->raw_akid = v;
>> diff --git a/crypto/asymmetric_keys/x509_parser.h b/crypto/asymmetric_keys/x509_parser.h
>> index 7c5c0ad1c22e..74a9f929e400 100644
>> --- a/crypto/asymmetric_keys/x509_parser.h
>> +++ b/crypto/asymmetric_keys/x509_parser.h
>> @@ -39,6 +39,7 @@ struct x509_certificate {
>> bool unsupported_sig; /* T if signature uses unsupported crypto */
>> bool blacklisted;
>> bool root_ca; /* T if basic constraints CA is set */
>> + bool kcs_set; /* T if keyCertSign is set */
>> };
>>
>> /*
>> --
>> 2.27.0
>>
>
> LGTM but I'll hold with reviewed-by's up until the patch set overally
> looks good to me and I have actually tested it.
Thanks for your review. I will make all the other changes you brought up with
the other patches in the next round.
next prev parent reply other threads:[~2023-01-04 21:47 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-14 0:33 [PATCH v3 00/10] Add CA enforcement keyring restrictions Eric Snowberg
2022-12-14 0:33 ` [PATCH v3 01/10] KEYS: Create static version of public_key_verify_signature Eric Snowberg
2023-01-04 11:31 ` Jarkko Sakkinen
2022-12-14 0:33 ` [PATCH v3 02/10] KEYS: Add missing function documentation Eric Snowberg
2023-01-04 11:33 ` Jarkko Sakkinen
2022-12-14 0:33 ` [PATCH v3 03/10] KEYS: X.509: Parse Basic Constraints for CA Eric Snowberg
2022-12-15 11:10 ` Mimi Zohar
2023-01-04 12:29 ` Jarkko Sakkinen
2023-01-04 20:14 ` Eric Snowberg
2023-01-04 22:38 ` Mimi Zohar
2023-01-04 11:40 ` Jarkko Sakkinen
2022-12-14 0:33 ` [PATCH v3 04/10] KEYS: X.509: Parse Key Usage Eric Snowberg
2022-12-15 11:25 ` Mimi Zohar
2023-01-04 11:43 ` Jarkko Sakkinen
2023-01-04 21:46 ` Eric Snowberg [this message]
2022-12-14 0:33 ` [PATCH v3 05/10] KEYS: Introduce a CA endorsed flag Eric Snowberg
2023-01-04 11:45 ` Jarkko Sakkinen
2022-12-14 0:33 ` [PATCH v3 06/10] KEYS: Introduce keyring restriction that validates ca trust Eric Snowberg
2022-12-14 0:33 ` [PATCH v3 07/10] KEYS: X.509: Flag Intermediate CA certs as endorsed Eric Snowberg
2022-12-15 10:21 ` Mimi Zohar
2022-12-14 0:33 ` [PATCH v3 08/10] integrity: Use root of trust signature restriction Eric Snowberg
2022-12-14 0:34 ` [PATCH v3 09/10] KEYS: CA link restriction Eric Snowberg
2023-01-04 11:51 ` Jarkko Sakkinen
2023-01-04 11:54 ` Jarkko Sakkinen
2022-12-14 0:34 ` [PATCH v3 10/10] integrity: restrict INTEGRITY_KEYRING_MACHINE to restrict_link_by_ca Eric Snowberg
2022-12-15 10:21 ` [PATCH v3 00/10] Add CA enforcement keyring restrictions Mimi Zohar
2022-12-15 16:26 ` Eric Snowberg
2022-12-15 19:58 ` Mimi Zohar
2022-12-15 20:28 ` Eric Snowberg
2022-12-15 21:03 ` Mimi Zohar
2022-12-15 21:45 ` Eric Snowberg
2022-12-16 14:06 ` Coiby Xu
2022-12-18 12:21 ` Mimi Zohar
2022-12-21 18:27 ` Eric Snowberg
2022-12-21 19:01 ` Mimi Zohar
2022-12-22 15:15 ` Eric Snowberg
2022-12-22 15:41 ` Mimi Zohar
2022-12-23 16:13 ` Eric Snowberg
2022-12-23 16:34 ` Mimi Zohar
2022-12-23 18:17 ` Eric Snowberg
2022-12-23 19:45 ` Mimi Zohar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=B90D2183-4712-4E01-9986-52CB51F968DF@oracle.com \
--to=eric.snowberg@oracle.com \
--cc=coxu@redhat.com \
--cc=davem@davemloft.net \
--cc=dhowells@redhat.com \
--cc=dmitry.kasatkin@gmail.com \
--cc=dwmw2@infradead.org \
--cc=erpalmer@linux.vnet.ibm.com \
--cc=herbert@gondor.apana.org.au \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=kanth.ghatraju@oracle.com \
--cc=keyrings@vger.kernel.org \
--cc=konrad.wilk@oracle.com \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=noodles@fb.com \
--cc=paul@paul-moore.com \
--cc=pvorel@suse.cz \
--cc=serge@hallyn.com \
--cc=tiwai@suse.de \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).