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.

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.

Removed the definition from part-1.

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

Removed <env:Header> from those examples.

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

Fix applied to the Editor's draft.

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

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.

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.

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>

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.

(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"" />

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

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.

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.

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.

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.

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

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.

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.

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.

>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.

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.

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

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/*

[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.