Defining header for stapled certificate extensions

[Nikos Mavrogiannopoulos]

On Wed, 2014-09-10 at 08:02 +0200, Stef Walter wrote:

> Sure I can do it. There is no list. But I guess we can reference the
> PKIX list, and then note the specific cases where we deviate from
> their behavior.

I'd prefer to restrict the scope. The RFC5280 extension are very
extensive with very different requirements, which may not apply to a
system-wide certificate store. Also, as I user of the trust store, I
don't support all the RFC5280 extensions, and I'd like to know which
extensions to support in order to use the trust store. Otherwise, if I'm
expected to implement every single bit of RFC5280 to support the trust
store, I should give up from now.

> >>> 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 p11-kit trust module is an implementation of the stores discussed in
> the document.

I'm not sure I understand either. The p11-kit trust module is a PKCS #11
module that provides access to trusted certificates, black lists and
extensions right? (a representation of the backend as discussed in
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html )

As far as I understand, you mean that this module can be used with
various back-ends right? I'm not really interested in the various
back-ends feature, I'm merely interested on what policies and features
p11-kit will have if used with the best, the one used in Fedora or
whatever backend. I think this is an important point. If p11-kit is
simply reflecting whatever the backend has, then I actually lose by
using p11-kit rather than using the backend directly.

That is because with p11-kit, I'd have no idea about the policies and
features, meaning more risky usage of it, as it is used without context.
I believe the p11-kit trust module should provide a profile of the
available policies, and features (something like the quote below).

> > E.g.:
> > 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 "example.com". Am I right on the scope?
> 
> Yes, that's correct.
> 
> Although we're not limited to the above modifications to the trusted CA
> list, and such modifications can be made to certificates other than root
> anchor CA's.

So do you mean that the trust store may contain other than root
certificates? That is not mentioned in 
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-pkcs11.html
and neither in
http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-model.html
which only mention Anchors (unless you really mean about the
blacklists).

regards,
Nikos