Plug-and-Play PKI for Web Services

Dear WS Architects,

As you may know I am currently developing an Internet-Draft called "Plug-and-Play PKI for Web Services", a.k.a. "PnP".
Early version: http://www.x-obi.com/OBI400/draft-rundgren-pkix-pnppki4ws-00.pdf

The primary goal with PnP is to provide an easy (well-defined) way to integrate PKI with typical business systems.

Why Plug-and-Play?
Some people have questioned the need for a plug-and-play scheme.  Based on several years of hands-on experience with these issues, I maintain that linking RFC3280-compliant certificates to existing business systems in a robust, and simple way using shrink-wrapped software is infeasible.   Or to be more precise, RFC3280 "as-is" in this context, creates unmanageable systems disabling most of the potential of PKI.   One should not forget that PKI's main "competitor", shared secrets, are conceptually much simpler, and are generally at least perceived as not requiring "issuers", lawyers, mutually agreed-upon policies etc.

Profiled Versus Self-describing Objects
The only viable solution as I see it (and acknowledged by early reviewers of the draft), is to use strongly profiled certificates like existing web-server dittos.  PnP essentially does this profiling as well, but in an explicit way, vastly simplifying the handling of PnP-enabled certificates by relying party software and trust administrators, while still preserving a wide range of issuing options.   PnP achieves this by making PKI objects to a certain extent self-describing.  As self-describing objects seem to be the norm for related technologies like XML Schemas, MS-COM, Java reflection API, Web Services (WSDL), etc, it is hard to see any justification for PKI being different.

The Challenge
In case you are interested in understanding how business systems (as described in the PnP draft SQL appendix), are to be interfaced with PKI, I suggest that you perform a "virtual design" of the GUI and SQL needed for supporting plain-vanilla RFC3280 certificates.  In particular you should consider the following points:
  a.. RFC3280 does not require unique subject DNs.  How to handle name-clashes? 
  b.. RFC3280 allows a CA to put subject identity information outside of the subject DN.  How do you know where to look? 
  c.. RFC3280 allows a CA-key to be used for entirely different certificates (policies).  How do you separate these given that policy extensions are only optional? 
  d.. RFC3280 allows a CA to only put policy information in EE-certificates.  How are business systems assumed to be handling newly encountered policies? 
  e.. There may be permanent identifiers in EE-certificates.  How do you know, and how do you configure software to handle such identifiers? 
  f.. There may be implicitly shared "name spaces". As the entire concept of name spaces is absent in X.500, how do you know? 
  g.. There are currently no recognized standard certificate policies 
  h.. The GUI support needed for configuring the massive out-of-band information
This is just for Starters
Digging further into these issues you will soon note that the e-business industry as represented by ebXML etc. have not yet begun to address how identity information as expressed in a signer's certificate is supposed to map to the identity information as expressed in signed business messages!  I don't think this issue is even possible to address without having a "smarter", self-describing PKI.

As I do neither claim to have all the answers nor to have all the questions, I hope that some of you may actually want to help making plug-and-play PKI a reality.  It will be fun as well!

Regards
Anders Rundgren
X-OBI
+46 70 - 627 74 37