On 09.09.2014 17:46, Nikos Mavrogiannopoulos wrote: > 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.
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. >> 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]. > http://p11-glue.freedesktop.org/doc/storing-trust-policy/storing-trust-pkcs11.html If you click on the 'Home' link or 'Prev' links a few times you end up here: http://p11-glue.freedesktop.org/doc/storing-trust-policy/index.html There's far more about the overview and underlying concepts available. Maybe I should probably restructure things so everything about the "attached" (see other email) certificate extensions is in one place. > So if I understand correctly, only the stapled extension will be used if > it is present. Yes, that's right. >>> 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. > 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. Cheers, Stef _______________________________________________ p11-glue mailing list p11-glue@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/p11-glue
