Re: From whence we came...

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

Ted Hardie wrote:
> On Fri, Jan 04, 2002 at 09:34:42AM -0500, Steve Hanna wrote:
> > What applications do you have in mind?
>
> I'm personally interested in the kinds of things the FreeS/WAN folks
> are doing, and I see some application in things like secure MTA-MTA
> communication (particularly in the context of Internet Fax).

For FreeS/WAN and other opportunistic encryption systems, a single
global trusted root may be OK. In fact, any sort of trust model is
OK. You don't care too much whether you have the right person or
who you have to trust to get that person's public key, you just
want to encrypt your traffic. But this isn't true for most systems.

> The basic problem I see, though, is that there is no particular reason
> for an application to believe that a CA should be authoritative for a
> particular host.  If there is a user at a browser being presented with
> a cert signed by Joe's Bait and Tackle CA, that user may realize that
> her or his broker is unlikely to be using JBT as a CA.  A man in the
> middle attack would be thwarted, in other words, only because a user
> had a good sense of who was and wasn't a trustworthy CA.  As others
> have noted, that may or may not be a good assumption about the users.

Actually, users of web browsers rarely examine certificates. This
is OK. They shouldn't need to. That's the job of the browser. If
I have decided to trust JBT as a trust anchor or one of my trust
anchors has decided to delegate full CA authority to JBT, I
shouldn't need to examine the cert that JBT issues.

There is an exception to this. Current browsers will prompt the
user to see if they want to accept an unverifiable certificate.
This is not a very good idea. How is the user going to decide?
Looking at the issuer name (as you suggest) won't help. JBT could
just as easily issue a certificate claiming to be from NYSE to
MyBroker. The user could call MyBroker and verify the certificate
fingerprint, but that's not realistic. Really, they have no
basis on which to decide.

> If I have an application with no user, as you note, some administrator
> must configure a trusted set of CAs, which will eliminate secure
> communication with anyone not using those CAs.  That either
> perpetuates a monopoly/oligopoly, reduces the usefulness of the
> system, or both.  The DNS can give an application some reason to
> believe that a particular key/cert should be authoritative for a
> particular host or service.  (Of course, if the DNS is secured so that
> applications are assured that the data they receive is the data placed
> into the zone by the zone's administrator, that reason to believe
> turns into a trust anchor).

Using DNSSEC for key distribution is certainly *more* likely to
perpetuate a monopoly than using certificates, since DNSSEC requires
a single global trusted root. Many organizations (like Sun) have
set up their own CAs and installed those as their trust anchor.
Server applications are often the first to move over to the new
trust anchor, since they only need to be configured once.

You're concerned about communicating with someone who doesn't have
a certificate from one of your trust anchors. Your trust anchors
can cross-certify with other CAs (companies cross-certifying with
partners and customers, universities cross-certifying with other
universities or with consortia, etc.). These cross-certificates
can be marked to indicate which applications can use them. If you
really want to be able to talk to *anyone*, then you can use a
very promiscuous CA who will certify anyone. You won't get much
security, though.

-Steve