W3C

DRAFT XKMS Interop Matrix - 2004xxxx

Pre-CR implementation intentions:
http://www.w3.org/2001/XKMS/pre-cr.html
Comments/changes:
Guillermo Alvaro Rey <alvarorg@cs.tcd.ie>
Mailing Lists
General Discussion: www-xkms@w3.org
Subscribe: www-xkms-request@w3.org
??? In Subject: (un)subscribe

Archive: http://lists.w3.org/Archives/Public/www-xkms/

1. Message processing mechanisms
2. Message Syntax
3. X-KISS Protocol Set
4. X-KRSS Protocol Set
5. Bindings
6. Misc

1. Message processing mechanisms

For each of the services defined by X-KISS and X-KRSS:
Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
PROTOCOL EXCHANGES
REQUEST TYPES
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 SHOULD
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. MUST NOT Y
SYNCHRONOUS PROCESSING
Synchronous Request / Response
ASYNCHRONOUS PROCESSING
Initial Request
Requestor generation of the Request Message - ResponseMechanism value Pending MUST be specified MUST Y
Pending Request
TWO PHASE REQUEST PROTOCOL
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. MUST NOT Y
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. SHOULD
Phase 1
Requestor generation of the Phase 1 Request Message - ResponseMechanism value Represent MUST be specified MUST Y
Phase 2
COMPOUND REQUESTS AND RESPONSES
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. MUST NOT

table 1

2. Message Syntax

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
MESSAGE BASE
MessageAbstractType type Y
Id REQUIRED Y
Service REQUIRED Y
Nonce OPTIONAL Y
<ds:Signature> OPTIONAL
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. MUST NOT
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. MUST
<MessageExtension> ANY NUMBER
<OpaqueClientData> OPTIONAL
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. SHOULD
REQUEST MESSAGES
RequestAbstractType type Y
ResponseLimit OPTIONAL Y
<ResponseMechanism> ANY NUMBER Y
<RespondWith> ANY NUMBER Y
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. SHOULD
<PendingNotification> OPTIONAL Y
If the <PendingNotification> element is present the value Pending MUST be specified as a <ResponseMechanism> value. MUST
<OriginalRequestId> OPTIONAL Y
RESPONSE MESSAGES
ResultType type Y
ResultMajor REQUIRED Y
ResultMinor OPTIONAL Y
RequestId OPTIONAL Y
If the MajorResult value has the value Represent the nonce attribute MUST be present and MUST NOT be the empty string. MUST Y
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. MUST
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. MUST
<RequestSignatureValue> OPTIONAL Y
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. MUST NOT
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. MUST
COMPOUND REQUESTS
<CompoundRequest> element Y
<CompoundResult> element Y
STATUS REQUEST
<StatusRequest> element Y
<StatusResult> element Y

table 2

3. X-KISS Protocol Set

3.1 Message processing mechanism

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
Synchronous response - Y
Asynchronous response - Y
Two-phase protocols - Y

table 3

3.2 Message syntax

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
Compound requests - Y
Status requests - Y

table 4

3.3 Services

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
Locate - Y
Validate - Y

table 5

3.4 Detailed

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
LOCATE AND VALIDATE
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. SHOULD
KEY BINDING SPECIFICATION
KeyBindingAbstractType type Y
Id OPTIONAL Y
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. MUST NOT
<ds:KeyInfo> OPTIONAL
<KeyUsage> 0 to 3 Y
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. MUST
<UseKeyWith> ANY NUMBER Y
Application REQUIRED Y
Identifier REQUIRED Y
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. SHOULD
Applications SHOULD NOT forward <UseKeyWith> elements returned in a Locate result in a subsequent Validate query. SHOULD NOT
<UnverifiedKeyBinding> ANY NUMBER Y
<ValidityInterval> OPTIONAL Y
NotBefore OPTIONAL Y
NotOnOrAfter OPTIONAL Y
All dateTime values MUST fully specify the date. MUST Y
Implementations MUST NOT generate time instances that specify leap seconds. MUST NOT Y
<KeyBinding> ANY NUMBER Y
<Status> REQUIRED Y
StatusValue REQUIRED Y
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. MUST Y
<ValidReason> ANY NUMBER Y
<IndeterminateReason> ANY NUMBER Y
<InvalidReason> ANY NUMBER Y
<QueryKeyBinding> REQUIRED Y
<TimeInstant> OPTIONAL Y
Time REQUIRED Y
All dateTime values MUST fully specify the date. MUST Y
LOCATE SERVICE
<LocateRequest> element Y
<LocateResult> element Y
VALIDATE SERVICE
<ValidateRequest> element Y
<ValidateResult> element Y

table 6

4. X-KRSS Protocol Set

4.1 Message processing mechanism

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
Synchronous response -
Asynchronous response -
Two-phase protocols -

table 7

4.2 Message syntax

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
Compound requests -
Status requests -

table 8

4.3 Services

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
Register -
Reissue -
Revoke -
Recover -

table 9

4.4 Detailed

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
KEY REGISTRATION SERVICE DESCRIPTION
REGISTRATION
REISSUE
REVOCATION
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. SHOULD
KEY RECOVERY
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. MUST
Clients supporting key recovery SHOULD support asynchronous processing. SHOULD
REQUEST AUTHENTICATION
An X-KRSS Service SHOULD ensure that all requests are authentic and authorized. [272] Authenticity: The request message originated from the specified party. [273] Integrity: The request message has not been modified. [274] Possession: If a public key is specified in a registration request, proof that the request is authorized by a party that has access to the corresponding private key. SHOULD
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. SHOULD
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. SHOULD
KEY REGISTRATION SERVICE MESSAGE SET
<PrototypeKeyBinding> REQUIRED
<ValidityInterval> OPTIONAL
<RevocationCodeIdentifier> OPTIONAL
<Authentication> REQUIRED
<KeyBindingAuthentication> OPTIONAL
<ds:Signature> REQUIRED
<NotBoundAuthentication> OPTIONAL
Protocol REQUIRED
Value REQUIRED
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. MUST NOT
<ProofOfPossession> OPTIONAL
<ds:Signature> REQUIRED
<PrivateKey> OPTIONAL
<xenc:EncryptedData> REQUIRED
<RevocationCode> CHOICE
REGISTER SERVICE
<RegisterRequest> element
<RegisterResult> element
REISSUE SERVICE
<ReissueRequest> element
<ReissueResult> element
REVOKE REQUEST
<RevokeRequest> element
<RevokeResult> element
RECOVER REQUEST
<RecoverRequest> element
<RecoverResult> element

table 10

5. Bindings

5.1 Bindings

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
Plain HTTP - Y
Soap/1.1 - Y
Soap/1.2 - Y
Payload authentication -
TLS bindings -

table 11

5.2 Detailed

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
SECURITY REQUIREMENTS
Confidentiality
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. SHOULD
A service that supports registration of server generated keys or Key Recovery MUST implement the use of XML Encryption with a strong cipher. MUST
An XKMS service SHOULD support Confidentiality by means of encryption. SHOULD
Request Authentication
An XKMS service SHOULD support Message Request Authentication. SHOULD
Response Authentication
An XKMS service SHOULD support Request Authentication. SHOULD
Persistent Authentication
Message Correlation
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). MUST
In order to prevent response replay and request message substitution attacks the requestor SHOULD ensure that the response corresponds to the request. SHOULD
Request Replay
An XKMS service SHOULD support protection against a Denial of Service attack. SHOULD
Security Issues Summary
If a Register service supports registration of server generated key pairs or key recovery strong encryption of the private key MUST be supported. MUST
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. SHOULD
XKMS Registration services SHOULD support the verification of Proof Of Possession in the initial registration of client generated keys. SHOULD
SOAP BINDING
XKMS implementers should support the SOAP message protocol for interoperability. When doing do, they MUST use the binding described herein. MUST Y
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 MUST Y
SECURITY BINDINGS
Payload Authentication Binding
Secure Socket Layer and Transaction Layer (SSL/TLS)Security Binding
When TLS is to be used in XKMS, XKMS responders MUST support server authenticated TLS. MUST
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. MUST

table 12

6. Misc

Features KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData total
Versions Namespaces and Identifiers
The XML namespace [XML-ns] URI that MUST be used by implementations of this (dated) specification is: http://www.w3.org/2002/03/xkms# MUST Y
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. MUST Y
Use of Limited-Use Shared Secret Data
Applications MUST ensure that the limited use shared secret data contains sufficient entropy to prevent dictionary attacks. MUST
CONFORMANCE
A sender SHOULD NOT send a message unless it is known that it will be accepted by the recipient. SHOULD NOT
Services SHOULD support retrieval of their own credential by means of the Locate operation with the XKMS protocol URI. SHOULD
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. MUST
Services SHOULD support status operations if asynchronous processing and compound requests are also supported SHOULD
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. MUST
A conforming XKMS service MUST be capable of returning an immediate response to any XKMS request. MUST
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. RECOMMENDED
Services that support Compound Operations SHOULD support compound requests SHOULD
Clients SHOULD support use of the two phase request protocol. The additional complexity of implementing the two phase protocol is not high and allows a service to provide a response even in cases where it is under a denial of service attack. SHOULD Y
Services MUST support the use of HTTP transport MUST
Services MUST support the use of SOAP 1.2 encapsulation MUST
No Security, Locate: REQUIRED REQUIRED
No Security, Others than Locate: RECOMMENDED RECOMMENDED
Payload Authentication I & II: RECOMMENDED RECOMMENDED
TLS Binding I, II & III: RECOMMENDED RECOMMENDED
If XML Signature is used, Exclusive Canonicalization MUST be supported. MUST
SECURITY CONSIDERATIONS
Replay Attacks
Implementations SHOULD ensure that replay of a previous XKMS response is not possible. SHOULD
Denial of Service
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. SHOULD
Recovery Policy
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. SHOULD
Security of Limited Use Shared Secret
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 SHOULD
Confidentiality of Opaque Client Data
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. SHOULD NOT
Security of Not Bound Authentication Data
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. MUST
Signature Oracle
XKMS services that provide signed responses SHOULD ensure that the requestor cannot solicit a predicted response, thus providing a signing oracle. SHOULD
Privacy
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]. SHOULD
Security of the Private Key
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. MUST
Message Length Disclosure Vulnerabilities
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 SHOULD

table 13

Guillermo Alvaro Rey <alvarorg@cs.tcd.ie>