Re: looking for draft volunteers

[Derek Atkins <warlord@MIT.EDU>]

Steve Hanna <steve.hanna@sun.com> writes:

> 2) Because different users on your system may have different
>    trust anchors. It's hard to run many DNSSEC configurations
>    with different trust anchors.

Ok, these users now cannot talk to each other.  Great.  Segmented
communities.  That's a way for global communication.

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

And I'd love to use one piece of plastic for my driver's license and
all my credit cards, too.  It's not a perfect world.  Also, as has
been pointed out, SSH doesn't do certificates.  Sure, there is room
the spec, but for all practical purposes nobody uses them.

> Who said I want a globally accessible system? There's often a

If you don't want a global system then you're not helping here.  The
proponents here want a global system.  I want to be able to contact
randomly ANY host on the internet and have a reasonable chance of
getting a reasonable key to use with that system.  Is this "perfect
security"?  No, of course not, but quite honestly it's the best anyone
can do with the requirements of "any to any".

> 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 you're going to do this in a small closed group then why do you
care about any kind of interoperability?  Why do you even need to use
DNS?  Why not use manually distributed hosts.txt files andkey rings?

The whole point of this efforst is to make globally-accessible keys.

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

I both understand PKI and I am NOT confusing the issue.  I'm pointing
out how current PKI works.  Perhaps by my using fake names you are
being confused?  Ok, let me use some real names.

Look at, say, the Verisign root certificate.  There is nothing in that
certificate that claims what subdomains it can sign.  There is nothing
that says that the Verisign root can sign for Sun.COM but the Thawte
root cannot.  That's my point.

When Verisign issues a certificate to Sun.COM, it can certainly put in
the certificate that Sun.COM can only sign for subdomains of Sun.COM,
but if I go to Verisign and get them to give me a Sun.COM certificate
(perhaps I forge some Sun stationary and send them a letter?) how is
some user on the net supposed to know whether to use the Verisign or
Thawte Sun.COM certificate?

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

No, just pointing out that, having been in research, many research
topics don't work in the real world.  For example, there are a number
of cryptographic protocols that are 100% provably secure up to some
amount of work.  However, none of them are reasonable to use.

One, in particular, winds up sending out N bits for every 1 bit you
want to send, where N is your security factor.  Meaning if you want
1024-bits of security, you need to increase your message size by three
orders of magnitude.

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

Who signs the Sun.COM certificate?  If nobody, then how can I be sure
that I've got the right one?  Moreover, if it's not signed by a higher
party, that doesn't scale (see my example in previous email).

If it _is_ signed, what's to stop me from going to a different root
and social engineering them into giving me an alternative Sun.COM
certificate?  Again, see my previous example.

> -Steve

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       warlord@MIT.EDU                        PGP key available