Client1 | Client2 | Client3 | Client4 | |
Server 1 | 1 2 | 1 | 4 | 1 4 |
Server 2 | 1 | 4 | 1 2 3 4 | |
Server 3 | 1 2 | 3 4 | 4 | 3 4 |
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
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
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
Features | KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | total |
Compound requests | - | Y | |||||||
Status requests | - | Y |
table 4
Features | KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | total |
Locate | - | Y | |||||||
Validate | - | Y |
table 5
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
Features | KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | total |
Synchronous response | - | ||||||||
Asynchronous response | - | ||||||||
Two-phase protocols | - |
table 7
Features | KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | total |
Compound requests | - | ||||||||
Status requests | - |
table 8
Features | KeyWord | xmlsec | Trinity College | Rich Salz | Entrust | Phaos | Tommy Lindberg | SQLData | total |
Register | - | ||||||||
Reissue | - | ||||||||
Revoke | - | ||||||||
Recover | - |
table 9
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
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
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
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>