CDR: Public Key Infrastructure: An Artifact...

[Lynn.Wheeler at firstdata.com]

the current SSL domain name infrastructure supposedly exists because of issues
with trusting the domain name infrastructure ... except the SSL domain name
certificate issuer has to trust the same (untrusted) domain name infrastructure
when issuing a certificate (i.e. the SSL domain name certificate is no better
than the authentication authority that the certificate authority has to rely on
as the final arbitrator of domain name ownership).

one of the integrity issues with the domain name infrastructure ... is that
domain names have been hijacked ... once hijacked ... you can go to certificate
authority and get a certificate with that domain name (and the certificate
authority will check with the domain name system and confirm that the requester
owns the domain name).

for more ... see merchant comfort certificate thread at

http://www.garlic.com/~lynn/aepay4.htm

specific news clipping on hijacking

http://www.garlic.com/~lynn/apay4.htm#dnsinteg1


so, the scenario goes that to fix various exposure & integrity risks to SSL
domain name certificate infrastructure, the domain name infrastructure that the
certification authority relies on needs to have its integrity fixed. the
proposal for fixing the domain name infrastructure (on which the SSL domain name
certificate issuing authority relies on as the authoritative reference for
domain names) is to register public keys at the same time domain names are
registered.

now the interesting catch-22 is that SSL domain name certificates were in part
justified because of weaknesses in the integrity of the domain name
infrastructure ...  however in order to issue those same SSL domain name
certificates, the SSL domain name issuing authority (certificate authority) has
to rely on the same domain name infrastructure (that everybody is being told
that you can't really trust because of integrity problems ... aka everybody
isn't to rely on domain name infrastructure ... because it can't be trusted ...
so buy a SSL domain name certificate .... however the SSL domain name
certificate issuing certification authority is allowed to rely on the same
domain name infrastructure for its authoritative information.

The SSL domain name certificate issuing certification authority just isn't
telling everybody that it has to reference the domain name infrastructure in
order to validate a request for an SSL domain name certificate.

I would call that ironic???

Now for even more ironic. In order to fix various integrity exposures in the SSL
domain name certificate ... integrity exposures in the domain name
infrastructure have to be fixed (i.e. integrity is nominally no stronger than
the weakest link). However, fixing integrity exposures in the domain name
infrastructure (in order to fix various integrity exposures in SSL domain name
certificates) ... can make those certificates superfluous, redundant and
unnecessary.

Now the issue isn't to use either SSL domain name certificates or domain name
infrastructure. Since SSL domain name certificates issuance relies on the domain
name infrastructure for its authoritative information ... then the
infrastructures that the SSL domain name certificates issuance certification
authority relies on has to have its integrity fixed.

Now, I considered this somewhat ironic ... that in order to fix a integrity
dependency that SSL domain name certificate issuance has ... the fix also
eliminates much of the original justification for SSL domain name certificates
(i.e. weaknesses in the domain name infrastructure) as well as making SSL domain
name certificates superfluous and redundant.

SSL domain name certificates provide a binding between public key and domain
name. However, if public keys were registered with domain names in the domain
name infrastructure ... the purpose of which was to fix various integrity
problems in the domain name infrastructure and allow the domain name
infrastructure to be trusted by the SSL domain name certificate issuing
certification authority ... then the integrity of the domain name infrastructure
can be fixed for everybody ... eliminating the purpose of the SSL domain name
certificate (aka integrity problems with the domain name infrastructure).
Furthermore, if public keys were registered with domain names, then the domain
name infrastructure could serve up real-time bindings of public keys and domain
names (as part of the domain name lookup process).

If a SSL protocol ... when it asked the domain name system to resolve a domain
name ... could set a flag and asked that both the resolved domain name and the
registered public key be returned ... the efficiency of the SSL protocol would
be improved.

All in all

1) fixing integrity of domain name infrastructure (so you can trust SSL
certificates) eliminates much of the requirement for SSL certificate (i.e.
needed because of integrity problems in the domain name infrastructure

2) fixing integrity of domain name infrastructure with the registration of
public keys and making that information public as part of standard domain name
infrastructure provides a trusted binding between domain name and public key ...
making the SSL domain name certificate superfluous and redundant.

Now as to the other kind of certificate. My wife and I were hired by a financial
services company in 1994 to work with a small client/server startup on the
peninsula that wanted their server to be able to interface to the financial
transaction infrastructure. One of the things that I eventually specified as
part of that infrastructure was a consumer oriented certificate (along the lines
of BBB, consumer reports, etc). However, the whole thing was in its infancy and
they were having enuf other problems creating infrastructures ... so it has yet
to happen. Two people my wife and I worked with at the startup are referenced in
the following:

http://www.garlic.com/~lynn/aadsmore.htm#dctriv

random other refs:

http://www.garlic.com/~lynn/aadsmore.htm#client3
http://www.garlic.com/~lynn/aadsmore.htm#client4
http://www.garlic.com/~lynn/96.html#32
http://www.garlic.com/~lynn/2000b.html#18
http://www.garlic.com/~lynn/95.html#13