Subject: Re: Software for PKI

From: Rich Salz <[email-masked]>
Date: Thu, 08 Nov 2001 10:05:28 -0500

> Adding keys and distributing them within the domain name infrastructure, in
> effect, is already supported (mechanically), since DNS already supports
> that for arbritrary information.

Do you know about DNSSEC, it's support in BIND, etc?
	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

---

From: [email-masked]
Date: Thu, 8 Nov 2001 07:50:09 -0700

A "master-database" for the domain name infrastructure is a common
integrity problem for both DNS and TTPs ... since that is where all the
information about domain name registration resides (both TTPs and DNS are
dependant on it). In effect that is the basis of the authoritative agency
that TTPs have to use to validate requests for SSL certificates. Until that
problem is fixed for domain name infrastructure .... then it continues to
be a compromise for the TTPs that wish to validate requests for SSL domain
name certifictes (since that is where they validate the request). Going to
public key registration along with domains ... is in fact almost identical
to the RA (registration authority) phase of a TTP. Even TTPs are putting
the keys someplace. Then going to signed transactions eliminates many of
the things like social engineering. However, the primary point is that if
that isn't fixed .... then it is an exposure to not only all of the domain
name infrastructure ... but also all the TTP CAs that have to check with
the domain name infrastructure as to the validity of a SSL domain name
certificate request.

If you want to talk about chain of trust ... then the root for SSL domain
name certificates start with those databases ... since they are the
authoritative databases for validating a SSL domain name certificate
request. In effect a CA ... certification authority ... is "certifying"
some piece of information as part of manufactoring a certificate. A CA's
certifying domain name information for a SSL domain name certificate
request consists of checking/validating with the authoritative agency
responsible for the information that is being certified. If that
authoritative agency has integrity issues, then the validating/checking has
intetrity issues, then the certification has integrity issues .... and we
aren't even to the point of actually manufactoring the certificate.

The database(s) have to be armored and the procedures fixed .... and at
least one of the proposals (on behalf of TTP trusted operation, if nothing
else) is to institute public key registration and public key signed
transactions to help address the integrity issue (which has to be fixed for
the TTP CAs ... if nobody else). Note that since the signed transactions go
directly to the authoritative agency that has registered the keys .... the
associated signed transactions don't require that certificates be appended
to such transactions .... since the authoritative agency already has the
public keys and all the information contained in any such certificate
(making the appending of certificates to such transactions, redundant,
superfulous, and unnecessary).

The remaining issue is the real live operation. The current certificate
world isn't a real PKI ... it is simply certificate manufactoring. It
doesn't actual provide infrastructure management of distributed information
(something that DNS already supports). The issue then is how hard is it to
add incremental integrity to all (or at least some) DNS transactions. That
is compared against adding all the stuff to the current certificate
infrastructure for a real-live PKI ..... say for instance, things like
guarenteed delivery and receipt of CRL to every entity on the face of the
earth that might be faced with relying on a certificate. For instance, my
understanding that after the Verisign issuing the Microsoft certificate,
Microsoft is distributing software updates to all clients in the world that
has special code specific for recognizing the invalid certificates.

[email-masked] at 11/7/2001 9:34 pm wrote

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