Re: gnome-keyring trust assertions

[Stef Walter <stefw collabora co uk>]

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.

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

Perfect. This is exactly the word we need. I've made this change.

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

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

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

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

Thanks for your insight, and taking the time to look it over.

Cheers,

Stef