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




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

2.10Type


The complex type is the base structure for request elements defined by the core protocol or profiles. It defines the following attributes and elements:

RequestID [Optional]

This attribute is used to correlate requests with responses. When present in a request, the server MUST return it in the response.

Profile [Optional]

This attribute indicates a particular DSS profile. It may be used to select a profile if a server supports multiple profiles, or as a sanity-check to make sure the server implements the profile the client expects.

[Optional]

Any additional inputs to the request.



[Optional]

The input documents which the processing will be applied to.













use=”optional”/>






2.11Type


The complex type is the base structure for response elements defined by the core protocol or profiles. It defines the following attributes and elements:

RequestID [Optional]

This attribute is used to correlate requests with responses. When present in a request, the server MUST return it in the response.

Profile [Required]

This attribute indicates the particular DSS profile used by the server. It may be used by the client for logging purposes or to make sure the server implements a profile the client expects.

[Required]

A code representing the status of the request.



[Optional]

Any additional outputs returned by the server.













use=”optional”/>






2.12Element


The element is an instance of the type. This element is useful in cases where the DSS server is not able to respond with a special response type. It is a general purpose response element for exceptional circumstances.

E.g.: "The server only supports verification requests.", "The server is currently under maintenance" or "The service operates from 8:00 to 17:00".

Other use cases for this type are expected to be described in special profiles ( e.g. the Asynchronous profile ).


3The DSS Signing Protocol

3.1Element


The element is sent by the client to request a signature or timestamp on some input documents. It contains the following attributes and elements inherited from :

RequestID [Optional]

This attribute is used to correlate requests with responses. When present in a request, the server MUST return it in the response.

Profile [Optional]

This attribute indicates a particular DSS profile. It may be used to select a profile if a server supports multiple profiles, or as a sanity-check to make sure the server implements the profile the client expects.

[Optional]

Any additional inputs to the request.



[Optional]

The input documents, which the signature will be calculated over. This element, while optional in RequestBaseType, is REQUIRED for the element.
















3.2Element


The element contains the following attributes and elements inherited from :

RequestID [Optional]

This attribute is used to correlate requests with responses. When present in a request, the server MUST return it in the response.

Profile [Optional]

This attribute indicates the particular DSS profile used by the server. It may be used by the client for logging purposes or to make sure the server implements a profile the client expects.

[Required]

A code representing the status of the request.



[Optional]

Any additional outputs returned by the server.

In addition to the element defines the following element:

[Optional]

The result signature or timestamp or, in the case of a signature being enveloped in an output document (see section 3.5.8), a pointer to the signature.

In the case of being used this MUST contain a , having the same XPath expression as in and pointing to a using it’s WhichDocument attribute.






















3.3Processing for XML Signatures

3.3.1Basic Process for


A DSS server that produces XML signatures SHOULD perform the following steps, upon receiving a .

These steps may be changed or overridden by procedures defined for the optional inputs (for example, see section 3.5.6), or by the profile or policy the server is operating under.



The ordering of the elements inside the MAY be ignored by the server.

  1. For each in the server MUST perform the following steps:

    1. In the case of (see later sub-sections for other cases), the server base64-decodes the data contained within into 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.

    2. The data is processed and transforms applied by the server to produce a canonicalized octet string as required in [XMLDSIG] section 4.3.3.2.
      Note: Transforms can be 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. Servers MAY choose not to apply transforms in basic processing and extract the binary data for direct hashing or canonicalize the data directly if certain optional inputs (see sections 3.5.8 point 2 and d.v, 3.5.9 ) are not to be implemented.
      Note: As required in [XMLDSIG] if the end result is an XML node set, the server MUST attempt to convert the node set back into an octet stream using Canonical XML [XML-C14N].

    3. The hash of the resulting octet stream is calculated.

    4. The server forms a with the elements and attributes set as follows:

      1. If the has a RefURI attribute, the element’s URI attribute is set to the value of the RefURI attribute, else this attribute is omitted.
        A signature MUST NOT be created if more than one RefURI is omitted in the set of input documents and the server MUST report a RequesterError by setting RequesterError qualified by a .

      2. If the has a RefType attribute, the element’s Type attribute is set to the value of the RefType attribute, else this attribute is omitted.

      3. The element is set to the hash method used.

      4. The element is set to the hash value that is to be calculated as per [XMLDSIG].

      5. The element is set to the sequence of transforms applied by the server in step b. This sequence MUST describe the effective transform as a reproducible procedure from parsing until hash.

  1. References resulting from processing of optional inputs MUST be included. In doing so, the server MAY reflect the ordering of the elements.

  2. The server creates an XML signature using the elements created in Step 1.d, according to the processing rules in [XMLDSIG].

3.3.2Process Variant for


In the case of an input document which contains Step 3.3.1 1.a is replaced with the following step:



    1. The XML document is extracted from the DSS protocol envelope, without taking inherited namespaces and attributes. Exclusive Canonical XML [XML-xcl-c14n] MUST be applied to extract data AND assure context free extraction.
      If signed data is to be echoed back to the client and hence details could get lost refer to Error: Reference source not found.

In Step 3.3.1 step 1.d.v, the element MUST begin with the canonicalization transform applied under revised step 3.3.2 1.a above.

3.3.3Process Variant for


In the case of an input document which contains Step 3.3.1 1.a is replaced with the following:



    In the case of the server unescapes the data contained within into a character string. If the RefURI references within the same input document the server parses the unescaped character content to NodeSetData if necessary. If the RefURI does not reference within the same input document then the server canonicalizes the characters or parsed NodeSetData (see [XMLDSIG] section 4.3.3.3) to octet stream if necessary before proceeding to the next step.

    Note: If the characters are converted to an octet stream directly a consistent encoding including ByteOrderMark has to be ensured.



In Step 3.3.1 1.d.v, the element MUST begin with the canonicalization transform applied under revised step 3.3.3 above.

3.3.4Process Variant for


In the case of an input document which contains Step 1 a and Step 1 b are replaced with the following:



    1. The server base64-decodes the data contained within into an octet string.

    2. No transforms or other changes are made to the octet string before hashing.

      Note: If the RefURI references within the same input document the Document MUST also be referenced by in section 3.5.6 to include the object as base64 data inside a otherwise a (section 2.6) issuing a RequesterError qualified by a NotParseableXMLDocument.


3.3.5Process Variant for


In the case of an input document which contains Step 3.3.1 1 is replaced with the following:

  1. For each in the server MUST perform the following steps:

    1. The server base64-decodes the data contained within of into an octet string.

    2. Omitted.

    3. The hash over of the octet stream extracted in step a is calculated.

    4. as in 3.3.1 step 1d updated as follows

    replace the word "" by otherwise as in as 3.3.1 step 1d.i.

    replace the word "" by otherwise as in as 3.3.1 step 1d.ii.

    same as 3.3.1 step 1d.iii.

    The element is set to the sequence of transforms indicated by the client in the element within the . This sequence MUST describe the effective transform as a reproducible procedure from parsing until digest input.


3.3.6Process Variant for


In the case of an input document which is provided in the form of a hash value in Step 3.3.1 1 is replaced with the following:

  1. For each in the server MUST perform the following steps:

    1. Omitted.

    2. Omitted.

    3. Omitted.

    4. as in 3.3.1 step 1d updated as follows

      1. replace the word "" by otherwise as in as 3.3.1 step 1d.i.

      2. replace the word "" by otherwise as in as 3.3.1 step 1d.ii.

      3. The element is set to the value of in

      4. The element is set to the value of in .

      5. The element is set to the sequence of transforms indicated by the client in the element within , if any such transforms are indicated by the client. This sequence MUST describe the effective transform as a reproducible procedure from parsing until hash.
1   2   3   4   5   6   7   8   9   10   11


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

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