keyrings.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jarkko Sakkinen <jarkko@kernel.org>
To: Eric Snowberg <eric.snowberg@oracle.com>
Cc: zohar@linux.ibm.com, dhowells@redhat.com, dwmw2@infradead.org,
	herbert@gondor.apana.org.au, davem@davemloft.net,
	dmitry.kasatkin@gmail.com, paul@paul-moore.com,
	jmorris@namei.org, serge@hallyn.com, pvorel@suse.cz,
	tadeusz.struk@intel.com, kanth.ghatraju@oracle.com,
	konrad.wilk@oracle.com, erpalmer@linux.vnet.ibm.com,
	coxu@redhat.com, keyrings@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-crypto@vger.kernel.org,
	linux-integrity@vger.kernel.org,
	linux-security-module@vger.kernel.org
Subject: Re: [PATCH v4 4/6] KEYS: X.509: Parse Key Usage
Date: Fri, 10 Feb 2023 05:48:18 +0200	[thread overview]
Message-ID: <Y+W+glb35hn9AS7H@kernel.org> (raw)
In-Reply-To: <20230207025958.974056-5-eric.snowberg@oracle.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

  parent reply	other threads:[~2023-02-10  3:48 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-02-07  2:59 [PATCH v4 0/6] Add CA enforcement keyring restrictions Eric Snowberg
2023-02-07  2:59 ` [PATCH v4 1/6] KEYS: Create static version of public_key_verify_signature Eric Snowberg
2023-02-10  3:39   ` Jarkko Sakkinen
2023-02-10 22:38     ` Eric Snowberg
2023-02-07  2:59 ` [PATCH v4 2/6] KEYS: Add missing function documentation Eric Snowberg
2023-02-08 21:48   ` Mimi Zohar
2023-02-10  3:40   ` Jarkko Sakkinen
2023-02-07  2:59 ` [PATCH v4 3/6] KEYS: X.509: Parse Basic Constraints for CA Eric Snowberg
2023-02-08 21:01   ` Mimi Zohar
2023-02-10  3:46   ` Jarkko Sakkinen
2023-02-07  2:59 ` [PATCH v4 4/6] KEYS: X.509: Parse Key Usage Eric Snowberg
2023-02-08 21:02   ` Mimi Zohar
2023-02-10  3:48   ` Jarkko Sakkinen [this message]
2023-02-10 22:39     ` Eric Snowberg
2023-02-07  2:59 ` [PATCH v4 5/6] KEYS: CA link restriction Eric Snowberg
2023-02-09  2:55   ` Mimi Zohar
2023-02-07  2:59 ` [PATCH v4 6/6] integrity: machine keyring CA configuration Eric Snowberg
2023-02-10 13:05   ` Mimi Zohar
2023-02-10 22:42     ` Eric Snowberg
2023-02-13  7:54     ` Jarkko Sakkinen
2023-02-14 21:24       ` Eric Snowberg
2023-02-08 12:38 ` [PATCH v4 0/6] Add CA enforcement keyring restrictions Mimi Zohar
2023-02-08 23:26   ` Eric Snowberg
2023-02-09  2:54     ` 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=Y+W+glb35hn9AS7H@kernel.org \
    --to=jarkko@kernel.org \
    --cc=coxu@redhat.com \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=dmitry.kasatkin@gmail.com \
    --cc=dwmw2@infradead.org \
    --cc=eric.snowberg@oracle.com \
    --cc=erpalmer@linux.vnet.ibm.com \
    --cc=herbert@gondor.apana.org.au \
    --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=paul@paul-moore.com \
    --cc=pvorel@suse.cz \
    --cc=serge@hallyn.com \
    --cc=tadeusz.struk@intel.com \
    --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).