Where does XKRSS fit in?

Attending the F2F and PKI Workshop last week was enlightening.  I realize I
did not have the best grasp of the goals of XKMS.  I just read the XKMS
mission and see that the emphasis is on allowing "a simple client to obtain
key information (values, certificates, management or trust data) from a web
service."  There was emphasis by different individuals on aspects of this
such as offloading the trust decision to a trusted server (like in 4 corner
model), abstracting a non X509 PKI (like XRML), and not requiring clients to
have to understand ASN.1/X.509 (XML as the new 'esperanto') .  But everyone
seemed pretty consistent about emphasizing the XKISS side of the spec.
 
That's all great and represents an interesting problem but I'm not sure how
the XKRSS part of the spec fits in.  Registering keys, generating keys on
the server, reissuing keys, recovering keys seem to lead down the
certificate life cycle management path, the terrain of certificate
management systems.  From my perspective, it would be very interesting to
have a standard XML, SOAP based API/protocol to full certificate life cycle
management functionality.  For example, GeoTrust offers a managed service
PKI.  As things are now if a customer implements our PKI there are
proprietary access mechanisms to do things like verify identity of an
employee, publish a certificate, or revoke a certificate.  Our customers get
tied into our PKI.  I think the same is true of other CMS implementations
either packaged or managed service based.  It seems like a worthy goal
(although I assume out of scope of XKMS) to standardize this interface so
that customers could move between CMS/PKI implementations based on their
business need.  For example, they could move easily between say a GeoTrust
implementation to an inhouse Entrust implementation or vice versa.
 
I have to admit (pre-F2F) I was thinking the goal of XKMS was essentially a
web service interface to Public Key *Infrastructure* (managing keys).
However, the goal actually seems to be looking up keys (and helping with
trust decisions).  Am I getting this wrong?
 
 
 
________________________________
Dave Remy
GeoTrust, Inc., Co-Founder
Chief Software Architect
phone:  503.657.3324
email: daver@geotrust.com