W3C

DRAFT XKMS Interop Matrix - 20040519

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:
KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData Total
PROTOCOL EXCHANGES
It is recommended XKMS implementers support SOAP over HTTP for interoperability purposes. XKMS is transport protocol agnostic however and MAY be layered over any SOAP transport. MAY
Implementers MAY implement bindings to other protocols at their option. MAY
No XKMS operations are idempotent, that is all XKMS requests MAY cause a change of state. MAY
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
A client MAY advise a service that it will accept asynchronous processing of a request by specifying the ResponseMechanism value Pending. An XKMS service that receives a request that specifies the ResponseMechanism value Pending MAY respond either synchronously or asynchronously. If the service is to respond asynchronously it advises the client that the response value will be returned asynchronously by specifying the MajorResult code Pending. MAY
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
Asynchronous processing MAY be used to allow administrator intervention during the processing of a request. For example an administrator might be required to verify and approve all XKRSS Registration requests before they are processed. MAY
SYNCHRONOUS PROCESSING
Synchronous Request / Response
Requestor generation of the Request Message - ResponseMechanism values Represent and/or Pending MAY be specified MAY
ASYNCHRONOUS PROCESSING
Initial Request
Requestor generation of the Request Message - ResponseMechanism value Pending MUST be specified MUST
Pending Request
The client MAY request the return of the result values before processing has been completed. In this case the service responds to the Pending Request with the MajorResult code Pending. MAY
TWO PHASE REQUEST PROTOCOL
A client MAY advise a service that it supports the two phase request protocol by specifying the ResponseMechanism value Represent. An XKMS service advises the client that the use of the two phase request protocol is required by specifying the MajorResult code Represent. MAY
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
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
Phase 2
COMPOUND REQUESTS AND RESPONSES
An XKMS service MAY support processing of Compound Requests. MAY
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. SHOULD
An XKMS service MAY support the use of the two phase protocol on the outer request of a compound response. The two phase protocol SHOULD NOT be used on an inner response. If an inner request specifies the ResponseMechanism value Represent the value SHOULD be ignored. MAY
An XKMS service MAY support the use of asynchronous processing in conjunction with a compound request. Asynchronous processing MAY be performed on the compound request as a whole, on individual inner requests or both. MAY
A service MAY return synchronous and asynchronous responses in a single compound response. MAY
Since the semantics of a compound request are exactly the same as if each inner request were made separately a client MAY issue separate pending requests to obtain the results of the inner requests of a previous compound request. Alternatively a client MAY issue a compound request containing multiple inner pending requests corresponding to requests which were originally made independently. MAY

2. Message Syntax

KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData Total
MESSAGE BASE
MessageAbstractType type - - - - - - - 0
Id REQUIRED - - - - - - - 0
Service REQUIRED - - - - - - - 0
Nonce OPTIONAL - - - - - - - 0
<ds:Signature> OPTIONAL - - - - - - - 0
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 - - - - - - - 0

<OpaqueClientData>

 OPTIONAL - - - - - - - 0
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
A client MAY use Opaque client data in conjunction with asynchronous request processing to match a responses to the original request context. Opaque client data MAY also be used in conjunction with synchronous request processing to provide context information for purposes such as audit trail reconciliation. MAY
REQUEST MESSAGES - - - - - - - 0
RequestAbstractType type - - - - - - - 0
ResponseLimit OPTIONAL
<ResponseMechanism> ANY NUMBER - - - - - - - 0
Pending - The requestor is prepared to accept a response that uses asynchronous processing, i.e. the service MAY return the MajorResult code Pending MAY
Represent - The requestor is prepared to accept a response that uses the two phase protocol, i.e. the service MAY return the MajorResult code Represent MAY
<RespondWith> ANY NUMBER - - - - - - - 0
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 - - - - - - - 0
If the <PendingNotification> element is present the value Pending MUST be specified as a <ResponseMechanism> value. MUST
Mechanism [Required] A URI that specifies the protocol by which the notification MAY be made

Identifier [Required] A URI that specifies the address to which the notification MAY be made

 MAY
<OriginalRequestId> OPTIONAL
RESPONSE MESSAGES
ResultType type
ResultMajor REQUIRED
ResultMinor OPTIONAL
TooManyResponses - The request resulted in the number of responses that exceeded either  the ResponseLimit value specified in the request or some other limit determined by the service. The service MAY either return a subset of the possible responses or none at all. MAY
RequestId OPTIONAL
If the MajorResult value has the value Represent the nonce attribute MUST be present and MUST NOT be the empty string. MUST
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
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.
 SHOULD
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
<CompoundResult> element
STATUS REQUEST
<StatusRequest> element
<StatusResult> element

3. X-KISS Protocol Set

KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData Total
LOCATE AND VALIDATE
The XKMS service MAY resolve the <ds:Keyinfo> element using local data or MAY relay request to other servers. MAY
Both the request and/or the response MAY be signed, to both authenticate the sender and protect the integrity of the data being transmitted, using an XML Signature. MAY
Validate: If the information in the prototype is incomplete, the XKMS service MAY obtain additional data required from an underlying PKI Service. MAY
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
A client MAY rely on the information returned by the service without further validation provided that the client has a means to determine that the information returned is authentic and is assured that the validation service applied the means of validation appropriate to the circumstances. MAY
KEY BINDING SPECIFICATION
An XKMS service MAY provide an interface to an underlying PKI such as PKIX or PGP. This specification does not define how XKMS operations interact with the underlying PKI. The XKMS key binding MAY be bound to a data object such as a certificate or key signing in the underlying PKI such that XKMS operations on the key binding result in a corresponding change to the data structures in the underlying PKI and vice versa. MAY
KeyBindingAbstractType type
Id OPTIONAL
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
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
Application REQUIRED
Identifier REQUIRED
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
<UseKeyWith> URI identifiers MAY be specified that represent key binding issuance and/or use policies instead of or in addition to an application protocol. MAY
Applications SHOULD NOT forward <UseKeyWith> elements returned in a Locate result in a subsequent Validate query. SHOULD NOT
<UnverifiedKeyBinding> ANY NUMBER
<ValidityInterval> OPTIONAL
NotBefore OPTIONAL
NotOnOrAfter OPTIONAL
All dateTime values MUST fully specify the date. MUST
Implementations MUST NOT generate time instances that specify leap seconds. MUST NOT
<KeyBinding> ANY NUMBER
<Status> REQUIRED
StatusValue REQUIRED
The status value MAY be supplemented with codes that state the status of specific aspects of the key binding status that were validated. MAY
If reason codes are specified StatusValue 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
<ValidReason> ANY NUMBER
<IndeterminateReason> ANY NUMBER
<InvalidReason> ANY NUMBER
<QueryKeyBinding> REQUIRED
<TimeInstant> OPTIONAL
Time REQUIRED
All dateTime values MUST fully specify the date. MUST
LOCATE SERVICE
<LocateRequest> element
<LocateResult> element
In some circumstances a Locate operation MAY return multiple matching results. MAY
VALIDATE SERVICE
<ValidateRequest> element
<ValidateResult> element
In some circumstances a Validate operation MAY return multiple matching results. MAY

4. X-KRSS Protocol Set

KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData Total
KEY REGISTRATION SERVICE DESCRIPTION
The Register operation MAY be used in a mode where client requests are accepted by an intermediary such as a Local Registration Authority (LRA) and forwarded to a Master Registration Authority (MRA). MAY
REGISTRATION
Generation of the public key pair MAY be performed by either the client or the Registration service. MAY
The registration service MAY require the client to provide additional information to authenticate the request. If the public key pair is generated by the client, the service MAY require the client to provide Proof of Possession of the private key. MAY
All information contained in the prototype of the requested key binding is advisory to the service and MAY be ignored or overridden at the option of the service. MAY
If the registration service accepts the request a key binding is registered. This key binding MAY include some, all or none of the information provided by the prototype key binding and MAY include additional information. MAY
The registration service MAY return part or all of the registered key binding to the client. MAY
REISSUE
A Registration service MAY permit clients to reissue previously issued key bindings. MAY
REVOCATION
A Registration service MAY permit clients to revoke previously issued key bindings. A revocation request need only contain sufficient information to identify the key binding to be revoked and the authority for the revocation request. MAY
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
The security policy of the issuer MAY consider the key recovery process itself as an actual or potential compromise of the recovered key and thus require the revocation of all associated key bindings, particularly if the key recovery was requested by a third party such as the supervisor of the key holder. MAY
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
A response message MAY contain multiple key bindings if the operation resulted in the creation or a change in the status of multiple key bindings. MAY
<PrototypeKeyBinding> REQUIRED
All fields in a <PrototypeKeyBinding> element are advisory and MAY be ignored by the service. MAY
<ValidityInterval> OPTIONAL
<RevocationCodeIdentifier> OPTIONAL
The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism. MAY
<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
The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism. MAY
REGISTER SERVICE
<RegisterRequest> element
<RegisterResult> element
REISSUE SERVICE
<ReissueRequest> element
<ReissueResult> element
REVOKE REQUEST
<RevokeRequest> element
<RevokeResult> element
RECOVER REQUEST
<RecoverRequest> element
<RecoverResult> element

5. Bindings

KeyWord xmlsec Trinity College Rich Salz Entrust Phaos Tommy Lindberg SQLData Total
SECURITY REQUIREMENTS
Security enhancements MAY be required to control the following risks: Confidentiality, Request Authentication, Response Authentication, Persistent Authentication, Response Replay, Request Substitution, Request Replay, Denial of Service. MAY
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. MAY
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
An XKMS service MAY determine the trustworthiness of an encryption key by reference to another XKMS service provided that the chain of references is eventually grounded by a mechanism that establishes direct trust between the client and the service. MAY
Request Authentication
Request Message Authentication MAY be required. An XKMS Service MAY require request authentication in deployments where the XKMS service is restricted to a specific audience, possibly as a paid service. An XKMS Service MAY require request authentication in contexts where different levels of service are supported according to the identity of the requestor. MAY
In addition various forms of Authentication MAY be required in the XKRSS Registration protocol to confirm the credentials of the party initiating the request and their possession of the private key component of the key pair(s) being registered. MAY
An XKMS service SHOULD support Message Request Authentication. SHOULD
Response Authentication
Message Response Authentication MAY be required. Message Response Authentication is required in any deployment of a Validate service. A Locate service that provides only data that is self-authenticating such as X.509 or PGP certificates does not require Message Response Authentication. MAY
An XKMS service SHOULD support Request Authentication. SHOULD
Persistent Authentication
An XKMS service MAY support Persistent Authentication by means of a digital signature on the message. MAY
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 MAY provide protection against a Request Replay. MAY
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
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
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

6. Misc

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
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
Use of Limited-Use Shared Secret Data
The authentication data itself MAY be randomly generated and represent an underlying numeric value, or MAY be a password or phrase. MAY
Applications MUST ensure that the limited use shared secret data contains sufficient entropy to prevent dictionary attacks. MUST
The default MAC algorithm used is HMAC-SHA1. Other MAC algorithms MAY be used provided that the client is advised that the service accepts such algorithms by means of an out of band mechanism such as a Web Service description or policy mechanism. MAY
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
Services MAY support Asynchronous responses be supported on these operations (Locate, Validate, Revoke). MAY
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
Services MUST support the use of HTTP transport MUST
Services MUST support the use of SOAP 1.2 encapsulation MUST
Services MAY support the use of SOAP 1.1 encapsulation MAY
No Security, Locate: REQUIRED REQUIRED
No Security, Others: 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
This MAY be a message level or transport level protocol that protects both encryption and integrity such as TLS [RFC-2246]. Note that merely encrypting the shared secret does not provide adequate security since the <PassPhraseAuth> element is not cryptographically bound to the message. MAY
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

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

Last updated: $Date: 2004/05/19 14:13:58 $