Re: [P1619-3] SOAP messaging work

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

Gentlemen,

I have been out of the country and have been unable to attend
any of the discussions.  My apologies.

Based on the current status, I would like to propose that the
discussion for the SOAP-based XML be approached by answering
the following question: what in SKSML prevents it from being
adopted by this WG as the SOAP-based KM messaging standard?

I would like to state that SKSML offers a number of advantages
to the IEEE WG:

1) It is specifically focused on key-management;

2) It has addressed security issues for authenticity, message-
    integrity and confidentiality;

3) It supports the "white-listing" of symmetric-keys through
    the KeyUsePolicy element; this is something that the Security
    and Audit community is very interested in, because it is a
    demonstrable and measurable control-objective for compliance;

4) It supports synchronous and asynchronous messaging (a recent
    request from Red Hat requested that we include asynchronous
    messaging for request/responses, so this will be included in
    SKSML 1.0; we've delayed the standards vote by 4-6 weeks to
    include this capability);

5) It supports standard error/message codes and messages.  The
    OASIS TC decided to standardize baseline error-codes and
    messages for SKSML implementers to reduce confusion amongst
    customers who might have SKMS software from multiple vendors.
    There is also a scheme to allow SKSML vendors to have unique
    codes/messages in their implementations.  Here is a link to
    an e-mail that describes the proposal on the table:

    http://lists.oasis-open.org/archives/ekmi/200810/msg00010.html

    This will also be in the SKSML 1.0 standard.

6) It has the support of at least 32+ organizational/individual
    members, some of whom represent end-user customers in the
    banking, government and retail industry.  There are also many
    system integrators and technology vendors in this group;

7) It has the support of a major open-source operating system
    vendor, while another commercial operating system vendor has
    been an Observer from the inception of the OASIS EKMI TC;

8) It is royalty-free;

9) It has an open-source implementation that can be used by WG
    members to start "playing" with the DRAFT 1 version of the
    protocol;

If there are issues with SKSML that do not work for the IEEE WG,
please help me understand them.  We've all heard the few customers
who showed up at the KMS, that they would like to see a single KM
standard from OASIS and the IEEE.  I strongly believe that SKSML
plus the IEEE's TLV-based protocol will be that answer, and will
be heartily endorsed by customers.

Regards,

Arshad Noor
StrongAuth, Inc.

P.S.  For OASIS EKMI TC Members:  The IEEE 1619.3 WG recently
passed a motion to include a SOAP-based messaging-protocol as
part of the IEEE's KM standard (see item 2.1 below):

https://siswg.net/index.php?option=com_content&task=view&id=173&Itemid=64

This represents an opportunity for the industry to come together
to address this customer problem once and for all.


Robert A. (Bob) Lockhart wrote:
> Based on this mornings vote I would like to recommend that we decide 
> quickly whether we do our own SOAP implementation or use an existing 
> messaging schema (i.e. SKSML or WS-Man).  We also need to determine what 
> functions within SOAP we will require and what we will leave as optional 
> or not supported.  I would like to begin this discussion at the next 
> P1619.3 Weekly meeting scheduled for October 22 at 10am Pacific if not 
> sooner via email.  I would like to get everyones opinion sooner than later.
> 
> I know that none of us have strong opinions one way or the other but I 
> figured I would ask anyway. ;')
> 
> Thanks,
> 
> Bob L.