XKMS Ver. 2 Last Call Working Draft Issues $Date: 2004/03/12 16:05:54 $ 2015-31-12 http://www.w3.org/2001/XKMS/Drafts/last-call-issues/ http://www.w3.org/2001/XKMS/Drafts/last-call-issues/ XKMS Working Group

This is the Disposition of Comments for the Last Call XKMS Working Drafts:

XML Key Management Specification (XKMS) Version 2.0

XML Key Management Specification (XKMS) Version 2.0 Bindings

SOAP Binding and use of SOAP 1.2 2003-05-13 1. Section 3 SOAP Binding para [41] The paragraph includes the sentences: "Use of SOAP 1.1 is REQUIRED by implementers in the near term for compatibility with existing tools and infrastructures. Use of SOAP 1.2 is Recommended." The XKMS requirements document includes the requirement that : XKMS services MUST implement SOAP 1.2 once that specification has achieved Candidate Recommendation status. SOAP 1.2 has now reached Proposed Recommendation status so we ask the XKMS WG to state that the use of SOAP 1.2 is REQUIRED by implementers. In addition, SOAP 1.1 is W3C Note which has an informal status. The XKMS specification should reflect this. We suggest the sentences above be changed to: "Use of SOAP 1.2 is REQUIRED by implementers of this specification. For near term compatibility with existing tools and infrastructure, SOAP 1.1 MAY be used" John Ibbotson SOAP/XML Protocol 2003-08-06

The changes you proposed to the specification have been accepted and the revised version of the specification may be seen at [1], Para 42.

[1] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

2003-08-06 Examples for XKMS Request and Response messages incorrect 2003-05-13 2. Section 3.1.1 SOAP 1.2 Binding The example XKMS Request and Response messages in paras [45] and [46] are syntactically incorrect - there is no termination for the env:Header element. Similar errors exist in the examples in paras [54] and [55]. John Ibbotson SOAP/XML Protocol 2003-08-06

The changes you proposed to the specification have been accepted and the revised version of the specification may be seen at [1], Para 46-47.

N.B. the par 55-56 change was missing and I added it later on. JK.

[1] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

2003-08-06 Addition of DelegatedSignature value to KeyUsage Element 2003-05-22 A DSS service may produce signatures (such as XML-DSIG and CMS signatures) for its clients - if it authenticates the client, it may attach the client's name as a signed attribute to the signature - this way a client can produce signatures that are associated with himself, without needing his own key pair. So it would be nice if a relying party can query an XKMS service on the DSS client's name, and receive back the DSS service's key, but the XKMS client would need to be told that this key is not in the sole possession of the DSS client, but must be associated with the DSS client through a signed attribute. Two options appear feasible. This could be done by adding a new "DelegatedSignature" value to the <KeyUsage> element: <KeyUsage>DelegatedSignature</KeyUsage>. So for a given protocol that uses signatures, an XKMS client could query for <KeyUsage>DelegatedSignature</KeyUsage> as well as <KeyUsage>Signature</KeyUsage>. This is simple, but would require a change to XKMS. Alternatively, the same an extra application URI could be defined for the <UseKeyWith> element, for every protocol that uses signatures, to denote the delegated signature version. This requires the definition of an extra URI for each protocol that uses signatures and thus seems more difficult to support, in general. It would not require a change to XKMS though. Robert Zuccherato OASIS DSS TC 2003-08-06

The DSS TC raised the issue of how one should indicate to an XKMS client that key information returned by an XKMS service was associated with a DSS service. This would indicate that the keys are in possession of the DSS service and associated with the DSS client through a signed attribute. It was suggested that a new <KeyUsage> element value or a <UseKeyWith> URI might be appropriate.

We do not believe a new <KeyUsage> element value is the correct mechanism for addressing this issue. KeyUsage is intended to identify the cryptographic operation that a key may be used for. It is not intended to indicate other factors such as how a key is stored or who has control over the key's use. Within the DSS context, the appropriate KeyUsage would be "Signature".

We recommend definition of a new <UseKeyWith> URI as the appropriate mechanism for meeting your requirements. The XKMS specification (23 July 2003 Editor's Draft), defines UseKeyWith as: "[184] The primary use intended for <UseKeyWith> identifiers is to identify application protocols. <UseKeyWith> URI identifiers MAY be specified that represent key binding issuance and/or use policies instead of or in addition to an application protocol. In this case the <UseKeyWith> element specifies that the key binding complies with the specified policy."

As we understand the objectives of the DSS TC, you are defining a use policy for a signing key. That use policy is along the lines of: signature generation is performed by an authorized DSS server and is bound to a given client via a signed attribute. Once the DSS TC has formalized this policy statement, a URI may be associated with it. The DSS TC should define this URI and incorporate it into the DSS specification. The DSS effort is not at the appropriate standards status level for a normative reference from within the XKMS specification.

2003-08-01 Use of distinguished names 2003-05-07 The overall model is making the silent assumption that only names that are unique by their structure, i.e. DNS names, RFC 822 names or IP addresses, shall be used. Since DNS names, RFC 822 names and IP addresses are unique, there is no difference between such names certified by CA1 or CA2. If Distinguished Names (DNs) were being used, a DN certified by CA1 and the same DN certified by CA2 could correspond to the same or to different entities. XKMS currently prohibits the use of DNs or, said in other words, exhibits security problems if such names were being used. This should be clearly advertised, or a fix to this problem should be made. Denis Pinkas IETF 2003-08-08

SF: To save some time I should preface our individual responses by saying that the wg felt that many of the comments reflect a misaphrehenshion of the goals of xkms - in particular, xkms is not intended to be an xml variant of x.509 and therefore concepts such as "CA" (etc.) do not make sense in and of themselves. That is, while it is a goal to be able to sensibly place an xkms responder "in front of" and x.509 based pki, there is no requirement that all xkms responders operate like that. It is entirely within the xkms wg's remit to consider single server, certificate-less (i.e. raw keys only) systems. This made it impossible for the wg to do other than to note many of your comments, since they could not be accepted given the wg's charter[1], which in its first sentence states: 

  "The mission of this working group is to develop a
   specification of anXML application/protocol that allows a
   simple client to obtain key information (values,
   certificates, management or trust data) from a web
   service."

[1] http://www.w3.org/2001/XKMS/2002/11/charter.html

Where your comments appear to require that xkms embody such x.509 concepts as "certificates", or "CAs" then we have simply referred to this preface since the wg cannot process those.

If you would care to "translate" your comments into more "xkms-friendly" terminology, then the wg would be happy to consider those after this last call process is completed.

 2003-08-08 Obtaining information about certificates rather than about keys 2003-05-07 A major error in XKMS is to consider to obtain information about keys, rather than information against certificates, which bind a public key to a name for a specific key usage and under a Certification Policy. Since there is not a one-to-one relationship between a key and a certificate, but a one-to-many relationship, it is not possible to make an unambiguous binding with a public key but only an unambiguous binding with a (public key) certificate. Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 Use of Certification Policy in XKMS 2003-05-07 The Certification Policy is a concept which seems to be ignored at the level of the interfaces that are being proposed. Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 Typo in X-KRSS service name 2003-05-07 In section [46] the text says: "The XKMS specification defines three types of request: X-KRSS Request A Register, Reissue, Revoke or Recover request as specified by the Key Information Service Specification". There is indeed a typo, probably intentionally left by the editor, to make sure that at least someone read the specification: "Key Information Service Specification" should be changed into "Key *Registration* Service Specification". Denis Pinkas IETF 2003-08-08

Fixed.

2003-08-08 Ambiguity in choosing a public key shared among certificates 2003-05-07 The <ds:KeyInfo> (see [135]) is described as an "hint". This should not be the case since it is important to make sure under which certificate a signer wanted to sign. Several certificates may include the same public key and for that reason it is important to make sure that the certificate (or an unambiguous reference to it) is linked to the data that has been signed and is indeed protected by the signature. Without that link certificates could be substituted without notice. The concept is similar to ESSCertID that is used in CMS (see RFC 2634). Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 make <ds:KeyInfo> always be cryptographically bounded to the signature 2003-05-07 The fact that <ds:KeyInfo> may or may not be cryptographically bound to the signature itself is advertised as an important property (see [136]). It is said: "This allows the <ds:KeyInfo> to be substituted or supplemented without "breaking" the digital signature". This should be considered as a severe weakness, since such a substitution is not desirable (see above). A certificate could be added, but the reference to the certificate should remain unchanged and unchangeable. Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 XKISS Validate should verify binding with a certificate 2003-05-07 The XKISS Validate service verifies a binding with a public key, while the binding should be verified with a certificate (which contains a public key), instead of directly a public key value. CAs may deliver different certificates with the same public key but with different attributes in them. It is important to know which certificate has been used, rather than which public key has been used, since several certificates may include the same public key. Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 The overviews from sections 1.5 and 1.6 are not clear 2003-05-07 The two overviews from sections 1.5 and 1.6 do not provide a clear picture of the functions that are supported. They should be both revised. A text is proposed as an annex at the end of these comments. Denis Pinkas IETF 2003-08-08

The WG felt that the current text was sufficient.

2003-08-08 Add more normative text and move examples to an informative annex 2003-05-07 The document provides several examples which are quite interesting. However the core of a standard should not include examples. Such examples should be placed in an annex. However if these examples were removed the text would not be understandable anymore, because the remaining explanations would be insufficient. It is thus requested to add more normative text and to move the examples in an informative annex. Denis Pinkas IETF 2003-08-08

The WG has attempted to match the style from previous standards like XKMSIG and SAML.

2003-08-08 Menaing of "resolving <ds:Keyinfo> element" 2003-05-07 The XKISS Locate service is defined as " The XKISS Locate service resolves a <ds:Keyinfo> element but does NOT REQUIRE the service to make an assertion concerning the validity of the binding between the data in the <ds:Keyinfo> element". What means "resolving <ds:Keyinfo> element" is not self-understandable. The exact processing that is supposed to be done by the service should be described in details. Denis Pinkas IETF 2003-08-08

The exact processing to be done is deliberately not determined here - that is one of the differences between xkms and x.509. "Resolves" means that the service attempts to provide fuller information about the keyinfo.

See also decision for 303-dpinkas-1 issue.

(SF comment: "self-understandable" is not "self-understandable"... ...I think:-)

2003-08-08 Should X-KISS return a certificate? 2003-05-07 The example (see [145]) is insufficient to describe what that service really does. The various input (and output) parameters should be clearly described. This is not the case. The service seems to return only a key value, while it should return the main components from a certificate. From the example, it can be seen that the input parameters are a DNS name and the name of a protocol. Since no key usage is mentioned, the service is unable to know whether a certificate that includes a signature verification key or includes an encryption key is requested. A certificate should be returned and not a key, so that the user can verify the validity period of the certificate, otherwise a validity date should be included in the request. The certification policy contained in the certificate may also be helpful, unless it is specified in the request. Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 Unclear definition of X-KISS validate 2003-05-07 The XKISS Validate service is defined as : "The XKISS Validate Service allows all that the Locate Service does, and in addition, the client may obtain an assertion specifying the status of the binding between the public key and other data, for example a name or a set of extended attributes". What means "other data" is not self-understandable. The exact processing that is supposed to be done by the service should be described in details. Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue and the response to 303-dpinkas-10.

2003-08-08 X-KISS Validate returns proof of binding a certificate, not to a key 2003-05-07 In [152] it is mentioned: "Furthermore the service represents that the status of each of the data elements returned is valid and that all are bound to the same public key". A <ds:Keyinfo> element may contain a <ds:X509Data> element. Therefore the binding is not with a key but with a certificate. Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 Unclar example 2003-05-07 The example (see [155]) is insufficient to describe what that service really does. The various input (and output) parameters should be clearly described. This is not the case. In particular, is the validation done only for the current time or can it be done for a time in the past ? Even, if this is the current time, is that time indicated in the response? The answer is only given (hidden) in section [215], but this should be clearly advertised upfront. Denis Pinkas IETF 2003-08-08

The WG felt that the current section was sufficient.

2003-08-08 XKISS Validate should include the concept of RFC 3379 "validation policy" 2003-05-07 From its name, the XKISS Validate Service present a few similarities with the validation service requirements that have been defined by the PKIX WG from the IETF. This working group has produced RFC 3379 (Delegated Path Validation and Delegated Path Discovery Protocol Requirements) which is a set of requirements. However, the XKMS specification is leaving aside many, if not most, of the these requirements. An important concept from RFC3379 is the concept of "validation policy". When a validation is done, it must be done according to a set of rules. These rules depends upon the application. In particular some root keys may be adequate for an application, but not for another. Trust elements cannot be uniform and cannot be left open to the Validate Server. The text is speaking of a "validation criteria (see [161]), but it is unclear what it really is. This is one of the most severe limitations of XKMS and this limitation is not advertised. It would be quite interesting to understand why the requirements from RFC3379 have not been followed. Denis Pinkas IETF 2003-08-08

xkms is a W3C activity and as such there is no onus on the group to take account of works-in-progress from elsewhere. However, as you say, there is a similarity with the on-going pkix work on on-line services. The WG has produced its own requirements document, which differs from rfc3379, and which was finalised well before rfc 3379. We would indeed be interested were someone to compare those documents, but the WG has no intention of doing so at present.

2003-08-08 Service discovery for XKMS services 2003-05-07 The text is speaking of some means to locate the correct XKMS service (see [163]) but does not provide any guidance in order to solve this problem, in particular in the context of multiple servers offering their services to the users. Denis Pinkas IETF 2003-08-08

The WG decided to omit this from its scope, given that W3C is also working on other mechanisms for service discovery.

2003-08-08 Lack of support for validation policy 2003-05-07 The text in [168] states: "the Service represents to the client accessing the service and to that client alone that the binding between the data elements is valid under whatever trust policy the service offers to that client." Unless the service can clearly advertise which trust policy is being used, the client cannot use any kind of trust policy without even knowing which one it is. As already stated, the concept of validation policy is not supported, but should be supported. Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 Uniqueness of key identifier 2003-05-07 The text under [171] mentions: "The Id identifier is defined to provide a means by which the key binding may be signed using XML Signature. Clients MUST NOT rely on the key binding identifier being either unique or stable". On the contrary it is believed that a key identifier should be unique. The ESSCertID from RFC 2634 is a good example of such a unique binding. Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 Define key usages in terms of security services, non-repudiation keys 2003-05-07 The text under [174] considers only three intended uses of the key: 1) Encryption : The key pair may be used for encryption and decryption, 2) Signature : The key pair may be used for signature and verification, 3) Exchange: The key pair may be used for key exchange. However, the key usages should be defined in terms of security services (see ISO 7498-2), i.e. authentication service, confidentiality service and non-repudiation service. To avoid some security problems it is particularly important to make a difference between a key usable for authentication and a key usable for non-repudiation. This cannot be covered by a single key usage called "signature". Denis Pinkas IETF 2003-08-08

The wg explicitly decided not to tackle issues to do with repudiation using the key usage mechanism.

2003-08-08 Meaning of subject identifier within the <UseKeyWith> element 2003-05-07 The text under [177] mentions the <UseKeyWith> element which specifies a subject identifier and application identifier that determine a use of the key. The <UseKeyWith> must contain "Application" which is a URI that specifies the application protocol with which the key may be used and "Identifier" which specifies the subject to which the key corresponds within the specified application protocol. A protocol can support a sender and a receiver. It is unclear whether the Identifier corresponds to the sender or the receiver. It seems that the notion is by itself insufficient and should be extended to make such difference. Denis Pinkas IETF 2003-08-08

UseKeyWith is intended to be extensible. A protocol where the sender/recipient distinction is required can define its own variant UseKeyWith URI.

2003-08-08 No mention of CMS as a protocol 2003-05-07 The text under [180] mentions S/MIME as a protocol. Why is CMS (Cryptographic Message Syntax) not considered as a protocol as well ? Denis Pinkas IETF 2003-08-08

CMS is used much more broadly. The wg felt happy to define the identifier for s/mime but not for all cms based protocols

2003-08-08 Why do you consider PKIX a protocol? 2003-05-07 The text under [180] mentions PKIX. It is very unclear to understand why PKIX is considered as a "protocol" since it is only a set of data structures. Denis Pinkas IETF 2003-08-08

The intent was to define the identifier and uri for protocols which abide by "pkix rules".

2003-08-08 Use of "Certificate Subject Name" as an identifier 2003-05-07 The text under [180] mentions the use of "Certificate Subject Name" as an appropriate identifier. It should be observed that this name only is insufficient to correctly identify an entity, since two CAs may certify the same name and that this name may correspond to the same or to different entities. Unless a sequence of CAs names is added to the entity name up to a root key, such names are ambiguous. This relates to the non-uniqueness of DN names already mentioned. Denis Pinkas IETF 2003-08-08

The wg felt that a single name was sufficient. A service deployment which faces that challenge might define something else.

2003-08-08 Include a quote about XAdES 2003-05-07 The text under [180] identifies various protocols. To this list, XAdES (XML Advanced Electronic Signature) which is a W3C Note issued on February 20, 2003 should be added (see: http://www.w3.org/TR/XAdES/). The "identifier" type is such a case is a SigningCertificate element, i.e. *not* a DN. Denis Pinkas IETF 2003-12-xx

JK: After later discussions, the following paragraph was added to the XKMS part-1 spec:

[184] The primary use intended for <UseKeyWith> identifiers is to identify application protocols. <UseKeyWith> URI identifiers MAY be specified that represent key binding issuance and/or use policies instead of or in addition to an application protocol. In this case the <UseKeyWith> element specifies that the key binding complies with the specified policy. For example, applications handling XAdES [XAdES] compliant signatures could define their own <UseKeyWith> application values. 2003-08-08 The description of the XKISS Validate service is confusing 2003-05-07 The description of the Validate Service are confusing. It seems to relate more to the Locate Service rather than the Validate Service where the primary response should be "valid according to some policy" or "invalid according to some trust policy". The exact service performed by the Validate Service is not sufficiently detailed. Denis Pinkas IETF 2003-08-08

The WG felt otherwise.

2003-08-08 Values returned by the XKISS Validate service 2003-05-07 In [221] it is mentioned: "The server returns one or more <KeyBinding> elements that meet the criteria specified in the request." It is questionable why not simply a valid, invalid or don't know assertion is made against the proposed binding. Denis Pinkas IETF 2003-08-08

The service is free to return additional information.

2003-08-08 Consider adding a "not valid yet" response to the XKISS Validate service 2003-05-07 In the case of validation, the "yet not valid" response should be considered, in particular when a certificate is suspended. This means that another validation request made later on may succeed. Denis Pinkas IETF 2003-08-08

(We assume you meant "not valid yet".) The wg didn't feel that this was of sufficient interest to warrant inclusion at this point.

2003-08-08 Incomplete definition of the XKRSS Register service 2003-05-07 The Register Service from KRSS is not sufficiently described. The two examples provide more information, but that information is not normative. From the example, two features are mentioned: 1. authentication information to be used later on for revocation can be transmitted. However, it is unfortunate that the data does not also include the question to be answered. 2. it is necessary to have a face to face contact with the LRA before being able to use the register request. During that face to face information is captured by the LRA and the secret "authentication code" is provide to the end-user. However, this method is time consuming and does not allow a cost effective deployment of a PKI. It is suggested to use another technique that places all the burden of the typing for the end-user, who receives back both a registration number and the hash of his request (signed by the service) so that the end-user can then authenticate to the LRA in a face to face where the Register Service has only to verify the information (and to only "click" to accept or reject). Another advantage is that no secret information is being used. Denis Pinkas IETF 2003-08-08

The WG felt that the current text was fine, given, as you say, that they are examples.

2003-08-08 Mapping of "UseKeyWith Application" with X.509 certificates 2003-05-07 In the example [241] several identifiers are included : <UseKeyWith Application="urn:ietf:rfc:2459" Identifier="C="US" O="Alice Corp" CN="Alice Aardvark""/> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test"/> <UseKeyWith Application="http://ca.example.com/cps/20030401/class3" Identifier="alice@alicecorp.test"/> It is unclear to understand how the concept of "UseKeyWith Application" will be translated in an X.509 certificate, since an X.509 certificate does not support the concept of "UseKeyWith Application". Denis Pinkas IETF 2003-08-08

There is no direct equivalent of UseKeyWith in x.509. The wg has no requirement to be compatible with everything in x.509, nor vice versa. In this case, probably the most common thing will be for services to map between UseKeyWith and various x.509 extensions (in particular some policy oids) with the help of local configuration. The wg felt that such mappings were easier done locally.

2003-08-08 Use of out-of-band information in the XKRS Register service 2003-05-07 In the example [245] the private key is returned in the response. It will be quite uneasy for the end-user to memorize the authentication code 3n9cj-jk4jk-s04jf-20934-jsr09-jwik4 previously obtained through some out-of-band mechanism. This method would be quite difficult to use and would not allow an easy and cost effective deployment of a PKI. It is suggested to use another technique that allows the end user to locally generate a key pair, so that the public key can be sent in the Register Service request and then used by the Register Service to encrypt the private key once generated. The main advantage is that no secret information is being used and no out-of-bands mechanism is necessary. Denis Pinkas IETF 2003-08-08

The WG felt that the example is sufficient.

2003-08-08 Differences between Reissue and Register requests 2003-05-07 The Reissue request mentions "A reissue request is made in the same manner as the initial registration of a key". It is not believed that this statement is correct. The user should provide the previously obtained certificate and ask for another validity period. There is no need to specify again secret information obtained through an out of bands mechanism. Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 The Revocation request should allow to specify a reason code and an invalidate date 2003-05-07 The Revocation request should allow the possibility to carry a reason code and an Invalidity Date (RFC 2459 states that CRL issuers are strongly encouraged to include meaningful reason codes in CRL entries). Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 Requesting a Revocation without quoting the certificate 2003-05-07 The Revocation request example includes the certificate. It is very doubtful that the user will be able to provide its full certificate, if his smart card has been stolen. However he could more easily provide his subject name instead. The input and the output parameters are not sufficiently described. Denis Pinkas IETF 2003-08-08

The WG felt that the example text was sufficient.

2003-08-08 The Recovery request is different from the Registration service 2003-05-07 The Recovery request mentions "A key recovery request is made in the same manner as the initial registration of a key". It is not believed that this statement is correct. There is no need to specify again secret information obtained through an out of bands mechanism. Users do not have only a confidentiality key, but also an authentication key. They could use it to authenticate. If they loose everything, they could encrypt the authentication code under a key they wish their private key to be recovered (using PKCS#12) and authenticate their request by phone using the non-secret registration number of their request. For this to be possible, a hash of the request should be present in the response. Denis Pinkas IETF 2003-08-08

"In the same manner" does not mean *exactly* the same, just similar, so the WG feels that the text is fine.

2003-08-08 Expand the security considerations issue to indicate more limitations 2003-05-07 The security considerations section should be augmented to mention the severe limitations that are indicated above (JK: in the previous 34 issues). Denis Pinkas IETF 2003-08-08

See decision for 303-dpinkas-1 issue.

2003-08-08 Two Phase Protocol and <Result> element 2004-05-16 # 1. Section 2.6: Two Phase Request Protocol. As far as I can tell from the text, the purpose of the two phase protocol and the nonce is for the service to protect itself against Denial of Service attacks and against replay attacks. So why is it sensible to make the client trigger this by including "Represent" in the first request message? How does the client know that the service will want to do this? On p.15 it says that if the service requires use of the two phase protocol and the requester did not put "Represent" in the request, then the service is to return a MajorResult of "Receiver" and a MinorResult of "MustRepresent". This logic seems odd -- almost as if the service is returning an error for a badly-formed request (even though the requester can't have known beforehand that this was needed). It would be preferable, I think, to simply send the regular response with a MajorResult of "Represent"; if the requester can't deal with this, then *it* should send the error message. # Section 3.3.1: Element . Related to the previous comment, I'll just note that if you want to keep the interchange the way it is currently specified then you need to add a MinorResult of "MustRepresent" to the second table in 3.3.1.1. Carlisle Adams XKMS 2003-08-05

The work group agreed that item 1 is a reasonable point, but that we should stay with our current approach since it works, even though is different.

2003-08-05 Section 3.3.2: Element <RequestSignatureValue> 2004-05-16 3. Section 3.3.2: Element <RequestSignatureValue>. The last line of the first paragraph says, "This provides a cryptographic linkage between the request and the response." Note that it's only a "cryptographic linkage" if the response is signed or cryptographically protected in some other way. The conditions in the remainder of the section do not say this. Carlisle Adams XKMS 2003-08-05

MinorResult error code of RepresentRequired was added to the latest draft in section 3.3.1.1 line 122 - see [2]

[2] Section 3.3 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_3_3

2003-08-05 Section 6.1.1 Example: Registration of Client Generated KeyPair 2004-05-16 4. Section 6.1.1: Example: Registration of Client-Generated Key Pair. In the <KeyBindingAuthentication> element, there is no key identifier. How is the service supposed to know which key to use to verify this binding? Is it supposed to be implied from the <UseKeyWith> elements in <PrototypeKeyBinding>? If so (or if there's some other way that the service is supposed to figure this out), shouldn't this be specified somewhere so that implementers know what to build? Carlisle Adams XKMS 2003-08-05

this is fixed with the following text at line 123 in the latest draft [2]: "If the response is signed this provides a cryptographic linkage between the request and the response."

There is no key identifier in a key authentication signature because the key is specified by the key authentication type. A proof of possession can ONLY be authenticated by the subject key. Similarly for the symmetric authentication mode. Leaving out the key identifiers deliberately prevents the possibility of error, checking against the wrong key.

[2] Section 3.3 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_3_3

2003-08-05 Section 6.1.2 Example: Registration of Service Generated KeyPair 2004-05-16 5. Section 6.1.2: Example: Registration of Service-Generated Key Pair. The third paragraph talks about encrypting the returned private key using a symmetric key derived from the authentication code and includes the following text: "as described in Appendix C.1.3". But Appendix C.1.3 does not describe this process in any way. What should be said is "as described in Section 8.1; see also Appendix C.1.3". [As an aside, was the key derivation algorithm in Section 8.1 created for the purposes of this specification? Are there not standard ones out there (e.g., in FIPS, ANSI, etc.) that could have been used instead?] Carlisle Adams XKMS 2003-08-06

proposal to change the text in 6.1.2 to say "as described in Section 8.1; see also Appendix C.1.3". This change has been made to the latest draft at line 248, [3]

The key derivation algorithm is carried over from v1.0 of the specification and to the best of the working group's knowledge there is no substantive issue with it, apart from the fact that it is not one of the recently developed standards. The work group discussed this point and believes it is appropriate not to make a change, maintaining compatibility with v1.0.

[3] Section 6.1 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_6_1

2003-08-06 Flow/Organization of the Document 2004-05-12 While the spec has improved a great deal, I've been hoping that folks new to the spec might be able to substantiate my lingering sense that the document doesn't flow as smoothly as it might. Since I'm familiar with the spec I don't completely trust my assessment but I was thinking: a. Section 1 says there are two "service specifications" but doesn't say where they are more fully described or specified. Forward references? b. The sections in section 1.7 do not correspond to the sections of the table of contents. c. Section 1.5 has the same title as Section 4 (except that it has "specification"). How to make this flow better, or at least use the term (r not) "specification" consistently. d. Generally, I don't distinguish between a "message format" and a "message syntax." What do these section do differently? I'm sure this is the result of our splitting/combinding documents, but we're to the point now where what we are doing is quite clear, and now we need to smooth out the flow. Consequently, I suspect we could improve the spec if we (1) kept in mind the progressive rendering of (description, example, specification), (2) had carefully considered section titles and (3) further nudged the reader along with "this section does blah blah blah, how blah blah blah is transported is in the following section foo foo foo" Joseph Reagle XKMS 2003-08-06

The changes you proposed to the specification have been accepted

  1. Issue a - added forward links to the sections that describe protocols
  2. Issue b - Fixed - see para 36
  3. issue c - Fixed - See Section 1.5, 4
  4. Issue d - Fixed - Section 2 is now protocol exchanges

 2003-08-06 Schema Error - CompoundResult 2004-05-12 I think there are 2 errors in the XKMS last call schema at http://www.w3.org/TR/2003/WD-xkms2-20030418/Schemas/xkms.xsd <http://www.w3.org/TR/2003/WD-xkms2-20030418/Schemas/xkms.xsd> : 1. The choice of inner results in CompoundResult should have a minOccurs attribute of 0, rather than defaulting to 1. The text at paragraph 77 of the XKMS spec part I indicates that there can be zero or more inner responses. This makes sense because a service which does not support compound requests will want to return an empty CompoundResult. 2. The comment field just above the CompoundResult definition mistakenly refers to it as "CompoundResponse". Roland Lockhart XKMS 2003-08-06

The changes you proposed to the specification have been accepted and the revised version of the specification may be seen at [2][3]

[2] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html

[3] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

2003-08-06 No way to specify the desired key type for LocateRequest 2004-04-30 0) As far as can see, there is no way to specify the desired key type (RSA/DSA/...) in <xkms:LocateRequest/> or <xkms:ValidateRequest/>. This is not a major problem because XKISS server may return a list of keys but I think that in most case the desired key type is known to the client and could be used to narrow key search on the server side (and reduce network traffic :) ). For example, I can easily imagine that RSA and DSA keys would be stored in different database tables. Key type may limit key search to one table instead of two. Aleksey Sanin XKMS 2003-08-06

No change was made. The ability to register or request specific types of key or key length is outside the scope of the requirements. If an application required such an ability it should define private UseKeyWith fields.

2003-08-06 Use of Symmetric Keys 2004-04-30 1) It does not seem that there is a way to use symmetric keys. While public key cryptography is became more and more afordable, there are still situations when symmetric key cryptography is usefull either because of performance, legacy or some other reasons. An use case example might be a couple of high traffic servers when one stores some sensitive data on the client in an encrypted format (say, in cookies) and another one decrypt this data. These two servers may use XKISS server as a central keys storage (for example, to provide keys rotation). Using symmetric keys might be desirable because of performance reasons as well as small encrypted data size. Aleksey Sanin XKMS 2003-08-06

No change was made. Symmetric keys are outside the scope of the specification. While use of such keys is important the XKMS specification is predicated on the management of public keys.

2003-08-06 ValidityInterval does not have optional attribute specified 2004-04-30 2) In the schema for <xkms:ValidityInreval/> element "NotBefore" and "NotAfter" attributes do not have "use=\"optional\"" specified. Aleksey Sanin XKMS 2003-08-06

Fixed - [198] line [1]

[1] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html

2003-08-06 Change KeyUsage attribute maxOccurs to use unbound 2004-04-30 3) The "maxOccurs=\"3\"" for <xkms:KeyUsage/> element may prevent schema extension in the future, I would suggest to change this to "maxOccurs=\"unbound\"". Aleksey Sanin XKMS 2003-08-06

No change was made. The element is deliberately specified so as to be restricted to cryptographic key uses and prevent extension to allow ambiguous key uses to be defined such as repudiation.

2003-08-06 Section 4.2.1 Example: Document Signature incorrect ValidateResponse 2004-04-30 I want to point out another mistake in the latest document of XKMS (18 April 2003 ) Section 4.2.1 Example: Document Signature The XKMS ValidateResponse is not correct according to the ValidateRequest The ValidateRequest requires KeyName element to be present in ValidateResult, the ValidateResult has the ResultMajor = Success but only contains X509Certificate in KeyInfo, according to this example KeyName should be present in KeyInfo for ResultMajor = Success . This shows that ValidateResult is not composed successfully. [156] Request: <?xml version="1.0" encoding="utf-8"?> <ValidateRequest xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="Ic4d10f0affff49382b021a820613fa71" Service="http://test.xmltrustcenter.org/XKMS" xmlns="http://www.w3.org/2002/03/xkms#"> <RespondWith>KeyName</RespondWith> <QueryKeyBinding> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>.....</ds:X509Certificate> <ds:X509Certificate>.....</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <KeyUsage>Signature</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test"/> </QueryKeyBinding> </ValidateRequest> [157]Response: <?xml version="1.0" encoding="utf-8"?> <ValidateResult xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:xenc="http://www.w3.org/2001/04/xmlenc#" Id="Ibc853a2455de4f7433eed5b32ece5918" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="#Ic4d10f0affff49382b021a820613fa71" xmlns="http://www.w3.org/2002/03/xkms#"> <KeyBinding Id="Ie4d5784ea01e70085de088bd09b6e134"> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate>.....</ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <KeyUsage>Signature</KeyUsage> <KeyUsage>Encryption</KeyUsage> <KeyUsage>Exchange</KeyUsage> <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="alice@alicecorp.test" /> <Status StatusValue="Valid"> <ValidReason>Signature</ValidReason> <ValidReason>IssuerTrust</ValidReason> <ValidReason>RevocationStatus</ValidReason> <ValidReason>ValidityInterval</ValidReason> </Status> </KeyBinding> </ValidateResult> Yasir Kahn XKMS 2003-08-06

Fixed - Request now has respondWith value of X509Cert so response is now consistent.

2003-08-06 Section 2.5.2: Pending Request and Response Examples incorrect 2004-04-30 In section 2.5.2 it is described: ............ Service generation of the Pending Response Message RequestID is set to the value of Id in the Pending request message Nonce is not present ResponseID is set to a randomly generated unique value ............ I think in corresponding example the values are not given correctly: 2.5.3.4 Pending Request <?xml version="1.0" encoding="utf-8"?> <PendingRequest Id="I4294d3993de300c1ef54d49bd0903b2d" Service="http://test.xmltrustcenter.org/XKMS" OriginalRequestId="#I1221aaad701f0aacc65444c9bb93a7c0" xmlns="http://www.w3.org/2002/03/xkms#" /> 2.5.3.5 Response <?xml version="1.0" encoding="utf-8"?> <LocateResult Id="If91f068062d27f8f5892df0de3bb18aa" Service="http://test.xmltrustcenter.org/XKMS" ResultMajor="Success" RequestId="#Idbdf93883e29a3f1f505d6fe9d0c5979" xmlns="http://www.w3.org/2002/03/xkms#" /> In 2.5.3.5 Response the value of RequestId should be "#I4294d3993de300c1ef54d49bd0903b2d" according to the specification. Yasir Kahn XKMS 2003-08-06

Issue 1,2 Fixed

2003-08-06 Use of # Before Id Values in XKMS response 2004-04-30 I couldn't understand the logic of putting '#' before the Id values in XKMS Response. Yasir Kahn XKMS 2003-08-06

Issue 3 Use of "#" This is now covered under Issue 312-dchopra-1. At present the schema uses anyURI as the type of references to the request and response IDs, this means that the reference has to be a local reference #xxxy. We propose to resolve this by either changing the type to NCName or to put in an explanation.

2003-08-06 Typos 2004-04-18 http://www.w3.org/TR/xkms2/ Just before line 386, Appendix DReferences -- TYPO; Need Space in between D & References [CSP] TBD -- FILL-IN HERE !! Shivaram Mysore XKMS 2003-08-06

Fixed [2] [3]

[2] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html

[3] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

2003-08-06 Typos - Protocol Bindings Spec 2004-04-18 http://www.w3.org/TR/2003/WD-xkms2-bindings-20030418/Overview.html Just before line 75, [PKIX] TDB -- FILL-IN HERE !! [SPKI] TDB -- FILL-IN HERE !! also make items in [] bold to be consistent. line 80 will need a hard reference soon. just before line 84 another item [XML-ns] that needs to be in bold. Shivaram Mysore XKMS 2003-08-06

Fixed [2] [3]

[2] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-1.html

[3] http://www.w3.org/2001/XKMS/Drafts/XKMS20030804/xkms-part-2.html

2003-08-06 Use of Requester and Responder instead of Sender and Receiver 2004-05-20 Section 2, paragraph 43, two codes "Sender" and "Receiver" may make more sense if changed to "Requester" and "Responder". In any request/response protocol, where you have two messages, Receiver and Sender do not indicate the appropriate system entities. Requester and Responder make more sense. Dipak Chopra XKMS 2003-08-06

The terms sender and reciever are defined in the SOAP protocol and refer to messages and not protocols.

2003-08-06 Use Pending instead of Asynchronous 2004-05-20 Section 2.4, paragraph 51, 52, "ResponseMechanism" should have "Pending" instead of "Asynchronous". Dipak Chopra XKMS 2003-08-06

Fixed

2003-08-06 Section 2.4.1 - Use of Asynchronous in RespondWith 2004-05-20 3. Section 2.4.1, "RespondWith values Represent and/or Asynchronous MAY be specified'. It should be ResponseMechanism and even then how can ResponseMechanism be set to Asynchronous in synchronous processing? Dipak Chopra XKMS 2003-08-06

Fixed.

The requestor may offer asynchronous processing, but the responder is not obliged to honor this request.

2003-08-06 Section 2.5 -PendingRequest 2004-05-20 4. Section 2.5, PendingRequest is sent after the arrival of Notification. But if the requester sends PendingRequest even if Notification has not arrived, what should be the response? Dipak Chopra XKMS 2003-08-06

If the service is not ready it simply returns pending again. This was intentional to allow for polling as opposed to notification.

2003-08-06 Section 2.5.1 -Value of RespondWith 2004-05-20 5. Section 2.5.1, "RespondWith value Asynchronous MUST be specified" should be changed to "ResponseMechanism value Pending MUST be specified". Same should be reflected in Section 2.5.3.1 example. Dipak Chopra XKMS 2003-08-06

Fixed

2003-08-06 Section 2.5.3.5 -Value of RequestID 2004-05-20 6. Section 2.5.3.5, 'RequestID' value should be '#I4294d3993de300c1ef54d49bd0903b2d". Dipak Chopra XKMS 2003-08-06

Fixed

2003-08-06 Difference between Asynchronous processing and 2 phase protocol 2004-05-20 7. Section 2.6, in the differences between asynchronous processing and two phase request protocol, it is not pointed out clearly that while asynchronous processing is mandatory (once it is specified by request RespondWith) whereas two phase request protocol usage is the discretion of responder. Dipak Chopra XKMS 2003-08-06

No, asynchronous processing is always an option. Fixed the text to make this clearer

2003-08-06 Is nonce required 2004-05-20 8. Section 2.6.2, document specifies one method of nonce construction. Is it mandatory to use this method? Paragraph 68 does not suggest that. Dipak Chopra XKMS 2003-08-06

It is open to implementors, the text has been fixed to make this clear.

2003-08-06 Who can handle CompoundRequests? 2004-05-20 9. Section 2.8, paragraph 76, "Web Service" mention is unclear here. Till now, all the services are XKMS services. Does it mean that only web services can handle compound requests? Dipak Chopra XKMS 2003-08-06

Fixed

2003-08-06 Section 3.2.4 2004-05-20 10. Section 3.2.4, for Mechanism attribute, "A URI that specifies the protocol by which the notification is made". <PendingNotification> is a part of <RequestAbstractType> so it is going to be used by requester. And requester is not using Mechanism attribute, it is merely specifying it. In my opinion, "A URI that specifies the protocol by which the notification CAN BE made" seems more appropriate. Dipak Chopra XKMS 2003-08-06

Its a MAY, Fixed

2003-08-06 Fix types for OriginalRequestID, RespondID, RequestID 2004-05-20 11. OriginalRequestId (RequestAbstractType), RespondID (PendingRequest) , RequestId (ResultType) should be of type "xsd:NCName" as they are referring to "xsd:ID" type elements in other XML docs. Dipak Chopra XKMS 2003-08-06

This has been deferred to issue 312-ykahan-2 for further action. http://lists.w3.org/Archives/Public/www-xkms/2003Aug/0023.html

2003-08-06 Authentication 2004-05-20 12. Section 3.3.2, paragraph 124, "The corresponding request was not authenticated, or..." does it mean that ResultMajor.ResultMinor is Sender.NoAuthentication? If yes, then this probably is more concrete wording. Dipak Chopra XKMS 2003-08-06

No. The constraint is correctly on the request, if there is no signature on the request then there is no way to link it in the response. This is not the same as no authentication which indicates a violation of the service authentication policy. The lack of the signature in this case is simply a logic error since the requestor is asking the service to return a data item that was not provided.

2003-08-06 Add details to CompoundRequest as per schema 2004-05-20 13. Section 3.4.1, CompoundRequest can have multiple requests of the same type. Although this is clear from the schema definition, it would be better if some text can be provided to indicate that. Besides that there is no clear reasoning given for that. Dipak Chopra XKMS 2003-08-06

Fixed

2003-08-06 UseKeyWith Identifiers 2004-05-20 14. Section 5.1.3, paragraph 178. UseKeyWith specifies subject identifier and application identifier but the corresponding attributes (Identifier and Application) do not seem consistent. Probably attributes like Subject and Application; or SubjectIdentifier and ApplicationIdentifier seem more appropriate. Dipak Chopra XKMS 2003-08-06

This would break existing applications without providing significant value. No Change

2003-08-06 Bindings Doc: Section 3.1 2004-05-20 1. Section 3.1, can we have some other XML elements besides XKMS content inside Body element? Document does not say anything about that. Dipak Chopra XKMS 2003-08-06

This is a SOAP issue

2003-08-06 Bindings Doc: Soap fault error codes and use of Requester and Responder 2004-05-20 2. In the SOAP Faults section, error codes are "env:Receiver" and "env:Sender". In any request/response protocol, where you have two messages, Receiver and Sender do not indicate the appropriate system entities. Requester and Responder make more sense. So probably "env:Requester" and "env:Responder" seem little bit better. Dipak Chopra XKMS 2003-08-06

This is the SOAP spec.

2003-08-06 Bindings Doc: Where is the 3rd security binding? 2004-05-20 3. Section 4, "This specification describes three principal security bindings...". I can see two, Payload Authentication Binding and SSL/TLS Security Binding. Where is the third one? Dipak Chopra XKMS 2003-08-06

Fixed

2003-08-06 Fix types for OriginalRequestID, RespondID, RequestID 2004-05-20 11. OriginalRequestId (RequestAbstractType), RespondID (PendingRequest) , RequestId (ResultType) should be of type "xsd:NCName" as they are referring to "xsd:ID" type elements in other XML docs. Dipak Chopra XKMS 2003-08-06

I took a look at this. It seems to make sense to me. A NCName production is lexicaly the 'local' part of a URI - i.e. after the # mark.

This seems better than anyURI, it would mean that references to requests and responses would no longer require the # mark.

On the other hand this would break all the examples (not a real issue) and any code. On the other hand the changes to the existing code would be pretty simple.

JK: Although there was no announcement on the mailing list, the editor applied the proposed change in the xkms xsd schema and the examples were cleaned up. See also issue312-ykahan-2

 2003-08-06 Use of # before Id Values in XKMS response 2004-04-30 I couldn't understand the logic of putting '#' before the Id values in XKMS Response. Yasir Kahn XKMS 2003-08-06

JK: XKMS uses the the ID value to identify each request and response. Apparently the spec. was not consistent enough in the use of "#" before the ID values when quoting a previous message, e.g., the RequestID in a Response message, as it sometimes appeared and sometimes didn't. Following a related comment, the XKMS schema was changed and the use of the "#" become unnecessary. All the examples were cleaned up in the editor's draft, although there was no direct answer sent at the time. A follow-up message to the issuers of this comment did not occur in further feedback.

2003-08-06