Defining header for stapled certificate extensions

[Stef Walter]

On 10.09.2014 09:58, Nikos Mavrogiannopoulos wrote:
> On Wed, 2014-09-10 at 09:53 +0200, Stef Walter wrote:
>>>> Obviously not all callers may be willing to change their entire
>>>> implementation around to do this, and might choose an approach which
>>>> ends up at the same result.
>>>
>>> I think API-wise this approach is very cumbersome. After searching the
>>> PKCS #11 module for an issuer certificate, an implementation must start
>>> searching for the overridden extensions, and replace them in the
>>> certificate.
>>>
>>> Why not simplify, and provide a search option for an anchor certificate
>>> that has already its overridden extensions replaced?
>>
>> 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.

NSS and other PKIX verification stacks apply trust policy to
intermediates and endpoint certificates as well, and consume this
intermediate certificate trust policy from the store.

Perhaps this is a feature that GnuTLS does not want to support ... but
even then the API for sharing the trust policy needs to have this
capability.

But if you would like to build such a helper API which munges an anchor
certificate based on its attached certificates, then you can build it on
top of the underlying trust store model.

Cheers,

Stef

-- 

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