A DSS server that verifies CMS 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.
The server retrieves the CMS signature by decoding the child of .
The server retrieves the input data. 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.
The CMS signature and input data are verified in the conventional way (see [RFC 3852] for details).
If the signature validates correctly, the server returns the first code listed in section 4.4. 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.
4.5Optional Inputs and Outputs
This section defines some optional inputs and outputs that profiles of the DSS verifying protocol might find useful. Section 2.8 defines some common optional inputs that can also be used with the verifying protocol. Profiles of the verifying protocol can define their own optional inputs and outputs, as well. General handling of optional inputs and outputs is discussed in section 2.7.
The presence of this element instructs the server to validate manifests in an XML signature.
On encountering such a document in step 2 of basic processing, the server shall repeat step 2 for all the elements within the manifest. In accordance with [XMLDSIG] section 5.1, DSS Manifest validation does not affect a signature's core validation. The results of verifying individual 's within a are returned in the optional output.
For example, a client supplies the optional input , then the returned is urn:oasis:names:tc:dss:1.0:resultminor:valid:hasManifestResults if XMLSig core validation succeeds and the optional output is returned indicating the status of the manifest reference verification. In case of a negative XMLSig core validation no attempt is made to verify manifests.
The optional input is allowed in multi-signature verification. The is comprised of one or more s that contain the following:
Indicates the manifest validation result. It takes one of the values urn:oasis:names:tc:dss:1.0:manifeststatus:Valid or urn:oasis:names:tc:dss:1.0:manifeststatus:Invalid.
This element instructs the server to attempt to determine the signature’s validity at the specified time, instead of a time determined by the server policy.
Note: In order to perform the verification of the signature at a certain time, the server MUST obtain the information necessary to carry out this verification (e.g. CA certificates, CRLs) applicable at that time.
Instructs the server to use its current time (normally the time associated with the server-side request processing).
Allows the client to manage manually the time instant used in the verification process. It SHOULD be expressed as UTC time (Coordinated Universal Time) to reduce confusion with the local time zone use.
Profiles MAY define new child elements associated to other different behaviors.
If the verification time is a significant period in the past the server MAY need to take specific steps for this, and MAY need to ensure that any cryptographic weaknesses over the period do not affect the validation.
This optional input is allowed in multi-signature verification.
4.5.3Optional Input/Output /
This element allows the client to obtain the time instant used by the server to validate the signature.
Optionally, in addition to the verification time, the server MAY include in the response any other relevant time instants that may have been used when determining the verification time or that may be useful for its qualification.
The time instant used by the server when verifying the signature. It SHOULD be expressed as UTC time (Coordinated Universal Time) to reduce confusion with the local time zone use.
Any other time instant(s) relevant in the context of the verification time determination.
The Type attribute qualifies the kind of time information included in the response. The Ref attribute allows to establish references to the source of the time information, and SHOULD be used when there is a need to disambiguate several elements with the same Type attribute.
This specification defines the following base types, whose values MUST be of type xs:dateTime and SHOULD be expressed as UTC time (Coordinated Universal Time). Profiles MAY include and define new values for the Type attribute.
The time carried inside a timestamp applied over a signed object.
Note that XML Signatures can be produced over multiple objects (via multiple ds:Reference elements), and therefore it's possible to have multiple timestamps, each one applied over each object. In this case, the Ref attribute MUST include the value of the Id attribute of the ds:Reference element.
The presence of the optional input instructs the server to return a
These options are not allowed in multi-signature verification.
optional output elaborates on what signature verification steps succeeded or failed. It may contain the following child elements:
A verification detail that was evaluated and found to be valid.
A verification detail that could not be evaluated or was evaluated and returned an indeterminate result.
A verification detail that was evaluated and found to be invalid.
Each detail element is of type dss:DetailType. A dss:DetailType contains the following child elements and attributes:
A URI which identifies the detail. It may be a value defined by this specification, or a value defined by some other specification. For the values defined by this specification, see below.
Multiple detail elements of the same Type may appear in a single
. For example, when a signature contains a certificate chain that certifies the signing key, there may be details of the same Type present for each certificate in the chain, describing how each certificate was processed.
A URI which more precisely specifies why this detail is valid, invalid, or indeterminate. It must be a value defined by some other specification, since this specification defines no values for this element.
A human-readable message which MAY be logged, used for debugging, etc.
The values for the Type attribute defined by this specification are the following:
Whether the issuer of trust information for the signing key (or one of the certifying keys) is considered to be trustworthy.
Sometimes, depending on the applicable server policy, this signing time needs to be qualified, in order to avoid unacceptable measurement errors or false claims, using time boundaries associated to trustworthy time values (based on timestamps or time-marks created using trusted time sources). In this case, the server MAY include these values in the and elements, respectively.
Criteria for determining when a time instant can be considered trustworthy and for determining the maximum acceptable delays between the signing time and their boundaries (if any) is outside the scope of this specification.
When there's no way for the server to determine the signing time, the server MUST omit the output.
The time value considered by the server to be the signature creation time.
The trusted time values considered as lower and upper limits for the signing time. If this element is present, at least one of the and elements MUST be present.
This optional input is not allowed in multi-signature verification.
This optional input and output are not allowed in multi-signature verification.
The optional output contains an indication of who performed the signature.
4.5.8Optional Input and Outputs ,
The presence of the optional input instructs the server to return an output, containing a new or updated signature.
The Type attribute on , if present, defines exactly what it means to “update” a signature. For example, the updated signature may be the original signature with some additional unsigned signature properties added to it (such as timestamps, counter-signatures, or additional information for use in verification), or the updated signature could be an entirely new signature calculated on the same input documents as the input signature. Profiles that use this optional input MUST define the allowed values and their semantics, and the default value, for the Type attribute (unless only a single type of updated signature is supported, in which case the Type attribute can be omitted).
Multiple occurrences of this optional input can be present in a single verify request message. If multiple occurrences are present, each occurrence MUST have a different Type attribute. Each occurrence will generate a corresponding optional output. These optional outputs SHALL be distinguishable based on their Type attribute, which will match each output with an input.
The resulting updated signature or timestamp or, in the case of a signature being enveloped in an output document, a pointer to the signature. This is used in steps 2. and 3. in the processing described below.These options are not allowed in multi-signature verification.
The optional output contains the returned signature.
The is as follows.
A DSS server SHOULD perform the following steps, upon receiving a . These steps may be changed or overridden by a profile or policy the server is operating under. (e.g For PDF documents enveloping cms signatures)
If the signature to be verified and updated appears within a 's (detached or enveloping) or then the optional ouput MUST contain the modified with the corresponding (detached or enveloping) or child containing the updated signature.
If the signature to be verified and updated is enveloped, and if the contains a with a pointing to an (, , ) enveloping the signature then the server MUST produce the following TWO optional outputs, first a optional output containing the document that envelopes the updated signature, second an optional output containing a having a element that MUST point to the former .
If there is no at all in the request then the server MUST produce only a optional output containing the document with the updated signature.
No element will be generated.
As appears in steps 2. and 3. of the processing above it is explained here again:
The optional output (for the schema refer to section 3.5.8) contains the input document with the given signature inserted.
It has one child element:
This returns the given document with a signature inserted in some fashion.
The resulting document with the updated enveloped signature is placed in the optional output . The server places the signature in the document identified using the /'s WhichDocument attribute.
This MUST include a same-documentRefURI attribute which references the data updated (e.g of the form RefURI).
4.5.9Optional Input and Output
The optional input instructs the server to return an input document to which the XML signature transforms specified by a particular have been applied. The is indicated by the zero-based WhichReference attribute (0 means the first in the signature, 1 means the second, and so on). Multiple occurrences of this optional input can be present in a single verify request message. Each occurrence will generate a corresponding optional output.
These options are not allowed in multi-signature verification.
The optional output contains a document corresponding to the specified , after all the transforms in the reference have been applied. In other words, the hash value of the returned document should equal the element’s . To match outputs to inputs, each will contain a WhichReference attribute which matches the corresponding optional input.
4.5.10Optional Input and Outputs ,
The element within a message indicates that the client wishes the server to update the signature after its verification by embedding a signature timestamp token as an unauthenticated attribute (see "unauthAttrs" in section 9.1 [RFC 3852]) or *unsigned* property (see section 6.2.5 "The UnsignedSignatureProperties element" and section 7.3 "The SignatureTimeStamp element" [XAdES]) of the supplied signature.
The timestamp token will be on the signature value in the case of CMS/PKCS7signatures or the element in the case of XML signatures.
The Type attribute, if present, indicates what type of timestamp to apply. This document defines two values for it, namely:
b. urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken, for generating a XML timestamp token as defined in section 5 of this document.
Profiles that use this optional input MUST define the allowed values, and the default value, for the Type attribute (unless only a single type of timestamp is supported, in which case the Type attribute can be omitted).
Below follows the schema definition for these elements.
A DSS server SHOULD perform the steps 1. - 3. as indicated in 4.5.8 upon receiving a replacing by
Procedures for handling RFC 3161 and XML timestamps are as defined in 188.8.131.52 and 184.108.40.206.
Note: Procedures for handling other forms of timestamp may be defined in profiles of the Core. In particular, the DSS XAdES profile [DSS-XAdES-P] defines procedures for handling timestamps against the document being signed, and the DSS Timestamp profile [DSS-TS-P] defines procedures for handling standalone timestamps.