Copyright © 2004 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document draws on assertions found in the XML Key Management specifications [XKMS Part1], [XKMS Part2], and provides a set of tests in order to show whether the assertions are implemented in a XKMS client/server.
This document is an editors' copy that has no official standing.
1. Introduction
2. XKMS Assertions
2.1 XKMS, Part 1
Assertions
2.2 XKMS, Part 2
Assertions
3. XKMS Test Collection
3.1 Introduction
3.2 Tests
4. References
4.1 Normative References
This document draws on assertions found in the XKMS specifications, and provides a set of tests in order to show whether the assertions are implemented in a XKMS client/server.
The means by which the service specifies protocol options which it accepts is outside the scope of this document. If the mechanism used for this purpose uses URI based identifiers for this purpose the following identifiers SHOULD be used: Asynchronous Processing http://www.w3.org/2002/03/xkms#Asynchronous Two Phase Request Protocol http://www.w3.org/2002/03/xkms#Represent Compound Requests and Responses http://www.w3.org/2002/03/xkms#Compound
An XKMS service MUST NOT return the MajorResult code Pending unless the ResponseMechanism value Pending was specified in the corresponding request. If an XKMS service receives a request that cannot be processed synchronously and the ResponseMechanism value Pending is not specified the MajorResult code Receiver and MinorResult codeNotSynchronous are returned.
Requestor generation of the Request Message - ResponseMechanism value Pending MUST be specified
An XKMS service MUST NOT return the MajorResult code Represent unless the ResponseMechanism value Represent was specified in the corresponding request. If an XKMS service requires the use of the Two Phase Request protocol and the ResponseMechanism value Represent is not specified in the corresponding request the MajorResult code Sender and MinorResult codeRepresentRequiredare returned.
The service SHOULD verify that the nonce value specified in a second phase request was recently generated by the service. The service MAY verify that the nonce value has not been previously responded to.
Requestor generation of the Phase 1 Request Message - ResponseMechanism value Represent MUST be specified
If the ResultMajor value of the outer response is Success the compound response SHOULD contain an inner response response element corresponding to each inner request element of the compound request. If the the ResultMajor value of the outer response is not Success the response MUST NOT contain any inner responses. If a compound response has an outer ResultMajor value Success but does not contain a response corresponding to an inner request the ResultMajor value failure is assumed for that inner request.
The scope of the signature is the entire request message (i.e. the element derrived from MessageAbstractType) and is specified using a reference to the Id attribute specified in the MessageAbstractType abstract type. The empty identifier "" MUST NOT be used.
Data specified by the client that is opaque to the service. An XKMS service SHOULD return the value of the <OpaqueClientData> element unmodified in a request in a response with status code Success.
Validation of XML Signatures MUST be done independent of any ancestral XML context of the message. This may be achieved by: Isolating the XKMS message from any 'wrapper' (eg. SOAP) before validation, or; Specifying a canonicalization algorithm, such as Exclusive XML Canonicalization, in <SignedInfo>:<CanonicalizationMethod> to exclude ancestral XML context during the validation of the message. For interoperability purposes XKMS implementations MUST support the use of Exclusive XML Canonicalization.
If the <PendingNotification> element is present the value Pending MUST be specified as a <ResponseMechanism> value.
The Service SHOULD return a requested data element if it is available. The Service MAY return additional data elements that were not requested. In particular, the service MAY return data elements specified in the request with the response.
If the MajorResult value has the value Represent the nonce attribute MUST be present and MUST NOT be the empty string.
Care must be taken when signing responses to ensure that the service does not provide a signing oracle, that is sign messages whose content is guessable by an attacker. Implementations MUST ensure that response messages contain a sufficient quantity of unpredictable data such as a pseudo-randomly chosen Id attribute.
Represent - Not Final - The service has not acted on the request. In order for the request to be acted upon the request MUST be represented with the specified nonce in accordance with the two phase protocol.
A service SHOULD include the <RequestSignatureValue> element in a response if the following conditions are satisfied and MUST NOT include the value otherwise: The <ds:Signature> element was present in the corresponding request The service successfully verified the <ds:Signature> element in the corresponding request, and The ResponseMechanism RequestSignatureValue was specified.
If the <RequestSignatureValue> element is present in a response the requestor MUST reject the message if either: The corresponding request was not authenticated, or: The value ds:Signature/ds:SignatureValue in the request does not match the value RequestSignatureValue in the response.
A Location service SHOULD attempt to provide only information which is trustworthy to the best of its knowledge but does not provide any assurance that it will do so. Information obtained from a Locate service SHOULD NOT be relied upon unless it is validated.
Clients MUST NOT rely on the key binding identifier being either unique or stable. In the case that an XKMS service is providing an interface to an underlying PKI, clients MUST NOT rely on the service choosing key binding identifiers that are either the same as or bear a systematic relationship to the serial numbers or other identifiers of the corresponding credentials in the underlying PKI.
If a key usage is specified in a KeyBinding that the cryptographic algorithm associated with the key does not support the element MUST be ignored. If a key usage is specified in a QueryKeyBinding however the key usage forms part of the criteria the service should attempt to match.
An XKMS service SHOULD support discovery of the supported security profiles and corresponding key bindings by means of a Locate operation that specifies the XKMS application URI and the URL of the service role. Note that as with any other Locate operation the credentials returned by this mechanism SHOULD only be considered trustworthy if validated according to the trust policy of the client.
Applications SHOULD NOT forward <UseKeyWith> elements returned in a Locate result in a subsequent Validate query.
Implementations MUST NOT generate time instances that specify leap seconds.
If reason codes are specifiedStatusValue attribute MUST be consistent with the reason codes specified as follows: If an <InvalidReason> code is present the StatusValue attibute MUST have the value Invalid If an <IndeterminateReason> code is present the StatusValue attibute MUST have the either the value Indeterminate or the value Invalid. If neither an <InvalidReason> nor an <IndeterminateReason> code is present the StatusValue attibute MAY have any defined value, i.e. Valid, Indeterminate or Invalid.
If an XKMS key binding is bound to a data object in an underlying PKI the revocation of the key binding SHOULD result in the revocation of the underlying data object. For example if the XKMS key binding is bound to an X.509 certificate the revocation of the key binding SHOULD result in revocation of the underlying certificate.
A Registration service MAY support key recovery. For key recovery to be possible the private key to be recovered MUST have been previously escrowed with the recovery service, for example by means of the XKRSS registration of a server generated key.
An X-KRSS Service SHOULD ensure that all requests are authentic and authorized.
Services SHOULD require that clients demonstrate Proof of Possession of the private key components of a public key if a request is made to register a valid key binding bound to that public key.
Services SHOULD accept Proof of Possession of the private key component of a public key to effect revocation of any key binding bound to that key.
The authentication data is not securely bound to the request and thus the element [NotBoundAuthentication] MUST NOT be employed except in circumstances where the message or transport protocol provides adequate protection of both confidentiality and integrity.
The XML namespace [XML-ns] URI that MUST be used by implementations of this (dated) specification is: http://www.w3.org/2002/03/xkms#
While applications MUST support XML and XML namespaces, the use of internal entities [XML] or the "xkms" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.
Applications MUST ensure that the limited use shared secret data contains sufficient entropy to prevent dictionary attacks.
A sender SHOULD NOT send a message unless it is known that it will be accepted by the recipient.
Services SHOULD support retrieval of their own credential by means of the Locate operation with the XKMS protocol URI.
A conforming XKMS service MUST support at least one XKMS operation, that is there MUST be at least one possible input that results in the result Success.
Services SHOULD support status operations if asynchronous processing and compound requests are also supported
A conforming XKMS service MUST accept any valid XKMS request sent to it and be capable of responding to the request with a correctly formatted XKMS result. If a service does not support an operation it MUST respond to all requests for a particular operation with the result Sender.MessageNotSupported.
A conforming XKMS service MUST be capable of returning an immediate response to any XKMS request.
Asynchronous Response for Register, Reissue, Recover: RECOMMENDED+: Processing of certain XKRSS operations may require manual intervention by an operator in certain circumstances. It is therefore recommended that clients support the use of asynchronous processing with these operations unless it is known that all requests will be serviced immediately.
Services that support Compound Operations SHOULD support compound requests
A client MAY offer asynchronous processing of Pending and Status operations however a service MUST NOT return a pending response.
Implementations SHOULD ensure that replay of a previous XKMS response is not possible.
XKMS Services SHOULD take measures to prevent or mitigate denial of service attacks. In particular XKMS Services SHOULD NOT perform an unlimited number of resource intensive operations unless the request comes from an authenticated source.
Services SHOULD carefully assess the extent to which a recovery operation compromises a private key and apply sufficient controls such as the revocation of the underlying key binding as appropriate.
Applications SHOULD enforce the following minimum entropy values for the shared secret: Registration of Client Generated Key The shared secret SHOULD contain a minimum of 32 bits of entropy if the service implements measures to prevent guessing of the shared secret and a minimum of 128 bits of entropy otherwise. Registration of Service Generated Key The shared secret SHOULD have a minimum of 128 bits of entropy
Clients SHOULD NOT send confidential or privacy sensitive data to an XKMS Service as Opaque Data unless it is encrypted such that it is not disclosed to the service.
If a service supports the use of authentication using the <NotBoundAuthentication> element, controls MUST be employed to ensure the confidentiality of the authentication data and to ensure that the <NotBoundAuthentication> is bound to the request.
XKMS services that provide signed responses SHOULD ensure that the requestor cannot solicit a predicted response, thus providing a signing oracle.
An XKMS service MAY solicit data which is subject to privacy concerns. In certain circumstances management of such data MAY be subject to government regulation, corporate policies or contractual obligations. Deployments SHOULD consider whether the information they collect is subject to such concerns and if necessary deploy a privacy notification mechanism such as P3P [P3P].
Implementations MUST ensure that in cases where a private key is generated by the service, the information used to encrypt the private key data is adequately protected. In particular if an authentication pass phrase exchanged out of band is used to encrypt the private key the implementation MUST ensure that the out of band communication mechanism adequately protects the confidentiality of the pass phrase.
In certain circumstances the length of an encrypted response MAY reveal information that is useful to an attacker. For example a short message might indicate that a request was refused. Deployments SHOULD consider whether such disclosures might result in compromise of confidential information
Confidentiality MAY be a requirement for an XKMS service. Deployments SHOULD consider the extent to which the content of XKMS messages reveal sensitive information. A confidentiality requirement MAY exist even if a service only provides information from public sources as the contents of a request might disclose information about the client.
A service that supports registration of server generated keys or Key Recovery MUST implement the use of XML Encryption with a strong cipher.
An XKMS service MUST support a means of ensuring correct message correlation. That is the requestor must be assured that the response returned was made in response to the intended request sent to the service and not a modification of that request (Request Substitution attack) or a response to an earlier request (response replay attack).
In order to prevent response replay and request message substitution attacks the requestor SHOULD ensure that the response corresponds to the request.
An XKMS service SHOULD support protection against a Denial of Service attack.
If a Register service supports registration of server generated key pairs or key recovery strong encryption of the private key MUST be supported.
XKMS Registration services SHOULD support the authentication of registration requests for initial registration of a key binding. Registration requests for secondary registration of previously issued credentials (i.e. a signed key binding or a digital certificate) MAY be permitted without authentication.
XKMS Registration services SHOULD support the verification of Proof Of Possession in the initial registration of client generated keys.
XKMS implementers should support the SOAP message protocol for interoperability. When doing do, they MUST use the binding described herein.
XKMS 2.0 implementations MUST support the use of SOAP 1.2. For near term compatibility with existing tools and infrastructure, SOAP 1.1 MAY be used
When TLS is to be used in XKMS, XKMS responders MUST support server authenticated TLS.
All XKMS clients and responders which support TLS MUST support the TLS_RSA_WITH_3DES-EDE_CBC_SHA ciphersuite. Other ciphersuites MAY be supported, but weak ciphersuites intended to meet export restrictions ("export grade") are NOT RECOMMENDED to be supported.
Message Request
Message Response
Message Request
Message Response