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




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

4The DSS Verifying Protocol

4.1Element


The inherits from . This element is sent by the client to verify a signature or timestamp on some input documents. It contains the following additional elements:

[Optional]

This element contains a signature or timestamp, or else contains a that points to an XML signature in one of the input documents. If this element is omitted, there must be only a single which the server will search to find the to-be-verified signature(s). Either a or a single and no MUST be used whenever the to-be-verified signature is an XML signature which uses an Enveloped Signature Transform; otherwise the server would have difficulty locating the signature and applying the Enveloped Signature Transform.
























4.2Element


The inherits from . This element defines no additional attributes and elements.


4.3Basic Processing for XML Signatures


A DSS server that verifies XML signatures SHOULD perform the following steps, upon receiving a . These steps may be changed or overridden by the optional inputs, or by the profile or policy the server is operating under. For more details on multi-signature verification, see section 4.3.1.

  1. The server retrieves one or more objects, as follows: If the is present, the server retrieves either the that is a child element of the (see: Note at the end of this section), or those objects which are pointed to by the in the .

    1. If the points to an input document but not a specific element in that document, the pointed-to input document must be a element containing XML either in an , or element.
      If the document is inside or it is decoded and parsed as described in 3.3.1 Step 1.a or 3.3.3 Step 1a respectively.
      If the document is inside the document is extracted using exclusive canonicalization. The corresponding to the document MUST have a chain of transforms (at least one ds:Transform inside ds:Transforms) that anticipates and reflects this. If this is not the case the server MUST throw an Error (urn:oasis:names:tc:dss:1.0:resultminor:inappropriate:signature).
      Note: Otherwise false negatives due to namespace conflicts may appear.

    2. If the is omitted, there MUST be only a single element. This case is handled as if a pointing to the single was present: the server will search and find every element in this input document, and verify each according to the steps below.

  2. For each in the , the server finds the input document with matching RefURI and RefType values (omitted attributes match omitted attributes). If the uses a same-document URI, the XPointer should be evaluated against the input document the is contained within, or against the itself if it is contained within the element. The element or optional input of the input document or will be used, if present, to identify ID attributes when evaluating the XPointer expression. If the uses an external URI and the corresponding input document is not present, the server will skip the , and later return a result code such as ReferencedDocumentNotPresent to indicate this. The RefURI MAY be omitted in at most one of the set of Input documents.

    1. 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).

    2. If the input document is a , the server MAY check that the (if supplied) match between the and the and then hashes the resultant data object according to , and MUST check that the result matches .

    3. If the input document is a , the server MAY check that the , (if supplied) and elements match between the and the .

    4. If the combination of RefURI and RefType matches more than one input document all of them MUST be either a or a otherwise a RequesterError is issued qualified by result minor of ReferencedDocumentNotPresent.
      Only one of them is allowed to have a WhichReference value that matches the order of the within the in question otherwise a RequesterError is issued qualified by result minor of ReferencedDocumentNotPresent. Using this input document either variant b. or c. is applied respectively before continuing with step 3.

  3. The server shall verify the validity of the signature at a particular time (i.e. current time, assumed signing time or other time), depending on the server policy. This behaviour MAY be altered by using the optional input (see section 4.5.2).

  4. If the signature validates correctly, the server returns one of the first three codes listed in section 4.4, depending on the relationship of the signature to the input documents (not including the relationship of the signature to those XML elements that were resolved through XPointer evaluation; the client will have to inspect those relationships manually). If the signature fails to validate correctly, the server returns some other code; either one defined in section 4.4 of this specification, or one defined by some profile of this specification.

Note: The extraction of the from the should be performed without namespace inheritance. If the signature does not use exclusive canonicalization for it's there can appear problems caused by namespace declarations moved by gateways or protocol processors of outer protocol bindings that alter the signature object and cause false negatives on validation. Problems appearing due to different behavior of xml parsers in schema validating parsing vs. non-validating parsing like data type normalizations would have to be healed by canonicalization only as no transforms are available for ds:SignedInfo. As currently available specifications of canonicalization are not aware of schema data types a solution to heal these defects is currently not possible. Beware, these problems can already occur on parsing the whole request including protocol bindings like SOAP. Implementors are encouraged to make use of or instead.

4.3.1Multi-Signature Verification


If a client requests verification of an entire input document, either using a without an or a missing (see section 4.3 step 1), then the server MUST determine whether the input document contains zero, one, or more than one elements. If zero, the server should return a code of RequesterError.

If more than one elements are present, the server MUST either reject the request with a code of RequesterError and a code of NotSupported, or accept the request and try to verify all of the signatures.

If the server accepts the request in the multi-signature case (or if only a single signature is present) and one of the signatures fails to verify, the server should return one of the error codes in section 4.4, reflecting the first error encountered.

If all of the signatures verify correctly, the server should return the Success code and the following code:

urn:oasis:names:tc:dss:1.0:resultminor:ValidMultiSignatures

Note: These procedures only define procedures for handling of multiple signatures on one input document. The procedures for handling multiple signatures on multiple documents are not defined in this core specification, but however such procedures, along with any optional elements that may be required, may be defined in profiles of this specification.

Only certain optional inputs and outputs are allowed when performing multi-signature verification. See section 4.6 for details.

4.3.2Signature Timestamp verification procedure


The following sub-sections will describe the processing rules for verifying:

- RFC 3161 timestamp tokens on CMS Signatures

- XML timestamp tokens on XML Signatures

- RFC 3161 timestamp tokens on XML Signatures

This section describes signature timestamp processing when the timestamp is embedded in the incoming signature.

Note: procedures for handling other forms of timestamp may be defined in profiles of the Core. In particular, the DSS AdES profile [DSS-AdES-P] defines procedures for handling timestamps against the document being signed, and the DSS Timestamp profile defines procedures for handling standalone timestamps.

For a definition of the element see section 5.1 Details of the XML timestamp token can be found in subsection 5.1.1.

4.3.2.1Processing for RFC 3161 Timestamp tokens on CMS Signatures.


The present section describes the processing rules for verifying a CMS RFC3161 timestamp token passed in on a Verify call within the of the element. In the CMS case, since the "signature timestamp" is embedded in the signature as an unsigned attribute, only the time stamped signature is required for verification processing. As such, no additional input is required.

The processing by the server is broken down into the following steps:



  1. The signature timestamp is embedded in the incoming signature as an unsigned attribute whose object identifier is 1.2.840.11359.1.9.16.2.14. Extract and verify the timestamp token.

  2. Verify that the token's public verification certificate is authorized for time stamping by examining the Extended Key Usage field for the presence of the time stamping OID "1.3.6.1.5.5.7.3.8".

  3. Validate that the TstInfo structure has a valid layout as defined in [RFC 3161].

  4. Extract the MessageImprint hash value and associated algorithm from the TstInfo structure which will be compared against the hash value derived in the next step.

  5. Recalculate the hash of the signature value field of the signature in which the timestamp is embedded.

  6. Compare the hash values from the two previous steps, and if they are equivalent, then this timestamp is valid for the signature that was time stamped.

  7. Verify that the public verification certificate conforms to all relevant aspects of the relying-party's policy including algorithm usage, policy OIDs, time accuracy tolerances, and the Nonce value.

  8. Set the dss:Result element as defined in this specification. Minor Error
    urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTimestamp MAY be used to indicate that the signature is valid but the timestamp against that signature is invalid.

4.3.2.2Processing for XML timestamp tokens on XML signatures


The present section describes the processing rules for verifying and XML Signature timestamp token embedded within an XML signature using the incorporation mechanisms specified in XAdES (i.e., in the element's child). This XML signature may be passed in on a Verify call within the or embedded within a ’s child.

The server shall verify the timestamp token performing the steps detailed below. If any one of them results in failure, then the timestamp token SHOULD be rejected.



  1. Extract the timestamp token embedded in the incoming signature as defined in 3.5.2.2.

  2. Verify that the verification key and algorithms used conforms to all relevant aspects of the applicable policy. Should this key come within a public certificate, verify that the certificate conforms to all relevant aspects of the applicable policy including algorithm usage, policy OIDs, and time accuracy tolerances.

  3. Verify that the aforementioned verification key is consistent with the ds:SignedInfo/SignatureMethod/@Algorithm attribute value.

  4. Verify the timestamp token signature in accordance with the rules defined in [XMLDSIG].

  5. Verify that the element contains at least two elements.

  6. Verify that one of the elements has its Type attribute set to “urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken”. Take this one and proceed as indicated below:

    1. Retrieve the referenced data object. Verify that it references a element, which in turn envelopes a element.

    2. Verify that the element has a valid layout as per the present specification.

    3. Extract the digest value and associated algorithm from its and elements respectively.

    4. Recalculate the digest of the retrieved data object as specified by [XMLDSIG] with the digest algorithm indicated in , and compare this result with the contents of .

  7. Take each of the other elements and for each validate the hash as specified in [XMLDSIG].

  8. Check that for one of the elements the retrieved data object is actually the element and that it contains its digest after canonicalization.

  9. Set the element as appropriate. Minor Error
    urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTimestamp MAY be used to indicate that the signature is valid but the timestamp against that signature is invalid.

4.3.2.3Processing for RFC 3161 timestamp tokens on XML Signatures


The present section describes the processing rules for verifying an RFC 3161 timestamp token embedded within an XML signature as an unsigned property. This XML signature may be passed in on a Verify call within the or embedded within a ’s child.

The server shall verify the timestamp token performing the steps detailed below. If any one of them results in failure, then the timestamp token SHOULD be rejected.



  1. Extract the timestamp token embedded in the incoming signature as defined in 3.5.2.3.

  2. Verify that the token's public verification certificate is authorized for time stamping by examining the Extended Key Usage field for the presence of the time stamping OID "1.3.6.1.5.5.7.3.8".

  3. Process the signature timestamp as defined in [XAdES] Annex G.2.2.16.1.3.

  4. Verify that the public verification certificate conforms to all relevant aspects of the relying-party's policy including algorithm usage, policy OIDs, time accuracy tolerances, and the Nonce value.

  5. Set the dss:Result element as appropriate.
    urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTimestamp MAY be used to indicate that the signature is valid but the timestamp against that signature is invalid.
1   2   3   4   5   6   7   8   9   10   11


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

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