This wiki is a read-only archive. It was frozen on 3 October 2026 and is no longer edited.

Comments received on the ekmi comments mailing list

Ladies and Gentlemen,

Having been made aware of the SKSML work. I wanted to comment on the current specification and make a proposal.

I am the author of the PSKC spec (http://www.ietf.org/internet-drafts/draft-ietf-keyprov-portable-symmetr ic-key-container-06.txt) which is part of the IETF 'keyprov' working group (http://www.ietf.org/html.charters/keyprov-charter.html) that has some overlap with the work done for SKSML

My main comment around SKSML is that it would be nice to be able to define the type of payload container (where the key resides) that is transported.

This has several advantages:

1. It decouples the protocol to obtain the keys from the payload to transfer the keys 2. it allows for several different containers to be transported with the same protocol 3. It allows extensions to the payload to have a separate lifecycle to the protocol 4. It will allow profiling of payloads for key related meta-data not yet considered by the spec

One of the main reasons is that there could be alignment of the payload between SKSML and the work that has been done in IETF keyprov group.

Especially I would suggest you to consider the work that has been done on the PSKC spec which seems to satisfy most of the requirements in SKSML and already has many implementers.

The proposal could be to add one layer of abstraction in the SymKeyResponse element which indicates the type of key container being used:

Example 1 - using SKSML container

<ekmi:SymkeyResponse xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01' xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'&gt;

<ekmi:SymkeyContainer type="http://docs.oasis-open.org/ekmi/2008/01"&gt;

<ekmi:SymkeyList>

<ekmi:Symkey>

<ekmi:KeyUsePolicy>

<ekmi:KeyUsePolicyID>10514-4</ekmi:KeyUsePolicyID>

......

Example 2 - using PSKC container

<ekmi:SymkeyResponse xmlns:ekmi='http://docs.oasis-open.org/ekmi/2008/01' xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'&gt;

<ekmi:SymkeyContainer type="urn:ietf:params:xml:ns:keyprov:pskc:1.0">

xmlns="urn:ietf:params:xml:ns:keyprov:pskc:1.0">

KeyAlgorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"

Looking forward to your feedback and please do not hesitate to contact me for further clarificatons,

Resolution from TC on Comment 1

Comment accepted to be incorporated.

Reference: http://www.ietf.org/mail-archive/web/keyprov/current/msg00666.html

I have not read the spec in detail but I have the following two early comments:

1. The spec refers in numerous places to SOAP 1.1 as a W3C recommendation. SOAP 1.1 was a Member Submission having no specific standing as a W3C product. The W3C Recommendation is SOAP 1.2 where SOAP no longer is an acronym expanding to Simple Object Access Protocol.

  1. The SKSML specification should properly reference the SOAP specs. See Recommendations under the Deliverables section at http://www.w3.org/2000/xp/Group/#drafts. b. The SKSML specification should have a SOAP 1.2 representation. A SOAP 1.1 representation may be an additional part of the spec for legacy applications, but SOAP 1.2 is widely enough adopted (and is included in the WS-I BP 2.0 draft) that it does not make sense to have a new OASIS Standard supporting only SOAP 1.1.

2. This is a specification for key management but there is no explanation of how this relates to the XML Key Management Specification (XKMS) that has been a W3C Recommendation since 28 June 2005. Such an explanation is necessary in order to properly describe where SKSML is to be used vice XKMS. Links to the family of XKMS Recommendations can be found at http://www.w3.org/2001/XKMS/#CurrentWork.

I hope to have the opportunity to read the full SKSML spec in time to submit additional comments.

Resolution from TC on Comment 2

Comment accepted to be incorporated into TC spec.