On 10.09.2014 09:43, Nikos Mavrogiannopoulos wrote: > 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.
It really isn't that hard. In general you should retrieve extensions from the trust store for the extensions you already process on any certificate. For example if you add support for respecting NameConstraints in a certificate chain, at that point you start retrieving the attached NameConstraints certificate extensions and processing them as if they were on the certificates. If you currently *don't* support NameConstraints then don't bother retrieving them from the trust store. Or, put another way, if you already support *all* the RFC5280 extensions in certificates, then retrieve them all the RFC5280 attached extensions from the trust store. >>>>> 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 > ) Yes. > As far as I understand, you mean that this module can be used with > various back-ends right? No. > 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. p11-kit-trust is the "backend" and exposes its trust stores for callers to consume. These stores are populated from files on disk. As a compatibility measure, p11-kit-trust *also* exposes an NSS API for NSS to consume. You can see this in pkcs11x.h. As far as I am aware NSS has never documented this API. If you feel uncomfortable using the actual real trust store backend, you might choose to use this more predigested data. You can see the PKCs#11 NSS API here: http://cgit.freedesktop.org/p11-glue/p11-kit/tree/common/pkcs11x.h#n48 And you can see some rough documentation I put together here: http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-existing.html#nss-trust-objects > 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). I can copy and paste the text from RFC5280 if that would make you happy, and note exceptions. In general we support any certificate extension that RFC5280 supports, but our callers may not support them all. >>> 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 Yes, any extension can be added/overridden on any certificate. That's the goal of attaching certificate extensions. Cheers, Stef -- s...@thewalter.net http://stef.thewalter.net _______________________________________________ p11-glue mailing list p11-glue@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/p11-glue
