Digital Signatures

M6.1

The package implementer shall include only one Digital Signature Origin part in a package and it shall be targeted from the package root using the well-defined relationship type specified in Annex F, “Standard Namespaces and Content Types”.

12.2.1

×

M6.2

When creating the first Digital Signature XML Signature part, the package implementer shall create the Digital Signature Origin part, if it does not exist, in order to specify a relationship to that Digital Signature XML Signature part.

12.2.1

×

M6.3

The producer shall create Digital Signature XML Signature parts that have a relationship from the Digital Signature Origin part and the consumer shall use that relationship to locate signature information within the package.

12.2.1

×

M6.4

If the certificate is represented as a separate part within the package, the producer shall target that certificate from the appropriate Digital Signature XML Signature part by a Digital Signature Certificate relationship as specified in Annex F, “Standard Namespaces and Content Types” and the consumer shall use that relationship to locate the certificate.

12.2.3

×

M6.5

The producer shall create Reference elements within a SignedInfo element that reference elements within the same Signature element. The consumer shall consider Reference elements within a SignedInfo element that reference any resources outside the same Signature element to be in error.

12.2.4.1

×

M6.6

The producer shall not create a reference to a package‑‑

12.2.4.1

×

M6.7

The producer shall create one and only one package-specific Object element in the Signature element. The consumer shall consider zero or more than one package-specific Object element in the Signature element to be an error.

12.2.4.1

×

M6.8

The producer shall create package-specific Object elements that contain exactly one Manifest element and exactly one SignatureProperties element. [Note: This SignatureProperties element can contain multiple SignatureProperty elements. end note] The consumer shall consider package-specific Object elements that contain other types of elements to be an error.

12.2.4.1

×

M6.9

The producer shall create Reference elements within a Manifest element that reference with their URI attribute only parts within the package. The consumer shall consider Reference elements within a Manifest element that reference resources outside the package to be an error.

12.2.4.1

×

M6.10

The producer shall create relative references to the local parts that have query components that specifies the part content type as described in §12.2.4.6. The relative reference excluding the query component shall conform to the part name grammar. The consumer shall consider a relative reference to a local part that has a query component that incorrectly specifies the part content type to be an error.

12.2.4.1

×

M6.11

The producer shall create Reference elements with a query component that specifies the content type that matches the content type of the referenced part. The consumer shall consider signature validation to fail if the part content type compared in a case-sensitive manner to the content type specified in the query component of the part reference does not match.

12.2.4.1

×

M6.12

The producer shall not create Reference elements within a Manifest element that contain transforms other than the canonicalization transform and relationships transform. The consumer shall consider Reference elements within a Manifest element that contain transforms other than the canonicalization transform and relationships transform to be in error.

12.2.4.1

×

M6.13

A producer that uses an optional relationships transform shall follow it by a canonicalization transform. The consumer shall consider any relationships transform that is not followed by a canonicalization transform to be an error.

12.2.4.1

×

M6.14

The producer shall create exactly one SignatureProperty element with the Id attribute value set to idSignatureTime. The Target attribute value of this element shall be either empty or contain a fragment reference to the value of the Id attribute of the root Signature element. A SignatureProperty element shall contain exactly one SignatureTime child element. The consumer shall consider a SignatureProperty element that does not contain a SignatureTime element or whose Target attribute value is not empty or does not contain a fragment reference the Id attribute of the ancestor Signature element to be in error.

12.2.4.1

×

M6.15

The producer shall create a <Signature> element that contains exactly one local-data, <package-specific> Object element and zero or more <application‑specific> Object elements. If <a> Signature element violates this constraint, a consumer shall consider this to be an error.

12.2.4.2

×

M6.16

The producer shall create a <SignedInfo> element that contains exactly one reference to the <package-specific> Object element. The consumer shall consider it an error if <a> SignedInfo element does not contain a reference to the <package-specific> Object element.

12.2.4.3

×

M6.17

Producers shall support DSA and RSA algorithms to produce signatures. Consumers shall support DSA and RSA algorithms to validate signatures.

12.2.4.5

×

M6.18

The producer shall create a <Reference >element within a <Manifest> element with a @URI attribute and that attribute shall contain a part name, without a fragment identifier. The consumer shall consider a <Reference> element with a @URI attribute that does not contain a part name to be an error.

12.2.4.6

×

M6.19

The following transforms shall be supported by producers and consumers of packages with digital signatures:

• XML Canonicalization (c14n)

• XML Canonicalization with Comments (c14n with comments)

• Relationships transform (package-specific)

Consumers validating signed packages shall fail the validation if other transforms are encountered. Relationships transforms shall only be supported by producers and consumers when the <Transform> element is a descendant element of a <Manifest> element

12.2.4.7

×

M6.20

Producers shall create application-specific Object elements that contain XML-compliant data; consumers shall treat data that is not XML-compliant as an error.

12.2.4.14

×

M6.21

Producers and consumers shall use the certificate embedded in the Digital Signature XML Signature part when it is specified.

12.2.4.15

×

M6.22

The producer shall not create a <Manifest >element that references any data outside of the package. The consumer shall consider a <Manifest >element that references data outside of the package to be in error.

12.2.4.18

×

M6.23

The producer shall create a data/time format that conforms to the syntax described in the W3C Note "Date and Time Formats". The consumer shall consider a format that does not conform to the syntax described in that WC3 note to be in error.

12.2.4.22

×

M6.24

The producer shall create a value that conforms to the format specified in the Format element. The consumer shall consider a value that does not conform to that format to be in error.

12.2.4.23

×

M6.25

To sign a subset of relationships, the producer shall use the package-specific relationships transform. The consumer shall use the package-specific relationships transform to validate the signature when a subset of relationships are signed.

12.2.4.25

×

M6.26

Producers shall specify a canonicalization transform immediately following a relationships transform and consumers that encounter a relationships transform that is not immediately followed by a canonicalization transform shall generate an error.

12.2.4.25

×

M6.27

When applying a relationships transform for digital signatures, the package implementer shall remove all Relationship elements that do not have eitheran Id value that matches any SourceId valueor a Type value that matches any SourceType value, among the SourceId and SourceType values specified in the transform definition. Producers and consumers shall compare values as case-sensitive Unicode strings.

12.2.4.26

×

M6.28

When signing Object element data, package implementers shall follow the generic reference creation algorithm described in §3.1 of the W3C Recommendation “XML-Signature Syntax and Processing”.

12.4

×

M6.29

When validating digital signatures, consumers shall verify the content type and the digest contained in each Reference descendant element of the SignedInfo element, and validate the signature calculated using the SignedInfo element.

12.5

M6.30

The package implementer shall compare the generated digest value against the <DigestValue> element in the <Reference> element of the <SignedInfo> element. Package implementers shall consider references invalid if there is any mismatch.

12.5

×

M6.31

Streaming consumers that maintain signatures shall be able to cache the parts necessary for detecting and processing signatures.

12.5.1

M6.32

The package implementer shall not use the Markup Compatibility namespace, as specified in Annex F, “Standard Namespaces and Content Types,” within the package-specific Object element. The package implementer shall consider the use of the Markup Compatibility namespace within the package-specific Object element to be an error.

12.6.2

×

M6.33

If an application allows for a single part to contain information that might not be fully understood by all implementations, then the format designer shall carefully design the signing and verification policies to account for the possibility of different implementations being used for each action in the sequence of content creation, content signing, and signature verification. Producers and consumers shall account for this possibility in their signing and verification processing.

12.6.2

×

×

M6.34

The following canonicalization methods shall be supported by producers and consumers of packages with digital signatures:

XML Canonicalization (c14n)

XML Canonicalization with Comments (c14n with comments)

Consumers validating signed packages shall fail the validation if other canonicalization methods are encountered.

12.2.4.4

×

S6.1

The producer should not create any content in the Digital Signature Origin part itself.

12.2.1

×

S6.2

Producers generating digital signatures should not create Digital Signature Certificate parts that are not the target of at least one Digital Signature Certificate relationship from a Digital Signature XML Signature part. In addition, producers should remove a Digital Signature Certificate part if removing the last Digital Signature XML Signature part that has a Digital Signature Certificate relationship to it.

12.2.3

×

S6.3

For digital signatures, a producer should apply a canonicalization transform to the <SignedInfo element> when it generates it, and a consumer should apply the canonicalization transform to the SignedInfo <element when >validating it.

12.2.4.4

×

S6.4

Producers and consumers should also use canonicalization transforms for references to parts that hold XML documents.

12.2.4.4

×

O6.1

Format designers might allow a package to include digital signatures to enable consumers to validate the integrity of the contents. The producer might include the digital signature when allowed by the format designer.

12

×

×

O6.2

If there are no Digital Signature XML Signature parts in the package, the Digital Signature Origin part is optional.

12.2.1

×

O6.4

The producer might create zero or more Digital Signature XML Signature parts in a package.

12.2.2

×

O6.5

Alternatively, the producer might store the certificate as a separate part in the package, might embed it within the Digital Signature XML Signature part itself, or might not include it in the package if certificate data is known or can be obtained from a local or remote certificate store.

12.2.3

×

O6.6

The producer might sign the part holding the certificate.

12.2.3

×

O6.7

Producers might share Digital Signature Certificate parts by using the same certificate to create more than one signature.

12.2.3

×

O6.8

The format designer might permit one or more application-specific Object elements. If allowed by the format designer, format producers can create one or more application-specific Object elements.

12.2.4.14

×

×

O6.9

Format designers and producers might not apply package-specific restrictions regarding URIs and Transform elements to application-specific Object element.

12.2.4.14

×

×

O6.10

Format designers might permit producers to sign individual relationships in a package or the Relationships part as a whole.

12.2.4.25

×

×

O6.11

The package implementer might create relationships XML that contains content from several namespaces, along with versioning instructions as defined in Part 5: “Markup Compatibility and Extensibility”.

12.2.4.26

×