PKI obstacles

["David L. Wasley" <david.wasley@ucop.edu>]

Here it is June 25 and I failed to respond earlier to your web survey.  I hope it's not to late to offer some ideas.

I'm one of those folks who has been swimming uphill with PKI for years now and I am still a strong believer, although scarred.  Attached is a paper I wrote several years ago on this subject.  Please feel free to use it as you see fit.  Some of the issues have been addressed, at least partially but many remain.

I believe most "barriers" are not in the PKI itself but in the implementation, user interface, and lack of compelling applications.  There are a few technical areas that could help immensely however:

 1. Require all certs to include in the AuthorityInfoAccess (AIA) field, a URI that can be invoked by a relying party to retrieve a copy of -all- authority certs issued to the signer of that certificate.  By -all- I mean not only the CA authority cert containing the public key associated with the signing key that was used but also all cross-certificates naming the same signer - i.e. all certificates that the signer has accepted in which the signer is the Subject.  This requirement must apply to CA certs as well as end-entity certs.

This would allow very straight forward construction of trust paths, even through cross-certification bridges.  (It doesn't address validation of the trust, merely discovery of a possible chain.)  

 2. Require all certs to include in the SubjectInfoAccess (SIA) field, a URI that can be invoked to retrieve additional information about the Subject.  This would alleviate the need to revoke/reissue certs if relevant information changes.

Various types of access could be supported but I'd bet the most common one would be LDAP.  A filter URI could be specified that would retrieve Subject information to the extent that the requested was allowed to get it.

Another (emerging) type would point to an "attribute authority" server that would mediate information release, offer a rich set of interfaces, use any sort of backend DB, etc.

My comments on your survey page were:

 1. There needs to be a recognized "PKI-lite" model that lowers the barrier
 to getting started, e.g. for apps that don't require high assurance (S/MIME)

 2. There needs to be a killer app that is (a) widely available, (b) attractive
 to a wide range of folks, (c) is "user friendly" for non-techies

 3. User management of their certs needs to be much easier: standards are
 needed for smartchip devices (USB dongles primarily) so they are all 'plug n
 play' like disk drives or digital cameras, and support for them needs to be
 in every O/S right out of the box.  Non-technical users can deal with that
 paradigm - it's just like credit cards or ATM cards.


I am -very- anxious to see broad use of PKI for all the reasons we know and love.  I think the criticisms of PKI amount to "it's hard" but then what worthwhile undertaking isn't?

What can I do to help?

FWIW.

	David Wasley
	UC Office of the President

DRAFT-HEPKI-TAG-Browsers-14.pdf