Re: From whence we came...

[Steve Hanna <steve.hanna@sun.com>]

I'm pretty sure that we want certs here, not just keys. Putting keys
in DNS and relying on DNSSEC to authenticate the keys means that
you're tied to the DNSSEC trust model. Top down, single root (per
TLD), single certification policy that may not match an application
or user's needs, etc. Not good!

Of course, using certs brings with it the problem of revocation.
And certs are often big, so retrieving them from DNS is problematic.
Passing the certs in the application protocol (as with TLS) is
certainly the easiest way to handle key distribution. As for
revocation, each cert can indicate how to get revocation
information pertaining to that cert (for X.509 certificates, the
CRL Distribution Point and Authority Information Access extensions
serve this purpose).

I know that certs are complicated. But there are libraries that
handle this stuff now. And I don't want to go back to a single
root model!

-Steve

Paul Hoffman / IMC wrote:
> 
> A few comments on the threads so far.
> 
> Randy: it is hard for those of us who weren't around in the DNSSEC
> discussion of keys and certs to know what it is you want. You said
> (approximately) "this should be being done in the Security Area" and
> "we should wait for the Apps area to tell us they need it". As
> someone who straddles both areas, I can tell you that both
> suggestions can be read as the equivalent of "this will never happen".
> 
> The PKIX WG has done a pretty lousy job of standardizing access to
> certs. We have a bunch of competing methods for cert retrieval, few
> of which are typically implemented in the real world. The dirty
> little secret is that no one likes LDAP; even though it is the
> primary cert retrieval protocol, only a small number of people in the
> PKIX follows the spec.  The Apps area still doesn't understand public
> key cryptography well enough to know whether we want certs or keys,
> and we have gotten almost no help from the Security area other than
> statements like "run it over TLS".
> 
> Everyone: you have to decide whether you want certs or keys. In
> either case, you have to deal with the expected mechanism of trust.
> Without that, you can't design an access protocol because you can't
> tell how many round trips you will need, you can't tell whether the
> user expects to get all her information from one spot or has to find
> multiple certs, and so on. And you have to deal with the extremely
> thorny issue of how the user trusts either a root key or a particular
> key they have been handed.
> 
> Again, going to the security area for this is Very Bad Idea. They
> aren't applications folks, nor do they particularly like applications
> folks.
> 
> --Paul Hoffman, Director
> --Internet Mail Consortium