Defining header for stapled certificate extensions

[Stef Walter]

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.

> Nevertheless, I understand that this API was derived from NSS, and
> that's the way NSS was doing its work. I just realized we can simplify
> much things given the constraints and features of the p11-kit trust
> module.

Yes, this API was designed to address the inherent limitations in the
NSS API and provide something more flexible to model both what it
contained and future trust policy, such as NameConstraints.

Cheers,

Stef

-- 

stef at thewalter.net
http://stef.thewalter.net