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




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

3.4Basic Processing for CMS Signatures


A DSS server that produces CMS signatures [RFC 3852] 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. With regard to the compatibility issues in validation / integration of PKCS#7 signatures and CMS implementations please refer to [RFC 3852] section 1.1.1 “Changes Since PKCS #7 Version 1.5”.

The MUST contain either a single not having RefURI, RefType set or a single not having RefURI, RefType, set:



  1. If a is present, the server hashes its contents as follows:

    1. If the contains , the server extracts the ancestry context free text content of the as an octet stream by base64 decoding it’s contents.

    2. If the contains , the server extracts the ancestry context free text content of the as an octet stream as explained in (section 3.3.2 1.a ). This octet stream has to be returned as / . For CMS signatures this only has to be returned in the case of CMS signatures that are external/detached/"without eContent", as these return the signed Data anyway.

    3. If the contains , the server unescapes the content of the as a character stream and converts the character stream to an octet stream using an encoding as explained in (section 3.3.3).

    4. If the contains , the server base64-decodes the text content of the into an octet stream.

    5. The server hashes the resultant octet stream.

  2. The server forms a SignerInfo structure based on the input document. The components of the SignerInfo are set as follows:

    1. The digestAlgorithm field is set to the OID value for the hash method that was used in step 1.c (for a ), or to the OID value that is equivalent to the input document’s (for a ).

    2. The signedAttributes field’s message-digest attribute contains the hash value that was calculated in step 1.e (for a ), or that was sent in the input document’s (for a ). Other signedAttributes may be added by the server, according to its profile or policy, or according to the
      optional input (see section 3.5.5).

    3. The remaining fields (sid, signatureAlgorithm, and signature) are filled in as per a normal CMS signature.

  3. The server creates a CMS signature (i.e. a SignedData structure) containing the SignerInfo that was created in Step 2. The resulting SignedData should be detached (i.e. external or “without eContent”) unless the client sends the optional input (see section 3.5.9).

3.4.1Process Variant for


    In the case of a the processing by the server is as follows:

  1. Omitted.

    1. Omitted.

    2. Omitted.

    3. Omitted.

    4. Omitted.

    5. Omitted.

  2. Same as in 3.4 step 2

    1. Unchanged.

    2. Unchanged.

    3. Unchanged.

  3. As in 3.4 step 3, with the requirement that the signature has to be external/detached/"without eContent", since is incompatible with optional input (see 3.5.7).

3.5Optional Inputs and Outputs


This section defines some optional inputs and outputs that profiles of the DSS signing protocol might find useful. Section 2.8 defines some common optional inputs that can also be used with the signing protocol. Profiles of the signing protocol can define their own optional inputs and outputs, as well. General handling of optional inputs and outputs is discussed in section 2.7.

3.5.1Optional Input


The element indicates the type of signature or timestamp to produce (such as a XML signature, a XML timestamp, a RFC 3161 timestamp, a CMS signature, etc.). See section 7.1 for some URI references that MAY be used as the value of this element.


3.5.2Optional Input


The element indicates that the client wishes the server to embed a timestamp token as a property or attribute of the resultant or the supplied signature. The timestamp token will be applied to the signature value in the case of CMS/PKCS7 signatures or the element in the case of XML signatures.

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 generating timestamps over the content which is about to be signed (sometimes called content timestamps), and the DSS Timestamp profile [DSS-TS-P] defines procedures for handling standalone timestamps.

The schema definition of this optional input is as follows:









use="optional" default="false"/>





The type UpdateSignatureInstructionType is defined as follows:







The Type attribute, if present, indicates what type of timestamp to apply. 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).

Two scenarios for the timestamping of both CMS and XML signatures are supported by this Optional Input. They are as follows:

a) Create and embed a timestamp token into the signature being created as part of this SignRequest.

b) Create and embed a timestamp token into an existing signature, without verification, which is passed in the element of this SignRequest.

The following subsections specify the use of RFC 3161 timestamps with CMS signatures and the use of XML Timestamps or RFC 3161 timestamps with XML Signature. These subsections address both scenarios.


3.5.2.1Processing for CMS signatures time-stamping


In both scenarios, the timestamp token created by the server SHALL be created according to [RFC 3161]. The MessageImprint field within the TstInfo structure of the timestamp token will be derived from the signature value of the just-created or incoming signature depending on the scenario. The timestamp SHALL be embedded in the CMS signature as an unsigned attribute with the object identifier (see Appendix A of [RFC 3161]):

{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14}

The signature and its embedded timestamp is returned in the of the .

In scenario b) the incoming signature is passed in a element, with the MimeType attribute set to application/pkcs7-signature.

The Type attribute of the optional input SHALL be set to:

"urn:ietf:rfc:3161".

Note: In scenario b) the server SHOULD not verify the signature before adding the timestamp. If a client wishes that its signatures be verified as a condition of time stamping, the client SHOULD use the optional input of the Verify protocol.

3.5.2.2Processing for XML Timestamps on XML signatures


If the type attribute in this optional input is
urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken and signature being timestamped is an XML signature, then the XML signature MUST contain as defined in 5.1, placed in a within a
as defined in [XAdES].

The MUST contain with at least two elements:

- One with the Type attribute set to "urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken". and referencing a element whose content is a element.

- The other referencing the being timestamped.

The present specification defines a format for XML timestamp tokens. In addition XAdES defines a mechanism for incorporating signature timestamps in XML signatures. The present document mandates that signature timestamps in XML format MUST follow the syntax defined in section 5.1 of this document. These time-stamp tokens MUST be added to XML signatures as specified by XAdES.

The signature and its embedded timestamp SHALL be returned in the of the .

In scenario b) the incoming signature MUST be passed in on one of the following three elements , or .

Note: In scenario b) the server SHOULD not verify the signature before adding the timestamp. If a client wishes that its signatures be verified as a condition of time stamping, the client SHOULD use the optional input of the Verify protocol.

The Type attribute of the optional input SHALL be set to:
"urn: oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken”.

3.5.2.3Processing for RFC 3161 Timestamps on XML signatures


If the type attribute in this optional input is urn:ietf:rfc:3161 and signature being timestamped is an XML signature then the XML signature MUST contain an RFC 3161, placed in a within a as defined in [XAdES].

In scenario b) the incoming signature MUST be passed in on one of the following three elements , or .

Note: In scenario b) the server SHOULD not verify the signature before adding the timestamp. If a client wishes that its signatures be verified as a condition of time stamping, the client SHOULD use the optional input of the Verify protocol.

3.5.3Optional Input


The element tells the server who the target audience of this signature is. The server MAY use this to parameterize any aspect of its processing (for example, the server MAY choose to sign with a key that it knows a particular recipient trusts).







maxOccurs=”unbounded”/>








3.5.4Optional Input


The element tells the server which key to use.
















3.5.5Optional Input


The
element is used to request that the server add certain signed or unsigned properties (aka “signature attributes”) into the signature. The client can send the server a particular value to use for each property, or leave the value up to the server to determine. The server can add additional properties, even if these aren’t requested by the client.

The
element contains:



[Optional]

These properties will be covered by the signature.



[Optional]

These properties will not be covered by the signature.

Each
element contains:

[Required]

A URI reference identifying the property.



[Optional]

If present, the value the server should use for the property.

This specification does not define any properties. Profiles that make use of this element MUST define the allowed property URIs and their allowed values.







type=”dss:PropertiesType” minOccurs=”0”/>



type=”dss: PropertiesType” minOccurs=”0”/>

























minOccurs=”0”/>








3.5.6Optional Input


Optional input is used to request the creation of an XMLSig enveloping signature as follows. Multiple occurrences of this optional input can be present in a single message. Each occurrence will cause the inclusion of an object inside the signature being created.

The attributes of are:

WhichDocument [Required]

Identifies the input document which will be inserted into the returned signature (see the ID attribute in section 2.4.1).

hasObjectTagsAndAttributesSet

If True indicates that the contains a element which has been prepared ready for direct inclusion in the .

ObjId [optional]

Sets the Id attribute on the returned .

createReference

This attribute set to false inhibits the creation, carried by the Basic Processing specified in section 3.3.1, of the associated to the RefURI attribute of the input document referred by the WhichDocument attribute, effectively allowing clients to include elements not covered/protected by the signature being created.









type="xs:boolean" default="false"/>

use="optional"/>

use="optional" default="true"/>




3.5.6.1XML Signatures Variant Optional Input


An enveloping signature is a signature having s which are referenced by s having a same-document URI.

For each the server creates a new element containing the document, as identified using the WhichDocument attribute, as its child. This object is carried within the enveloping signature. The ordering of the optional inputs MAY be ignored by the server.

This MUST include a “same-document” RefURI attribute (having a value starting with “#”) which references either:


  • The whole newly-created .

  • The relevant parts of the newly-created ’s contents to be covered/protected by the signature (only applicable when the element contains either , or )

If the result of evaluating the expression included in the RefURI attribute doesn’t fit in any of the options described above, the server MUST reject the request using a RequesterError which MAY be qualified by a urn:oasis:names:tc:dss:1.0:resultminor:InvalidRefURI

Note :If the server does not support the ordering of , it is recommended either to use ID-based referencing to the (using the client-generated ID included in the ObjId attribute) or to rely on expressions based on 's contents that allow to unambigously refer to the included object or their relevant parts.



The URI in the RefURI attribute of this should at least reference the relevant parts of the Object to be included in the calculation for the corresponding reference. Clients MUST generate requests in a way that some ’s URI values actually will reference the generated by the server once this element will have been included in the produced by the server.

  1. For each the server MUST carry out the following steps before performing Basic Processing (as specified in section 3.3.1):

    1. The server identifies the that is to be placed into a as indicated by the WhichDocument attribute.

    2. The data to be carried in the enveloping signature is extracted and decoded 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).

    3. if the hasObjectTagsAndAttributesSet attribute is false or not present the server builds the as follows:

      1. The server generates the new and sets its Id attribute to the value indicated in ObjId attribute of the optional input if present.

      2. In the case of the Document pointed at by WhichDocument having Base64Data, ('s) MIME Type is to be set to the value of ('s) MIME Type value and the Encoding is to be set to http://www.w3.org/TR/xmlschema-2/#base64Binary

    4. The server splices the to-be-enveloped documents as (s) into the , which is to be returned.

    5. If CreateReference is set to true generate a ds:Reference element referencing the spliced and exclude this from the set of s ready for further processing. Otherwise just exclude this from the set of s ready for further processing.

  2. The server then continues with processing as specified in section 3.3.1 for the rest of the documents.

3.5.7Optional Input


In the case of the optional input (that stands for include enveloped or encapsulated content) section 3.4 step 3 is overridden as follows.

  1. The server creates a CMS signature (i.e. a SignedData structure) containing the SignerInfo that was created in Step 3. The resulting SignedData is now internal, as the document is enveloped in the signature.

For CMS details in this context please refer to [RFC 3852] sections 5.1 “SignedData Type” and 5.2 “EncapsulatedContentInfo Type”.

3.5.8Enveloped Signatures, Optional Input and Output


Optional input is used to request the creation of an XMLSig enveloped signature placed within an input document. The resulting document with the enveloped signature is placed in the optional output .

The server places the signature in the document identified using the WhichDocument attribute.

In the case of a non-XML input document then the server will return an error unless alternative procedures are defined by a profile or in the server policy for handling such a situation.

The element contains the following attributes and elements:

WhichDocument [Required]

Identifies the input document which the signature will be inserted into (see the ID attribute in section 2.4.1).

CreateEnvelopedSignature

If this is set to true a reference having an enveloped signature transform is created.



[Optional]

Identifies an element, inside the XML input document, after which the signature will be inserted. (The rules for XPath evaluation are those stated in section 2.5 SignatureObject)



[Optional]

Identifies an element, in the XML input document, which the signature will be inserted as the first child of. For details on the evaluation of The XPath expression see above (). The signature is placed immediately after the start tag of the specified element.











type="xs:string"/>





type="xs:boolean" default="true"/>



The optional output contains the input document with the signature inserted. It has one child element:



[Required]

This contains the input document with a signature inserted in some fashion.















For an XMLSig enveloped signature the client produces a request including elements set as follows:



  1. The WhichDocument attribute is set to identify the to envelope the signature.

  2. The RefURI attribute MUST be set to include a “same-document” URI which references either:
    - The whole containing the signature (by using a RefURI=””)
    - The relevant parts of the to be covered/protected by the signature (by using a “same-document” RefURI attribute having a value starting with “#”, like RefURI=”#some-id”, RefURI=”#xpointer(/)”, RefURI=”#xpointer(/DocumentElement/ToBeSignedElement)” or the like).
    If the result of evaluating the expression included in the RefURI attribute doesn’t fit in any of the options described above, the server MUST reject the request using a RequesterError which MAY be qualified by a urn:oasis:names:tc:dss:1.0:resultminor:InvalidRefURI.

  3. The createEnvelopedSignature is set to true (or simply omitted).

If the element is present the server processes it as follows before performing Basic Processing (as specified in section 3.3.1):

  1. The server identifies the in which the signature is to be enveloped as indicated by the WhichDocument attribute.

  2. This document is extracted and decoded 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).

  3. The server splices the to-be-enveloped into the document.

  4. If createEnvelopedSignature equals true,
    a. Perform Basic Processing for the enveloping , as described in section 3.3.1 with the following amendments:



    1. Omitted

    2. As in 3.3.1 1.b, with the additional requirement of adding an EnvelopedSignatureTransform as the first transform in the list (even preceding transforms used for extraction).
      Note: This is necessary because the EnvelopedSignatureTransform would not work if there was a Canonicalization before it. Similar problems apply to transforms using the here() function. If such are to be supported, the use of Base64XML or EscapedXML MAY be required.

    3. Unchanged

    4. Unchanged

      1. Unchanged

      2. Unchanged

      3. Unchanged

      4. Unchanged

      5. Unchanged (Note: the requirement imposed in 1.b of having the EnvelopedSignatureTransform as the first transform in the list MUST be observed).

  1. Omitted

  2. Omitted

    b. After creating the due to the modified Basic Processing, make it available for the Basic Processing, as required in 3.3.1 Step 2.

  1. Add the returned as required in 3.3.1 Step 2 of Basic processing.

3.5.9Optional Input


The element gives the client greater control over how the elements are formed. When this element is present, step 1 of Basic Processing (section 3.3.1) is overridden. Instead of there being a one-to-one correspondence between input documents and elements, now each element controls the creation of a corresponding .

Since each refers to an input document, this allows multiple elements to be based on a single input document. Furthermore, the client can request additional transforms to be applied to each , and can set each element’s Id or URI attribute. These aspects of the can only be set through the optional input; they cannot be set through the input documents, since they are aspects of the reference to the input document, not the input document itself.

Each element contains:

WhichDocument [Required]

Which input document this reference refers to (see the ID attribute in section 2.4.1).

RefId [Optional]

Sets the Id attribute of the corresponding .

RefURI [Optional]

If this attribute is present, the corresponding element’s URI attribute is set to its value. If it is not present, the URI attribute is omitted in the corresponding

RefType [Optional]

overrides the RefType of

[Optional]

Requests the server to perform additional transforms on this reference.



    When the optional input is present, basic processing 3.3.1 step 1 is performed for each overriding steps a., b., c. and d.:

If the element is present the server processes it as follows:

    For each in

  1. The server identifies the referenced as indicated by the WhichDocument attribute.

  2. If RefURI is present create an additional for the document in question by performing basic processing as in section 3.3.1 Step 1 amended as follows:



    1. Unchanged.

    2. Applies the transforms indicated in . Afterwards, the server may apply any other transform it considers appropriate as per its policy and then generates a canonicalized octet string as required in step b. of basic Processing before hashing.

    3. Unchanged.

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

      1. Use this RefURI attribute from the if present instead of RefURI from in step i. of Basic Processing.
        The Id attribute is set to the element’s RefId attribute. If the has no RefId attribute, the element’s Id attribute is omitted.

      2. Unchanged.

      3. Unchanged.

      4. Unchanged.

      5. The used here will have to be added to of step v. of basic processing so that this element describes the sequence of transforms applied by the server and describing the effective transform as a reproducible procedure from parsing until hash.

  1. Add the returned as required in 3.3.1 Step 2 of Basic processing.

  2. If RefURI is not present perform basic processing for the input document not creating an additional amending Step 1 as follows:



    1. Unchanged.

    2. Applies the transforms indicated in . Afterwards, the server may apply any other transform it considers as appropriate as per its policy and then generates generating a canonicalized octet string as required in step b. of basic Processing before hashing.

    3. Unchanged.

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

      1. Perform step i. of Basic Processing and the Id attribute is set to the element’s RefId attribute. If the has no RefId attribute, the element’s Id attribute is omitted.

      2. Unchanged

      3. Unchanged

      4. Unchanged

      5. The used here will have to be added to of step v. of basic processing so that this element describes the sequence of transforms applied by the server and describing the effective transform as a reproducible procedure from parsing until hash.

  1. The server continues with processing as specified in section 3.3.1 for the rest of the documents.







maxOccurs=”unbounded”/>



























1   2   3   4   5   6   7   8   9   10   11


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

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