Re: Where does XKRSS fit in?

And just to prove the unification theory aspect of Thomas' message:

Thomas Hardjono wrote:
> 
> 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.

That's right. XKMS is afaik the only registration-capable scheme
supported by all the pki vendors and with none against.

Stephen.

> 
> 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.com

-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

Received on Thursday, 2 May 2002 06:54:27 UTC