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
Color key: error warning note
|301-ji-1 : SOAP Binding and use of SOAP 1.2||agreed||proposal||No reply from reviewer|
|301-ji-2 : Examples for XKMS Request and Response messages incorrect||agreed||editorial||No reply from reviewer|
|302-rzuccherato-1 : Addition of DelegatedSignature value to KeyUsage Element||disagreed||request||No reply from reviewer|
|303-dpinkas-1 : Use of distinguished names||no decision|
|303-dpinkas-2 : Obtaining information about certificates rather than about keys||no decision|
|303-dpinkas-3 : Use of Certification Policy in XKMS||no decision|
|303-dpinkas-4 : Typo in X-KRSS service name||agreed||editorial||No reply from reviewer|
|303-dpinkas-5 : Ambiguity in choosing a public key shared among certificates||no decision|
|303-dpinkas-6 : make <ds:KeyInfo> always be cryptographically bounded to the signature||no decision|
|303-dpinkas-7 : XKISS Validate should verify binding with a certificate||no decision|
|303-dpinkas-8 : The overviews from sections 1.5 and 1.6 are not clear||disagreed||editorial||No reply from reviewer|
|303-dpinkas-9 : Add more normative text and move examples to an informative annex||disagreed||editorial||No reply from reviewer|
|303-dpinkas-10 : Menaing of "resolving <ds:Keyinfo> element"||disagreed||editorial||No reply from reviewer|
|303-dpinkas-11 : Should X-KISS return a certificate?||no decision|
|303-dpinkas-12 : Unclear definition of X-KISS validate||no decision|
|303-dpinkas-13 : X-KISS Validate returns proof of binding a certificate, not to a key||no decision|
|303-dpinkas-14 : Unclar example||disagreed||editorial||No reply from reviewer|
|303-dpinkas-15 : XKISS Validate should include the concept of RFC 3379 "validation policy"||disagreed||clarification||No reply from reviewer|
|303-dpinkas-16 : Service discovery for XKMS services||disagreed||clarification||No reply from reviewer|
|303-dpinkas-17 : Lack of support for validation policy||no decision|
|303-dpinkas-18 : Uniqueness of key identifier||no decision|
|303-dpinkas-19 : Define key usages in terms of security services, non-repudiation keys||disagreed||clarification||No reply from reviewer|
|303-dpinkas-20 : Meaning of subject identifier within the <UseKeyWith> element||disagreed||clarification||No reply from reviewer|
|303-dpinkas-21 : No mention of CMS as a protocol||disagreed||clarification||No reply from reviewer|
|303-dpinkas-22 : Why do you consider PKIX a protocol?||disagreed||clarification||No reply from reviewer|
|303-dpinkas-23 : Use of "Certificate Subject Name" as an identifier||disagreed||clarification||No reply from reviewer|
|303-dpinkas-24 : Include a quote about XAdES||agreed||editorial||No reply from reviewer|
|303-dpinkas-25 : The description of the XKISS Validate service is confusing||disagreed||clarification||No reply from reviewer|
|303-dpinkas-26 : Values returned by the XKISS Validate service||disagreed||clarification||No reply from reviewer|
|303-dpinkas-27 : Consider adding a "not valid yet" response to the XKISS Validate service||disagreed||clarification||No reply from reviewer|
|303-dpinkas-28 : Incomplete definition of the XKRSS Register service||disagreed||clarification||No reply from reviewer|
|303-dpinkas-29 : Mapping of "UseKeyWith Application" with X.509 certificates||disagreed||clarification||No reply from reviewer|
|303-dpinkas-30 : Use of out-of-band information in the XKRS Register service||disagreed||clarification||No reply from reviewer|
|303-dpinkas-31 : Differences between Reissue and Register requests||no decision|
|303-dpinkas-32 : The Revocation request should allow to specify a reason code and an invalidate date||no decision|
|303-dpinkas-33 : Requesting a Revocation without quoting the certificate||disagreed||clarification||No reply from reviewer|
|303-dpinkas-34 : The Recovery request is different from the Registration service||disagreed||clarification||No reply from reviewer|
|303-dpinkas-35 : Expand the security considerations issue to indicate more limitations||no decision|
|304-cadams-1 : Two Phase Protocol and <Result> element||disagreed||clarification||No reply from reviewer|
|304-cadams-2 : Section 3.3.2: Element <RequestSignatureValue>||agreed||editorial||No reply from reviewer|
|304-cadams-3 : Section 6.1.1 Example: Registration of Client Generated KeyPair||agreed||clarification||No reply from reviewer|
|304-cadams-4 : Section 6.1.2 Example: Registration of Service Generated KeyPair||agreed||clarification||No reply from reviewer|
|305-jreagle-1 : Flow/Organization of the Document||agreed||editorial||No reply from reviewer|
|306-rlockhart-1 : Schema Error - CompoundResult||agreed||error||No reply from reviewer|
|307-asanin-1 : No way to specify the desired key type for LocateRequest||disagreed||editorial||No reply from reviewer|
|307-asanin-2 : Use of Symmetric Keys||disagreed||request||No reply from reviewer|
|307-asanin-3 : ValidityInterval does not have optional attribute specified||agreed||error||No reply from reviewer|
|307-asanin-4 : Change KeyUsage attribute maxOccurs to use unbound||disagreed||request||No reply from reviewer|
|308-ykhan-1 : Section 4.2.1 Example: Document Signature incorrect ValidateResponse||agreed||error||No reply from reviewer|
|309-ykhan-1 : Section 2.5.2: Pending Request and Response Examples incorrect||agreed||error||No reply from reviewer|
|309-ykhan-2 : Use of # Before Id Values in XKMS response||Subsumed||clarification||No reply from reviewer|
|310-smysore-1 : Typos||agreed||editorial||No reply from reviewer|
|310-smysore-2 : Typos - Protocol Bindings Spec||disagreed||editorial||No reply from reviewer|
|311-dchopra-1 : Use of Requester and Responder instead of Sender and Receiver||disagreed||editorial||No reply from reviewer|
|311-dchopra-2 : Use Pending instead of Asynchronous||agreed||editorial||No reply from reviewer|
|311-dchopra-3 : Section 2.4.1 - Use of Asynchronous in RespondWith||agreed||clarification||No reply from reviewer|
|311-dchopra-4 : Section 2.5 -PendingRequest||agreed||clarification||No reply from reviewer|
|311-dchopra-5 : Section 2.5.1 -Value of RespondWith||agreed||error||No reply from reviewer|
|311-dchopra-6 : Section 220.127.116.11 -Value of RequestID||agreed||error||No reply from reviewer|
|311-dchopra-7 : Difference between Asynchronous processing and 2 phase protocol||agreed||clarification||No reply from reviewer|
|311-dchopra-8 : Is nonce required||agreed||clarification||No reply from reviewer|
|311-dchopra-9 : Who can handle CompoundRequests?||agreed||clarification||No reply from reviewer|
|311-dchopra-10 : Section 3.2.4||agreed||editorial||No reply from reviewer|
|311-dchopra-11 : Fix types for OriginalRequestID, RespondID, RequestID||Subsumed||error||No reply from reviewer|
|311-dchopra-12 : Authentication||disagreed||clarification||No reply from reviewer|
|311-dchopra-13 : Add details to CompoundRequest as per schema||agreed||editorial||No reply from reviewer|
|311-dchopra-14 : UseKeyWith Identifiers||disagreed||clarification||No reply from reviewer|
|311-dchopra-15 : Bindings Doc: Section 3.1||disagreed||clarification||No reply from reviewer|
|311-dchopra-16 : Bindings Doc: Soap fault error codes and use of Requester and Responder||disagreed||clarification||No reply from reviewer|
|311-dchopra-17 : Bindings Doc: Where is the 3rd security binding?||agreed||error||No reply from reviewer|
|312-dchopra-1 : Fix types for OriginalRequestID, RespondID, RequestID||agreed||error||No reply from reviewer|
|312-ykhan-2 : Use of # before Id Values in XKMS response||agreed||clarification||No reply from reviewer|
1. Section 3 SOAP Binding para  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"
The changes you proposed to the specification have been accepted and the revised version of the specification may be seen at , Para 42.
2. Section 3.1.1 SOAP 1.2 Binding The example XKMS Request and Response messages in paras  and  are syntactically incorrect - there is no termination for the env:Header element. Similar errors exist in the examples in paras  and .
The changes you proposed to the specification have been accepted and the revised version of the specification may be seen at , Para 46-47.
N.B. the par 55-56 change was missing and I added it later on. JK.
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.
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: " 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.
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.
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, 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."
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.
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.
The Certification Policy is a concept which seems to be ignored at the level of the interfaces that are being proposed.
In section  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".
The <ds:KeyInfo> (see ) 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).
The fact that <ds:KeyInfo> may or may not be cryptographically bound to the signature itself is advertised as an important property (see ). 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.
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.
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.
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.
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.
The example (see ) 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.
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.
In  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.
The example (see ) 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 , but this should be clearly advertised upfront.
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 ), 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.
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.
The text is speaking of some means to locate the correct XKMS service (see ) 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.
The text in  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.
The text under  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.
The text under  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".
The text under  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.
The text under  mentions S/MIME as a protocol. Why is CMS (Cryptographic Message Syntax) not considered as a protocol as well ?
The text under  mentions PKIX. It is very unclear to understand why PKIX is considered as a "protocol" since it is only a set of data structures.
The text under  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.
The text under  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.
JK: After later discussions, the following paragraph was added to the XKMS part-1 spec:
 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.
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.
In  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.
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.
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.
In the example  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="firstname.lastname@example.org"/> <UseKeyWith Application="http://ca.example.com/cps/20030401/class3" Identifier="email@example.com"/> 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".
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.
In the example  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.
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.
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).
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.
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.
The security considerations section should be augmented to mention the severe limitations that are indicated above (JK: in the previous 34 issues).
# 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 18.104.22.168.
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.
MinorResult error code of RepresentRequired was added to the latest draft in section 22.214.171.124 line 122 - see 
 Section 3.3 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_3_3
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?
this is fixed with the following text at line 123 in the latest draft : "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.
 Section 3.3 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_3_3
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?]
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, 
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.
 Section 6.1 latest draft: http://www.w3.org/2001/XKMS/Drafts/XKMS-20030723/#XKMS_2_0_LC3_Section_6_1
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"
The changes you proposed to the specification have been accepted Issue a - added forward links to the sections that describe protocolsIssue b - Fixed - see para 36issue c - Fixed - See Section 1.5, 4Issue d - Fixed - Section 2 is now protocol exchanges
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".
The changes you proposed to the specification have been accepted and the revised version of the specification may be seen at 
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.
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.
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.
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.
2) In the schema for <xkms:ValidityInreval/> element "NotBefore" and "NotAfter" attributes do not have "use=\"optional\"" specified.
Fixed -  line 
3) The "maxOccurs=\"3\"" for <xkms:KeyUsage/> element may prevent schema extension in the future, I would suggest to change this to "maxOccurs=\"unbound\"".
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.
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.  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="firstname.lastname@example.org"/> </QueryKeyBinding> </ValidateRequest> 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="email@example.com" /> <Status StatusValue="Valid"> <ValidReason>Signature</ValidReason> <ValidReason>IssuerTrust</ValidReason> <ValidReason>RevocationStatus</ValidReason> <ValidReason>ValidityInterval</ValidReason> </Status> </KeyBinding> </ValidateResult>
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: 126.96.36.199 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#" /> 188.8.131.52 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 184.108.40.206 Response the value of RequestId should be "#I4294d3993de300c1ef54d49bd0903b2d" according to the specification.
I couldn't understand the logic of putting '#' before the Id values in XKMS Response.
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.
http://www.w3.org/TR/xkms2/ Just before line 386, Appendix DReferences -- TYPO; Need Space in between D & References [CSP] TBD -- FILL-IN HERE !!
Fixed  
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.
Fixed  
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.
Section 2.4, paragraph 51, 52, "ResponseMechanism" should have "Pending" instead of "Asynchronous".
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?
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?
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 220.127.116.11 example.
6. Section 18.104.22.168, 'RequestID' value should be '#I4294d3993de300c1ef54d49bd0903b2d".
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.
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.
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?
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.
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.
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.
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.
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.
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.
1. Section 3.1, can we have some other XML elements besides XKMS content inside Body element? Document does not say anything about that.
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.
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?
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.
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
I couldn't understand the logic of putting '#' before the Id values in XKMS Response.
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.
Last update: $Date: 2004/03/12 16:05:53 $
This page was generated as part of the Extensible Issue Tracking System (ExIT)
Copyright © 2003, 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply. Your interactions with this site are in accordance with our public and Member privacy statements.