XML Digital Signature Implementation Guide

Transcription

1 XML Digital Signature Implementation Guide Document Status FINAL Document Date February 11, 2014 Editors Contributors Abdias Lira, Wolters Kluwer Financial Services Mark Kleingers, elynx Leendert Bijnagte, Wells Fargo Bank Mike Holmes, MGIC Matthew Hailstone, Simplifile John Liston, ASC - listonj@asconline.com Chris Ulbright, Document Systems - chris@docmagic.com Jim Blust, Veros - JBlust@veros.com COPYRIGHT 2014 MORTGAGE INDUSTRY STANDARDS MAINTENANCE ORGANIZATION (MISMO) ALL RIGHTS RESERVED. THIS MISMO STANDARD INCLUDES THE END USER LICENSE AGREEMENT ATTACHED HERETO AT AND IS GOVERNED BY AND SUBJECT TO THE END USER LICENSE AGREEMENT. NO USER OF THIS STANDARD MAY REMOVE THIS REFERENCE TO AND STATEMENT REGARDING THE END USER LICENSE. ANY HARD COPY PUBLICATION OF THIS STANDARD MUST INCLUDE AND ATTACH A HARD COPY PRINT OUT OFTHE END USER LICENSE. ANY FURTHER ELECTRONIC DISTRIBUTION OF THIS STANDARD MUST INCLUDE A SPECIFIC REFERENCED LINK TO THE END USER LICENSE AGREEMENT OR OTHER MEANS OF ATTACHMENT OF THE END USER LICENSE AGREEMENT. DISCLAIMER: THIS MISMO STANDARD IS PROVIDED "AS IS." MISMO, THE MORTGAGE BANKERS ASSOCIATION OF AMERICA ("MBA"), THE COPYRIGHT HOLDER, THE AUTHORS OF THIS MISMO STANDARD AND ANY STANDARD- SETTING BODY PARTICIPANTS TO THIS MISMO STANDARD MAKE NO REPRESENTATIONS OR WARRANTIES (I) EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE OR NON-INFRINGEMENT; (II) THAT THE CONTENTS OF SUCH MISMO STANDARD ARE FREE FROM ERROR OR SUITABLE FOR ANY PURPOSE; NOR THAT IMPLEMENTATION OF SUCH CONTENTS WILL NOT INFRINGE ANY THIRD-PARTY PATENTS, COPYRIGHTS, TRADEMARKS OR OTHER RIGHTS. IN NO EVENT WILL MISMO, MBA, THE COPYRIGHT HOLDER OR THE STANDARD-SETTING BODY PARTICIPANTS TO THIS MISMO STANDARD BE LIABLE TO ANY PARTY FOR ANY DIRECT, INDIRECT, SPECIAL OR CONSEQUENTIAL DAMAGES FOR ANY USE OF THIS MISMO STANDARD, INCLUDING, WITHOUT LIMITATION, ANY LOST PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR OTHER DATA ON YOUR INFORMATION HANDLING SYSTEM OR OTHERWISE, EVEN IF MISMO, MBA, THE COPYRIGHT HOLDER AND/OR ANY AUTHORS AND/OR ANY STANDARD- SETTING BODY PARTICIPANTS TO THIS MISMO STANDARD ARE EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

2 1. Introduction 1.1. Abstract The XML Signature Syntax and Processing specification [XML-DSIG] is an XML syntax and processing model for digital signatures defined by the World Wide Web Consortium (W3C). XML digital signatures can be applied to any digital content, including text and XML. An XML signature MAY be applied to the content of one or more resources. An XML digital signature is commonly used to create a tamper-evident seal around an entire electronic resource, which invalidates any changes to any part of that resource after the XML digital signature has been applied. This approach is useful when the signed resource is not supposed to be changed in subsequent steps of its lifecycle. In addition to that, the XML Signature Syntax and Processing specification also allows for using XPath filtering [XML-DSIG] to selectively sign any portion of a resource, while leaving other portions unsigned and open for changes. This approach is useful for a collaborative document that is incrementally modified by multiple participants during its lifecycle, before becoming a final, immutable record. Selective signing allows each participant in the process to verify that there have been no changes to the document prohibited by tamper-evident seals applied by previous participants; a participant can then perform and seal the changes that are pertinent to their function in the process and forward the document for further processing by other participants. The MISMO V3 reference model enables the use of XML digital signatures for creating tamper-evident electronic seals around the MESSAGE and the DOCUMENT elements. It also enables tamper-evident seals to be used in conjunction with stakeholder, witness, and notary signatures represented in the SIGNATORY element of a DOCUMENT. Although the XML Signature Syntax and Processing specification is a mature and widely-adopted technology, many considerations need to be taken into account when creating signatures that need to be interoperable between multiple participants using different systems and platforms. This document provides the guidelines and requirements for creators and consumers of signed MISMO MESSAGES and DOCUMENTS to allow interoperability in the context of complex mortgage business workflows Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC- 2119]. Note on typographic conventions for standalone terms: REFERENCE (upper case) refers to the REFERENCE container element in the MISMO namespace, dsig:reference (mixed case), refers to the Reference element in the XML dsig namespace, and reference (lower case) refers to the occurrence of a REFERENCE or ObjectURL element in the MISMO namespace in an instance document Definitions 1. Full Signature: A Full Signature signs the entire resource it points to. 2. Selective Signature: the XML Digital Signature specification also allows using XPath Filtering [XML- DSIG] to selectively sign any portion of an XML resource, while leaving other portions open for changes.

3 2. Conformance Requirements 2.1. MISMO Conformance Requirements This I-Guide applies to XML instance documents that use the MISMO Reference Model Version 3.0 or above. However, some usages specified in section 7 of this guide require Version 3.2 or above W3C Conformance Requirements XML Digital signatures used in conjunction with signed MISMO MESSAGES and DOCUMENTS MUST conform to the W3C [XML-DSIG] Recommendation dated 10 June In addition to that, implementers SHOULD follow W3C XML Signature Best Practices [DSIG-PRACTICES]. 3. URI References Requirements XML digital signatures used in conjunction with signed MISMO DOCUMENTS SHOULD use relative URI values for the dsig:reference/@uri attribute to allow for portability of the signed resources. Readers MUST support both relative and absolute URI values. 4. General Requirements for Full Signatures A Full dsig:reference signs the entire resource it points to and SHOULD be used for resources whose content will remain the same during the entire life cycle of the MESSAGE or DOCUMENT. Examples of those types of resources would include a message in transit, or immutable external files like mapping style sheets, CSS, and locked views. For more information on signing external resources, please refer to Section 7 below. To define a Full dsig:reference, use the dsig:reference element without a XPATH dsig:transform. If you are signing the instance document that contains the signature, the dsig:reference/@uri attribute MUST be an empty string and you MUST use the Enveloped Signature Transform Algorithm [XML-DSIG]. Otherwise, if the dsig:reference refers to a resource external to the xml instance document containing the signature, then dsig:reference/@uri attribute MUST contain the address of the external resource. Readers MUST support both relative and absolute URI values. 5. General Requirements for Selective Signatures If MESSAGE or DOCUMENT contains resources that will remain the same during its entire life cycle, but also contains other portions that can be modified or added, that MESSAGE or DOCUMENT SHOULD be signed using a combination of one complement dsig:reference and zero or more union dsig:references. Examples would include a DOCUMENT where certain portions of the data are fixed, but others can be completed by other participants in downstream workflow steps. To define complement and union dsig:references, use the dsig:reference element with an XPATH Filtering Transform Algorithm [XML-DSIG]. The figure below gives an overview of the three dsig:reference schemes:

4 5.1. XPath Filtering Transform Processing Model The XPath filtering transform is a mechanism that allows for signing specific nodes of an XML instance document while leaving others unsigned. The nodes to be signed are specified by an XPath expression. The XPath syntax and evaluation is the same as what is defined for general XPath usage [XPath]. However, instead of being executed only once against the root element of the target document, the XPath expression in the transform is executed against each individual node. More specifically, the output of the XPath transform is equivalent to the one that would be created by the following process: 1. Set context node equal to the input XML document's root node, and set the context position and size to Evaluate the XPath expression (//. //@* //namespace::*). The result is a node-set containing every node in the XML document. 3. For each node in the above node-set, evaluate the given XPath expression. If the expression is true, include the node in the result set. Otherwise, do nothing Complement dsig:references A complement dsig:reference signs the entire resource, except certain sections. In other words, the XPath filtering excludes specific portions of the resource, while including everything else. For example, the XPath filtering below excludes all PARTY, SIGNATURE, and VIEW elements, while including all other elements in the referenced resource: not(ancestor-or-self::mismo:party) and not(ancestor-or-self::mismo:signatory) and not(ancestor-or-self::mismo:document/views/view) To allow automated processes to easily discover which portions of a document are not being signed by a complement signature, the XPath filtering expression MUST conform to the following syntax: complement_filter := negation ('and' negation)* negation := 'not(ancestor-or-self:: ' element_selector ')'

5 element_selector := element_qname ('/' element_qname)* Where element_qname is the qualified name of an element defined in the MISMO namespace or in a custom namespace used according to the MISMO V3 Reference Model Extension Rules [MISMO-MEG 25] Union dsig:references A union dsig:reference only signs specific sections of a resource, leaving everything else unsigned. For example, the XPath filtering below includes only the PARTY labeled PARTY_1, the VIEW element labeled VIEW_1, and the RELATIONSHIP element where the SequenceNumber attribute has a value of 2, while excluding everything else. boolean(ancestor-or-self::mismo:party[@xlink:label= PARTY_1 ]) or boolean(ancestor-or-self::mismo:view[@xlink:label= VIEW_1 ]) or boolean(ancestor-or-self::mismo:relationship[string(@sequencenumber) = 2 ]) To allow automated processes to easily discover which portions of a document are being signed by a complement signature, the XPath filtering expression MUST conform to the following syntax: Where: union_filter := item ('or' item)* item := boolean(ancestor-or-self:: element_selector ')' element_selector := element_qname ('/' element_qname)* predicate predicate := label_predicate sequence_predicate label_predicate := '[@xlink:label=' string ']' sequence_predicate := '[string(@sequencenumber=)' string ']' element_qname is the qualified name of an element defined in the MISMO namespace or in a custom namespace used according to the MISMO V3 Reference Model Extension Rules [MISMO-MEG 25]. sequence_predicate can only be used for RELATIONSHIP elements 5.4. Allowing Elements to be Referenced in Future Signatures Every element that MAY be referenced by a union signature MUST have an xlink:label attribute with a value that is unique within the scope of its siblings. This includes elements that an implementer is currently signing in its step of the workflow as well as elements expected to be signed by others in downstream processes. The exception to this rule is the RELATIONSHIP elements, which are commonly signed, but do not allow for the xlink:label attribute. To work around that, every RELATIONSHIP element MUST have a SequenceNumber attribute with a value that is unique within the scope of its siblings Allowing Signed Elements to Participate in Future Relationships Any XML element that is covered by a signature and is listed as an endpoint in the MISMO Standard Relationship Definitions [MISMO-LDD] SHOULD have an xlink:label attribute with a value that is unique

6 within the scope of its siblings. In addition, a participant MAY require that their upstream partners add labels to elements that MAY be included in custom relationships defined by that participant Selective Signing of Foreign Objects or Partially Signing Views Selective signing of exposed XML content inside of FOREIGN OBJECTS can be done following the rules stated in this I-Guide. Selective signing of binary foreign Objects will be covered by other implementation guides for V3 SMART Doc Specification. 6. Canonicalization and Whitespace Handling Requirements 6.1. Canonicalization Overview Given the flexibility of the XML specification, it is possible to construct two different XML statements that are physically different, but logically identical. Consider the examples below: (a) <element0 type= x7 _ref= 6 > <element0a>some text</element0a> </element0> (b) <element0 _ref= 6 type = x7 > </element0> <element0a>some text</element0a> If either (a) or (b) were run through a data mapping transformation, or read into an object tree inside a program, the results would be logically identical. However, because of whitespace differences, attribute order differences, and use of double vs. single quotes around attribute values, the byte streams are not physically identical. Canonicalization is the act of normalizing an XML byte stream to eliminate certain physical differences between two logically equivalent XML streams. See [XML-EXC-C14N] for the current recommendation for XML canonicalization defined by the W3C consortium.. During the XML DSIG process, the signing software computes a one-way hash of the characters in the byte stream being signed. Hashing examples (a) and (b), although they are logically identical, would produce two different hash values. Since comparing the hash of two different copies of a signed XML document section is central to how one ensures that the signed content was not tampered with, it is vital that the physical representation of the signed XML sections doesn t change as the XML document progresses through its life cycle. Unfortunately, since different sections of a MISMO DOCUMENT are signed at different times, by different software, it is possible that at some point during the process a previously signed section MAY get slightly reformatted, breaking the signature hash. To avoid this situation, W3C XML DSIG provides for performing canonicalization on an XML byte stream before computing the hash value. However, canonicalization does not resolve all byte stream issues. For instance, canonicalization will not fully undo pretty printing when applied to an XML stream. The following requirements are intended to

7 make the resulting digital signatures compatible with the widest range of systems and to ensure that digital signatures are not broken by casual document handling. If additional requirements are discovered, participants are encouraged to contact the MISMO emortgage workgroup so that we can address the issue in a standard fashion in a future release of this document Encoding MISMO XML document files SHOULD use UTF-8 character encoding. Canonicalization converts the input to UTF-8 encoding; making the document UTF-8 natively will avoid problems with non-standard character mapping Writing Whitespaces The use of whitespace between element tags is discouraged as the rules for managing such whitespace can be difficult to implement in some environments. XML Canonicalization only provides for normalization of line endings and not of all whitespace; many XSL processors routinely remove whitespace-only text nodes which makes it impossible to preserve the whitespace between consecutive tags. XML Canonicalization will normalize whitespace between elements down to a single space character and preserve carriage return characters between elements. If a system 1) adds or removes carriage returns between elements, or 2) inserts or removes all whitespace between elements, canonicalization will NOT resolve it back to its original canonical form and will invalidate any digital signatures over those elements. For this reason, MISMO XML document content writers MUST NOT insert whitespace or carriage return/linefeed characters between elements (see exception below). Although pretty-print and other formatting tools makes XML document more readable to humans, this formatting SHOULD NOT be applied when readying the document for processing. The content of a FOREIGN_OBJECT is the exception to this requirement. If necessary, FOREIGN_OBJECT content that is XML formatted MAY contain whitespace in mixed content elements that is important to the document rendering or content. However, such white space MAY be used in embedded mixed content only when required in its namespace Preserving Existing Whitespaces MISMO XML document content readers and signature engines MUST NOT modify whitespace in existing documents. XML contained in a FOREIGN_OBJECT element in the MISMO namespace presents a special case. Since the content of FOREIGN_OBJECT is not within the MISMO namespace, it MAY contain spacing or carriage returns between elements, usually in mixed content elements, that is important to the formatting or content of the document. Therefore, MISMO XML document readers and signature engines MUST preserve this content inside the FOREIGN_OBJECT. To simplify implementation, and as general good practice, this requirement has been expanded to the entire document: MISMO XML document content readers and signature engines MUST NOT modify whitespace in existing documents that have digital signatures Namespace Prefixes Namespace prefixes are included in the signature hash, but can potentially be modified by some XML processors. 1. Writers SHOULD NOT include namespace declarations that are not necessary to the document. 2. Each namespace used in the entire instance document MUST have just one namespace prefix associated with it. 3. Writers MUST NOT modify existing namespace prefixes while signing MISMO XML document content.

8 6.6. Schema-Aware Canonicalization XML tools may produce a different canonicalized result depending on whether or not the tool has access to the corresponding XML schema at the time of the canonicalization. Specifically, this occurs when a schema defines default or fixed values for elements or attributes. 1. The initial writer SHOULD generate and use a schema-aware canonicalized version of the document before applying the first signature to the document. If that is not possible, the initial writer MUST explicitly expand all default values specified in the schema and make those part of the XML instance document before applying any signatures. 2. Subsequent writers SHOULD explicitly expand all default values specified in the schema for any elements and attributes they add to the document. 3. Readers SHOULD avoid schema-aware canonicalization; 6.7. Exclusive XML Canonicalization MISMO XML document signature writers SHOULD use the Exclusive XML Canonicalization method during signing. This avoids potential problems with signed content that was imported from another document. See [XML-EXC-C14N] for details Avoid Other XML DSIG Transforms The XML DSIG standard specifies an option for including transforms that are applied to the byte stream before hashing. Readers and writers MUST support at least the following transforms: 1. XPath Transform. This transform is used for selective signing (see section 5 above) 2. XmlDSIGDecrypt. If the content being signed MAY be encrypted after the XmlSignature is applied, then you SHOULD use XmlDSIGDecrypt transform [DSIG-DECRYPT] to preserve the validity of your signatures. 3. Exclusive Canonicalization. See [XML-EXC-C14N] for details. 4. Enveloped Transform. See [XML-DSIG] for more details. Writers MUST NOT use any other transforms. If you need to implement additional transforms in your digital signature (other than the ones mentioned above), please notify the MISMO emortgage group so that the use case can be evaluated and a standard solution can be designed and documented for inclusion in future releases of this document. 7. Requirements for Signing REFERENCE and FOREIGN_OBJECT Content The highest levels of usability and portability are achieved when XML content is signed in a consistent manner as standalone XML without the use of references (content pointed to by a URL). This means not using any REFERENCE or any FOREIGN_OBJECT/ObjectURL elements. However, when it is necessary to use these features of the model, there are several methods to support signing so that each SYSTEM_SIGNATURE on the XML content can be validated along with the trustworthiness of the referenced content. In addition, standalone XML can be signed and then transformed to use either REFERENCEs or ObjectURLs in a manner that permits validation after resolution i.e. by first reversing the transformations. The ReferenceSigningType attribute of a REFERENCE or FOREIGN_OBJECT/ObjectURL element makes explicit the signing method to avoid resorting to heuristics for determining how references are or can be used when SYSTEM_SIGNATURES are involved. Conforming systems MUST use this attribute in the prescribed manner when creating or validating SYSTEM_SIGNATURES in documents with references.

9 7.1. The ReferenceSigningType Attribute The following is a list of the enumerated values for the ReferenceSigningType. The normative definitions are in the MISMO Logical Data Dictionary [MISMO-LDD]. 1. ReferenceSignedDirectly 2. ReferenceAndContentSignedDirectly 3. ReferenceAndContentSignedIndirectly 4. ReferenceCreatedFromSignedContent 5. NotSigned ReferenceSignedDirectly: Signing a Reference without Signing Its Content Prior to the signature process, set the ReferenceSigningType attributes for all references to be signed directly to the correct value. Ensure that each reference is covered by identifying, transforming and hashing node sets for a dsig:reference that include the references you are signing. Once it is signed, the reference MUST NOT be modified ReferenceAndContentSignedDirectly: Signing Referenced Content Directly Prior to the signature process, determine the correct setting of the ReferenceSigningType attribute for each REFERENCE and ObjectURL element; if you wish to preserve the references created from signed content, save as the document being signed. Then recursively for each ObjectURL element with the ReferenceSigningType attribute equal to ReferenceCreatedFromSignedContent resolve that reference. Create the XML document s dsig:reference element just as you normally would by identifying, transforming and hashing node sets including the references you are signing. For each REFERENCE whose content you also wish to sign, add a dsig:reference with the URI of the LocationURL, a transform using the Algorithm with an XPath selecting an element with the name of the parent of the REFERENCE and an xlink:label attribute value equal to the value of the LocationLabelValue; add other transforms (e.g. canonicalization) as needed. For each ObjectURL whose content you also wish to sign, add a dsig:reference with the URI of the ObjectURL; add dsig:transform elements (e.g. Canonicalization if the content is xml) as needed. Then compute the signature as you normally would. If you wish to preserve the original references created from signed content, the resulting signature block SHOULD be placed into a new SYSTEM_SIGNATURE container in the document saved earlier. If multiple ObjectURLs point to the same resource, a single SignedInfo/Reference covers them all. Similarly, if multiple LocationURLs point to the same resource, it is often advantageous to consolidate them to a single dsig: Reference and either combine the XPaths that refer to each LocationLabelValue or ignore them altogether if the resource will be static. This approach can be used for signatures on the content in a MISMO ZIP Archive [MISMO-ZIP]. It could also work well for a short lived signature used in messaging where there is reasonable confidence that the resource at the URL would be available in the form it was signed or any place where the components would not be modified or become unavailable during the expected life of the signature. A difficulty is that the retrieval process required by the URL MAY not be supported by the signature validation process but it has the advantage of clarity about how to get to the format that is hashed ReferenceAndContentSignedIndirectly: Signing External Content Indirectly Use a well known algorithm (preferably the same one used in the signature) to compute a hash value of the

10 content at the REFERENCE and save it as the OriginalCreatorDigestValue element (with an AlgorithmURI attribute) for each external REFERENCE element to be signed. Similarly, use a well known algorithm to compute a hash value of the content at the ObjectURL and save it as the OriginalCreatorDigestValue element (with an AlgorithmURI attribute) for each external FOREIGN_OBJECT element to be signed. Then sign the XML document just as you normally would by creating and hashing references to node sets within the document. The OriginalCreatorDigestValue element MUST be covered by the dsig:reference elements; in addition to that you MAY consider signing the entire REFERENCE or FOREIGN_OBJECT element. If multiple ObjectURLs point to the same resource, their OriginalCreatorDigestValue elements SHOULD be identical. If multiple LocationURLs point to the same resource, unless their Labels are also identical their OriginalCreatorDigestValue elements MUST be created and tested independently, although the resource could be cached. This strategy separates the validation of external content from internal content so that the signature validation processor does not need to be able to resolve the external URLs. More importantly for a signature on an XML document that uses external content to deal with size limitations, it permits validation of the value of each of the OriginalCreatorDigestValue elements to be done independently as well. A difficulty is that the retrieval process does not provide information for transforming the format before it is hashed, so the resource MUST provide the correct format of the content ReferenceCreatedFromSignedContent: Reference Creation and Resolution The following summary of REFERENCE and FOREIGN_OBJECT/ObjectURL creation and resolution is not normative. The normative definitions are in the MISMO Logical Data Dictionary. Please see Section 6 above for additional requirements on canonicalization and white space handling. Create REFERENCE: The content MUST NOT be a REFERENCE element but MAY contain REFERENCE elements. The content from the first element to the last element is copied to an element with the same name as the parent and an xlink:label attribute with the LocationLabelValue value in the resource at LocationURL with internal whitespace intact but without any leading or trailing whitespace. That content is then replaced by the REFERENCE element with the appropriate attribute and child values but without adding leading or trailing whitespace. Resolve REFERENCE: The REFERENCE element is replaced by the content i.e. node() children found at an element with the same name as the parent of the REFERENCE and an xlink:label attribute value equal to the value of the LocationLabelValue in the resource at LocationURL but without any leading or trailing whitespace. The content MUST NOT be a REFERENCE element but MAY contain REFERENCE elements. Create ObjectURL: The content MUST have an ObjectEncodingType that has a MISMO defined symmetrical implementation (Base64, EscapedXML, None); the EmbeddedContentXML MUST have been encoded using that implementation. The EmbeddedContentXML is decoded (if required) and copied without further changes to the resource location. The EmbeddedContentXML element is replaced with an ObjectURL element with the value of the resource location and the appropriate attributes, i.e. copying the attributes of the EmbeddedContentXML and adding the ReferenceSigningType. None of the siblings of EmbeddedContentXML are modified in any way. Resolve ObjectURL: The ObjectURL element is replaced by an EmbeddedContentXML element with all the attributes of the ObjectURL element except the ReferenceSigningType and with the content of the resource found at the ObjectURL location, without changes, and encoded (if required) using the MISMO defined symmetrical implementation of the ObjectEncodingType. Note that the retrieval process MAY impose its own transfer encoding, which MUST first be decoded.

11 NotSigned This enumeration MAY be used to provide greater transparency for downstream processes Requirements for ObjectEncodingType The decoding/encoding processes used on signed content MUST result in identical octet streams so the exact form of an encoding that makes decoding and re-encoding symmetrical MUST be used for transformable signed content. These are defined as follows: Base64 Base64 encoding MUST follow RFC 4648 as documented in sections 3 and 4. This prohibits both line terminators and characters outside the encoding set (including neither leading nor trailing whitespace) and requires appropriate padding at the end of the stream EscapedXML EscapedXML encoding MUST take the input as if it were the content of an XML text node and follows the rules of Canonical XML Version 1.0 in section 2.3 for producing that text node. MISMO Version 3 requires that the character encoding of the text be UTF-8. This prohibits the use of a CDATA section or of entities other than those specified in section DeflateBase64 and GzipBase64 DeflateBase64 and GzipBase64 (wrapped around Deflate encoding) are not symmetrical [see RFC 2394] and EmbeddedContentXML with those encodings in signed content MUST NOT be transformed into an ObjectURL if signatures need to be preserved. Instead, use an external REFERENCE to its parent FOREIGN_OBJECT if transformation is REQUIRED. 8. Timestamp Requirements XML digital signatures used in conjunction with signed MISMO MESSAGES and DOCUMENTS SHOULD contain a trusted timestamp conforming to the XAdES-T profile of the ETSI TS XAdES Standard V1.4.1 [XADES]. It MAY contain higher profile levels if desired. 9. Implementation Samples 9.1. Limitations The implementation samples do not validate the authenticity of the digital certificates used for signing. The sample documents use a self-signed test certificate Sample Workflow Steps The XML samples below show the system signature implementations for a hypothetical workflow with the following steps: 1. Starting with a simple MISMO document containing a two parties and a mocked-up PDF view, baseline the document by performing a schema-aware canonicalization. Sample-SDV3-1.xml

12 2. Apply selective signatures: a. Apply and verify a system signature containing a complement set dsig:reference to tamper-seal the entire document, except for the PARTY and SYSTEM_SIGNATURE elements. Sample-SDV3-2.xml b. Apply and verify a system signature containing a union set dsig:reference to tamper-seal the two parties initially provided and the complement signature created in step Add a new party to show that the complement signature is working correctly. Sample-SDV3-3.xml 4. Apply and verify a system signature containing a full set dsig:reference to tamper seal the entire document. Sample-SDV3-4.xml 9.3..Net Implementation Notes 1. In order to accommodate XPATH filters that rely on namespace prefixes, those prefixes need to be declared in the creation of the transform. For example, the following code can create an XPath transform which includes namespaces: private static XmlDsigXPathTransform CreateXPathTransform(string xpath, IDictionary<string, string> namespaces) { // create the XML that represents the transform XmlDocument doc = new XmlDocument(); XmlElement xpathelem = doc.createelement("xpath"); xpathelem.innertext = xpath; // Add the namespaces that should be in scope for the XPath expression if (namespaces!= null) { foreach (string ns in namespaces.keys) { XmlAttribute nsattr = doc.createattribute("xmlns", ns, " nsattr.value = namespaces[ns]; xpathelem.attributes.append(nsattr); } } // Build a transform from the inputs XmlDsigXPathTransform xpathtransform = new XmlDsigXPathTransform(); xpathtransform.loadinnerxml(xpathelem.selectnodes(".")); return xform; } 2. The.Net Framework 4.0 schema validation does not recognize integers longer than 29 digits, which will generate false errors for ds:x509serialnumber elements containing long numbers. 10. References MISMO-RM

13 MISMO-LDD MISMO-MEG25 RFC-2119 XML-DSIG XPATH DSIG-PRACTICES DSIG-DECRYPT XML-EXC-C14N XADES Key words for use in RFCs to Indicate Requirement Levels. S. Bradner, Editor. The Internet Engineering Task Force. March XML Signature Syntax and Processing (Second Edition)W3C Recommendation 10 June XML Path Language (XPath) Version 1.0. W3C Recommendation XML Signature Best Practices Decryption Transform for XML Signature Exclusive XML Canonicalization ETSI TS V XML Advanced Electronic Signatures (XAdES)