RE: [ekmi] Discussion on comment received on 15-day review of SKSML

[<Benjamin.Tomhave@ins.com>]

I'm a bit surprised by the assertion made that keyprov is already widely implemented. My understanding, consistent with their own timeline (http://www.ietf.org/html.charters/keyprov-charter.html), is that they are just nearing the end of their implementation and interop testing. KEYPROV is not in full DRAFT status yet, that I know of, and thus may still be modified. If this were a FINAL DRAFT standard from IETF, then that would perhaps be a little different story. My guess is that a handful of vendors directly involved in the committee (Verisign for one) have test implementations of keyprov, but nothing finalized or production-deployed.

In terms of what it is: keyprov is for secure provisioning (aka distribution) of symmetric keys. From our conversations at the KMS in September, this was not necessarily the original intent of the standard. A few of us wondered why keyprov was even going forward with IKE2 in the offing.

I thus agree with Arshad's conclusion: let's get SKSML into Community Specification status so that we can close out the initial development. This will allow us to continue moving forward with the TC while we keep an eye on other developments. The comments about being compatible with keyprov could be equally applied to IKE and IKE2 and any other number of protocols. It may be worthwhile to interview each respective committee (as many as we can find working in this space, or reasonably tangential to it) and then produce a white paper that explains what each protocol does, it's current status, and how SKSML will or will not interoperate with them.

The big thing for now, though, is regaining some forward momentum as we enter the new year. Lack of forward progress for an extended period of time could lead to TC atrophy and death, which would be very undesirable.

fwiw.

-ben

--
Benjamin Tomhave, MS, CISSP
Senior Security Consultant, Mid-Atlantic Operation
BT Professional Services        http://www.ins.com/
M: 703.282.8600
E: benjamin.tomhave@bt.com
________________________________________
From: Arshad Noor [arshad.noor@strongauth.com]
Sent: Monday, December 29, 2008 2:15 PM
To: ekmi
Subject: [ekmi] Discussion on comment received on 15-day review of SKSML

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.

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php