Subject: Re: Software for PKI

From: [email-masked]
Date: Wed, 7 Nov 2001 20:21:31 -0700

The scenerio probosed for improving the integrity of the domain name
infrastructure for CAs is to have person registering his domain name, also
register his public key along with his domain name in the domain name
registery. One of the insecurities of the domain name system .... happens
to be domain name hijacking ... somebody impersonating the domain name
owner (with domain name hijack) getting a certificate issued to him for
that domain name (somewhat the same way that somebody got Verisign to issue
them a microsoft certificate). They now have a certificate from verisign
for that domain name. So registering the public key is the solution to
domain name infrastructure integrity so that the CAs can have better
confidence (including verisign) that they are truely dealing with the
person that registered the domain name.

Ok, however, if there is a public key registered with the domain name
infrastructure (as part of improving the integrity of the domain name
infrastructure on behalf of the TTP CAs) .... then the domain name
infrastructure could include the public key as part of the domain name
record.

Now the original purpose of certificates were the offline world .... the
early 80s where somebody called up, downloaded their email and hung up. Now
that they are no longer online ... they can not directly contact the
authoritative agency for the information directly and so needed a
substitute. Now these things called certificates effectively contained a
copy of the information kept by the authoritative agency ... these
certificates were manufactored at some time in the past and the information
by now could be quite stale. However, given the design point for
certificates of an offline world, with no authoritative information at all;
then a stale certificate was slightly better than now information at all.

Now the interesting part is that if the domain name infrastructure
registers the public key for the domain name owner .... and I was
interested in timely information .... which would i prefer 1) some piece of
stale data manufactored at some time way in the past that is the copy of
the information at the authoritative agency (based on the original design
point of a totally offline world)  or 2) the near real-time information
directly from the authoritative agency in an online world (especially
considering that the certificate is effectively only a stale copy of that
information from the authoritative agency design to address a problem of
the offline world and unable to contact the authoritative agency directly).

Now the interesting thing for SSL .... is if the TTP CAs fix the domain
name integrity issue for their own purpose with the registering of the
public key .... the existing domain name infrastructure can serve up the
real-time version of that registered information (public key) in the same
transaction that the ip-address is served up. Given a choice of an old
stale, R/O copy of the authoritative agency information .... getting the
currect up-to-date information seems a whole lot more interesting (and also
as a side-point was actually designed for an online world rather than the
certificate copy design point for the offline world). The other interesting
part is that the SSL setup handshacking chatter gets drastically simplified
.... all the client does is get the authoritative copy of the public key at
the same time it gets the domain name lookup. Huge amounts of SSL setup
chatter & noise goes away.

Now have an implementation that was actually designed for an online world
.... not the certificate stale copies that were designed for the offline
world; also since it is real-time, online ... there is no more of this
horrendously complex stuff about PKIs .... not more worry about things like
CRLs. These are the exact analogies to the credit-card paper booklets that
addressed the offline credit card credential world of the first half of the
last century .... every month send  out a paper-booklet to everybody of the
revoked credit card numbers. The problem was the same issue that PKI is
attempting to address .... credentials issued at some time in the past for
the offline world ...... and how to try and manage the updating of stale
information for an offline world.

Of course, in the 2nd half of the last century ... it appeared that the
world started going online ... and a large part of the target market for
certificates, CRLs, PKIs, is now having a harder time finding a niche.  If
I'm dealing with totally inconsequencial information of now value ... that
I problem am now as concerned about whether or not I may be dealing with
offline year-old stale copy of some information as opposed to a online
transaction directly with the authoritative agency for the information to
get the current, non-stale version.

random refs and more detail:
http://www.garlic.com/~lynn/subtopic.html#sslcerts

Eric Rescorla <[email-masked]> at 11/07/2001 5:03 PM wrote

Of course, it's possible that some CAs (even Verisign, perhaps) gets
the information from DNS but those CAs have insecure policies.
Discovering that they did so wouldn't invalidate the purpose of
SSL certificates any more than it would be invalidated by discovering
that Verisign left it's private key lying around. You'd just want
to stop trusting said CA.

-Ekr

--
[Eric Rescorla                                   [email-masked]]
                http://www.rtfm.com/

---

From: Eric Rescorla <[email-masked]>
Date: 07 Nov 2001 20:34:12 -0800

> infrastructure could include the public key as part of the domain name
Yes, this would certainly be possible. If we had SecureDNS a lot
of life would be simpler. But we don't and so we're stuck with
what we've currently got.

There are really two issues with DNS security:
(1) The security of DNS itself.
(2) The security of the database from which the DNS records are
derived.

SSL certificates are (or at least should be) derived directly
from the database so the security of DNS is irrelevant (that's what
I took your previous comment to be about).

The security of the database is fundamentally a non-technical problem
and I don't believe that putting public keys in the DB will help. It
will always be possible for someone to socially engineer the DB
maintainers into contaminating the database. The defense against
that (to the extent there is one) is good administrative policies.

-Ekr