Dave, My understanding of XKMS/XKRSS is in fact to provide life cycle management. The folks in Project DPLOY want to provide further PKI-related functionality to VPN boxes, so that VPN boxes have a uniform interface to PKI-management and certain functions could be automated (e.g. automatic cert renewal). http://www.projectdploy.com/ XKRSS would definitely be a big piece of this scenario. The only way to get a unified response from the PKI-industry is to use XKMS, regardless of what technology type lies behind it. cheers, thomas ------ ------------------------------ Thomas Hardjono Principal Scientist CTO office VeriSign 401 Edgewater Place, Suite 280 Wakefield, MA 01880 Tel: 781-245-6996x231 Fax: 781-245-6006 Email: thardjono@verisign.com ------------------------------ At 4/29/2002||02:50 PM, Dave Remy wrote: >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. 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. > > > >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.comReceived on Wednesday, 1 May 2002 14:53:39 GMT
This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 20 September 2007 14:30:51 GMT