Re: gnome-keyring trust assertions

[Yaron Sheffer <yaronf gmx com>]

OK, now I've actually read it...

Before listing my comments, I'd like to point out that this 
specification is about security policy. And policy is an old and famous 
rat-hole. Which means that a partial solution is better than debating 
details ad infinitum. With that said, here goes:

- At the highest level, we are proposing to trust the wrong thing. We 
can only trust a certificate to identify (or to name) an object. This 
may be ambiguous, in some cases servers may even share a certificate. 
And then we can trust that object (e.g. a server) to behave well, e.g. 
not to send us malicious code. 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.

- "Distrusted" is probably a better term than "untrusted", since 
"untrusted" can also mean "trust level unknown: we don't know enough 
about it to trust it". "Distrusted" is more explicit.

- 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").

- 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.

- 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.

- 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.

- 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.

Thanks,
    Yaron

On 12/12/2010 04:16 PM, Stef Walter wrote:
> On 2010-12-12 07:49, Yaron Sheffer wrote:
> > I know people hate to discuss terminology, but I cannot resist :-)
> Heh. But this is the right place and time for it :)
>
> > In the IETF PKIX community (e.g. http://tools.ietf.org/html/rfc5934) the
> > term "trust anchor" is used, instead of the unadorned (and highly
> > overloaded, etc.) "trust". So this could be "trust anchor assertions" or
> > "trust anchor properties". And we would need to cringe a little less...
> We could definitely use better terminology. Sadly I don't think "trust
> anchor" is it. "Trust anchor" only describes part of the concept here,
> since trust assertions also represents pinned certificates, and
> untrusted things like certificate revocation lists.
>
> Actually the use of the term "trust assertions" doesn't really worry me
> that much. We define this term as a specific concept, and then use it
> consistently. It's the other uses of the word 'trust' that make me cringe :(
>
> > And regarding the spec: please spell "IPsec" consistently (and this is
> > the common way to spell it).
> Done.
>
> What do you mean by the "IPsec Tunnel"
> > purpose? Shouldn't it be "IPsec Gateway" instead?
> I think the actual term (in RFC 2459, it turns out) is "IPsec Tunnel".
>
> BTW, that is the
> > canonical reference for values of the Extended Key Usage Field? Note
> > that RFC 3280 has been obsoleted by RFC 5280.
> I've updated the various RFC links. Thanks for pointing that out.
>
> Uploaded a new version of the spec [1]. Thanks for taking the time to
> look it over.
>
> Cheers,
>
> Stef
>
> [1] http://people.collabora.co.uk/~stefw/trust-assertions.html