Digital Signature Service Core Protocols, Elements, and Bindings Version 0 oasis standard 11 April 2007




старонка11/11
Дата канвертавання24.04.2016
Памер0.54 Mb.
1   2   3   4   5   6   7   8   9   10   11

5DSS Core Elements


This section defines two XML elements that may be used in conjunction with the DSS core protocols.

5.1Element


This section defines an XML timestamp. A contains some type of timestamp token, such as an RFC 3161 TimeStampToken [RFC 3161] or a (aka an “XML timestamp token”) (see section 5.1.1). Profiles may introduce additional types of timestamp tokens. Standalone XML timestamps can be produced and verified using the timestamping profile of the DSS core protocols [XML-TSP].

An XML timestamp may contain:



[Optional]

This is an enveloping XML signature, as defined in section 5.1.1.



[Optional]

This is a base64-encoded TimeStampToken as defined in [RFC3161].











type=”xs:base64Binary”/>










5.1.1XML Timestamp Token


An XML timestamp token is similar to an RFC 3161 TimeStampToken, but is encoded as a element (see section 5.1.2) inside an enveloping . This allows conventional XML signature implementations to validate the signature, though additional processing is still required to validate the timestamp properties (see section 4.3.2.2).

The following text describes how the child elements of the MUST be used:

[Required]

The element SHALL identify the issuer of the timestamp and MAY be used to locate, retrieve and validate the timestamp token signature-verification key. The exact details of this element may be specified further in a profile.



/ [Required]

There MUST be a single element whose URI attribute references the containing the enveloped element, and whose Type attribute is equal to urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken.



[Required]

A element SHALL be contained in a element.

Additional elements MUST appear for data objects [XMLDSIG] being time-stamped. For details on further use of time-stamps, please refer to appropriate profiles.

5.1.2Element


A element is included in an XML timestamp token as a / child element. A element has the following children:

[Required]

This element SHALL contain a serial number produced by the timestamp authority (TSA). It MUST be unique across all the tokens issued by a particular TSA.



[Required]

The time at which the token was issued.


[Optional]

This element SHALL identify the policy under which the token was issued. The TSA’s policy SHOULD identify the fundamental source of its time.

[Optional]

The TSA’s estimate of the maximum error in its local clock.



[Default=”false”]

This element SHALL indicate whether or not timestamps issued by this TSA, under this policy, are strictly ordered according to the value of the CreationTime element value.

TSA [Optional]

The name of the TSA.















minOccurs=”0”/>



default=”false” minOccurs=”0”/>



minOccurs=”0”/>








5.2Element


This section contains the definition of an XML Requester Identity element. This element can be used as a signature property in an XML signature to identify the client who requested the signature.

This element has the following children:

Name [Required]

The name or role of the requester who requested the signature be performed.

SupportingInfo [Optional]

Information supporting the name (such as a SAML Assertion [SAMLCore1.1], Liberty Alliance Authentication Context, or X.509 Certificate).

The following schema fragment defines the element:









minOccurs=”0”/>








6DSS Core Bindings


Mappings from DSS messages into standard communications protocols are called DSS bindings. Transport bindings specify how DSS messages are encoded and carried over some lower-level transport protocol. Security bindings specify how confidentiality, authentication, and integrity can be achieved for DSS messages in the context of some transport binding.

Below we specify an initial set of bindings for DSS. Future bindings may be introduced by the OASIS DSS TC or by other parties.


6.1HTTP POST Transport Binding


In this binding, the DSS request/response exchange occurs within an HTTP POST exchange [RFC 2616]. The following rules apply to the HTTP request:

The client may send an HTTP/1.0 or HTTP/1.1 request.

The Request URI may be used to indicate a particular service endpoint.

The Content-Type header MUST be set to “application/xml”.

The Content-Length header MUST be present and correct.

The DSS request message MUST be sent in the body of the HTTP Request.

The following rules apply to the HTTP Response:

The Content-Type header MUST be set to “text/xml”.

The Content-Length header MUST be present and correct.

The DSS response message MUST be sent in the body of the HTTP Response.

The HTTP status code MUST be set to 200 if a DSS response message is returned. Otherwise, the status code can be set to 3xx to indicate a redirection, 4xx to indicate a low-level client error (such as a malformed request), or 5xx to indicate a low-level server error.

6.2SOAP 1.2 Transport Binding


In this binding, the DSS request/response exchange occurs using the SOAP 1.2 message protocol [SOAP]. The following rules apply to the SOAP request:

A single DSS or element will be transmitted within the body of the SOAP message.

The client MUST NOT include any additional XML elements in the SOAP body.

The UTF-8 character encoding must be used for the SOAP message.

Arbitrary SOAP headers may be present.

The following rules apply to the SOAP response:

The server MUST return either a single DSS or element within the body of the SOAP message, or a SOAP fault code.

The server MUST NOT include any additional XML elements in the SOAP body.

If a DSS server cannot parse a DSS request, or there is some error with the SOAP envelope, the server MUST return a SOAP fault code. Otherwise, a DSS result code should be used to signal errors.

The UTF-8 character encoding must be used for the SOAP message.

Arbitrary SOAP headers may be present.

On receiving a DSS response in a SOAP message, the client MUST NOT send a fault code to the DSS server.


6.2.1SOAP Attachment Feature and Element


Applications MAY support SOAP 1.2 attachment feature [SOAPAtt] to transmit documents in the context of a or a and can take advantage of /.

AttRefURI

SOAP 1.2 attachment feature [SOAPAtt] states that any secondary part ("attachment") can be referenced by a URI of any URI scheme.

AttRefURI refers to such a secondary part ("attachment") and MUST resolve within the compound SOAP message. The default encapsulation mechanism is MIME as specified in the WS-I Attachments Profile [WS-I-Att] (cf. swaRef, http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html#Referencing_Attachments_from_the_SOAP_Envelope).

MimeType [Optional]

Declares the MIME type of the referred secondary part of this SOAP compound message.

Note: If MIME is used as encapsulation mechanism, the MIME content-type is available via a MIME header. However, the MIME headers may not be available to implementations and the SOAP 1.2 attachment feature is not restricted to MIME. Further the MIME header is not secured by the AttachmentReference's DigestValue, which is calculated over the binary attachment data (not including the MIME headers).

[Optional Sequence]

These optional elements can be used to ensure the integrity of the attachment data.

If these elements are supplied the server SHOULD compute a message digest using the algorithm given in over the binary data in the octet stream and compare it against the supplied .

If the comparison fails then a RequesterError qualified by a GeneralError and an appropriate message containing the AttRefURI is returned.

Note: The attachments digest value(s) can be included in the primary SOAP part to allow the entire request (including secondary parts) to be secured by WSS. However, the MIME headers are not covered by the digest value and therefore can be included into the dss:AttachmentReference (which is relevant for the processing of dss:IncludeObject referring to an dss:AttachmentReference).

The digest value may be computed while the data is read from the attachment. After the last byte being read from the attachment the server compares the calculated digest value against the supplied .




















6.2.1.1Signing Protocol, Processing for XML Signatures, Process Variant for


In the case of an input document which contains the server retrieves the MIME type from the MimeType attribute (if present) otherwise from the content-type MIME header of the attachment referred by AttRefURI. If the MimeType attribute diverges from the attachment's MIME header content-type, an implementation MAY either ignore the MIME header's content-type or issue a RequesterError qualified by a GeneralError and an appropriate message containing the AttRefURI.

IF the MIME type indicates that it contains XML continue with processing as in section 3.3.1 and Step 1 a is replaced with the following:

1.

a. The server retrieves the data from the attachment referred by AttRefURI as an octet stream. This data MUST be a well formed XML Document as defined in [XML] section 2.1. If the RefURI attribute references within the same input document then the server parses the octet stream to NodeSetData (see [XMLDSIG] section 4.3.3.3) before proceeding to the next step.



ELSE continue with processing as in section 3.3.4 and Step 1 a is replaced with the following:

1.

a. The server retrieves the data from the attachment referred by AttRefURI as an octet stream.



Note: In the first case attachmentReference is always treated like Base64XML in the latter like Base64Data for further processing. (E.g. In the case of dss:IncludeObject, the MimeType attribute is copied from dss:AttachmentReference to ds:Object.)

6.2.1.2Verifying Protocol, Processing for XML Signatures, Process Variant for


Perform section 4.3 Basic Processing for XML Signatures amending step 2 2.a as follows:

2.

a. If the input document is a , the server extracts and decodes as described in 3.3.1 Step 1 a (or equivalent step in variants of the basic process as defined in 3.3.2 onwards depending of the form of the input document) or in the case of as described in section 6.2.1.1.


6.2.1.3Signing Protocol, Basic Processing for CMS Signatures, Process Variant for


Perform section 3.4 Basic Processing for CMS Signatures adding the following variant 1. d' after 1.d and before 1.e:

1.

d'. If the contains , the server retrieves the data from the attachment referred by AttRefURI as an octet stream.


6.2.1.4Verifying Protocol, Basic Processing for CMS Signatures, Process Variant for


Perform section 4.4 Basic Processing for CMS Signatures amending step 2 as follows:

2. The server retrieves the input data. (In the case of this is done as in section 6.2.1.3 step 1. d'. If the CMS signature is detached, there must be a single input document: i.e. a single or element. Otherwise, if the CMS signature is enveloping, it contains its own input data and there MUST NOT be any input documents present.


6.3TLS Security Bindings


TLS [RFC 2246] is a session-security protocol that can provide confidentiality, authentication, and integrity to the HTTP POST transport binding, the SOAP 1.2 transport binding, or others. TLS supports a variety of authentication methods, so we define several security bindings below. All of these bindings inherit the following rules:

TLS 1.0 MUST be supported. SSL 3.0 MAY be supported. Future versions of TLS MAY be supported.

RSA ciphersuites MUST be supported. Diffie-Hellman and DSS ciphersuites MAY be supported.

TripleDES ciphersuites MUST be supported. AES ciphersuites SHOULD be supported. Other ciphersuites MAY be supported, except for weak ciphersuites intended to meet export restrictions, which SHOULD NOT be supported.


6.3.1TLS X.509 Server Authentication


The following ciphersuites defined in [RFC 2246] and [RFC 3268] are supported. The server MUST authenticate itself with an X.509 certificate chain [RFC 3280]. The server MUST NOT request client authentication.

MUST:


TLS_RSA_WITH_3DES_EDE_CBC_SHA

SHOULD:


TLS_RSA_WITH_AES_128_CBC_SHA

TLS_RSA_WITH_AES_256_CBC_SHA


6.3.2TLS X.509 Mutual Authentication


The same ciphersuites mentioned in section 6.2.1 are supported. The server MUST authenticate itself with an X.509 certificate chain, and MUST request client authentication. The client MUST authenticate itself with an X.509 certificate chain.

6.3.3TLS SRP Authentication


SRP is a way of using a username and password to accomplish mutual authentication. The following ciphersuites defined in [draft-ietf-tls-srp-08] are supported.

MUST:


TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA

SHOULD:


TLS_SRP_SHA_WITH_AES_128_CBC_SHA

TLS_SRP_SHA_WITH_AES_256_CBC_SHA


6.3.4TLS SRP and X.509 Server Authentication


SRP can be combined with X.509 server authentication. The following ciphersuites defined in [draft-ietf-tls-srp-08] are supported.

MUST:


TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA

SHOULD:


TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA

TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA


7DSS-Defined Identifiers


The following sections define various URI-based identifiers. Where possible an existing URN is used to specify a protocol. In the case of IETF protocols the URN of the most current RFC that specifies the protocol is used (see [RFC 2648]). URI references created specifically for DSS have the following stem:

urn:oasis:names:tc:dss:1.0:


7.1Signature Type Identifiers


The following identifiers MAY be used as the content of the optional input (see section 3.5.1).

7.1.1XML Signature


  • URI: urn:ietf:rfc:3275

  • This refers to an XML signature per [XMLDSIG].

7.1.2XML TimeStampToken


  • URI: urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken

  • This refers to an XML timestamp containing an XML signature, per section 5.1.

7.1.3RFC 3161 TimeStampToken


  • URI: urn:ietf:rfc:3161

  • This refers to an XML timestamp containing an ASN.1 TimeStampToken, per [RFC 3161].

7.1.4CMS Signature


  • URI: urn:ietf:rfc:3369

  • This refers to a CMS signature per [RFC 3852] or prior versions of CMS.

7.1.5PGP Signature


  • URI: urn:ietf:rfc:2440

  • This refers to a PGP signature per [RFC 2440].
  1. Use of Exclusive Canonicalization


Exclusive Canonicalization of dereferenced and transformed data can be achieved by appending exclusive canonicalization as the last transform in the element of or .

In the case of being used this can be done by adding exclusive canonicalization as the last transform in the of a pointing to that .

By doing this the resulting data produced by the chain of transforms will always be octet stream data which will be hashed without further processing on a level by the server as indicated by basic processing section 3.3.1 step 1 b. and c.

Another possibility to apply exclusive canonicalization on level is the freedom given to servers to apply additional transforms to increase robustness. This however implies that only trustworthy transformations are appended by a server.

As in section 3.3.1 step 1 b an implementation can choose to use exclusive canonicalization: "... Transforms are applied as a server implementation MAY choose to increase robustness of the Signatures created. These Transforms may reflect idiosyncrasies of different parsers or solve encoding issues or the like. ..."

In such a case that the exclusive canonicalization is to be included in the as well (cf. section 3.3.1 step 1.d.v.)

The standards default is however in line with [XMLDSIG] as indicated in the Note in section 3.3.1 step 1 b.

However after the server formed a (section 3.3.1 step 3.) this information to be signed also needs to be canonicalized and digested, here [XMLDSIG] offers the necessary element directly and can be used to specify exclusive canonicalization.


  1. More Complex Example


To further explain the use of the element which is useful in cases where the DSS server is not able to respond with a special response type a more complex example is given in the following paragraph.

Consider for example a client sends a to a service that only supports 's over plain HTTP (as opposed to protocols where some information could be derived from the header ). As the service does not support 's it has to either generate a with a "bad message" result or fail at the HTTP layer. In the former case, the client will receive a response that does not correspond semantically to the request - it got a to a . This leaves both parties thinking that the other one is at fault.


  1. Acknowledgements


The following individuals have participated in the creation of this specification and are gratefully acknowledged:

Participants:

Dimitri Andivahis, Surety

Glenn Benson, JPMorganChase

Juan Carlos Cruellas, individual

Carlos Gonzalez-Cadenas, Netfocus, S.L

Frederick Hirsch, Nokia

Pieter Kasselman, Cybertrust

Andreas Kuehne, individual

Konrad Lanz, Austria Federal Chancellery

Tommy Lindberg, individual

Paul Madsen, Entrust

John Messing, American Bar Association

Tim Moses, Entrust

Trevor Perrin, individual

Nick Pope, Thales eSecurity

Rich Salz, DataPower

Ed Shallow, Universal Postal Union


oasis-dss-core-spec-v1.0-os 11 April 2007

Copyright © OASIS® 2007. All Rights Reserved. Page of


1   2   3   4   5   6   7   8   9   10   11


База данных защищена авторским правом ©shkola.of.by 2016
звярнуцца да адміністрацыі

    Галоўная старонка