Re: gnome-keyring trust assertions

[Stef Walter <stefw collabora co uk>]

On 2010-12-14 01:01, Yaron Sheffer wrote:
> On 12/13/2010 07:07 PM, Stef Walter wrote:
>> Yes that's true, there can certainly be other sources of negative trust
>> assertions. Where in the specification did it limit negative trust
>> assertions to CRLs? Let's fix that spot.
>>
> It doesn't. I guess what I was looking for is a "reason" attribute:
> {in_a_crl, ocsp_indication, manual_distrust, other}. And possibly an
> open-ended reason_comment field.

I imagine CKA_LABEL could be used for the open-ended field. I've now
made it clear in the spec that the standard PKCS#11 object attributes
may be present.

Having a reason attribute is a good idea for negative assertions. But
I'm not sure about that the reason should necessarily indicate the
source of the distrust, but rather the reason for the distrust. For
example we might use the reasons from RFC 5280 or OSCP and then add one
or two like 'manual-distrust'.

> Please review http://tools.ietf.org/html/rfc5280#section-4.2.1.12. Based
> on that document, I agree we should remove the IPsec values, and suggest
> we add the following text:

I've removed the IPsec values.

> All values of the ExtendedKeyUsage certificate attribute are valid for
> this field, including current and future extensions to RFC 5280.

In addition any string value is valid. This is in keeping with the
concept that not necessarily all trust assertions (in future versions of
the spec) are about certificates.

> Applications should ignore trust assertions whose Purpose field they do
> not understand. They should NOT treat them as negative assertions.

This is a good clarification. I've added it to the specification.

> [Also note that a cert may have multiple EKU values, which I suppose
> translate into multiple trust assertions.]

Yes, that's correct.

> PKIX cert validation is complex, and I am not an expert. But I'm afraid
> we have to fully specify the cert chain algorithm as you did. So we have
> to cover all corner cases, including expiration etc.

I don't understand why we would need to specify things like expiration.
Aren't they covered by 'Step 5' in the 'Building a Certificate Chain'
section? Could you explain further?

> Regarding Anchored Assertions, I suggest to clarify: "These assertions
> are only evaluated when associated with the root of the constructed
> certificate chain. They are ignored if associated with any intermediate
> certificate in the chain."

I don't think that's the case. An intermediate certificate may be
anchored. See step 3 in 'Building a Certificate Chain'. RFC 5280 allows
for this, as do most PKI implementations.

> I'm afraid we should be aligned with
> http://tools.ietf.org/html/rfc5280#section-6 (probably ignoring much of
> their "policy" stuff).

Good plan. I'll study this further to see what it says when multiple
paths are available.

Cheers,

Stef