Defining header for stapled certificate extensions

[Nikos Mavrogiannopoulos]

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