The summer of PKI love

Anne & Lynn Wheeler lynn at garlic.com
Fri Aug 12 17:09:51 EDT 2005


James A. Donald wrote:
> PKI's deployment to identify ssl servers is near one
> hundred percent.  PKI's deployment to sign and secure
> email, and to identify users, is near zero and seems
> unlikely to change.  PGP has substantially superior
> penetration. 

PKI deployment to authenticate SSL servers almost doesn't exist.

we were called in to work with this small client/server startup that
wanted to do payments on their server ... and had this technology called
SSL. we had to do a lot of laying out the business ground work for the
payment stuff ... and because they wanted to use SSL for pieces of it
and certification authorities issuing digital certificates were involved
... we also had to go audit the major digital certificate issuing
institutions.
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

in the course of doing this ... we coined the term "certificate
manufactoring" to describe what we were finding ... as one way of
differentiating it from the industry accepted definition for PKI.
http://www.garlic.com/~lynn/subpubkey.html#sslcert

another place that it came up ... was that we had a SSL encrypted
session defined between webservers (doing payment transactions) and the
payment gateway. special digital certificates were issued for both the
webservers and the payment gateway as part of initializing the encrypted
tunnel (and we forced the implementation of mutual authentication ...
rather than the simple one-way that was available at the time). At this
point it became readily apparent that the digital certificates part of
all this were redundant and superfluous. All the webservers had the
public key of the payment gateway pre-installed in the webserver ... and
the payment gateway had a separate mechanism (once the encrypted tunnel
was set up) for authenticating the webserver (based on established
payment processing conventions). while there was movement of digital
certificates during the setup of this encrypted tunnel ... it was purely
an artificial artifact of the existing code implementation and didn't
actually serve any other useful purpose.

this then resulted in re-examing the design-point and requirements for
digital certificates, certification authorities, and PKI ... which was
to address an introduction issue where a relying party was facing first
time communication with a total stranger and had no access to any other
means for obtaining information (aka the letters of credit model from
the sailing ship days). In situations where there was an established
relationship between the two parties ... it was fairly trivial to
demonstrate that the digital certificates were redundant and superfluous.

so the original justification for server domain name digital
certificates in SSL was

1) key exchange ... which can be done via other mechanism

2) address perceived integrity issues with the domain name
infrastructure so that the user has some level of confidence that the
server they think they are talking to actually is the server they are
talking to.

basically, the browser checks the typed-in URL against the domain name
in the server's certificate. this originally was specified as happening
at the time the user typed in the URL that initially contacted the
server and the SSL session existed for the complete period that the user
interacted with the server.

however, most servers very quickly discovered that SSL operation cut
their thruput by 80-90 percent and so you found e-commerce servers
moving to straight HTTP w/o SSL for the browsing and shopping experience
and providing a "checkout/pay" button that moved into SSL for actual
payment. As been repeated described before this creates a large
vulnerability in the SSL use for real live environments ... since if a
user was initially interacting with a fraudulent site (because SSL
wasn't used for the original typed in URL) ... when the user got to
clicking on the "checkout/pay" button ... a fraudulent site was more
than likely to specify a URL for which they had a valid server domain
name SSL certificate.

the other issue ... is most of the certification authorities in the
world aren't actually the authoritative agency for the information they
are certifying. the actual trust root for many digital certificates ...
are the authoritative agency that the certification authority has to
check with regarding the validaty of the digital certificate application.

Now, it happens that the authoritative agency for domain name ownership,
is the domain name infrastructure ... the very same domain name
infrastructure that has the integrity concerns giving rise to the
requirement for ssl domain name certificates.

so there has been some proposals for improving the integrity of the
domain name infrastructure ... in part from the certification authority
industry so that the certification authority process can better trust
the information that they are certifying.

Part of this proposal is to have domain name owners register their
public key with the domain name infrastructure. Future communication
between the domain name owner and the domain name infrastructure would
be digitally signed and the domain name infrastructure can verify the
digital signature using the on-file public key (note no digital
certificates required)
http://www.garlic.com/~lynn/subpubkey.html#certless

The other benefit is to the ssl domian name certificatin authority
industry ... they can change an expensive, error-prone, and
time-consuming identification process (matching the identity of the
certificate applicant with the identity of the domain name owner on file
with the domain name infrastructure) into a simpler, less expensive, and
more reliable authentication process (by requiring that certificant
applicants digitally sign their applications and the certification
authority then verify the digital signature by doing a realtime, online
retrieval of the onfile public key).

Of course, this represents a signficant catch22 for the ssl domain name
certification authority industry;

1) if you improve the integrity of the domain name infrastructure it
reduces the requirement for having ssl domain name certificates

2) if the certification authority can base their trust infrastructure on
realtime retrieval of online public keys for authenticating digital
signatures ... it is possible that the rest of the world could also
start doing realtime retrieval of online public keys for authenticating
digital signatures (eliminting the requirement that a webserver needs to
transmit a digital certificate to a relying party in order for them to
verify a digital signature).

One could even imagine an enhanced, optimized hostname->ipaddress
transaction with the domain name infrastructure ... where the ipaddress,
any public key, and other optional information all piggybacked in a
single response. Then the client could do a real, transaction oriented
operation ... they piggyback the encrypted random transaction symmetric
key and the encrypted transaction data in a single transmission (to the
webserver) ... with the webserver being able to do a single transmission
reply. None of the certificate related protocol chatter needs to even
occur ... you have a single round-trip with the domain name
infrastructure (if the information isn't already cached locally) and it
is possible to also have a single tround-trip transmission with the
webserver.

slightly related post in another thread
http://www.garlic.com/~lynn/2005n.html#43 X509 digital certificate for
offline solution
http://www.garlic.com/~lynn/2005n.html#33 X509 digital certificate for
offline solution

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com



More information about the cryptography mailing list