Re: gnome-keyring trust assertions

[Yaron Sheffer <yaronf gmx com>]

Hi Stef,

please see my responses inline.

Thanks,
    Yaron

On 12/13/2010 07:07 PM, Stef Walter wrote:
> On 2010-12-12 12:46, Yaron Sheffer wrote:
> > But we can trust other credential types
> > to identify trustworthy objects. For example in IPsec I can have a
> > shared secret which is shared with server S, and identifies it just as
> > strongly as a cert. So ontology aside, we need to have trust assertions
> > for non-certificate secrets as well.
> That's very true. However I'm a big proponent of not spec'ing something
> which is not yet implemented anywhere. So I've added a paragraph to the
> spec saying that "...future versions of the specification may specify
> trust assertions for these other subjects".
>
> However if this is research you would like to do and there's an
> implementation and specific use cases you have in mind, I'd love to work
> together on this and broaden the specification to cover these
> non-certificate secrets.
No. While I can *imagine* how this would be used, I don't have a 
concrete use case.
> [snip]
> > - You might have negative assertions that are the result of OCSP lookup.
> > Those would not have an actual CRL associated with them. Or a user might
> > have manually entered such an assertion ("distrust by rumor").
> 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.
> > - Extended Key Usage: this field is central to the spec. I have been
> > unable to locate a reference to the semantics of its different values,
> > and I strongly suspect many of them are obsolete/unused. OTOH, RFC 4334
> > extends the older definition with new values. Ditto RFC 5924. Moreover,
> > if this spec is to be extensible, it had better point out how new values
> > can be specified for this field. As well as the expected behavior when
> > an application encounters a new/unknown value.
> Interesting. Yes, the purpose field is very definitely open ended. I
> guess we should make this more clear. Maybe we should drop the IPsec
> ones, and make it clearer that the purpose is open ended? Does that
> sound good?
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:

All values of the ExtendedKeyUsage certificate attribute are valid for 
this field, including current and future extensions to RFC 5280. 
Applications should ignore trust assertions whose Purpose field they do 
not understand. They should NOT treat them as negative assertions.

[Also note that a cert may have multiple EKU values, which I suppose 
translate into multiple trust assertions.]
> > - Which leads me to suggest that you post this spec to the PKIX mailing
> > list (after all, you are proposing to store their "stuff") for comments.
> I'm interested in sending this to the cryptoki mailing list shortly, but
> the PKIX group would also be a good place.
>
> > - Please say explicitly that anchored trust for a CA cert is inherited
> > by all EE certs that are "below" that cert. Also, I *think* you ignore
> > anchored trust assertions for intermediate CAs in a chain. Please
> > clarify this point.
> I'd like to stay away from specifying as little as possible of the other
> PKIX RFC's in here. Which part of the spec contained the inaccuracy? If
> at all possible I'd like to rephrase things (perhaps with relevant links
> to other RFCs) so that we do not outline things like this except for by
> example.
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.

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."
> > - The algorithm for validating a chain's trust does not seem to cover
> > the case where there are multiple chains. Even if the answer is: "we
> > pick one of them arbitrarily", we should say so.
> Interesting point. And good to think about more... What happens when
> there is a anchored trust assertions to an expired version of a
> certificate, and an anchored trust assertion to more current certificate
> (with the same issuer).
I'm afraid we should be aligned with 
http://tools.ietf.org/html/rfc5280#section-6 (probably ignoring much of 
their "policy" stuff).
> Thanks for your insight, and taking the time to look it over.
>
> Cheers,
>
> Stef