Discussion on comment received on 15-day review of SKSML

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

All,

Many people are probably still on vacation and enjoying the holidays
with their families/loved ones, but I thought that it would be useful
to start the discussion on the comment received from Philip Hoyer on
the 15-day review of SKSML that concluded last week:

http://lists.oasis-open.org/archives/ekmi-comment/200812/msg00000.html

Here are my thoughts (in no particular order of importance):

1) We have not received any objections or concerns with the current
    definition of the SKSML protocol itself;

2) Harmonizing key-management standards are good for the industry and
    for customers; those amongst us at the Key Management Summit held
    in Baltimore in September 2008 heard this very clearly from the
    customers that attended the summit;

3) The IETF key-management effort has always been focused on symmetric
    authentication keys, which is a very different objective than what
    the EKMI TC is focused on.  This was discussed even before the TC
    came into existence:

http://lists.oasis-open.org/archives/oasis-charter-discuss/200611/msg00003.html

    Since it was agreed that there was no overlap between KEYPROV and
    EKMI TC (other than that both groups used symmetric cryptographic
    keys to achieve their different objectives), the OASIS TC was
    allowed to be created.

4) The key-container is an integral part of the SKSML protocol, but
    not the most critical part of the protocol.  The truly critical
    element is the KeyUsePolicy element, since this is what defines
    policy and establishes control.  Without the KUP, there is no
    key-management system;

5) The key-container in SKSML is tied to the use of XML Encryption
    and X509 digital certificates for transporting the key; this not
    only provides us the transport security, but also ties it to the
    authentication credential of the client (also an X509 digital
    certificate).  Without having studied the KEYPROV protocol, I am
    not certain what additional benefits SKSML will gain by allowing
    for different key-containers to carry the key.  At a minimum, it
    will require studying the impact on the security and assumptions
    we need to make about the requesting client;

6) We are at the point of only voting on a Committee Specification,
    not an OASIS standard.  The next 3-6 months will be spent in
    creating implementations to validate our choices and learn from
    the experience before voting on the standard.

I would recommend that, given the effort we have put in over the
last two years, we continue with making the current spec a Committee
Specification to validate our work through implementations.  At the
same time, I also recommend that one or more TC members engage in
discussions with Philip to understand the details and implications
of his suggestion.  The engaging-member(s) can then report back to
the TC with an analysis on what impact this suggestion has on SKSML
and his/her/their recommendation.  The analysis can occur concurrently
with the implementation validation so we will have a fair amount of
information before deciding on what to do before going for an OASIS
standards vote.

Let me know what others think about this.

Arshad Noor
StrongAuth, Inc.