FW: SKSML draft

["Roddy, Sue A." <s.roddy@radium.ncsc.mil>]

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 would
cause interoperability nightmares), but can this practice be enforced
another 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 with
classification 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 using
XML-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?), including
potentially 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.