Re: [ekmi] Groups - EKMI Implementation and Operations Guidelines (ODT)

[Arshad Noor <arshad.noor@strongauth.com>]

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?
> 
> Regards,
> Tomas
> 
> 
> arshad.noor@strongauth.com skrev:
> 
>> 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).
>>
>> View Document Details:
>> http://www.oasis-open.org/apps/org/workgroup/ekmi-implementation/document.php?document_id=22606 
>>
>>
>> Download Document:  
>> http://www.oasis-open.org/apps/org/workgroup/ekmi-implementation/download.php/22606/EKMI-Implementation-Operations-Guidelines.odt 
>>
>>
>>
>> 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