Re: [ekmi] FW: SKSML draft

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

Absolutely great questions, Sandi.   I do have answers for
all of them, but am going to respond to them on the SKSML
Sub-Committee alias to keep the protocol discussion
within the group of people who expressed an interest in the
protocol details.

Others who are interested in tracking this thread should
join the SC alias through the OASIS site.  Thanks.

Arshad Noor
StrongAuth, Inc.

----- Original Message -----
From: "Roddy, Sue A." <s.roddy@radium.ncsc.mil>
Date: Tuesday, July 3, 2007 4:03 am
Subject: [ekmi] FW: SKSML draft

> Some comments on the SKSML draft.
> 
> Sandi Roddy
> I5 Technical Leader for IA Infrastructure Transformation
> National Security Agency
> 
> EKMICoreLibrary.xsd:
> 1.
> The gkid element:
> Comment a:
> The current naming scheme (gkid) doesn't seem to easily allow for
> interoperability (sharing symmetric keys) between multiple enterprises
> & their clients.  There would easily be collisions where multiple
> enterprises use the same gkid for their own, different symmetric keys.
> Has  true global collision-free naming scheme been considered to
> identify symmetric keys so that the keys can be shared between
> enterprises?  This same concern also applies to the sharing of the key
> policy
> information.
> 
> Comment b:
> Has the group considered multiple "editions" of the symmetric key 
> to ease
> rollover to the next key?  For example, users of the same
> symmetric key "5-9" might roll to a new key once a week.  Could the
> first week's key be called "5-9-1", second week's key "5-9-2", etc.
> 
> 2.
> The algorithm element:
> If I'm reading the XML Schema correctly the choices for the symmetric
> key's algorithm seem to be limited to the ones explicitly defined 
> in the xsd
> file
> (3DES-CBC, AES128-CBC, AES192-CBC, AES256-CBC).  I can think of others
> that would be nice to list (AES Key Wrap of various bit lengths, HMAC
> with various hash algorithms, AES operating in other modes).  But, in
> general, there needs to be
> flexibility for organizations to use this schema to distribute
> symmetric keys for *any* algorithm.  I do agree that it would be great
> if the organizations all refer to the same URIs for the same
> algorithms, rather than making up their own algorithm URIs (which 
> wouldcause interoperability nightmares), but can this practice be 
> enforcedanother way?
> 
> 3.
> The keysize element:
> Is it necessary to have a keysize element if the algorithm implies 
> the key
> size?
> 
> 4.
> The duration element:
> Is this duration timed from when the key is first generated by the
> server or from when the client receives it?
> 
> 5. 
> Organizations may want the flexibility to add additional elements
> to describe the properties of a symmetric key.  Does the schema allow
> for custom elements/extensions?  One example of another desirable
> element would be "key usage", indicating whether the symmetric key is
> to be used as a key encryption key (key wrapping), traffic / data
> encryption, integrity protection, etc., (though the algorithm choice
> might imply these), or perhaps even indicating the specific types of
> applications the key is for use in (examples: encrypting an IPSec 
> tunnel,encrypting documents, encrypting blocks on a hard drive,
> integrity-protecting a document, etc.)
> 
> In the government sector we would want to label the symmetric keys 
> withclassification labels indicating up to what level of data the 
> key can be
> used to protect (and what level the key itself needs to be 
> protected to).  
> 
> 
> General comments:
> 6.
> Has there been consideration of specific mechanisms to be used for
> encrypting the symmetric key & its properties (ie: key wrapping 
> with a
> key encryption key, asymmetrically encrypting with the key consumer's
> public key, etc.) or are all of the options of XML-Encryption open for
> use?  It would be good to force the symmetric key, in transmission 
> usingXML-Encryption, to be protected by an algorithm & bit size of 
> equal or
> greater strength of the key being transported.
> 
> 7.
> How much work has gone into access control for determining which
> clients can access which symmetric keys, as well as how to identify
> the consumers (ie: using X.509 certificates? SAML assertions?), 
> includingpotentially allowing clients from other enterprises to 
> request keys,
> or passing symmetric keys between enterprise systems run by different
> organizations.
> 
> 8.
> Has there been consideration of a need to sometimes supply symmetric
> keys to disconnected devices?  An intermediary with network access
> would pick up the key from the key management server, then supply
> it to the disconnected device physically or via an isolated network.
> The symmetric key would perhaps be encrypted for the final destination
> but carried by the intermediary.
> 
>