CFP: PKI research workshop

[lynn.wheeler at firstdata.com]

for the most part HTTPS SSL is certificate manufactoring (a term we coined
a couple years ago) .... "infrastructure" typically implies the
administrative and management .... which would require (at a minimum) CRLs
for a certificate-based PKI.

the interesting thing about the use of SSL domain name server certificates
is that they supposedly are addressing an integrity issue in the domain
name infrastructure .... i.e. SSL checks that the domain name listed in the
SSL domain name server certificate is the same as the domain name
clicked/typed in for contacting the server. The issue is that the domain
name could be hijacked and instead of going to the "real" IP-address ....
it gets rerouted to a fraudulent IP-address.

however, if you track back the trust infrastructure for the SSL domain name
server certificate .... the process is somebody applies for a SSL domain
name server certifificate with a certification authority. The standard
operating procedure for certification authorities is that they typically
have to verify the information that they are certifying (in this case
domain name ownership) with the authoritative agency for the information
(in this case the domain name infrastructure). Now since there could be an
integrity problem in the domain name infrastructure with respect to domain
name hijacking ... there in fact could be a domain name hijacking prior to
the application for a certificate .... which results in the issuing of a
valid SSL domain name server certificate to the wrong entity.

One of the suggestions for addressing the domain name infrastructure
integrity issue is for public keys to be registered at the same time as the
domain name .... and then further communication with the domain name
infrastructure be with digitally signed messages ... as part of the process
for thwarting domain name hijacking. Note however, since the domain name
infrastructure is the registration authority for the public key as well as
the relying party receiving the signed messages .... certificates are
redundant, superfulous, and extraneous .... even tho it still could be
considered a (certificate-less) "publick key infrastructure" with
significant administrative and management support.

The other interesting aspect is that the existing domain name
infrastructure is set up for (presumably) trusted, (near) real-time
distribution (and updating) of almost any kind of information; not just the
(nearly) trusted binding of domain name to IP-address. Given that public
keys are also registered with domain names at the same time as domain name
and ip-address .... then a trusted domain name infrastructure could be
relied upon to implement a (certificate-less) near real-time "public key
infrastructure" (with full administrative and management functions already
in existance) .... aka the domain name infrastructure could optionally
distribute public key in the same response that it distributes ip-address
...... eliminating the requirement for a certificate-based PKI for trusted
public key distribution.

This is somewhat a catch-22 .... that one of the solutions to addressing a
basic SSL domain name certificate integrity problem (i.e. a CA has a broken
trust chain if there is an integrity issue with the authoritative agency
responsible for the information that a certification authority must
certificate) could also be the solution eliminating any requirement for SSL
domain name certificates.

As an aside, having the public key at the same time as the ip-address for
setting up the base TCP session could also be used to simplify the normal
SSL session setup (since there is no certificate distribution that has to
occur).

random additional discussion:
http://www.garlic.com/~lynn/subtopic.html#sslcerts

there is also the claim that 99.99999 percent of client authentication in
the internet world today is radius-based; typically userid/password
(although radius supports multiple authentication processes specifiable at
an individual userid/account level). There has been work done on an
authentication process for radius involving digital signature where a
public key is registered in place of a password. This would also represent
a (certificate-less) public key infrastructure with full administrative and
management support.

random raidus discussion
http://www.garlic.com/~lynn/subtopic.html#radius

for pointer to radius standards & documents:
http://www.garlic.com/~lynn/rfcietff.htm

& click on "Term (term->RFC#)

and then click on "RADIUS" in the "Acronym fastpath" section

remote authentication dial in user service (RADIUS )
see also authentication , network access server , network services
3162 2882 2869 2868 2867 2866 2865 2809 2621 2620 2619 2618 2548 2139 2138
2059 2058

also of some interest are the AAA rfcs:
Authentication, Authorization and Accounting
see also accounting , authentication , authorization
3127 2989 2977 2906 2905 2904 2903




perry e. metzger <perry at wasabisystems.com> on 12/26/2001 3:45 pm wrote:

HTTPS SSL does not use PKI. SSL at best has this weird system in which
Verisign has somehow managed to charge web sites a toll for the use of
SSL even though for the most part the certificates assure the users of
nothing whatsoever. (If you don't believe me about the assurance
levels, read a Verisign cert practice statement sometime.)

Of course, client side certificates barely even exist, although people
made substantial preparation for them early on in the history of all
of this.

Were it not for historical accident no one would care about "PKI" in
this context.

> S/MIME use is significant and growing.

I get PGP encrypted mail a few times a week. I've never received a
request from any counterparty to set myself up to receive S/MIME. Your
mileage may vary.

> The financial industry is not looking at offline PKI models in
> general.

When I was still doing security consulting, nearly every firm I worked
for had installed Entrust or something similar -- and none of them
used the systems for anything.

PKI and the Emperor's New Clothes have a bunch in common.

> As for what PKI vendors have been up to, the sucessful ones have been
> supporting private label certification hierarchies from the start.

The PKI vendors are, I think, largely surprised by what has
happened. They were expecting things like lots of mutual
authentication using PKI to be in place, and in fact, there's almost
none in use at all.

I think many of the PKI vendors haven't been doing too well -- some of
them that I used to have dealings with barely exist any longer. The
one business that seems to make money is charging a toll for running
an e-commerce site. I wonder who they might be.

Of course, none of this should be surprising in the least. Commerce
and the PKI model have nearly nothing to do with each other. Some of
us were writing about this years ago.

--
Perry E. Metzger                    perry at wasabisystems.com
--
NetBSD Development, Support & CDs. http://www.wasabisystems.com/



---------------------------------------------------------------------
The SPKI Mailing List
Unsubscribe by sending "unsubscribe spki" to majordomo at wasabisystems.com







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