|Subject:||Re: [ekmi] Groups - EKMI Implementation and Operations Guidelines (ODT)|
|From:||Arshad Noor (arsh...@strongauth.com)|
|Date:||Mar 14, 2007 3:08:50 pm|
I don't see why SKMS cannot precede PKI in the Implementation Guide document; they will both be equivalent players in an EKMI, so discussing either first, would be appropriate.
WRT the directory, Tomas, most PKIs that I've been involved with in the past have required publishing certificates to Active Directory or some other form of LDAP - although the last 2 we deployed did not require that. Technically, there is no requirement for it unless the business required it; but if the business did require it, it would be good to discuss it in the guidelines document. Perhaps we should move it to an Appendix as an optional component of a PKI. Any other thoughts on this from others?
I had originally thought that revocation should be discussed as part of 2.6.5 Certificate Validation, but I now realize you're right; it can mean something entirely different (as in validating a certificate path; although I'm not certain our guidelines document will get into that level of detail it would be a good idea to mention it and what it does).
I will add 2.6.6 Certificate Revocation to the TOC.
WRT 3.6.2 Symmetric Key Client Library including XKMS capabilities for enrolling new EKMI clients into the PKI, this is an intriguing idea. I had not thought of it and it does have merit, given that a lot of this technology is migrating to the XML world. But should it be in the "Symmetric" Key Client Library (SKCL) or should we be calling an "EKMI" Client Library (ECL) and include SKCL and XKMS as two (initial) components of the ECL? I'm starting to like the idea of an EKMI Client Library to go with the concept of an EKMI.
Arshad Noor StrongAuth, Inc.
P.S. I need to study XKMS a little bit before I can say speak intelligently on the subject, since I have not delved into XKMS too deeply. Other than the W3C site with the specification, are there any other documents/presentations that you'd recommend to us for our reading list? Thanks Tomas.
Tomas Gustavsson wrote:
Hi, I'm thinking that we should move chapter 2 (PKI) after chapter 3 (SKMS), since SKMS is the most interesting part we can leave the infrastructure we depend on to the later chapters. You want to read the most interesting parts first right?
The PKI chapter should be kept in the context of PKI, focusing only on the parts that are relevant for EKMI. Is a directory needed for example?
Should there be a chapter 2.6.6 about Revoacation?
For operations with PKI we need to have easy enrollment from the EKMI client. Here we can suggest usage of XKMS I assume, since we are in the XML world now. This may go into 3.6.2 that the client library can have XKMS enrollment cababilities?
Please review for discussion, additions, deletions, etc.
-- Arshad Noor*
The document named EKMI Implementation and Operations Guidelines (ODT) (EKMI-Implementation-Operations-Guidelines.odt) has been submitted by Arshad Noor* to the EKMI SKMS Implementation and Operations Guidelines SC document repository.
Document Description: An editable first DRAFT of the Table of Contents for the Implementation and Operations Guidelines for building Enterprise Key Management Infrastructures (EKMI).
PLEASE NOTE: If the above links do not work for you, your email application may be breaking the link into two pieces. You may be able to copy and paste the entire link address into the address field of your web browser.
-OASIS Open Administration