Defining header for stapled certificate extensions

Nikos Mavrogiannopoulos nmav at
Tue Sep 9 08:46:11 PDT 2014

On Tue, 2014-09-09 at 14:12 +0200, Stef Walter wrote:

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

I cannot do such additions as it seems I had no idea what the current
list has and uses.

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

ok it seems that the URL [0] I was using is pretty old and doesn't have
that text. [0].

So if I understand correctly, only the stapled extension will be used if
it is present.

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

I am a bit confused here. Doesn't the trust module's policy apply to its
store? Or is the store something external to the trust module? I'd
expect for the p11-kit trust module to set requirements that are
relevant to an OS.

The trust module (or its store if you like) allows the following
modifications to the trusted CA list: 
 - Extended Key Usage (allow to modify the purpose of the CA -
email/www/code signing)
 - Basic Constraints (allow to modify the ca status - my understanding
is that this is equivalent to disabling the CA without removing it)
 - Name Constraints (allow to modify the scope of the CA, which domains
it is allowed to sign)

and have some tools for administrators to modify these for the OS
provided trusted certificates. So for example an administrator could set
that the CA certificate "XXX", is allowed to sign certificates only for
the domain "". Am I right on the scope?


More information about the p11-glue mailing list