On Wed, 2014-09-10 at 10:14 +0200, Stef Walter wrote: > On 10.09.2014 10:10, Nikos Mavrogiannopoulos wrote: > > On Wed, 2014-09-10 at 10:03 +0200, Stef Walter wrote: > > > >>>> Because such a certificate would be invalid. > >>>> The whole point of attaching certificate extensions outside the > >>>> certificate is exactly because they cannot be replaced in the > >>>> certificate itself due to the signature. > >>> > >>> Why would that matter? The signature in an anchor certificate is not > >>> verified as part of the verification process, and the caller would be > >>> calling for exactly that, a certificate with its extensions overridden > >>> with the local policy. > >> > >> Because trust policy should not only apply to anchor certificates, even > >> though OpenSSL and GnuTLS currently assume that it does. > > > > I'm not sure I quite understand here. We are talking about the p11-kit > > trust module, and as defined now, its trust policy applies to Anchor > > certificates only. > > No it doesn't. p11-kit-trust has trust policy that applies to *any* > certificate. Until now only NSS consumed that additional trust policy.
I'm at this point where I read an anchor certificate, its CKA_PUBLIC_KEY_INFO (to avoid me parsing the certificate), from the trust module. Then I construct a FindObjects query with CKO_X_CERTIFICATE_EXTENSION, and as CKA_CLASS and the provided CKA_PUBLIC_KEY_INFO. What should I expect as an answer? My guess would be that there will always be a stapled extension for an anchor certificate that indicates its purpose (i.e., the ExtendedKeyUsage extension). Is that correct? (I don't get any stapled extension as answer, and I'm wondering whether there is something wrong in my code or the no extensions answer is expected). Is there some easy way to add custom stapled (or attached) extensions in order to test that code? regards, Nikos _______________________________________________ p11-glue mailing list p11-glue@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/p11-glue
