Re: looking for draft volunteers

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

Derek Atkins wrote:
> Steve Hanna <steve.hanna@sun.com> writes:
> > If you're running even a moderately secure PKI, you will not have
> > hundreds of trust anchors. You'll have one trust anchor. That trust
> 
> If you only have one trust anchor, why not make that trust anchor
> DNS?

Any one of these reasons:

1) Because you don't trust the DNS root and want to trust someone
   else.
2) Because different users on your system may have different
   trust anchors. It's hard to run many DNSSEC configurations
   with different trust anchors.
3) Because you want to be able to use the same CA for SSH certs
   and for other applications (like S/MIME email, TLS client or
   server authentication, IKE, etc.).

> The whole point to this exercise was your requirement of having
> multiple, configurable trust anchors.  However, if you want a globally
> useful system, you basically are going to require a hundred global
> trusted anchors.  Look at what Netscape and IE have done.
> Unfortunately, that's exactly what happens when you want a globally
> accessible system.

Who said I want a globally accessible system? There's often a
trade-off between functionality and security. Some people will
want maximum functionality and minimum security. They'll have
a hundred global trust anchors. Other people want maximum security
within a particular community. They'll use one trust anchor that
follows strict procedures, as I described.

> If I can only authenticate the certificate for steve.hanna@sun.com if
> I have the Sun.COM CA cert pre-loaded on my system, I've already lost.
> I've lost because that does not scale.  It doesn't scale because
> tomorrow, when I want to send a message to my.friend@sgi.com, I need
> the sgi.com CA cert, and you need the MIT.EDU CA Cert to send back
> to me.  And we've now reverted back to hundreds of CAs.

Either you don't understand PKI or you're deliberately confusing the
issue. I'll assume the former. As I described earlier, you would
choose a single trust anchor. If you want to verify my cert (issued
by sun.com), you can find the cert from your trust anchor to sun.com.
Likewise with sgi.com. Yes, there may be hundreds of CAs in some
cases, but each one is trusted only for one part of the namespace.

> > To summarize: If your PKI is any good, you don't need DNSSEC or
> > LDAP over TLS to securely establish a key. If your PKI isn't any
> > good, why bother having one?
> 
> *snicker*   I think you've been in a research lab too long and have
> forgotten what it's like out in the real world.  Unfortunately what
> you consider "any good" is not what is currently deployed.  And if
> someone COULD deploy something that you consider "real good", then
> why couldn't they deploy that _as_ DNSSEC?

Getting personal? Not very professional. If you're satisfied with
lousy security and not interested in how things can be better,
good for you! But don't drag the rest of us down with you.

Sun has deployed a PKIX-compliant CA and issued many certificates.
We sell quite a few products that implement the PKIX standards and
the next version of Java (JDK 1.4) will ship with PKIX-compliant
certificate validation. My group built that library.

Now can you lay off the personal attacks?

-Steve