[2]This document specifies protocols for
distributing and registering public keys, suitable for use in conjunction
with the W3C Recommendations for XML Signature [XML-SIG] and XML Encryption [XML-Enc]. The XML Key Management Specification (XKMS)
comprises two parts — the XML Key Information Service Specification
(X-KISS) and the XML Key Registration Service Specification (X-KRSS).
This section describes the status of this document at the time
of its publication. Other documents may supersede this document. A
list of current W3C publications and the latest revision of this
technical report can be found in the W3C technical reports index at
http://www.w3.org/TR/.
This document is a W3C
Recommendation. It has been reviewed by W3C Members and other interested
parties and has been endorsed by the Director. It is a stable document and
may be used as reference material or cited as a normative reference from
another document. W3C's role in making the Recommendation is to draw
attention to the specification and to promote its widespread deployment. This
enhances the functionality and interoperability of the Web.
This document has been produced by the XKMS Working Group (WG).
The English version of this specification is the only normative version. Translations
of this document may be available.
If you have any comments on this document, send them to www-xkms@w3.org, a mailing
list with a public archive. An errata
list for this edition is available.
This is Part 1 of the W3C Recommendation for the XML Key
Management Specification (XKMS Version 2.0). This document specifies
protocols for distributing and registering public keys, suitable for use in
conjunction with the proposed standard for XML Signature and XML Encryption. The XML Key Management Specification (XKMS) comprises
two services — the XML Key Information Service (X-KISS) and the XML Key
Registration Service Specification (X-KRSS). Part 2 of this
specification covers different protocol bindings with security
characteristics for XKMS. For background on this work, please see the XKMS Activity Statement.
This document is based on the XKMS
Version 2.0 Proposed Recommendation of 2 May 2005. Feedback received during
that review resulted in minor editorial changes. Evidence of interoperation
between at least two implementations of this specification are documented in
the Implementation
Report. Changes to this document since the Proposed Recommendation
version are detailed in Appendix
F.
This document was produced under the 24
January 2002 CPP as amended by the W3C Patent Policy
Transition Procedure. The Working Group maintains a public list of
patent disclosures relevant to this document; that page also
includes instructions for disclosing a patent. An individual who has
actual knowledge of a patent which the individual believes contains
Essential Claim(s) with respect to this specification should disclose
the information in accordance with section
6 of the W3C Patent Policy.
[8]This document specifies protocols for
distributing and registering public keys, suitable for use in conjunction
with the standard for XML Signatures [XML-SIG] defined
by the World Wide Web Consortium (W3C) and the Internet Engineering Task
Force (IETF) and companion standard for XML encryption [XML-ENC]. The XML Key Management Specification
(XKMS) comprises two parts -- the XML Key Information Service Specification
(X-KISS) and the XML Key Registration Service Specification (X-KRSS).
[9]These protocols do not require any particular
underlying public key infrastructure (such as X.509) but are designed to be
compatible with such infrastructures.
[10]This document defines the following service
specifications:
- XML Key Information Service
Specification:
- A protocol to support the delegation by an application to a service
of the processing of key information associated with an XML signature,
XML encryption, or other usage of the XML Signature [XML-SIG] <ds:KeyInfo>
element.
- XML Key Registration Service
Specification:
- A protocol to support the registration of a key pair by a key pair
holder, with the intent that the key pair subsequently be usable in
conjunction with the XML Key Information Service Specification or a
Public Key Infrastructure (PKI) such as [X.509][PKIX].
1.1 Editorial and Conformance
Conventions
[11]This specification uses XML Schemas [XML-schema] to describe the content model.
[12]The key words "MUST", "MUST NOT", "REQUIRED",
"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this specification are to be interpreted as described in [RFC2119]:
[13]"they MUST only be used where it is actually
required for interoperation or to limit behavior which has potential for
causing harm (e.g., limiting retransmissions)"
[14]Consequently, we use these capitalized keywords
to unambiguously specify requirements over protocol and application features
and behavior that affect the interoperability and security of
implementations. These key words are not used (capitalized) to describe XML
grammar; schema definitions unambiguously describe such requirements and we
wish to reserve the prominence of these terms for the natural language
descriptions of protocols and features. For instance, an XML attribute might
be described as being "optional." Compliance with the XML-namespace
specification [XML-NS] is described as
"REQUIRED."
[17]The following terms are used within this
document with the particular meaning indicated below:
[18] Service
An application that provides computational or
informational resources on request. A service may be provided by several
physical servers operating as a unit.
[20] Client
An application that makes requests of a
service. The concept of 'client' is relative to a service request; an
application may have the role of client for some requests and service for
others.
[20a] Payload Security
Use of end-to-end security mechanisms, such as XML DSIG, not dependent
on the transport mechanism (HTTP, TLS, SOAP, ...).
[21]No provision is made for an explicit version
number in this syntax. If a future version is needed, it will use a different
namespace. The XML namespace [XML-ns] URI that MUST
be used by implementations of this (dated) specification is:
http://www.w3.org/2002/03/xkms#
[22]This namespace is also used as the prefix for
algorithm identifiers used by this specification. 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.
[23]In this document, certain namespace prefixes
represent certain namespaces in the schema fragments (shown on a yellow
background) as follows:
| Prefix |
Specification |
Schema |
| xsi |
XML Schema |
http://www.w3.org/2001/XMLSchema |
| ds |
XML Signature |
http://www.w3.org/2000/09/xmldsig# |
| xenc |
XML Encryption |
http://www.w3.org/2001/04/xmlenc# |
| ec |
Exclusive Canonicalization |
http://www.w3.org/2001/10/xml-exc-c14n# |
| xkms |
XKMS |
http://www.w3.org/2002/03/xkms# |
[24]For clarity, some examples of XML are not
complete documents and namespace declarations may be omitted from XML
fragments.
[25]In all examples (shown on a light blue
background) and in the body of the text the default namespace refers to the
xkms namespace itself. This means that namespace prefixes are omitted for all
element and type names in the xkms
namespace.
[26]These namespaces are declared in the XKMS
schema as follows:
<?xml version="1.0"?>
<schema targetNamespace="http://www.w3.org/2002/03/xkms#"
xmlns:xkms="http://www.w3.org/2002/03/xkms#"
xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
xmlns="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<import namespace="http://www.w3.org/2000/09/xmldsig#"
schemaLocation="xmldsig-core-schema.xsd"/>
<import namespace="http://www.w3.org/2001/04/xmlenc#"
schemaLocation="xenc-schema.xsd"/>
<annotation>
<documentation xml:lang="en">
XML Schema for XKMS 2.0 Proposed Recommendation Candidate 2005
</documentation>
</annotation>
<!-- /Namespace -->
...
<!-- End Schema -->
</schema>
[27]Internet Protocol addresses and Domain Name
System names used in examples are purposely chosen to avoid confusion with
assigned addresses and names. All Internet Protocol Addresses are in the
reserved non-routable network 10.x.x.x. All DNS names are in the reserved
domain example.com.
[28]X-KISS allows a client to delegate part or all
of the tasks required to process XML Signature [XML-SIG] <ds:KeyInfo> elements to an XKMS service.
A key objective of the protocol design is to minimize the complexity of
applications using XML Signature [XML-SIG]. By
becoming a client of the XKMS service, the application is relieved of the
complexity and syntax of the underlying PKI used to establish trust
relationships, which may be based upon a different specification such as
X.509/PKIX, SPKI or PGP.
[29]By design, the XML Signature specification [XML-SIG] does not mandate use of a particular trust
policy. The signer of a document is not required to include any key
information but may include a <ds:KeyInfo>
element that specifies the key itself, a key name, X.509 certificate, a PGP
key identifier etc. Alternatively, a link may be provided to a location where
the full <ds:KeyInfo> information may be
found.
[30]The information provided by the signer may
therefore be insufficient by itself to perform cryptographic verification and
decide whether to trust the signing key, or the information may not be in a
format the client can use. For example:
- The key may be specified by a name only.
- The local trust policy of the client may require additional information
in order to trust the key.
- The key may be encoded in an X.509 certificate that the client cannot
parse.
[31]In the case of an encryption operation:
- The client may not know the public key of the recipient.
1.5
(Non-Normative)
[32]X-KRSS describes a protocol for registration
and subsequent management of public key information. A client of a conforming
service may request that the registration service bind information to a
public key. The information bound may include a name, an identifier or
extended attributes defined by the implementation.
[33]The key pair to which the information is bound
may be generated in advance by the client or on request generated by the
service. The Registration protocol may also be used for subsequent management
operations including recovery of the private key and reissue or revocation of
the key binding.
[34]The protocol provides for authentication of the
applicant and, in the case that the key pair is generated by the client,
Proof of Possession (POP) of the private key. A means of communicating the
private key to the client is provided in the case that the private key is
generated by the registration service.
[35]This document specifies means of registering
RSA and DSA keys and a framework for extending the protocol to support other
cryptographic algorithms such as Diffie-Hellman and Elliptic Curve
variants.
[36]The remainder of this document describes the
XML Key Information Service Specification and XML Key Registration Service
Specification.
- Section 2: Protocol Exchanges
- Features of the XKMS protocol that are common to the XKMS services
are described.
- Section 3: Message Syntax
- The common syntax elements shared by XKMS messages are described.
- Section 4: Key Information Service Specification Overview.
- The functional behavior of the X-KISS service is described.
- Section 5: Key Information Service Specification Message
Set.
- The semantics of the X-KISS protocol messages are defined.
- Section 6: Key Registration Service Specification Overview.
- The functional behavior of the X-KRSS service is described.
- Section 7: Key Registration Service Specification Message
Set.
- The semantics of the X-KRSS protocol messages is defined.
- Section 8: Cryptographic Algorithm Specific Parameters
- Parameters and data formats specific to the use of particular
cryptographic algorithms are defined.
- Section 9: Conformance
- Conformance criteria for compliant XKMS 2.0 applications are
specified.
- Section 10: Security Considerations
- Security considerations for implementation and deployment of XKMS are
described.
[37]XKMS protocol exchanges consist of a sequence
of either one or two request response pairs.
[38]XKMS protocol messages share a common format
that may be carried within a variety of protocols. A binding to the
SOAP [SOAP][XMLP] message
protocol is provided in Part II:
Protocol Bindings. 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.
[39]Implementers MAY implement bindings to other
protocols at their option.
[40]No XKMS operations are idempotent, that is all
XKMS requests MAY cause a change of state.
[41] Part II of this specification
describes the XKMS Security Protocol bindings.
[42]The XKMS protocol consists of pairs of requests
and responses. The XKMS protocol binding allows for the case in which an
additional request/response round trip is required to support cases such as
pending responses and two-phase requests for replay attack protection.
[43]Each XKMS response message contains a MajorResult code that
determines whether the response is final or further processing is required.
The protocol is specified in the CSP formalism [CSP] as
follows:
- Final = { Success, VersionMismatch,
Sender, Receiver }
-
- Request ->
Result.Final
- |
- Request ->
Result.Pending->PendingNotification->Request->Result.Final
- |
- Request ->
Result.Represent->Request->Result.Final
[44]The following sections describe the message
protocol and the message processing steps taken by both parties in each of
the messages.
[45]The following processing steps are taken with
respect to all messages regardless of whether they are a request or a
response:
- Generation
- Id is set to a randomly generated unique
value
- Service is set to the value of the URI to
which the XKMS request is directed
Authentication Signature is generated (if required).
- Processing
- The value of Service is verified
The Authentication Signature value is verified (if required).
<?xml version="1.0" encoding="utf-8"?>
<MessageAbstractType Id="1noOYHt5Lx7xUuizWZLOMw=="
Service="http://www.example.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#" />
[46]The XKMS specification defines three types of
request:
- X-KISS Request
- A Locate or Validate request as specified by the Key Information
Service Specification.
- X-KRSS Request
- A Register, Reissue, Revoke or Recover request as specified by the
Key Registration Service Specification.
- Compound Request
- A compound request consists of a set of one or more X-KISS or X-KRSS
requests.
[47]The XKMS protocol supports a number of protocol
options, including asynchronous processing, two-phase requests and compound
requests. The client specifies the protocol options it supports in relation
to a specific request through ResponseMechanism
elements in the request.
[48]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
[49]All XKMS responses contain a Result code
comprised of a major and minor component. If a service applies a protocol
processing option the client is informed by means of the MajorResult code value of the
response.
[50]XKMS supports two processing modes, synchronous
processing and asynchronous processing.
- In synchronous processing the service responds to a request such
that it has satisfied its obligation and will issue no more responses
with respect to that request: a response code in the set Final
defined above is returned.
- In asynchronous processing the service will not complete the request
immediately and notifies that the request is not yet satisfied and
subsequent responses will be forthcoming: a response code that is not in
the set Final is returned in intermediate responses.
[51]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.
[52]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 code NotSynchronous are returned.
[53]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 X-KRSS Registration
requests before they are processed.
[54]Processing of a synchronous Request and
Response takes place as follows:
- Requestor generation of the Request Message
- Nonce and OriginalRequestId are not present
ResponseMechanism value Pending MAY be specified but the service will ignore it
- Service processing of the Request Message
- Verify that request meets service authorization policy
Process request to completion
- Service generation of the Response Message
- RequestId is set to the value of Id in the request message
- Nonce is not present
MajorResult is set to a Final result value
- Requestor processing of the Response Message
- The value of RequestId is verified
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I6d995b8d05a9a2ce0573d29e32ab9441"
Service="http://www.example.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#">
<QueryKeyBinding />
</LocateRequest>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I089b18dc1a520b26e2e6689dd3a5a820"
Service=
"http://www.example.org/XKMS"
ResultMajor="http://www.w3.org/2002/03/xkms#Success"
RequestId="I6d995b8d05a9a2ce0573d29e32ab9441"
xmlns="http://www.w3.org/2002/03/xkms#" />
[55]Asynchronous processing consists of a sequence of request/response
pairs; an initial request which specifies the request values, zero or
more status requests and a pending request which obtains the result of
the operation. The client may issue status requests in order to poll
the status of an asynchronous operation independently of the use of
the notification mechanism indicated (by the client) in the initial
request.
2.5.1 Initial Request
[56]The initial request message is processed as
follows:
- Requestor generation of the Initial Request Message
- Nonce and OriginalRequestId are not present
ResponseMechanism value Pending MUST be specified
- Service processing of the Initial Request Message
- Schedule request for asynchronous processing
- Service generation of the Initial Response Message
- RequestId is set to the value Id in the initial request message
- Nonce is not present
- MajorResult is set to Pending
- Requestor processing of the Initial Response Message
- Register request as pending completion, poll processing status and/or wait for
notification
2.5.2 Status Request
[56a]The client may poll the status of the asynchronous operation as follows:
- Requestor generation of the Status Request Message
- The request element is StatusRequest
- OriginalRequestId is set to the value of
Id in the initial request message
ResponseId is set to value of Id in the initial response message
- Service processing of the Status Request Message
- Identify pending request using OriginalRequestId
and ResponseId.
- Service generation of the Status Response Message
- RequestId is set to the value of Id in the Status request message
- Nonce is not present
- Requestor processing of the Status Response Message
- For non-compound messages, the ResultMajor
attribute indicates the status of the operation. For compound
messages, the Success, Failure,
and Pending attributes further indicate the number of
inner requests that have the respective status.
2.5.3 Pending Request
[57] The client determines, through notification or polling, that the
requested operation has completed and requests the return of the
result values by issuing a PendingRequest message as follows:
- Requestor generation of the Pending Request Message
- The request element is PendingRequest
- OriginalRequestId is set to the value of
Id in the initial request message
ResponseId is set to value of Id in the initial response message
- Service processing of the Pending Request Message
- Match pending request to pending response
- Service generation of the Pending Response Message
- RequestId is set to the value of Id in the Pending request message
- Nonce is not present
- Requestor processing of the Pending Response Message
- If MajorResult is set to a non-final
value consider it to be failure
[58]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.
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I6227979ae4073f2b3b145db7a488ce16"
Service="http://www.example.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#">
<ResponseMechanism>http://www.w3.org/2002/03/xkms#Pending</ResponseMechanism>
<PendingNotification Mechanism="urn:ietf:rfc:822"
Identifier="mailto:alice@example.org">
<QueryKeyBinding />
</LocateRequest>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I98366e407a2a78dff79687dbdb4d974c"
Service="http://www.example.org/XKMS"
ResultMajor="http://www.w3.org/2002/03/xkms#Pending"
RequestId="I6227979ae4073f2b3b145db7a488ce16"
xmlns="http://www.w3.org/2002/03/xkms#" />
The XKMS service notifies the client about the completion of the
request processing using the notification mechanism specified in the
<PendingNotification> element.
2.5.4.4 Pending Request
<?xml version="1.0" encoding="utf-8"?>
<PendingRequest Id="I6045ff8b2eb204edb538be1fa22e340a"
Service="http://www.example.org/XKMS"
OriginalRequestId="I6227979ae4073f2b3b145db7a488ce16"
ResponseId="I98366e407a2a78dff79687dbdb4d974c"
xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I4da52fc78e0391a11257d64926cd184c"
Service="http://www.example.org/XKMS"
ResultMajor="http://www.w3.org/2002/03/xkms#Success"
RequestId="I6045ff8b2eb204edb538be1fa22e340a"
xmlns="http://www.w3.org/2002/03/xkms#" />
[59]XKMS requests may employ a two-phase request
protocol to protect against a denial of service attack. The two-phase request
protocol allows the service to perform a lightweight authentication of the
source of an XKMS request, specifically the service determines that the
client is able to read messages sent to the purported source address.
Although this mechanism provides only a weak form of authentication it
prevents an attacker performing a Denial of Service attack by forcing the
service to perform a resource intensive form of authentication such as the
verification of a digital signature.
[60]The two-phase protocol consists of two phases
as follows:
[61]In the first phase the requestor presents the
request and the service responds the MajorResult
value Represent and presents a nonce.
[62]In the second phase the requestor represents
the original request together with the nonce.
[63]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.
[64]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 code RepresentRequired are returned.
[65]The two-phase request protocol bears some
similarity to asynchronous request processing. Both mechanisms introduce an
extra protocol round trip but each serve different purposes. The purpose of
asynchronous processing is to allow a delay to be introduced between the
initial request and the return of the result. In the two-phase request
protocol however there is no delay between the first request and the first
response or between the first response and the second request. The purpose of
the two-phase request protocol is to allow a service to protect itself
against a denial of service attack by allowing the service to perform a
lightweight authentication of the source of the request.
[66]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. The actual construction of the nonce value is outside the scope of this
specification and may be chosen as site specific circumstances dictate. The
techniques described in the section Construction of
Nonce Values describe a technique that reduces or avoids the need to
maintain server state in order to meet this requirement.
2.6.1 Processing Steps
[67]In the first phase of the two-phase protocol
the processing steps specified for the single phase case are performed with
the following exceptions:
- Requestor generation of the Phase 1 Request Message
- ResponseMechanism value Represent MUST be
specified
- Service processing of the Phase 1 Request Message
- Service decides to exercise option to require two-phase
processing
- Request is NOT processed
- Service generation of the Phase 1 Response Message
- RequestId is set to the value Id in the Phase 1 request message
- Nonce value is set in accordance with service
replay protection requirements
- MajorResult is set to Represent
- Requestor processing of the Phase 1 Response Message
- Proceed to phase 2
[68]In the Second phase of the two-phase protocol
the processing steps specified for the single phase case are performed with
the following exceptions:
- Requestor generation of the Phase 2 Request Message
- OriginalRequestId set to the value of
Id in the Phase 1 request message
Nonce value is set to the value of Nonce in the Phase 1 response message
- Service processing of the Phase 2 Request Message
- Verify value of Nonce
- Verify that request meets service authorization policy
Process request to completion
- Service generation of the Phase 2 Response Message
- RequestId is set to the value of Id in the Phase2 request message
- Nonce is not present
MajorResult is set to a Final result value
- Requestor processing of the Phase 2 Response Message
- If MajorResult set to a non-final value
consider to be failure
[69]Nonce values may be constructed in any manner
that the service chooses. It may be useful to construct the nonce so as to
permit the service to determine that they were generated by the server at a
specific time in a computationally efficient manner as follows.
[70]The nonce is constructed from the current time
at the service, a unique serial number and a secret key known only to the
service using a Message Authentication Code as follows
("+" indicates
concatenation):
[71] nonce = time + serial +
M ( time + serial , k )
[72]The service may limit the time interval in
which replay attacks are possible by rejecting nonce values that specify an
unacceptable time value or an incorrect MAC value.
[73]The service may prevent replay attacks
completely by tracking the serial numbers for which responses have already
been given, using the nonce time construction value to limit the interval
over which the serial number is tracked.
[74]The nonce value may be encrypted to avoid
leaking information such as the serial number value which might be of
interest to an attacker.
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="Ia1d6ca7a067fdd545f1a1396d2f26779"
Service="http://www.example.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#">
<ResponseMechanism>http://www.w3.org/2002/03/xkms#Represent</ResponseMechanism>
<QueryKeyBinding />
</LocateRequest>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="Idbc77142059a3a51c9eccd2425d77757"
Service="http://www.example.org/XKMS"
Nonce="Rj2BoUZM7PisPX2ytSAAWA=="
ResultMajor="http://www.w3.org/2002/03/xkms#Represent"
RequestId="Ia1d6ca7a067fdd545f1a1396d2f26779"
xmlns="http://www.w3.org/2002/03/xkms#" />
<?xml version="1.0" encoding="utf-8"?>
<LocateRequest Id="I47804adaec32e34afeecdb51f3e0f765"
Service="http://www.example.org/XKMS"
Nonce="Rj2BoUZM7PisPX2ytSAAWA=="
OriginalRequestId="Ia1d6ca7a067fdd545f1a1396d2f26779"
xmlns="http://www.w3.org/2002/03/xkms#">
<QueryKeyBinding />
</LocateRequest>
<?xml version="1.0" encoding="utf-8"?>
<LocateResult Id="I3b0111d2232507a56444c1bc85409a94"
Service="http://www.example.org/XKMS"
ResultMajor="http://www.w3.org/2002/03/xkms#Success"
RequestId="I47804adaec32e34afeecdb51f3e0f765"
xmlns="http://www.w3.org/2002/03/xkms#" />
[75]The two-phase protocol may be combined with
Asynchronous Processing. In this case the operation will consist of three
round trips as follows:
- Initial Request / Phase 1
- Initial Request / Phase 2
- Pending Response
[76]Message processing is performed as described
above with the following exceptions.
- OriginalRequestId set to that value of
Id in Initial Request / Phase 1 in
both subsequent requests.
- Nonce value is set to the value of Nonce in Phase 1 response in both subsequent
requests.
[77]An XKMS service MAY support processing of
Compound Requests. A compound request permits multiple XKMS requests to be
made at the same time. A compound request consists of an outer request and
one or more inner requests. There is no ordering implicit in the inner
requests. The semantics of making a set of requests as a compound request are
exactly the same as if each individual request in the set had been made
separately and simultaneously.
[78]The response to a compound request is a
compound response. A compound response consists of an outer response and zero
or more inner 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, that inner request is assumed to have failed.
[79]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.
[80]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.
[81]If asynchronous processing is to be performed
on the compound request as a whole the outer request specifies the ResponseMechanism value Pending. If the service decides to return an asynchronous
response a compound response is returned with a ResultMajor code of Pending. When the service has completed the processing, as determined through polling or notification, the client issues a PendingRequest message for
the outer request to which the service replies with a compound response
returning either the inner responses corresponding to the original inner
requests or an error report.
[82]If asynchronous processing is performed on the
individual inner requests each inner request for which an asynchronous
response is to be accepted specifies the ResponseMechanism value Pending. If the service decides to return an asynchronous
response to an inner request a compound response is returned with an outer
ResultMajor code of Success and an inner ResultMajor code of Pending
for the requests for which an asynchronous response is to be issued. A
service MAY return synchronous and asynchronous responses in a single
compound response.
[83]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.
<?xml version="1.0" encoding="utf-8"?>
<CompoundRequest Id="I264f5da49b1ff367d4e7aef1f7a1df1a"
Service="http://www.example.org/XKMS"
xmlns="http://www.w3.org/2002/03/xkms#">
<LocateRequest Id="I8c26be5f1b4dd228b43fb6eaee285faa"
Service="http://www.example.org/XKMS">
<RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
<QueryKeyBinding>
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<X509Data>
<X509Certificate>
MIICEDCCAX2gAwIBAgIQimXeUAxYJbJMady9vV1bLjAJBgUrDgMCHQUAMBIxEDA
OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
ArMSkwJwYDVQQDEyBBbGljZSBBYXJkdmFyayBPPUFsaWNlIENvcnAgQz1VUzCBn
zANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA0nIsmR+aVW2egl5MIfOKy4HuMKkk
9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgGthO6U9D0CNT5mbmhIA
ErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GDNiHKVDQg
gPBLc1XagW20RMvokCAwEAAaNWMFQwDQYDVR0KBAYwBAMCBkAwQwYDVR0BBDwwO
oAQAaVOkaVLLKoFmLN37pC8uqEUMBIxEDAOBgNVBAMTB1Rlc3QgQ0GCEC4MndUX
jPG1TZxVKg+HutAwCQYFKw4DAh0FAAOBgQABU91ka7IlkXCfv4Zh2Ohwgg2yObt
Y3+6C/BTFGrOEBJDy+DoxJ/NuBF18w3rrrR18xE6jNKYLCQb8zUGk4QOG5Y+HT/
QTTFvWkiOLXcpTuhnOhXatr42FoYpDkjx2QWK+J5Q2l/Rgjgc/0ZV8U/kD8UuRk
Xp4AZh7QsiX8AcO0w==
</X509Certificate>
</X509Data>
</KeyInfo>
<KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
</QueryKeyBinding>
</LocateRequest>
<LocateRequest Id="If8e63d729384ad35498e7b65b3dc785e"
Service="http://www.example.org/XKMS">
<RespondWith>http://www.w3.org/2002/03/xkms#KeyName</RespondWith>
<RespondWith>http://www.w3.org/2002/03/xkms#KeyValue</RespondWith>
<RespondWith>http://www.w3.org/2002/03/xkms#X509Cert</RespondWith>
<RespondWith>http://www.w3.org/2002/03/xkms#X509Chain</RespondWith>
<RespondWith>http://www.w3.org/2002/03/xkms#PGPWeb</RespondWith>
<RespondWith>http://www.w3.org/2002/03/xkms#PGP</RespondWith>
<QueryKeyBinding>
<KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
<UseKeyWith Application="urn:ietf:rfc:2440"
Identifier="bob@example.com" />
<UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="bob@example.com" />
</QueryKeyBinding>
</LocateRequest>
</CompoundRequest>
<?xml version="1.0" encoding="utf-8"?>
<CompoundResult Id="If2d286d4a542bd92989aa606d9f1a5ca"
Service="http://www.example.org/XKMS"
ResultMajor="http://www.w3.org/2002/03/xkms#Success"
RequestId="I264f5da49b1ff367d4e7aef1f7a1df1a"
xmlns="http://www.w3.org/2002/03/xkms#">
<LocateResult Id="I69044d458e0bceef5f78c79c32fa9ddf"
Service="http://www.example.org/XKMS"
ResultMajor="http://www.w3.org/2002/03/xkms#Success"
RequestId="I8c26be5f1b4dd228b43fb6eaee285faa">
<UnverifiedKeyBinding Id="I8f7367375ac134872eab7acf42a8d1bd">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyValue>
<RSAKeyValue>
<Modulus>
0nIsmR+aVW2egl5MIfOKy4HuMKkk9AZ/IQuDLVPlhzOfgngjVQCjr8uvmnqtNu8HBupui8LgG
thO6U9D0CNT5mbmhIAErRADUMIAFsi7LzBarUvNWTqYNEJmcHsAUZdrdcDrkNnG7SzbuJx+GD
NiHKVDQggPBLc1XagW20RMvok=
</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
</KeyInfo>
<KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
<KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
<KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
<UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="alice@example.com" />
</UnverifiedKeyBinding>
</LocateResult>
<LocateResult Id="Ic3d02a8b1f63ba694a8fad11a74fb499"
Service="http://www.example.org/XKMS"
ResultMajor="http://www.w3.org/2002/03/xkms#Success"
RequestId="If8e63d729384ad35498e7b65b3dc785e">
<UnverifiedKeyBinding Id="I42604b6f40f46b74b5c30077100fe8e9">
<KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<KeyValue>
<RSAKeyValue>
<Modulus>
3FFtWUsvEajQt2SeSF+RvAxWdPPh5GSlQnp8SDvvqvCwE6PXcRWrIGmV7twNf2T
UXCxYuztUUClMIy14B0Q+k1ej2nekmYL7+Ic3DDGVFVaYPoxaRY0Y2lV8tOreyn
WegpFbITXc8V6Y02QfR5O7Pn1/10ElslaF/TF8MQGqYE8=
</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>
</KeyValue>
<X509Data>
<X509Certificate>
MIICCTCCAXagAwIBAgIQe0Sk4xr1VolGFFNMkCx07TAJBgUrDgMCHQUAMBIxEDA
OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMDUwODE1MDY1OTU5Wj
AkMSIwIAYDVQQDExlCb2IgQmFrZXIgTz1Cb2IgQ29ycCBDPVVTMIGfMA0GCSqGS
Ib3DQEBAQUAA4GNADCBiQKBgQDcUW1ZSy8RqNC3ZJ5IX5G8DFZ08+HkZKVCenxI
O++q8LATo9dxFasgaZXu3A1/ZNRcLFi7O1RQKUwjLXgHRD6TV6Pad6SZgvv4hzc
MMZUVVpg+jFpFjRjaVXy06t7KdZ6CkVshNdzxXpjTZB9Hk7s+fX/XQSWyVoX9MX
wxAapgTwIDAQABo1YwVDANBgNVHQoEBjAEAwIGQDBDBgNVHQEEPDA6gBABpU6Rp
UssqgWYs3fukLy6oRQwEjEQMA4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUq
D4e60DAJBgUrDgMCHQUAA4GBAF4jP1gGDbaq3rg/Vo3JY7EDNTp0HmwLiPMLmdn
B3WTIGFcjS/jZFzRCbvKPeiPTZ6kRkGgydFOuCo5HMAxIks/LtnKFd/0qYT+AOD
q/rCrwSx+F+Ro2rf9tPpja9o7gANqxs6Pm7f1QSPZO57bT/6afiVm7NdaCfjgMp
hb+XNyn
</X509Certificate>
<X509Certificate>
MIIB9zCCAWSgAwIBAgIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAMBIxEDA
OBgNVBAMTB1Rlc3QgQ0EwHhcNMDMwODE1MDcwMDAwWhcNMTAwODE1MDcwMDAwWj
ASMRAwDgYDVQQDEwdUZXN0IENBMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBg
QCn23HHp+HtXpiyKVSDtdE3dO0r0oLB/H9sxUEkeXB8oMxwbhdcizWH92zrtm1V
fVtxkfmwF14ZXoyDZHeZXuCOtAfz/mW6s2gmfD45TfFFVGksDGVRNK5XmKXA5sE
C51RCvaxzGBdGDlCuVPqX7Cq3IcZpRU1IXbi5YzGwV7j6LwIDAQABo1YwVDANBg
NVHQoEBjAEAwIHgDBDBgNVHQEEPDA6gBABpU6RpUssqgWYs3fukLy6oRQwEjEQM
A4GA1UEAxMHVGVzdCBDQYIQLgyd1ReM8bVNnFUqD4e60DAJBgUrDgMCHQUAA4GB
ABDYD4Fwx2dscu+BgYcZ+GoQQtCJkwJEXytb4zlNl7HLFKbXSw4m0blQquIsfsi
QgFYAQBXSbu7aeUqqmSGHvILu3BGwVOKjxbHfcM4/MefuTtpOpCN40wy3YwwngD
tHTaIqm8NwS966PE+W9f8kD70q5FNwf+GF/lX9qGc/x435
</X509Certificate>
</X509Data>
</KeyInfo>
<KeyUsage>http://www.w3.org/2002/03/xkms#Signature</KeyUsage>
<KeyUsage>http://www.w3.org/2002/03/xkms#Encryption</KeyUsage>
<KeyUsage>http://www.w3.org/2002/03/xkms#Exchange</KeyUsage>
<UseKeyWith Application="urn:ietf:rfc:2633"
Identifier="bob@example.com" />
</UnverifiedKeyBinding>
</LocateResult>
</CompoundResult>
[84]The security concerns that an XKMS service is
required to address are dependent on the specific service deployment. For
example a free XKMS Location service may not require controls for Request
Authentication or to prevent Request Replay attacks while a paid Validate
service might. The application of security enhancements is addressed in
Part II which describes
the application of the following security enhancements:
- Confidentiality
- Request Authentication
- Response Authentication
- Transitive Authentication
- Response Replay
- Request Substitution
- Request Replay
- Denial of Service
[85]The use of security enhancements is further
discussed in the section Security
Considerations below.
3 Message
Syntax
3.1 Message
Base
[86]The MessageAbstractType
abstract type is the type from which all XKMS message element types are
derived. The MessageAbstractType abstract type
contains the following element and attributes
- <ds:Signature> [Optional]
- An XML Signature [XML-SIG] in enveloped
mode. The scope of the signature is the entire request message (i.e.
the element derived from MessageAbstractType) and is specified using
a reference to the Id attribute specified in
the MessageAbstractType abstract type.
- <MessageExtension> [Any Number]
- An extension element derived from the MessageExtensionAbstractType.
- <OpaqueClientData> [Optional]
- A collection of 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.
- Id [Required]
- A unique identifier generated by the originator.
- Service [Required]
- The URI of the Web Service port to which the request is
addressed.
- Nonce [Optional]
- Cryptographically random data used to defend against replay
attack.
[87]The following schema defines the MessageAbstractType abstract type:
<!-- MessageAbstractType -->
<complexType name="MessageAbstractType" abstract="true">
<sequence>
<element ref="ds:Signature" minOccurs="0"/>
<element ref="xkms:MessageExtension" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="xkms:OpaqueClientData" minOccurs="0"/>
</sequence>
<attribute name="Id" type="ID" use="required"/>
<attribute name="Service" type="anyURI" use="required"/>
<attribute name="Nonce" type="base64Binary" use="optional"/>
</complexType>
<!-- /MessageAbstractType -->
[88]An XML Signature [XML-SIG] in enveloped mode. 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.
[89]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.
[90]For interoperability purposes XKMS
implementations MUST support the use of Exclusive XML Canonicalization.
[91]The <ds:Signature> element is specified in the XML
Signature specification [XML-SIG].
[92]The <MessageExtension> element is an abstract element of
the abstract type MessageExtensionAbstractType. Implementations may define
subclasses of the MessageExtensionAbstractType to define message extension
elements that may be applied to any XKMS message.
[93]The following schema defines the MessageExtension element:
<!-- MessageExtension -->
<element name="MessageExtension" type="xkms:MessageExtensionAbstractType"
abstract="true"/>
<complexType name="MessageExtensionAbstractType" abstract="true"/>
<!-- /MessageExtension -->
[94]The <OpaqueClientData> contains data specified by the
client that is opaque to the service. An XKMS service SHOULD return the value
of an <OpaqueClientData> element,
including its children, specified in a request unmodified in the
corresponding response.
[95]A client MAY use Opaque client data in
conjunction with asynchronous request processing to match a
response 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.
[96]The following schema defines the OpaqueClientData element:
<!-- OpaqueClientData -->
<element name="OpaqueClientData" type="xkms:OpaqueClientDataType"/>
<complexType name="OpaqueClientDataType">
<sequence maxOccurs="unbounded">
<element ref="xkms:OpaqueData" minOccurs="0"/>
</sequence>
</complexType>
<element name="OpaqueData" type="base64Binary"/>
<!-- /OpaqueClientData -->
3.2 Request
Message
[97]The RequestAbstractType
abstract type is the type from which all XKMS request element types are
derived. The RequestAbstractType abstract type
inherits the element and attributes of the MessageAbstractType abstract type and in addition contains
the following elements and attributes
- <ResponseMechanism> [Any
Number]
- Specifies the extended protocol mechanisms that the client supports
in connection with this request.
- <RespondWith> [Any
Number]
- Specifies the types of data the recipient requests to be sent in
the response.
- <PendingNotification> [Optional]
- Specifies a means by which the service may notify the requestor of
the completion of a pending response. If the <PendingNotification> element is present the
value Pending MUST be specified as a <ResponseMechanism> value.
- OriginalRequestId [Optional]
- Specifies the value Id of the first
request made in a multi-stage protocol such as the asynchronous
processing mechanism or the two-phase protocol.
- ResponseLimit [Optional]
- Specifies the maximum number of data items the requestor can accept
in the case that the schema specifies an unbounded number of
elements.
[98]The following schema defines the RequestAbstractType abstract type:
<!-- RequestAbstractType -->
<complexType name="RequestAbstractType" abstract="true">
<complexContent>
<extension base="xkms:MessageAbstractType">
<sequence>
<element ref="xkms:ResponseMechanism" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="xkms:RespondWith" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="xkms:PendingNotification" minOccurs="0"/>
</sequence>
<attribute name="OriginalRequestId" type="NCName"
use="optional"/>
<attribute name="ResponseLimit" type="integer" use="optional"/>
</extension>
</complexContent>
</complexType>
<!-- /RequestAbstractType -->
[99]The <ResponseMechanism> element in the request specifies
one or more strings included in the request that specify extended protocol
mechanisms that the client supports in connection with a request.
[100] ResponseMechanismvalues are specified as anyURIs, the following identifiers are defined:
| anyURI Name |
Description |
| http://www.w3.org/2002/03/xkms#Pending |
The requestor is prepared to accept a
response that uses asynchronous processing, i.e. the service MAY
return the MajorResult code Pending |
| http://www.w3.org/2002/03/xkms#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 |
| http://www.w3.org/2002/03/xkms#RequestSignatureValue |
The requestor is prepared to accept a
response that carries a <RequestSignatureValue> element. |
[101]The following schema defines the <ResponseMechanism> element::
<!-- ResponseMechanism -->
<simpleType name="ResponseMechanismEnum">
<restriction base="anyURI">
<enumeration value="http://www.w3.org/2002/03/xkms#Pending"/>
<enumeration value="http://www.w3.org/2002/03/xkms#Represent"/>
<enumeration value="http://www.w3.org/2002/03/xkms#RequestSignatureValue"/>
</restriction>
</simpleType>
<simpleType name="ResponseMechanismOpenEnum">
<union memberTypes="xkms:ResponseMechanismEnum anyURI"/>
</simpleType>
<element name="ResponseMechanism" type="xkms:ResponseMechanismOpenEnum"/>
<!-- /ResponseMechanism -->
[102]
The <RespondWith> element in a
request specifies one or more URI values that SHOULD resolve to data
elements provided in either the <ds:KeyInfo> element or private key
information defined in the section Cryptographic Algorithm Specific Parameters
below. The <RespondWith> element SHOULD
be included in requests of type LocateRequest,
ValidateRequest, RegisterRequest, ReissueRequest, RevokeRequest, and RecoverRequest. The XML Signature elements are
described here for convenience. The normative reference is the XML
Digital Signature Specification [XML-SIG].
[103]The Service SHOULD return any data elements that are resolvable
<RespondWith> URI values and that
are supported by the Service. The Service MAY return additional data
elements not requested. In particular, the service MAY return data
elements specified in the request with the response.
[104] RespondWith values
are specified as anyURIs,
the following identifiers are defined (all names under the first columnn are prefixed with URI http://www.w3.org/2002/03/xkms#):
anyURI Name
|
<ds:Keyinfo>
Element |
Description |
| KeyName |
<ds:KeyName> |
Key name |
| KeyValue |
<ds:KeyValue> |
Public key parameters |
| X509Cert |
<ds:X509Data> |
X509 Certificate v3 that authenticates
the specified key |
| X509Chain |
<ds:X509Data>* |
X509 Certificate v3 chain that
authenticates the specified key. Note that no ordering is implied in
the returned certificates. |
| X509CRL |
<ds:X509Data> |
X509 Certificate Revocation List v2 |
| RetrievalMethod |
<ds:RetrievalMethod> |
Retrieval Method data |
| PGP |
<ds:PGPData> |
PGP key signing data |
| PGPWeb |
<ds:PGPData>* |
Collection of PGP key signing data |
| SPKI |
<ds:SPKIData>* |
SPKI key signing |
| PrivateKey |
|
Request that the encrypted private key be
returned in the response. [Used in the X-KRSS protocol] |
[104a](In the above table, * stands for one or more.).
[105]For example, a client that has no X.509
processing capability might perform a Locate
operation to obtain the public key parameters and name information from a
<ds:Keyinfo> element that specifies only a
certificate. The RespondWith element values in this
case would be KeyName and KeyValue.
[106]The following schema defines the <RespondWith> element::
<!-- RespondWith -->
<simpleType name="RespondWithEnum">
<restriction base="anyURI">
<enumeration value="http://www.w3.org/2002/03/xkms#KeyName"/>
<enumeration value="http://www.w3.org/2002/03/xkms#KeyValue"/>
<enumeration value="http://www.w3.org/2002/03/xkms#X509Cert"/>
<enumeration value="http://www.w3.org/2002/03/xkms#X509Chain"/>
<enumeration value="http://www.w3.org/2002/03/xkms#X509CRL"/>
<enumeration value="http://www.w3.org/2002/03/xkms#RetrievalMethod"/>
<enumeration value="http://www.w3.org/2002/03/xkms#PGP"/>
<enumeration value="http://www.w3.org/2002/03/xkms#PGPWeb"/>
<enumeration value="http://www.w3.org/2002/03/xkms#SPKI"/>
<enumeration value="http://www.w3.org/2002/03/xkms#PrivateKey"/>
</restriction>
</simpleType>
<simpleType name="RespondWithOpenEnum">
<union memberTypes="xkms:RespondWithEnum anyURI"/>
</simpleType>
<element name="RespondWith" type="xkms:RespondWithOpenEnum"/>
<!-- /RespondWith -->
[107]The <PendingNotification> element is used to specify a
mechanism by means of which the service can inform a requestor that a pending
request has completed asynchronously.
[108]The <PendingNotification> element contains the following
attributes
- 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.
[109]The following mechanisms are defined:
| Protocol |
Mechanism |
Identifier |
Description |
| SMTP |
urn:ietf:rfc:822 |
mailto: |
Notification by email. The
content of the email is outside the scope of this specification |
| HTTP |
urn:ietf:rfc:2616 |
http:// |
Notification by HTTP. The
content of the request is outside the scope of this specification |
[110]The following schema defines the <PendingNotification> element and PendingNotificationType type:
<!-- PendingNotification -->
<element name="PendingNotification" type="xkms:PendingNotificationType"/>
<complexType name="PendingNotificationType">
<attribute name="Mechanism" type="anyURI" use="required"/>
<attribute name="Identifier" type="anyURI" use="required"/>
</complexType>
<!-- /PendingNotification -->
[111]The PendingRequest
element is used to request the result of a previously presented request for
which the MajorResult
code Pending was
returned. The PendingRequest element inherits the element and
attributes of
RequestAbstractType and the following
attribute:
- ResponseId [Required]
- The value of the Id attribute sent in the
original response containing the MajorResult code Pending.
[112]If the value of ResponseId is unknown to the
service the result Sender.UnknownResponseId is
returned.
[112a]The RespondWith element
MUST NOT be present
inside a PendingRequest element.
[113]The following schema defines the PendingRequest element and PendingRequestType type:
<!-- PendingRequest -->
<element name="PendingRequest" type="xkms:PendingRequestType"/>
<complexType name="PendingRequestType">
<complexContent>
<extension base="xkms:RequestAbstractType">
<attribute name="ResponseId" type="NCName" use="required"/>
</extension>
</complexContent>
</complexType>
<!-- /PendingRequest -->
3.3 Response
Message
[114]The ResultType type is
the type from which all XKMS response element types are derived. The ResultType type inherits the element and attributes
of the MessageAbstractType abstract type and in
addition contains the following attributes
- <RequestSignatureValue> [Optional]
- The value of the ds:SignatureValue element of the corresponding
request.
- ResultMajor [Required]
- The most significant component of the result code.
- ResultMinor [Optional]
- The least significant component of the result code.
- RequestId [Optional]
- The unique identifier Id specified in the
request.
[115]If the MajorResult
value has the value Represent the Nonce attribute MUST be present and
MUST NOT be the empty string.
[116]The <Result>
element is returned in response to an XKMS request if and only if the service
cannot return a more specific result element that inherits from the ResultType. For example if a request is made for the status
of a pending request whose identifier is unknown to the service.
[117] Security Consideration: 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. For more information see the
section Security Considerations.
[118]The following schema defines the <Result> element and
ResultType type:
<!-- ResultType -->
<element name="Result" type="xkms:ResultType"/>
<simpleType name="ResultMajorEnum">
<restriction base="anyURI">
<enumeration value="http://www.w3.org/2002/03/xkms#Success"/>
<enumeration value="http://www.w3.org/2002/03/xkms#VersionMismatch"/>
<enumeration value="http://www.w3.org/2002/03/xkms#Sender"/>
<enumeration value="http://www.w3.org/2002/03/xkms#Receiver"/>
<enumeration value="http://www.w3.org/2002/03/xkms#Represent"/>
<enumeration value="http://www.w3.org/2002/03/xkms#Pending"/>
</restriction>
</simpleType>
<simpleType name="ResultMajorOpenEnum">
<union memberTypes="xkms:ResultMajorEnum anyURI"/>
</simpleType>
<simpleType name="ResultMinorEnum">
<restriction base="anyURI">
<enumeration value="http://www.w3.org/2002/03/xkms#NoMatch"/>
<enumeration value="http://www.w3.org/2002/03/xkms#TooManyResponses"/>
<enumeration value="http://www.w3.org/2002/03/xkms#Incomplete"/>
<enumeration value="http://www.w3.org/2002/03/xkms#Failure"/>
<enumeration value="http://www.w3.org/2002/03/xkms#Refused"/>
<enumeration value="http://www.w3.org/2002/03/xkms#NoAuthentication"/>
<enumeration
value="http://www.w3.org/2002/03/xkms#MessageNotSupported"/>
<enumeration value="http://www.w3.org/2002/03/xkms#UnknownResponseId"/>
<enumeration value="http://www.w3.org/2002/03/xkms#RepresentRequired"/>
<enumeration value="http://www.w3.org/2002/03/xkms#NotSynchronous"/>
<enumeration
value="http://www.w3.org/2002/03/xkms#OptionalElementNotSupported"/>
<enumeration
value="http://www.w3.org/2002/03/xkms#ProofOfPossessionRequired"/>
<enumeration
value="http://www.w3.org/2002/03/xkms#TimeInstantNotSupported"/>
<enumeration
value="http://www.w3.org/2002/03/xkms#TimeInstantOutOfRange"/>
</restriction>
</simpleType>
<simpleType name="ResultMinorOpenEnum">
<union memberTypes="xkms:ResultMinorEnum anyURI"/>
</simpleType>
<complexType name="ResultType">
<complexContent>
<extension base="xkms:MessageAbstractType">
<sequence>
<element ref="xkms:RequestSignatureValue" minOccurs="0"/>
</sequence>
<attribute name="ResultMajor" type="xkms:ResultMajorOpenEnum"
use="required"/>
<attribute name="ResultMinor" type="xkms:ResultMinorOpenEnum"
use="optional"/>
<attribute name="RequestId" type="NCName" use="optional"/>
</extension>
</complexContent>
</complexType>
<!-- /ResultType -->
[119]Result codes consist of a major code and an
optional minor code. The major and minor codes are expressed as XML
anyURI types.
This specification uses the notation ResultMajor.ResultMinor to specify a result code. For example
the result code Sender.NoMatch indicates a ResultMajor code of Sender and a
ResultMinor code of NoMatch.
[120]The following ResultMajor codes are defined (the anyURI name entries are all prefixed with http://www.w3.org/2002/03/xkms#):
anyURI
Name |
Final |
Description |
| Success |
Final |
The operation succeeded. |
| VersionMismatch |
Final |
The service does not support the protocol version
specified in the request. |
| Sender |
Final |
An error occurred that was due to the message sent by
the sender. |
| Receiver |
Final |
An error occurred at the receiver. |
| 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. |
| Pending |
Not Final |
The request has been accepted for processing and the
service will return the result asynchronously. |
[121]The ResultMajor codes
Success, VersionMismatch,
Sender and Receiver are
Final, that is the protocol has completed when the code is returned.
The ResultMajor codes Represent and Pending are Not
Final and indicate that further processing is necessary to receive the
result.
[122]The following ResultMinor codes are defined (the anyURI name entries are all prefixed with http://www.w3.org/2002/03/xkms#):
anyURI Name |
Possible Major Codes |
Description |
| NoMatch |
- |
Generic Description: No match
was found for the search prototype provided. |
| Success |
The result code Success.NoMatch indicates that the service is
authoritative for the search prototype specified and that the service
positively asserts that no matches exist. |
| Receiver |
The result code Receiver.NoMatch indicates that the service is not
authoritative for the search prototype provided. |
| TooManyResponses |
- |
Generic Description: 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. |
| Success |
The service has returned one or more
responses that represent a subset of the possible responses. |
| Receiver |
The service has returned no responses. |
| Incomplete |
Success |
Only part of the information requested
could be provided. |
| Failure |
- |
Generic Description: The service
attempted to perform the request but the operation failed for
unspecified reasons. |
| Sender |
The reason for failure is attributed to
the sender (e.g., the request failed schema validation). |
| Receiver |
The reason for failure is attributed to
the receiver (e.g., a database lookup failed). |
| Refused |
- |
Generic Description: The
operation was refused. The service did not attempt to perform the
request. |
| Sender |
The sender failed to provide sufficient
information to authenticate or authorize the request (e.g., payment
not supplied). |
| Receiver |
The receiver is currently refusing certain
requests for unspecified reasons. |
| NoAuthentication |
Sender |
The operation was refused because the
necessary authentication information was incorrect or missing. |
| MessageNotSupported |
Sender |
The receiver does not implement the
specified operation. |
| UnknownResponseId |
Sender |
The ResponseId for which pending status
was requested is unknown to the service. |
| RepresentRequired |
Sender |
The responder requires that the sender
offer the represent protocol option in order to process the
request. |
| NotSynchronous |
Receiver |
The receiver does not support synchronous
processing of this type of request. |
| OptionalElementNotSupported |
Receiver |
The receiver has refused the
operation because it does not support the OPTIONAL Element value
present in the request. |
| ProofOfPossessionRequired |
Sender |
The receiver has refused the
operation because it requires the sender to include
the ProofOfPossession element in the
request. |
| TimeInstantNotSupported |
Receiver |
The receiver has refused the
operation because it does not support
the TimeInstant element. |
| TimeInstantOutOfRange |
Sender |
The receiver has refused the
operation because the indicated time is outside the range that it
responds to. |
[123]The <RequestSignatureValue> element in a response
contains the value of the base64 encoded value from the <ds:SignatureValue> content within the <ds:Signature> block in the corresponding request. If
the response is signed this provides a cryptographic linkage between the
request and the response.
[124]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.
[125]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 content of the <ds:SignatureValue> element used in the
request does not match the content of the <RequestSignatureValue>
element in the response.
[126]The <RequestSignatureValue> element is of ds:SignatureValueType type specified in the XML Signature
specification [XML-SIG].
<!-- RequestSignatureValue -->
<element name="RequestSignatureValue" type="ds:SignatureValueType"/>
<!-- /RequestSignatureValue -->
3.4 Compound
Requests
[127]The compound request mechanism allows multiple
requests and the corresponding responses to be sent in a single request
message. This allows considerable processing resources to be saved as a
single signature on the compound message may be used in place of multiple
signatures on the individual requests or responses. There are no constraints
on the type of request that may be made within a single compound request. A
compound request may contain multiple instances of the same type of request,
a mixture of different types of request or both.
[128]The <CompoundRequest> element is used to issue multiple
requests at the same time. The <CompoundRequest> element inherits the element and
attributes of
RequestAbstractType together with the
following elements in any order:
- <LocateRequest> [Any Number]
- An XKMS Locate Request
- <ValidateRequest> [Any Number]
- An XKMS Validate Request.
- <RegisterRequest> [Any Number]
- An XKMS Register Request.
- <ReissueRequest> [Any Number]
- An XKMS Reissue Request.
- <RecoverRequest> [Any Number]
- An XKMS Recover Request.
- <RevokeRequest> [Any Number]
- An XKMS Revoke Request.
[128a]The RespondWith element MUST NOT be a direct child of a CompoundRequest element. Each request that is encapsulated inside a CompoundRequest element may or may not have its own RespondWith element child.
[129]The following schema defines the <CompoundRequest> element and CompoundRequestType type:
<!-- CompoundRequest -->
<element name="CompoundRequest" type="xkms:CompoundRequestType"/>
<complexType name="CompoundRequestType">
<complexContent>
<extension base="xkms:RequestAbstractType">
<choice maxOccurs="unbounded">
<element ref="xkms:LocateRequest"/>
<element ref="xkms:ValidateRequest"/>
<element ref="xkms:RegisterRequest"/>
<element ref="xkms:ReissueRequest"/>
<element ref="xkms:RecoverRequest"/>
<element ref="xkms:RevokeRequest"/>
</choice>
</extension>
</complexContent>
</complexType>
<!-- /CompoundRequest -->
[130]The <CompoundResult> element is used to respond to a
<CompoundRequest>. If the compound result has
the MajorResult value Success it contains multiple responses corresponding to
the multiple requests specified