Defining header for stapled certificate extensions

Nikos Mavrogiannopoulos nmav at redhat.com
Tue Sep 9 04:17:40 PDT 2014


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. 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. 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.

> 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?

> 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.

> > 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).

regards,
Nikos




More information about the p11-glue mailing list