Re: Global PKI on DNS?

[Keith Moore <moore@cs.utk.edu>]

> On 6/11/02 8:14 PM, "Keith Moore" <moore@cs.utk.edu> wrote:
> > well, all of the above is sort of besides the point, because you really
> > don't need to use DNS to return certs
> 
> You don't _need_ to use the Internet, postal mail still works.  Of course,
> there may be efficiencies if you use an existing systems.

and (as in the case of using postal mail, or DNS, to obtain certs) there 
may be inefficiencies with using an existing system if that system is not 
well-suited to the task at hand.

> >  (and there are a lot of problems
> > with doing so)
> 
> OK, I'll bite.  What are those problems?

where to start?  okay, first the fact that DNS RRs aren't very extensible,
so if you want to cram something new that doesn't quite fit then you have
an upgrade problem.  second, DNS queries don't let you specify any
parameters other than DNS name, class, and a single integer query type,
which isn't exactly a good fit for "find me a cert that is signed
by one of the N CAs that I trust, and which has these properties and/or 
does not impose these constraints".

in other words, I don't buy the idea that you can make one kind of cert
fit all or even most applications - if you think about it when you certify 
a name-principal binding (or when you decide to trust one) then you quite 
naturally want to impose some contraints on that trust.  e.g. a credit
card is a kind of cert, but it has a credit limit, a required verification
procedure, there are constraints on who can get money from them (and
their liabilities), etc.  they don't suffice for ID in general.
neither does my social security card, for different reasons.
even my driver's license doesn't suffice for ID for all purposes,
and my passport doesn't entitle me to drive.

> > you still get to leverage DNS if you simply define a way
> > to use DNS to obtain certs with a different protocol (say, using SRV
> > records).
> 
> Of course, but then you have to do all the cache handling yourself.  

you pretty much need to do that anyway, because you typically want to
cache things on a per-application basis - or to put it another way,
the only way you can make use of certs that you get from DNS is 
in conjunction with some additional configuration information
(like which CAs you trust, and for what purposes), which is application-
specific and which you have to "cache" anyway.  Then again your cache
also needs to be sensitive not only to things that DNS returns like
TTLs but also expiration dates in certs.  Note that DNS TTLs aren't 
particularly good for certs that expire at a fixed date - you 
have to kludge them to get them to drop down to zero as that date 
approaches.

> On the
> serving side, you also have to come up with a way of doing redundancy and
> reliability.

DNS might be redundant, but I wouldn't want to emulate its reliability
record, or its performance.  I've seen too many DNS queries take longer 
than 30 seconds, too many servers providing obsolete information 
(probably because the zone was updated without incrementing the serial 
number, but sometimes because one server or another moved and they
didn't get the configuration adjusted correctly).

> But hey, coming up with new protocols that do the same thing as old
> protocols is fun, so why not?

it's almost as fun as trying to get old protocols to do things that
they were never designed (and aren't well-suited) to do!

Keith