Defining header for stapled certificate extensions

Tue Sep 9 05:12:06 PDT 2014

On 09.09.2014 13:17, Nikos Mavrogiannopoulos wrote:
> On Tue, 2014-09-09 at 12:58 +0200, Stef Walter wrote:
> 
>> (In reply to Nikos Mavrogiannopoulos)
>>> I realized that there is no predefined set of extensions in [0].
>>> Which extensions may be present in a p11-kit trust module, and is
>>> there some way to list them?
>> You can search for all objects with class CKO_X_CERTIFICATE_EXTENSION.
>> For all stapled extensions for a given certificate search for all
>> objects with class CKO_X_CERTIFICATE_EXTENSION *and* the appropriate
>> CKA_PUBLIC_KEY_INFO.
>>> I mean is it only the "Extended Key Usage"
>> No. All manner of stapled certificate extensions are possible. These can
>> be defined as input to the p11-kit-trust module as well.
> 
> I don't think that this is reasonable for an API. An API to be used
> correctly should be specific.

This part [1] of the API is specific to its purpose: To add/override
certificate extensions without including them in the certificate itself,
thereby having an effect on the certificate verification and
chain-building algorithms.

Note that this is rather distinct from the anchor/blacklist parts of the
API.

> Even PKIX defines a small set of possible
> extensions and doesn't let the implementors figure out what could be
> there. Also I think it makes sense to describe the extensions
> required/used today. 

No extensions are required to be present.

> In the future that set can be expanded if needed,
> but there will be no advantage from not describing what is used and
> allowed now.

Indeed, such an addition to the document would be very welcome [2]. It
would appear to me (but please prove me wrong here) that all of the PKIX
certificate extensions are valid.

In general however, the following portion of the document applies:

3.4 snippet
 * Callers which are validating certificate chains should retrieve all
stapled extensions for each certificate in the chain and use those
stapled extensions as if they had been present in the respective
certificate. If a stapled extension has the same extnID value as one
present in the certificate, the stapled certificate extension should be
used instead.

Obviously not all callers may be willing to change their entire
implementation around to do this, and might choose an approach which
ends up at the same result.

That said ... your point about ExtendedKeyUsage stands. See below.

>> For example ca-certificates in Fedora has added a BasicConstraints
>> extension to one of the CA's that was missing it.
> 
> There are two PKIX extensions for the key purpose. The "Extended key
> usage" and key usage. Which one will be used in the trust module?

At its core, the p11-kit reference trust module merely exposes the
stapled certificate extensions that are defined in its store.

When extracting into its compatibility certificate bundles the p11-kit
trust tools use ExtendedKeyUsage (to discover usages), BasicConstraints
(to filter certificate authorities), and SubjectKeyIdentifier (when a
key id is needed for the output format).

>> The format for this was explicitly unstable until now. However now that
>> we're finishing up work on how stapled certificate extensions are done,
>> the file format should be documented.
> 
> I'm not talking so much about the format, as of the intended usage of
> these extensions. As it is now, I have only a limited understanding of
> the intentions (e.g., the basicConstraints is a new thing for me), and I
> don't think a user of this API should be expected to reverse engineer in
> order to figure out what could be there.

See above, the basic intent is to use the extensions that are stapled
first, to override/add to the ones included in the certificate.

But yes, I agree where there are exceptions we should document them well.

>>> that you set (and if yes, which are the available values in it?).
>> As you're aware, inside of an Extended Key Usage, you find OID's for the
>> various usages. The common usages are found here:
>> http://tools.ietf.org/html/rfc5280#page-44
>> There is no definitive set. Enterprises often add their own. For example
>> Microsoft has an broad set of ExtendedKeyUsage OID's they use in their
>> products and certificates.
> 
> Indeed, but as you see their usage is undefined. For example there is
> id-kp-serverAuth which is defined as "TLS WWW server authentication".
> The description indicates a server certificate that uses its key for WWW
> authentication. However, some CAs also use it to mark a CA that will
> issue certificates for WWW authentication. So what is the intended usage
> of that extension in p11-kit trust module? Is it being used to mark CAs
> to issue certificates for WWW authentication, or some other extension
> used for that purpose. That's why I think that any extensions being
> used, they should be described and defined (or at least delegate to a
> more specific document - RFC5280 is notoriously known for leaving things
> undefined).

Yes, it appears we are using ExtendedKeyUsage stapled to a certificate
authority as a way of controlling the usages for which the entire chain
can be used, and not just ExtendedKeyUsage on the endpoint certificate
as previously expected.

This is probably something worth calling out specifically in the
document. If the above behavior is non-standard perhaps we should define
a different OID to use here instead? More discussion here is worthwhile.

But in general I agree about documenting these cases better.

Stef

[1]
 -
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html#concept-stapled
 -
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html#model-stapled
 -
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-pkcs11.html#idm265616376480

[2] http://cgit.freedesktop.org/p11-glue/p11-glue/

-- 

stef at thewalter.net
http://stef.thewalter.net