3.0 Processing Rules

The sections below describe the operations to be performed as part of signature generation and validation.

3.1 Core Generation

The REQUIRED steps include the generation of Reference elements and the SignatureValue over SignedInfo.

3.1.1 Reference Generation

For each data object being signed:

1. Apply the Transforms, as determined by the application, to the data object.
2. Calculate the digest value over the resulting data object.
3. Create a Reference element, including the (optional) identification of the data object, any (optional) transform elements, the digest algorithm and the DigestValue. (Note, it is the canonical form of these references that are signed in 3.1.2 and validated in 3.2.1 .)

3.1.2 Signature Generation

1. Create SignedInfo element with SignatureMethod, CanonicalizationMethod and Reference(s).
2. Canonicalize and then calculate the SignatureValue over SignedInfo based on algorithms specified in SignedInfo.
3. Construct the Signature element that includes SignedInfo, Object(s) (if desired, encoding may be different than that used for signing), KeyInfo (if required), and SignatureValue.

3.2 Core Validation

The REQUIRED steps of core validation include (1) reference validation, the verification of the digest contained in each Reference in SignedInfo, and (2) the cryptographic signature validation of the signature calculated over SignedInfo.

Note, there may be valid signatures that some signature applications are unable to validate. Reasons for this include failure to implement optional parts of this specification, inability or unwillingness to execute specified algorithms, or inability or unwillingness to dereference specified URIs (some URI schemes may cause undesirable side effects), etc.

3.2.1 Reference Validation

1. Canonicalize the SignedInfo element based on the CanonicalizationMethod in SignedInfo.

   For each Reference in SignedInfo:

2. Obtain the data object to be digested. (For example, the signature application may dereference the URI and execute Transforms provided by the signer in the Reference element, or it may obtain the content through other means such as a local cache.)
3. Digest the resulting data object using the DigestMethod specified in its Reference specification.
4. Compare the generated digest value against DigestValue in the SignedInfo Reference; if there is any mismatch, validation fails. Note: validation must be by numeric or decoded octet sequence comparison. Encoded base 64 strings may have accidental white space or other differences.

Note, SignedInfo is canonicalized in step 1. The application must ensure that the CanonicalizationMethod has no dangerous side affects, such as rewriting URIs, (see CanonicalizationMethod (section 4.3)) and that it Sees What is Signed, which is the canonical form.

3.2.2 Signature Validation

1. Obtain the keying information from KeyInfo or from an external source.
2. Obtain the canonical form of the SignatureMethod using  the CanonicalizationMethod and use the result (and previously obtained KeyInfo) to validate the SignatureValue over the SignedInfo element. Note: validation must be by numeric or decoded octet sequence comparison. Encoded base 64 strings may have accidental white space or other differences.

Note the following:

• KeyInfo (or some transformed version thereof) may be signed via a Reference element. Transformation and validation of this reference (3.2.1) is orthogonal to Signature Validation which uses the KeyInfo as parsed.
• The SignatureMethod URI may have been altered by the canonicalization of SignedInfo (e.g., absolutization of relative URIs) and it is the canonical form that MUST be used. However, the required canonicalization [XML-C14N] of this specification does not change URIs.
• Different implementations may produce different SignatureValue elements even when signing the same data with the same key and signature algorithm. That is because they may encode the relevant DigestValue in the Reference to the data with different white space or the like.