Re: From whence we came...

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

Greg Hudson wrote:
> If the requirement for preconfigured root CAs bothers you, then you
> shouldn't like the DNS solution either, since it requires every
> recursive resolver to know the public key of the DNS root.

The requirement for a single global trusted root does bother me.
That's why I would rather use a PKI, where the user can configure
their own set of trust anchors. Most users will be happy with
whatever ships with the browser, but people who care can always
change it. And administrators who care can change the defaults
in the configuration files they distribute with the browser.

> It is very easy to argue that PKI, in its current incarnation, is not
> practical beyond use by web sites belonging to companies with large
> budgets. "Every certificate generates $500 in revenue to Verisign"
> is not what some of us call practical.

But that's not a limitation of PKI. It's just a reflection of the
fact that Verisign is the most widely recognized root CA.

If you don't like having to use a single trusted root, then DON'T
design your system around DNSSEC. Design it to support multiple
certificate types: PKIX, PGP, or whatever. This maximizes the user's
flexibility. The math department can set up their own CA using one of
the freely available packages and trust that or use the university's
CA or outsource the CA function or just trust the roots that are built
into their software or add their friends to their PGP keyring and use
the web of trust.

A few comments on your description of how a PKIX-based design for SSH
might work. Basically, I think it's right on. But I have a few nits.

>   * Everyone trusts and knows the public key of some number of
>     well-known PKIX roots.

There's no need for everyone to share the same trusted anchor. People
at MIT can have the MIT CA as their trusted anchor and people at
Berkeley can have the Berkeley CA as their trusted anchor (and/or the
Slashdot CA or whatever). As long as you can build and verify a chain
of certs from one of your trust anchors to the other party, their
cert is OK with you. Consortia will often serve as a bridge or trust
anchor (Internet2 for education, for instance). And well-known roots
will continue to serve those who aren't too worried about security.

>   * The ssh protocol would be modified so that a host can present a
>     certificate instead of just a public key.

It would be best if, like TLS, each host could indicate to the other
who it trusts. Then the other party can provide a certificate chain
from one of those trust anchors.

But, as you said, your description was simplified.

-Steve