FW: Asynchronous Protocol Processing Issues 4, 5, 64

 
 
The following text replaces the description of synchronous/asynchronous
processing in section 2.1
 

2.1 Request Types


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
Information Service Specification 

Compound Request 

A compound request consists of a sequence of one or more X-KISS or X-KRSS
requests. 


2.2 Synchronous and Asynchronous Processing


XKMS supports two processing modes, synchronous processing and asynchronous
processing.

*	In synchronous processing the service returns the final response to
the requestor using the same communication channel used to issue the
request. 

*	Asynchronous processing is used in cases where a service cannot
complete the request immediately and it is undesirable to keep the
communication channel used for the request open while the request is being
completed.

A client MAY advise a service that it will accept asynchronous processing of
a request by specifying the ResponseMechanism value xkms:Asynchronous. An
XKMS service advises the client that the response value will be returned
asynchronously by specifying the MajorResult code xkms:Pending. 

An XKMS service MUST NOT return the MajorResult code xkms:Pending unless the
ResponseMechanism value xkms:Asynchronous was specified in the corresponding
request. If an XKMS service receives a request that cannot be processed
synchronously and the ResponseMechanism value xkms:Asynchronous is not
specified the MajorResult code xkms:Receiver and MinorResult code
xkms:NotSynchronous are returned.

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.

XKMS Clients

*	MUST support synchronous processing of X-KISS requests 

*	MUST support synchronous processing of X-KRSS requests 

*	MUST support synchronous processing of compound XKMS requests 

*	MAY support asynchronous processing of X-KISS requests 

*	SHOULD support synchronous processing of X-KRSS requests 

*	SHOULD support synchronous processing of compound XKMS requests

XKMS services 

*	MUST support synchronous processing of X-KISS requests 

*	SHOULD support synchronous processing of X-KRSS requests 

*	MAY support synchronous processing of compound XKMS requests 

*	MAY support asynchronous processing of X-KISS requests 

*	SHOULD support synchronous processing of X-KRSS requests 

*	SHOULD support synchronous processing of compound XKMS requests

In each case the requirement to support a particular processing mode only
applies if the client or service would otherwise support the specified
request type. For example if an XKMS service supports X-KISS requests it
MUST support synchronous processing of those requests but an XKMS service is
not required to support the X-KISS services.

The Synchronous and Asynchronous processing of requests is described in
<file:///C:/Documents%20and%20Settings/Phill/My%20Documents/XML%20Trust/XKMS
/xkms-part-2.html> Part II.


2.3 Two Phase Request Protocol


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. 

A client MAY advise a service that it supports the two phase request
protocol by specifying the ResponseMechanism value xkms:Represent. An XKMS
service advises the client that the use of the two phase request protocol is
required by specifying the MajorResult code xkms:Represent. 

An XKMS service MUST NOT return the MajorResult code xkms:Represent unless
the ResponseMechanism value xkms:Represent was specified in the
corresponding request. If an XKMS service requires the use of the Two Phase
Request protocol and the ResponseMechanism value xkms:Represent is not
specified in the corresponding request the MajorResult code xkms:Receiver
and MinorResult code xkms:MustRepresent are returned.

The Two Phase request protocol bears some similarity to asynchronous request
processing. Both mechanisms introduce an extra protocol round trip but
server 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.

The Two Phase Request Protocol may be combined with the Asynchronous
protocol in which case a single XKMS operation would require a total of
three request/response message pairs to complete.

The Two Phase Request Protocol is described in
<file:///C:/Documents%20and%20Settings/Phill/My%20Documents/XML%20Trust/XKMS
/xkms-part-2.html> Part II.