XKMS Ver. 2 Proposed Recommendation Issues

In Section 1.2 there is a definition of Web Service that is not used in the document and is not compatible with current usage. I suggested that we just loose the unnecessary definition rather than argue.

Acknowledgment cycle

Not started

In Section 1.2 there is a definition of Web Service that is not used in the document and is not compatible with current usage. I suggested that we just loose the unnecessary definition rather than argue.

Acknowledgment cycle

Not started

Removed the definition from part-1.

Acknowledgment cycle

announced by group on 22 Jun 2005

pp. 46, 47, 55, 56 of Part 2 incorrectly indicate that the SOAP Body resides inside the SOAP Header.

Acknowledgment cycle

Not started

Removed <env:Header> from those examples.

Acknowledgment cycle

announced by group on 22 Jun 2005

Part 2, p. 47 has a redundant semicolon (;) at the end.

Acknowledgment cycle

Not started

Fix applied to the Editor's draft.

Acknowledgment cycle

announced by group on 22 Jun 2005

Section 3.1.1 (SOAP Binding) See [1]

"XKMS implementers shall use SOAP document style request-response messaging with the XKMS messages defined in Part 1 carried as unencoded Body element content. The SOAP 1.2 RPC representation, and requisite encoding style, are not used. The potential benefits of using the RPC representation do not justify the additional effort required to define a mapping from the Part 1 messages to an appropriate encoding style."

Suggest: XKMS implementers shall use SOAP document style request-response messaging with the XKMS messages defined in Part 1 carried as a literal Body element content.

Justification: It is unambiguously clear that the XKMS message is of document-literal form. The semantic justification of why encoding was not selected is irrelevant.

[1] http://www.w3.org/TR/xkms2-bindings/#XKMS_2_0_Section_3_1

Acknowledgment cycle

Not started

p. [43] was changed as suggested, with a slight modification:

[43] XKMS implementers shall use SOAP document style request-response messaging with the XKMS messages defined in Part 1 carried as literal Body element content. This is equivalent to associating the Body content with a SOAP 1.2 env:encodingStyle attribute that has the value http://www.w3.org/2003/05/soap-envelope/encoding/none.

Acknowledgment cycle

announced by group on 23 Jun 2005

Issue: Section 3.2.3 [part-1]

- Use of terms strings is semantically incorrect.

- More RFC[2119] terminology needed for clarity.

Section 3.2.3 [102] states:

[102]The <RespondWith> in the request specifies one or more strings included in the request that specify data elements to be provided in the <ds: Keyinfo> element of the response. Each string is a single identifier corresponding to a sub-element of the XML Signature Specification[XML-SIG]<ds: Keyinfo> element or the private key information defined in the sectionCryptographic Algorithm Specific Parametersbelow. The XML Signature elements are described here for convenience. The normative reference is the specification [XML-SIG].

Purposed Text:

[102]The <RespondWith> allows the sender of a request to specify which data elements MAY be provided in the <ds:KeyInfo> element in the response. One or more <RespondWith> elements MAY be included in a request where each <RespondWith> element URI value is an identifier than corresponds to either a sub-element of the XML Signature Specification [XML-SIG] <ds:KeyInfo> or the private key information defined in section Cryptographic Algorithm Specific Parameters below. The XML Signature elements are described here for convenience. The normative reference is the specification [XML-SIG].

Justification:

(1)Eliminates the term "strings" where URI is required.

(2)Specifies MAY for <ds:KeyInfo> sub-element response items, which is accurate.

(3)Disambiguates the element's value as the identifier.

Acknowledgment cycle

Not started

This issue was subsumed by issue 344-ml.

The <RespondWith> in the XKMS schema is optional because the following request types MUST NOT include a <RespondWith> element(s) as immediate children.

PendingRequest, CompondRequest, StatusRequest

The following request types REQUIRE the use of one or more <RespondWith> elements.

LocateRequest, ValidateRequest, RegisterRequest, ReissueRequest, RevokeRequest, RecoverRequest.

Proposal:

A more accurate representation of the RespondWith element is to remove the RespondWith element reference from the RequestAbstractType, then extend a new type with RequestAbstractType that includes a RespondWith element reference (one unbound) in the new type. Then extend the requests that require the RespondWith element by the new type NOT RequestAbstractType. In this manner, <RespondWith> can be clearly defined for the applicable requests.

<complexType name="RequestWithAbstractType" abstract="true">

<complexContent>

<extension base="xkms:RequestAbstractType">

<sequence>

<element ref="xkms:RespondWith" minOccurs="1" maxOccurs="unbounded"/>

</sequence>

</extension>

</complexContent>

</complexType>

Acknowledgment cycle

Not started

The WG acknowledges your XKMS schema changes but has decided it is not convenient to change the XKMS schema for additional clarity at this stage. Your schema changes will be documented in a To-Do list (in addition to the issues list) so that they can be taken into account in future revisions of the XKMS specification.

Acknowledgment cycle

announced by group on 23 Jun 2005

agreement by reviewer on 23 Jun 2005

(1) SECTION 6.1.1 Example: Registration of Client-Generated Key Pair [246] response:

In example response message use of double quotes invalid XML in /UseKeyWith/ @Identifier value (see below)

<UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C="US" O="Alice Corp" CN="Alice Aardvark"" />

Should be escaped (see below)

<UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C="US" O="Alice Corp" CN="Alice Aardvark"" />

(2) SECTION 6.1.2 Example: Registration of Service-Generated Key Pair [252]The response In example response message use of double quotes invalid XML in /UseKeyWith/ @Identifier value (see below)

<UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C=UK" O="Bob Corp" CN="Bob Baker"" />

Should be escaped (see below)

<UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C="UK" O="Bob Corp" CN="Bob Baker"" />

Acknowledgment cycle

Not started

Change applied to the editor's version of part-1.

Acknowledgment cycle

announced by group on 22 Jun 2005

The XKMS Schema RequestAbstractType is used to extend all request types, but uses an optional element 'RespondWith' that is only applicable and required by certain request types and must be omitted by other request type.

Proposal:

(1) Remove the RespondWith element from RequestAbstractType.

(2) Define a new abstract type RequestWithAbstractType that extends the RequestAbstractType and add the RespondWith element as (one\205unbounded) to extended type.

(3) Extend the following request types by RequestWithAbstractType LocateRequest, ValidateRequest, RegisterRequest, ReissueRequest, RevokeRequest, RecoverRequest.

Justification:

(1) Clearly defines which request types encode and require RespondWith elements and which request types do not.

(2) Removes the optional RespondWith element from request types that must not encode RespondWith elements.

(3) Defines request types that must encode RespondWith elements must use one or more.

(4) Should not break any current implementations.

(5) Allows the specification clearly state processing rules concerning RespondWith by not having to deal with the optional issue in the current schema.

Acknowledgment cycle

Not started

The WG acknowledges your XKMS schema changes but has decided it is not convenient to change the schema for additional clarity at this stage. Your schema changes will be documented in a To-Do list (in addition to the issues list) so that they can be taken into account in future revisions of the XKMS specification

Issue 344-ml was accepted and took into account the changes you proposed to the text that will clarify the semantics.

Acknowledgment cycle

announced by group on 23 Jun 2005

agreement by reviewer on 23 Jun 2005

Issue, Proposal, and Justification for Section 3.2.3

Issue: Section 3.2.3

- Use of terms strings is semantically incorrect.

- More RFC[2119] terminology needed for clarity.

- More clarity needed with respect to which elements encode <RespondWith>

- Faults conditions not specified.

Proposed Text:

[102] The <RespondWith> element encoded in a request specifies one or more URI values that SHOULD resolve to data elements provided in either the [XML-SIG] <ds:KeyInfo> element or private key information defined in the section Cryptographic Algorithm Specific Parameters below. The <RespondWith> element MUST be encoded in requests of type LocateRequest, ValidateRequest, RegisterRequest, ReissueRequest, RevokeRequest, RecoverRequest. If the receiver does not support any of the <RespondWith> element URI values sent in the request or the specified request is not encoded with <RespondWith> the receiver SHOULD fault with either [XKMS Bindings 3.4.1] (5) or [XKMS Bindings 3.4.2] (5). The XML Signature elements are described here for convenience. The normative reference is the specification [XML-SIG].

Justification:

- Eliminates the term 'strings' where URI is required.

- Explicity states which request types encoded <RespondWith>

- Disambiguates the element's value as the identifier.

- Makes normative the expected response of sending 'all' unresolvable URI values.

- Makes normative the expected response of not encoding <RespondWith> with required request types.

- Semantic modification clarifies ambiguities in schema.

Acknowledgment cycle

Not started

pp. 102 and 103 were modified as follow to take into account your proposal.

[102] The <RespondWith> element in a request specifies one or more URI values that SHOULD resolve to data elements provided in either the <ds:KeyInfo> element or private key information defined in the section Cryptographic Algorithm Specific Parameters below. The <RespondWith> element SHOULD be included in requests of type LocateRequest, ValidateRequest, RegisterRequest, ReissueRequest, RevokeRequest, RecoverRequest. The XML Signature elements are described here for convenience. The normative reference is the XML Digital Signature Specification [XML-SIG].

[103] The Service SHOULD return any data elements that are resolvable <RespondWith> URI values and that are supported by the Service. The Service MAY return additional data elements not requested. In particular, the service MAY return data elements specified in the request with the response.

The "MUST fault" change was discarded as it is requesting a change in behaviour. Moreover, it doesn't take into account the HTTP bindings. Finally, the 3.4.1 (5) means that that the Server couldn't parse the XKMS message. This is not the case here. It could parse it, but couldn't find any pertinent information. It doesn't look like a good choice.

Also note that Receiver.Failure defined in p. [127] already serves this purpose. Moreover, there are many other parts in part-1. that define the use of Receiver.Failure as such and none that mention "fault".

Your "MUST fault if none" proposal will be documented in a To-Do list (in addition to the issues list) so that it can be taken into account in future revisions of the XKMS specification.

Acknowledgment cycle

announced by group on 23 Jun 2005

Section 3.2 (Bindings) [1] states:

Insertion of an XKMS message into the SOAP message structure must not alter namespace prefixes, or use of default namespaces, within the XKMS message. Any change in these encodings will likely break an XML Signature internal to the XKMS messages due to the use of QNames and namespace prefixes. The implementer must insure that prefix values used with the SOAP namespaces http://www.w3.org/ 2003/05/soap-envelope (SOAP 1.2) and http://schemas.xmlsoap.org/soap/envelope/ (SOAP 1.1) do not conflict with prefixes used in the XKMS message.

I read this to suggest some form of prefix-collision, which I do not understand. Is the intent is to make XKMS prefixes unique vs. soap prefixes, why? How can a resolved URI of a prefix within the XKMS message created any issue with the soap:Envelope, soap:Body, or soap:Header.

[1] http://www.w3.org/TR/xkms2-bindings/#XKMS_2_0_Section_3_2

Acknowledgment cycle

Not started

I think that since we no longer use QName's in XKMS, that this is not much of an issue any more. Also, since WS-Security and WS-I, et al., are now all recommending exclusive-c14n, which doesn't have the problems caused by standard c14n and embedding content, we should strike this.

It's not really an editorial change, although it can be treated as such, since it's removing a limitation. We can either remove the text, and let folks like ws-i, etc., advise what to do, or we can explicitly say XKMS messages that will be embedded in SOAP documents SHOULD be signed using exc-c14n.

Acknowledgment cycle

Not started

Following feedback from the developers, p. [60] in the bindings document was changed to say:

"XKMS messages that will be embedded in SOAP documents SHOULD be signed using the Exclusive XML Canonicalization algorithm [XML-EXC-C14N]."

This was already being suggested by pp. [89, 90] of the XKMS specification.

Acknowledgment cycle

announced by group on 22 Jun 2005

Is there a reason why the RSAKeyPair schema component does not extend ds: RSAKeyValue?

It appears to me to somewhat redundant to redefine exponent and modulus just to get them both in the same namespace for XKMS purposes...or maybe that *is* the point.

My thoughts are along these lines:

Assertions

1) Xml Signature is a normative to XKMS.

2) ds:CryptoBinary is a reference to an intrinsic type xsd: base64Binary

A) If ds:CryptoBinary is used, then make xkms:RSAKeyPair an extension of ds:RSAKeyValue Reason: XKMS is already referencing the Xml Signature schema and extending xkms:RSAKeyPair seems logical sinces the xkms: RSAKeyPair does reference Xml Signature components through ds: CryptoBinary.

B) If ds:CryptoBinary is not used, then change XKMS schema for use the intrinsic type xsd:base64Binary for the components of xkms: RSAKeyPair

Reason: Eliminate the need for reference to Xml Signature schema (for xksm:RSAKeyPair) by redefining the ds:CryptoBinary elements type to their respective intrinsic type.

I think either method is cleaner.

Acknowledgment cycle

Not started

>Is there a reason why the RSAKeyPair schema component does not extend ds:RSAKeyValue?

I think the answer's probably: "nope - no particular reason".

Is there a reason we ought to extend that rather than just re-use the ds:CryptoBinary as we've done?

>It appears to me to somewhat redundant to redefine exponent and modulus

I guess it is a little, but can't see the harm really.

>just to get them both in the same namespace for XKMS purposes...or maybe that *is* the point.

Maybe that was it all right. I guess mixing up namespaces is would possibly be a little more error prone (at coding time) than doing as we've done.

Acknowledgment cycle

announced by group on 20 Jun 2005

agreement by reviewer on 20 Jun 2005

p. 218 ends with:

"The <UnverifiedKeyBinding> returned are specified by the Respond element in the request."

Shouldn't it say "by the RespondWith element in the request"? The schema has no such element as <Respond> anyways.

Acknowledgment cycle

Not started

Change applied to the editor's version of part-1.

Acknowledgment cycle

announced by group on 20 Jun 2005

A change similar to [43] (Issue-339-ml) is is needed for [53] regarding the SOAPv1.1 binding. Albeit, that a URI equivalence for 'literal' does not exist for SOAPv1.1 in terms of env:encodingStyle between v1.1 and v1.2. Therefore, the omission of the encodingStyle attribute for SOAPv1.1 is correct syntax for

env:Envelope

env:Envelope/env:Body

env:Envelope/env:Body/*

Acknowledgment cycle

Not started

[53] XKMS implementers using SOAP 1.1 messaging shall use request-response messaging and carry the XKMS messages as literal content within the SOAP Body element. The SOAP 1.1 Section 5 encoding model shall not be used. SOAP 1.1 messages carrying XKMS content shall use the UTF-8 character encoding to insure interoperability.

Acknowledgment cycle

announced by group on 24 Jun 2005