Defining header for stapled certificate extensions

[Stef Walter]

On 10.09.2014 10:05, Nikos Mavrogiannopoulos wrote:
> On Wed, 2014-09-10 at 09:57 +0200, Stef Walter wrote:
> 
>>>> 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.
>>>
>>> I'd prefer to restrict the scope. The RFC5280 extension are very
>>> extensive with very different requirements, which may not apply to a
>>> system-wide certificate store. Also, as I user of the trust store, I
>>> don't support all the RFC5280 extensions, and I'd like to know which
>>> extensions to support in order to use the trust store. Otherwise, if I'm
>>> expected to implement every single bit of RFC5280 to support the trust
>>> store, I should give up from now.
>>
>> It really isn't that hard.
>>
>> In general you should retrieve extensions from the trust store for the
>> extensions you already process on any certificate.
>>
>> For example if you add support for respecting NameConstraints in a
>> certificate chain, at that point you start retrieving the attached
>> NameConstraints certificate extensions and processing them as if they
>> were on the certificates.
>>
>> If you currently *don't* support NameConstraints then don't bother
>> retrieving them from the trust store.
> 
> The point is, that I want to support whatever the trust store supports,
> and as it is now I have no idea what the trust store supports. You point
> to RFC5280 and say potentially everything, but this is pointless, as the
> trust store doesn't provide the tooling to override any possible
> extension in RFC5280. Are there tools to override extensions in the
> trust store? How do the existing overrides get there?

Currently via .p11-kit format files, and distros have added various
extensions manually that way. But soon the 'trust' tool will have
mechanisms for adding these extensions.

>>> That is because with p11-kit, I'd have no idea about the policies
>> and
>>> features, meaning more risky usage of it, as it is used without
>> context.
>>> I believe the p11-kit trust module should provide a profile of the
>>> available policies, and features (something like the quote below).
>> I can copy and paste the text from RFC5280 if that would make you
>> happy,
>> and note exceptions. In general we support any certificate extension
>> that RFC5280 supports, but our callers may not support them all.
> 
> I believe we are talking past each other. By support, I am not referring
> to a potential future implementation. If today I want to add
> NameConstraints in a CA in the trust store, can I do it with some tools?
> If yes, which tools are they, and which other extensions do they
> support?

At the current time there are several ways attached extensions make it
into the p11-kit-trust stores.

 * Files like OpenSSL 'TRUSTED CERTIFICATE' placed in the store
   attached ExtendedKeyUsage and SubjectKeyIdentifier.

 * Raw .p11-kit files. This was discussed on this mailing list. Now
   that we're exposing the necessary PKCS#11 defines for this the
   format is (must be) stable, and we can document it further [0].

The 'trust' tool is the tool for frobing those extensions by an
administrator is something that was blocked until now. But we should
implement it at this point.

If you're more comfortable waiting until all this is in place, that's
fine too.

Cheers,

Stef

[0]
http://cgit.freedesktop.org/p11-glue/p11-kit/tree/doc/internal/persist-format.txt