• Abstract and Figures
• Public Full-text

1

2Digital Signature Service Core 3Protocols, Elements, and Bindings 4Version 1.0

5OASIS Standard

611 April 2007

7Specification URIs: 8This Version: 9 http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html 10 http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.pdf 11 http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.doc 12Latest Version: 13 http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html 14 http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.pdf 15 http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.doc 16Technical Committee: 17 OASIS Digital Signature Services TC 18Chair(s): 19 Nick Pope, Thales eSecurity 20 Juan Carlos Cruellas, Centre d'aplicacions avançades d’Internet (UPC) 21Editor(s): 22 Stefan Drees, individual 23Related work: 24 25Declared XML Namespace(s): 26 urn:oasis:names:tc:dss:1.0:core:schema 27Abstract: 28 This document defines XML request/response protocols for signing and verifying XML documents 29 and other data. It also defines an XML timestamp format, and an XML signature property for use 30 with these protocols. Finally, it defines transport and security bindings for the protocols. 31Status: 32 This document was last revised or approved by the membership of OASIS on the above date. 33 The level of approval is also listed above. Check the current location noted above for possible 34 later revisions of this document. This document is updated periodically on no particular schedule. 35 Technical Committee members should send comments on this specification to the Technical 36 Committee’s email list. Others should send comments to the Technical Committee by using the 37 “Send A Comment” button on the Technical Committee’s web page at http://www.oasis- 38 open.org/committees/dss/.

1oasis-dss-core-spec-v1.0-os 11 April 2007 2Copyright © OASIS® 2007. All Rights Reserved. Page 1 of 62 39 For information on whether any patents have been disclosed that may be essential to 40 implementing this specification, and any offers of patent licensing terms, please refer to the 41 Intellectual Property Rights section of the Technical Committee web page (http://www.oasis- 42 open.org/committees/dss/ipr.php). 43 The non-normative errata page for this specification is located at http://www.oasis- 44 open.org/committees/dss/.

4oasis-dss-core-spec-v1.0-os 11 April 2007 5Copyright © OASIS® 2007. All Rights Reserved. Page 2 of 62 45Notices

46OASIS takes no position regarding the validity or scope of any intellectual property or other rights that 47might be claimed to pertain to the implementation or use of the technology described in this document or 48the extent to which any license under such rights might or might not be available; neither does it represent 49that it has made any effort to identify any such rights. Information on OASIS's procedures with respect to 50rights in OASIS specifications can be found at the OASIS website. Copies of claims of rights made 51available for publication and any assurances of licenses to be made available, or the result of an attempt 52made to obtain a general license or permission for the use of such proprietary rights by implementors or 53users of this specification, can be obtained from the OASIS Executive Director. 54OASIS invites any interested party to bring to its attention any copyrights, patents or patent applications, 55or other proprietary rights which may cover technology that may be required to implement this 56specification. Please address the information to the OASIS Executive Director. 57Copyright © OASIS® 1993–2007. All Rights Reserved. 58This document and translations of it may be copied and furnished to others, and derivative works that 59comment on or otherwise explain it or assist in its implementation may be prepared, copied, published 60and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice 61and this paragraph are included on all such copies and derivative works. However, this document itself 62may not be modified in any way, such as by removing the copyright notice or references to OASIS, except 63as needed for the purpose of developing OASIS specifications, in which case the procedures for 64copyrights defined in the OASIS Intellectual Property Rights document must be followed, or as required to 65translate it into languages other than English. 66The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors 67or assigns. 68This document and the information contained herein is provided on an "AS IS" basis and OASIS 69DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 70WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 71ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 72The name "OASIS" is a trademark of OASIS, the owner and developer of this specification, and should be 73used only to refer to the organization and its official outputs. OASIS welcomes reference to, and 74implementation and use of, specifications, while reserving the right to enforce its marks against 75misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance. 76

7oasis-dss-core-spec-v1.0-os 11 April 2007 8Copyright © OASIS® 2007. All Rights Reserved. Page 3 of 62 77Table of Contents

781 Introduction...... 7 79 1.1 Terminology...... 7 80 1.2 Normative References...... 7 81 1.3 Schema Organization and Namespaces...... 9 82 1.4 DSS Overview (Non-normative)...... 9 832 Common Protocol Structures...... 11 84 2.1 Type AnyType...... 11 85 2.2 Type InternationalStringType...... 11 86 2.3 Type saml:NameIdentifierType...... 11 87 2.4 Element ...... 11 88 2.4.1 Type DocumentBaseType...... 12 89 2.4.2 Element ...... 13 90 2.4.3 Element ...... 14 91 2.4.4 Element ...... 15 92 2.5 Element ...... 16 93 2.6 Element ...... 17 94 2.7 Elements and ...... 19 95 2.8 Common Optional Inputs...... 20 96 2.8.1 Optional Input ...... 20 97 2.8.2 Optional Input ...... 20 98 2.8.3 Optional Input ...... 20 99 2.8.4 Optional Input ...... 21 100 2.8.5 Optional Input ...... 21 101 2.9 Common Optional Outputs...... 21 102 2.9.1 Optional Output ...... 21 103 2.10 Type ...... 22 104 2.11 Type ...... 22 105 2.12 Element ...... 23 1063 The DSS Signing Protocol...... 24 107 3.1 Element ...... 24 108 3.2 Element ...... 24 109 3.3 Processing for XML Signatures...... 25 110 3.3.1 Basic Process for ...... 25 111 3.3.2 Process Variant for ...... 26 112 3.3.3 Process Variant for ...... 26 113 3.3.4 Process Variant for ...... 26 114 3.3.5 Process Variant for ...... 27 115 3.3.6 Process Variant for ...... 27 116 3.4 Basic Processing for CMS Signatures...... 28 117 3.4.1 Process Variant for ...... 28 118 3.5 Optional Inputs and Outputs...... 29 119 3.5.1 Optional Input ...... 29

10oasis-dss-core-spec-v1.0-os 11 April 2007 11Copyright © OASIS® 2007. All Rights Reserved. Page 4 of 62 120 3.5.2 Optional Input ...... 29 121 3.5.3 Optional Input ...... 31 122 3.5.4 Optional Input ...... 31 123 3.5.5 Optional Input ...... 31 124 3.5.6 Optional Input ...... 32 125 3.5.7 Optional Input ...... 34 126 3.5.8 Enveloped Signatures, Optional Input and Output 127 ...... 34 128 3.5.9 Optional Input ...... 36 1294 The DSS Verifying Protocol...... 38 130 4.1 Element ...... 38 131 4.2 Element ...... 38 132 4.3 Basic Processing for XML Signatures...... 38 133 4.3.1 Multi-Signature Verification...... 40 134 4.3.2 Signature Timestamp verification procedure...... 40 135 4.4 Basic Processing for CMS Signatures...... 42 136 4.5 Optional Inputs and Outputs...... 42 137 4.5.1 Optional Input and Output ...... 42 138 4.5.2 Optional Input ...... 43 139 4.5.3 Optional Input/Output / ...... 44 140 4.5.4 Optional Input ...... 45 141 4.5.5 Optional Input and Output ...... 45 142 4.5.6 Optional Input and Output ...... 46 143 4.5.7 Optional Input and Output ...... 47 144 4.5.8 Optional Input and Outputs , 145 ...... 47 146 4.5.9 Optional Input and Output ...... 49 147 4.5.10 Optional Input and Outputs , 148 ...... 49 1495 DSS Core Elements...... 51 150 5.1 Element ...... 51 151 5.1.1 XML Timestamp Token...... 51 152 5.1.2 Element ...... 52 153 5.2 Element ...... 52 1546 DSS Core Bindings...... 54 155 6.1 HTTP POST Transport Binding...... 54 156 6.2 SOAP 1.2 Transport Binding...... 54 157 6.2.1 SOAP Attachment Feature and Element ...... 55 158 6.3 TLS Security Bindings...... 56 159 6.3.1 TLS X.509 Server Authentication...... 57 160 6.3.2 TLS X.509 Mutual Authentication...... 57 161 6.3.3 TLS SRP Authentication...... 57 162 6.3.4 TLS SRP and X.509 Server Authentication...... 57 1637 DSS-Defined Identifiers...... 58 164 7.1 Signature Type Identifiers...... 58

13oasis-dss-core-spec-v1.0-os 11 April 2007 14Copyright © OASIS® 2007. All Rights Reserved. Page 5 of 62 165 7.1.1 XML Signature...... 58 166 7.1.2 XML TimeStampToken...... 58 167 7.1.3 RFC 3161 TimeStampToken...... 58 168 7.1.4 CMS Signature...... 58 169 7.1.5 PGP Signature...... 58 170A. Use of Exclusive Canonicalization...... 59 171B. More Complex Example...... 60 172C. Acknowledgements...... 61 173 174

16oasis-dss-core-spec-v1.0-os 11 April 2007 17Copyright © OASIS® 2007. All Rights Reserved. Page 6 of 62 1751 Introduction 176[All text is normative unless otherwise labeled]

1771.1 Terminology 178The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 179"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted 180as described in IETF RFC 2119 [RFC 2119]. These keywords are capitalized when used to 181unambiguously specify requirements over protocol features and behavior that affect the interoperability 182and security of implementations. When these words are not capitalized, they are meant in their natural- 183language sense. 184 This specification uses the following typographical conventions in text: , 185, Attribute, Datatype, OtherCode. 186 Listings of DSS schemas appear like this.

1871.2 Normative References 188 [Core-XSD] S. Drees,. DSS Schema. OASIS, February 2007. 189 [DSS-TS-P] T Perrin et al. DSS Timestamp Profile. OASIS, February 2007. 190 [DSS-AdES-P] JC Cruellas et al. Advanced Electronic Signature Profiles of the OASIS Digital 191 Signature Service. OASIS, February 2007 192 [RFC 2119] S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. IETF 193 RFC 2119, March 1997. 194 http://www.ietf.org/rfc/rfc2119.txt. 195 [RFC 2246] T Dierks, C. Allen. The TLS Protocol Version 1.0. IETF RFC 2246, January 196 1999. 197 http://www.ietf.org/rfc/rfc2246.txt. 198 [RFC 2396] T. Berners-Lee et al. Uniform Resource Identifiers (URI): Generic Syntax. IETF 199 RFC 2396, August 1998. 200 http://www.ietf.org/rfc/rfc2396.txt. 201 [RFC 2440] J. Callas, L. Donnerhacke, H. Finney, R. Thayer. OpenPGP Message Format. 202 IETF RFC 2440, November 1998. 203 http://www.ietf.org/rfc/rfc2440.txt. 204 [RFC 2616] R. Fielding et al. Hypertext Transfer Protocol – HTTP/1.1. IETF RFC 2616, June 205 1999. 206 http://www.ietf.org/rfc/rfc2616.txt. 207 [RFC 2648] R. Moats. A URN Namespace for IETF Documents. IETF RFC 2648, August 208 1999. 209 http://www.ietf.org/rfc/rfc2648.txt. 210 [RFC 2822] P. Resnick. Internet Message Format. IETF RFC 2822, April 2001. 211 http://www.ietf.org/rfc/rfc2822.txt 212 [RFC 3161] C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Internet X.509 Public Key 213 Infrastructure Time-Stamp Protocol (TSP). IETF RFC 3161, August 2001. 214 http://www.ietf.org/rfc/rfc3161.txt. 215 [RFC 3268] P. Chown. AES Ciphersuites for TLS. IETF RFC 3268, June 2002. 216 http://www.ietf.org/rfc/rfc3268.txt. 217 [RFC 3280] R. Housley, W. Polk, W. Ford, D. Solo. Internet X.509 Public Key Infrastructure 218 Certificate and Certificate Revocation List (CRL) Profile. IETF RFC 3280, April

19oasis-dss-core-spec-v1.0-os 11 April 2007 20Copyright © OASIS® 2007. All Rights Reserved. Page 7 of 62 219 2002. 220 http://www.ietf.org/rfc/rfc3280.txt. 221 [RFC 3852] R. Housley. Cryptographic Message Syntax. IETF RFC 3852, July 2004. 222 http://www.ietf.org/rfc/rfc3852.txt. 223 (Remark: As used in DSS, all implementations based upon RFC 3852, RFC 3369 224 and previous releases of CMS will suffice. For the sake of simplicity the 225 "urn:ietf::3369" is used throughout the document to indicate a CMS message as 226 specified in RFC 3852 or RFC 3369 or any version (including PKCS #7). 227 [SAMLCore1.1] E. Maler et al. Assertions and Protocol for the OASIS Security Assertion Markup 228 Language (SAML) V 1.1. OASIS, November 2002. 229 http://www.oasis-open.org/committees/download.php/3406/oasis-sstc-saml-core- 230 1.1.pdf 231 [Schema1] H. S. Thompson et al. XML Schema Part 1: Structures. W3C Recommendation, 232 May 2001. 233 http://www.w3.org/TR/xmlschema-1/ 234 [SOAP] M. Gudgin et al. SOAP Version 1.2 Part 1: Messaging Framework. W3C 235 Recommendation, June 2003. 236 http://www.w3.org/TR/xmlschema-1/ 237 [SOAPAtt] H. F. Nielsen, H. Ruellan SOAP 1.2 Attachment Feature, W3C Working Group 238 Note, 8 June 2004 239 http://www.w3.org/TR/soap12-af/ 240 [WS-I-Att] Ch. Ferris, A. Karmarkar, C. K. Liu Attachments Profile Version 1.0, The Web 241 Services-Interoperability Organization (WS-I), 20 April 2006 242 http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html 243 [XML-C14N] J. Boyer. Canonical XML Version 1.0. W3C Recommendation, March 2001. 244 http://www.w3.org/TR/xml-c14n 245 [XML-ESCAPE] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, et al. Predefined Entities in 246 Extensible Markup Language (XML) 1.0 (Third Edition), W3C Recommendation, 247 04 February 2004, 248 http://www.w3.org/TR/REC-xml/#dt-escape 249 [xml:id] xml:id, Version 1.0, W3C Recommendation, 9 September 2005, 250 http://www.w3.org/TR/xml-id/ 251 [XML-ns] T. Bray, D. Hollander, A. Layman. Namespaces in XML. W3C 252 Recommendation, January 1999. 253 http://www.w3.org/TR/1999/REC-xml-names-19990114 254 [XML-NT-Document] http://www.w3.org/TR/2004/REC-xml-20040204/#NT-document 255 [XML-PROLOG] Tim Bray, Jean Paoli, C. M. Sperberg-McQueen, et al. Prolog and Document 256 Type Declaration in Extensible Markup Language (XML) 1.0 (Third Edition), W3C 257 Recommendation, 04 February 2004, http://www.w3.org/TR/REC-xml/#sec- 258 prolog-dtd 259 [XMLDSIG] D. Eastlake et al. XML-Signature Syntax and Processing. W3C 260 Recommendation, February 2002. 261 http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/ 262 [XML-TSP] T. Perrin et al. XML Timestamping Profile of the OASIS Digital Signature 263 Services. W3C Recommendation, February 2002. OASIS, (MONTH/YEAR 264 TBD) 265 [XML] Extensible Markup Language (XML) 1.0 (Third Edition). W3C Recommendation 04 February 266 2004 http://www.w3.org/TR/REC-xml/#sec-element-content 267 [XPATH] XML Path Language (XPath) Version 1.0. W3C Recommendation 16 November 1999 268 http://www.w3.org/TR/xpath 269 [XML-xcl-c14n] Exclusive XML Canonicalization Version 1.0. W3C Recommendation 18 July 2002 270 http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/

22oasis-dss-core-spec-v1.0-os 11 April 2007 23Copyright © OASIS® 2007. All Rights Reserved. Page 8 of 62 2711.3 Schema Organization and Namespaces 272The structures described in this specification are contained in the schema file [Core-XSD]. All schema 273listings in the current document are excerpts from the schema file. In the case of a disagreement 274between the schema file and this document, the schema file takes precedence. 275This schema is associated with the following XML namespace:

276 urn:oasis:names:tc:dss:1.0:core:schema 277If a future version of this specification is needed, it will use a different namespace. 278Conventional XML namespace prefixes are used in the schema: 279  The prefix dss: stands for the DSS core namespace [Core-XSD]. 280  The prefix ds: stands for the W3C XML Signature namespace [XMLDSIG]. 281  The prefix xs: stands for the W3C XML Schema namespace [Schema1]. 282  The prefix saml: stands for the OASIS SAML Schema namespace [SAMLCore1.1]. 283Applications MAY use different namespace prefixes, and MAY use whatever namespace 284defaulting/scoping conventions they desire, as long as they are compliant with the Namespaces in XML 285specification [XML-ns]. 286The following schema fragment defines the XML namespaces and other header information for the DSS 287core schema: 288 295 296 This Schema defines the Digital Signature 297 Service Core Protocols, Elements, and Bindings Committee Draft 5 for Public 298 Review 299 300 302 305

3071.4 DSS Overview (Non-normative) 308This specification describes two XML-based request/response protocols – a signing protocol and a 309verifying protocol. Through these protocols a client can send documents (or document hashes) to a 310server and receive back a signature on the documents; or send documents (or document hashes) and a 311signature to a server, and receive back an answer on whether the signature verifies the documents. 312These operations could be useful in a variety of contexts – for example, they could allow clients to access 313a single corporate key for signing press releases, with centralized access control, auditing, and archiving 314of signature requests. They could also allow clients to create and verify signatures without needing 315complex client software and configuration. 316The signing and verifying protocols are chiefly designed to support the creation and verification of XML 317signatures [XMLDSIG], XML timestamps (see section 5.1), binary timestamps [RFC 3161] and CMS 318signatures [RFC 3852]. These protocols may also be extensible to other types of signatures and 319timestamps, such as PGP signatures [RFC 2440].

25oasis-dss-core-spec-v1.0-os 11 April 2007 26Copyright © OASIS® 2007. All Rights Reserved. Page 9 of 62 320It is expected that the signing and verifying protocols will be profiled to meet many different application 321scenarios. In anticipation of this, these protocols have only a minimal set of required elements, which 322deal with transferring “input documents” and signatures back and forth between client and server. The 323input documents to be signed or verified can be transferred in their entirety, or the client can hash the 324documents themselves and only send the hash values, to save bandwidth and protect the confidentiality 325of the document content. 326All functionality besides transferring input documents and signatures is relegated to a framework of 327“optional inputs” and “optional outputs”. This document defines a number of optional inputs and outputs. 328Profiles of these protocols can pick and choose which optional inputs and outputs to support, and can 329introduce their own optional inputs and outputs when they need functionality not anticipated by this 330specification. 331Examples of optional inputs to the signing protocol include: what type of signature to produce, which key 332to sign with, who the signature is intended for, and what signed and unsigned properties to place in the 333signature. Examples of optional inputs to the verifying protocol include: the time for which the client would 334like to know the signature’s validity status, additional validation data necessary to verify the signature 335(such as certificates and CRLs), and requests for the server to return information such as the signer’s 336name or the signing time. 337The signing and verifying protocol messages must be transferred over some underlying protocol(s) which 338provide message transport and security. A binding specifies how to use the signing and verifying 339protocols with some underlying protocol, such as HTTP POST or TLS. Section 6 provides an initial set of 340bindings. 341In addition to defining the signing and verifying protocols, this specification defines two XML elements that 342are related to these protocols. First, an XML timestamp element is defined in section 5.1. The signing 343and verifying protocols can be used to create and verify both XML and binary timestamps; a profile for 344doing so is defined in [XML-TSP]. Second, a RequesterIdentity element is defined in section 5.2. This 345element can be used as a signature property in an XML signature, to give the name of the end-user who 346requested the signature. 347 348

28oasis-dss-core-spec-v1.0-os 11 April 2007 29Copyright © OASIS® 2007. All Rights Reserved. Page 10 of 62 3492 Common Protocol Structures 350The following sections describe XML structures and types that are used in multiple places.

3512.1 Type AnyType 352The AnyType complex type allows arbitrary XML element content within an element of this type (see 353section 3.2.1 Element Content [XML]). 354 355 356 359 360

3612.2 Type InternationalStringType 362The InternationalStringType complex type attaches an xml:lang attribute to a human-readable string 363to specify the string’s language. 364 365 366 367 368 369 370

3712.3 Type saml:NameIdentifierType 372The saml:NameIdentifierType complex type is used where different types of names are needed (such 373as email addresses, Distinguished Names, etc.). This type is borrowed from [SAMLCore1.1] section 3742.4.2.2. It consists of a string with the following attributes: 375NameQualifier [Optional] 376 The security or administrative domain that qualifies the name of the subject. This attribute provides a 377 means to federate names from disparate user stores without collision. 378Format [Optional] 379 A URI [RFC 2396] reference representing the format in which the string is provided. See section 7.3 380 of [SAMLCore1.1] for some URI references that may be used as the value of the Format attribute.

3812.4 Element 382The element is used to send input documents to a DSS server, whether for signing 383or verifying. An input document can be any piece of data that can be used as input to a signature or 384timestamp calculation. An input document can even be a signature or timestamp (for example, a pre- 385existing signature can be counter-signed or timestamped). An input document could also be a 386, allowing the client to handle manifest creation while using the server to create the rest 387of the signature. Manifest validation is supported by an optional input / output. 388The element consists of any number of the following elements: 389 [Any Number]

31oasis-dss-core-spec-v1.0-os 11 April 2007 32Copyright © OASIS® 2007. All Rights Reserved. Page 11 of 62 390 It contains a document as specified in section 2.4.2 of this document. 391 [Any Number] 392 This contains the binary output of a chain of transforms applied by a client as specified in section 2.4.3 393 of this document. 394 [Any Number] 395 This contains the hash value of an XML document or some other data after a client has applied a 396 sequence of transforms and also computed a hash value as specified in section 2.4.4 of this 397 document. 398 399 Other may contain arbitrary content that may be specified in a profile and can also be used to extend 400 the Protocol for details see section 2.1. 401 402 403 404 405 406 407 408 409 410 411 412 413When using DSS to create or verify XML signatures, each input document will usually correspond to a 414single element. Thus, in the descriptions below of the , 415 and elements, it is explained how certain elements and 416attributes of a , and correspond to components 417of a .

4182.4.1 Type DocumentBaseType 419The DocumentBaseType complex type is subclassed by , and 420 elements. It contains the basic information shared by subclasses and remaining 421persistent during the process from input document retrieval until digest calculation for the relevant 422document. It contains the following elements and attributes: 423ID [Optional] 424 This identifier gives the input document a unique label within a particular request message. Through 425 this identifier, an optional input (see sections 2.7, 3.5.6 and 3.5.8) can refer to a particular input 426 document. 427RefURI [Optional] 428 This specifies the value for a element’s URI attribute when referring to this input 429 document. The RefURI attribute SHOULD be specified; no more than one RefURI attribute may be 430 omitted in a single signing request. 431RefType [Optional] 432 This specifies the value for a element’s Type attribute when referring to this input 433 document. 434SchemaRefs [Optional]: 435 The identified schemas are to be used to identify ID attributes during parsing in sections 2.5.2, 3.3.1 436 1.a and 4.3 and for XPath evaluation in sections 2.6, 3.5.7, 4.3.1. If anything else but are 437 referred to, the server MUST report an error. If a referred to is not used by the XML

34oasis-dss-core-spec-v1.0-os 11 April 2007 35Copyright © OASIS® 2007. All Rights Reserved. Page 12 of 62 438 document instance this MAY be ignored or reported to the client in the / 439 (for the definition of see 2.8.5 or 2.9.1 on ). 440 The Document is assumed to be valid against the first referred to by SchemaRefs. 441 If a element is referred to first by SchemaRefs the document is assumed to be valid 442 against the first inside . In both cases, the remaining schemas may occur in 443 any order and are used either directly or indirectly by the first schema. 444 If present, the server MUST use the schemas to identify the ID attributes and MAY also perform 445 complete validation against the schemas. 446 447 448 449 450 451 452Note: It is recommended to use xml:id as defined in [xml:id] as id in the payload being referenced by a 453, because the schema then does not have to be supplied for identifying the ID 454attributes.

4552.4.2 Element 456The element may contain the following elements (in addition to the common ones listed in 457section 2.4.1): 458If the content inside one of the following mutually exclusive elements , 459or is not parseable XML data, after appropriate decoding, then the server MUST return a 460 (section 2.6) issuing a RequesterError qualified by a 461NotParseableXMLDocument. 462The server MUST use the referred by for validation if specified. 463 [Optional] [Default] 464 This contains a base64 string obtained after base64 encoding of a XML data. The server MUST 465 decode it to obtain the XML data. 466 [Optional] 467 The InlineXMLType clearly expresses the fact, that content of is inline XML that should 468 be equivalent to a complete XML Document. I.e. having only one DocumentElement (see section 2.1 469 Well-Formed XML Documents [XML]) and not allowing anything but PI's and Comments before and 470 after this one element. 471 It may contain the ignorePIs and ignoreComments attributes. These attributes apply to the 472 complete document and indicate respectively, if processing instructions or comments MAY be ignored. 473 If one or both of these attributes are not present, their values MUST be considered to be "true". 474 InlineXML will work with PIs and/or Comments if ignorePIs and ignoreComments are false 475 respectively and if the server supports such behavior. 476 [Optional] 477 This contains an escaped string. The server MUST unescape (escape sequences are processed to 478 produce original XML sequence) it for obtaining XML data. 479 [Optional] 480 This contains a base64 encoding of data that are not XML. The type of data is specified by its 481 MimeType attribute, that may be required when using DSS with other signature types. 482 [Optional]

37oasis-dss-core-spec-v1.0-os 11 April 2007 38Copyright © OASIS® 2007. All Rights Reserved. Page 13 of 62 483 This contains a reference to an attachment like SOAP attachments or similar data containers that may 484 be passed along with the request. For details see section 6.2.1 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 507 508 509 510 511 512 513 514 515 516 518 520

5212.4.3 Element 522The element contains the following elements (in addition to the common ones 523listed in section 2.4.1): 524 [Required on a SignRequest] [Optional on VerifyRequest] 525 This is the sequence of transforms applied by the client and specifies the value for a 526 element’s child element. In other words, this specifies 527 transforms that the client has already applied to the input document before the server will hash it. 528 [Required] 529 This gives the binary output of a sequence of transforms to be hashed at the server side. 530WhichReference [Ignored on a SignRequest] [Optional on a VerifyRequest] 531 As there may be multiple TransformedData / DocumentHash elements of the same document 532 having the same URI [RFC 2396] and RefType on a SignRequest or VerifyRequest - their 533 correspondance to an already existing however needs to be established on a 534 VerifyRequest only. 535 There is a need to disambiguate such cases. This Attribute hence offers a way to clearly identify the 536 when URI and RefType match multiple ds:References / TransformedData /

40oasis-dss-core-spec-v1.0-os 11 April 2007 41Copyright © OASIS® 2007. All Rights Reserved. Page 14 of 62 537 DocumentHash. The corresponding ds:Reference is indicated by this zero-based 538 WhichReference attribute (0 means the first in the signature, 1 means the 539 second, and so on). 540 Note: It may be possible to establish the ds:References / TransformedData / DocumentHash 541 correspondence by comparing the optionally supplied chain of transforms to those of the 542 ds:References having the same URI and RefType in the supplied ds:Signature if this chain of 543 transform has been supplied. This can be quite expensive and even out the advantages of 544 TransformedData / DocumentHash. 545 546 547 548 549 550 551 552 553 555 556 557 558

5592.4.4 Element 560The element contains the following elements (in addition to the common ones listed in 561section 2.4.1): 562 [Required on a SignRequest] [Optional on VerifyRequest] 563 This specifies the value for a element’s child element when 564 referring to this document hash. In other words, this specifies transforms that the client has already 565 applied to the input document before hashing it. 566 [Required on a SignRequest] [Optional on VerifyRequest] 567 This identifies the digest algorithm used to hash the document at the client side. This specifies the 568 value for a element’s child element when referring to this 569 input document. 570 [Required] 571 This gives the document’s hash value. This specifies the value for a element’s 572 child element when referring to this input document. 573WhichReference [Ignored on a SignRequest] [Optional on a VerifyRequest] 574 As there may be multiple TransformedData / DocumentHash elements of the same document 575 having the same URI and RefType on a SignRequest or VerifyRequest - their correspondance 576 to an already existing however needs to be established on a VerifyRequest only. 577 There is a need to disambiguate such cases. This Attribute hence offers a way to clearly identify the 578 when URI and RefType match multiple ds:References / TransformedData / 579 DocumentHash. The corresponding ds:Reference is indicated by this zero-based 580 WhichReference attribute (0 means the first in the signature, 1 means the 581 second, and so on). 582 583 584 585

43oasis-dss-core-spec-v1.0-os 11 April 2007 44Copyright © OASIS® 2007. All Rights Reserved. Page 15 of 62 586 587 588 589 590 591 593 594 595 596

5972.5 Element 598The element contains a signature or timestamp of some sort. This element is 599returned in a sign response message, and sent in a verify request message. It may contain one of the 600following child elements: 601 [Optional] 602 An XML signature [XMLDSIG]. 603 [Optional] 604 An XML, RFC 3161 or other timestamp (see section 5.1). 605 [Optional] 606 A base64 encoding of some non-XML signature, such as a PGP [RFC 2440] or CMS [RFC 3852] 607 signature. The type of signature is specified by its Type attribute (see section 7.1). 608 [Optional] 609 This is used to point to an XML signature in an input (for a verify request) or output (for a sign 610 response) document in which a signature is enveloped. 611SchemaRefs [Optional] 612 As described above in 2.4.1 613A contains the following attributes: 614WhichDocument [Required] 615 This identifies the input document as in section 2.4.2 being pointed at (see also ID attribute in section 616 2.4.1). 617XPath [Optional] 618 a) This identifies the signature element being pointed at. 619 b) The XPath expression is evaluated from the root node (see section 5.1 of [XPATH]) of the 620 document identified by WhichDocument after the XML data was extracted and parsed if necessary. 621 The context node for the XPath evaluation is the document’s DocumentElement (see section 2.1 Well- 622 Formed XML Documents [XML]). 623 c) About namespace declarations for the expression necessary for evaluation see section 1 of 624 [XPATH]. Namespace prefixes used in XPath expressions MUST be declared within the element 625 containing the XPath expression. E.g.: . See 627 also the following example below. A piece of a XML signature of a containing a 628 with a XPath filtering element that includes inline namespace prefixes 629 declaration. This piece of text comes from one of the signatures that were generated in the course of 630 the interoperability experimentation. As one can see they are added to the element: 631 632

46oasis-dss-core-spec-v1.0-os 11 April 2007 47Copyright © OASIS® 2007. All Rights Reserved. Page 16 of 62 633 635 ancestor-or- 637 self::upc1:Root 638 639 640 641 24xf8vfP3xJ40akfFAnEVM/zxXY= 642 643 If the XPath does not evaluate to one element the server MUST return a (section 2.6) 644 issuing a RequesterError qualified by a 645 XPathEvaluationError. 646 647 Other may contain arbitrary content that may be specified in a profile and can also be used to extend 648 the Protocol. 649The following schema fragment defines the , , and 650 elements: 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 678 679

6802.6 Element 681The element is returned with every response message. It contains the following child 682elements: 683 [Required] 684 The most significant component of the result code. 685 [Optional]

49oasis-dss-core-spec-v1.0-os 11 April 2007 50Copyright © OASIS® 2007. All Rights Reserved. Page 17 of 62 686 The least significant component of the result code. 687 [Optional] 688 A message which MAY be returned to an operator, logged, used for debugging, etc. 689 690 691 692 693 695 697 698 699 700The URIs MUST be values defined by this specification or by some profile of this 701specification. The values defined by this specification are: 702urn:oasis:names:tc:dss:1.0:resultmajor:Success 703 The protocol executed successfully. 704urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError 705 The request could not be satisfied due to an error on the part of the requester. 706urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError 707 The request could not be satisfied due to an error on the part of the responder. 708urn:oasis:names:tc:dss:1.0:resultmajor:InsufficientInformation 709 The request could not be satisfied due to insufficient information. 710In case of doubt of who is responsible a 711urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError is assumed. 712This specification defines the following values, that are listed below, grouped by the 713respective associated code. 714One of the following values MUST be returned when the code is 715Success. 716urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:OnAllDocuments 717 The signature or timestamp is valid. Furthermore, the signature or timestamp covers all of the input 718 documents just as they were passed in by the client. 719urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:NotAllDocumentsReferen 720ced 721 The signature or timestamp is valid. However, the signature or timestamp does not cover all of the 722 input documents that were passed in by the client. 723urn:oasis:names:tc:dss:1.0:resultminor:invalid:IncorrectSignature 724 The signature fails to verify, for example due to the signed document being modified or the incorrect 725 key being used. 726urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:HasManifestResults 727 The signature is valid with respect to XML Signature core validation. In addition, the message also 728 contains VerifyManifestResults. 729 Note: In the case that the core signature validation failed no attempt is made to verify the manifest. 730urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTimest 731amp 732 The signature is valid however the timestamp on that signature is invalid.

52oasis-dss-core-spec-v1.0-os 11 April 2007 53Copyright © OASIS® 2007. All Rights Reserved. Page 18 of 62 733The following values is suggest MAY be returned when the code is 734RequesterError. 735urn:oasis:names:tc:dss:1.0:resultminor:ReferencedDocumentNotPresent 736 A ds:Reference element is present in the ds:Signature containing a full URI, but the corresponding 737 input document is not present in the request. 738urn:oasis:names:tc:dss:1.0:resultminor:KeyInfoNotProvided 739 The required key information was not supplied by the client, but the server expected it to do so. 740urn:oasis:names:tc:dss:1.0:resultminor:MoreThanOneRefUriOmitted 741 The server was not able to create a signature because more than one RefUri was omitted. 742urn:oasis:names:tc:dss:1.0:resultminor:InvalidRefURI 743 The value of the RefURI attribute included in an input document is not valid. 744urn:oasis:names:tc:dss:1.0:resultminor:NotParseableXMLDocument 745 The server was not able to parse a Document. 746urn:oasis:names:tc:dss:1.0:resultminor:NotSupported 747 The server doesn’t recognize or can’t handle any optional input. 748urn:oasis:names:tc:dss:1.0:resultminor:Inappropriate:signature 749 The signature or its contents are not appropriate in the current context. 750 For example, the signature may be associated with a signature policy and semantics which the DSS 751 server considers unsatisfactory. 752Further values for associated with code 753urn:oasis:names:tc:dss:1.0:resultmajor:RequesterError are left open to the implementer 754or profile to be defined with in their namespaces. 755The following values MAY be returned when the code is ResponderError. 756urn:oasis:names:tc:dss:1.0:resultminor:GeneralError 757 The processing of the request failed due to an error not covered by the existing error codes. Further 758 details should be given in the result message for the user which may be passed on to the relevant 759 administrator. 760urn:oasis:names:tc:dss:1.0:resultminor:invalid:KeyLookupFailed 761 Locating the identified key failed (e.g. look up failed in directory or in local key file). 762Further values for associated with code 763urn:oasis:names:tc:dss:1.0:resultmajor:ResponderError are left open to the implementer 764or profile to be defined within their namespaces. 765The following values MAY be returned when the code is 766InsufficientInformation. 767urn:oasis:names:tc:dss:1.0:resultminor:CrlNotAvailiable 768 The relevant certificate revocation list was not available for checking. 769urn:oasis:names:tc:dss:1.0:resultminor:OcspNotAvailiable 770 The relevant revocation information was not available via the online certificate status protocol. 771urn:oasis:names:tc:dss:1.0:resultminor:CertificateChainNotComplete 772 The chain of trust could not be established binding the public key used for validation to a trusted root 773 certification authority via potential intermediate certification authorities.

55oasis-dss-core-spec-v1.0-os 11 April 2007 56Copyright © OASIS® 2007. All Rights Reserved. Page 19 of 62 7742.7 Elements and 775All request messages can contain an element, and all response messages can 776contain an element. Several optional inputs and outputs are defined in this 777document, and profiles can define additional ones. 778The contains additional inputs associated with the processing of the request. 779Profiles will specify the allowed optional inputs and their default values. The definition of an optional input 780MAY include a default value, so that a client may omit the yet still get service from 781any profile-compliant DSS server. 782If a server doesn’t recognize or can’t handle any optional input, it MUST reject the request with a 783 code of RequesterError and a code of NotSupported (see 784section 2.6). 785The element contains additional protocol outputs. The client MAY request the 786server to respond with certain optional outputs by sending certain optional inputs. The server MAY also 787respond with outputs the client didn’t request, depending on the server’s profile and policy. 788The and elements contain unordered inputs and outputs. 789Applications MUST be able to handle optional inputs or outputs appearing in any order within these 790elements. Normally, there will only be at most one occurrence of any particular optional input or output 791within a protocol message. Where multiple occurrences of an optional input (e.g. in 792section 3.5.6) or optional output are allowed, it will be explicitly specified (see section 4.5.9 for an 793example). 794The following schema fragment defines the and elements: 795 796 797

7982.8 Common Optional Inputs 799These optional inputs can be used with both the signing protocol and the verifying protocol.

8002.8.1 Optional Input 801The element indicates a particular policy associated with the DSS service. The 802policy may include information on the characteristics of the server that are not covered by the Profile 803attribute (see sections 3.1 and 4.1). The element may be used to select a specific 804policy if a service supports multiple policies for a specific profile, or as a sanity-check to make sure the 805server implements the policy the client expects. 806

8072.8.2 Optional Input 808The element indicates the identity of the client who is making a request. The 809server may use this to parameterize any aspect of its processing. Profiles that make use of this element 810MUST define its semantics. 811The child element can be used by profiles to carry information related to the 812claimed identity. One possible use of is to carry authentication data that 813authenticates the request as originating from the claimed identity (examples of authentication data include 814a password or SAML Assertion [SAMLCore1.1], or a signature or MAC calculated over the request using 815a client key).

58oasis-dss-core-spec-v1.0-os 11 April 2007 59Copyright © OASIS® 2007. All Rights Reserved. Page 20 of 62 816The claimed identity may be authenticated using the security binding, according to section 6, or using 817authentication data provided in the element. The server MUST check that the 818asserted is authenticated before relying upon the . 819 820 821 822 823 825 826 827

8282.8.3 Optional Input 829The element indicates which language the client would like to receive 830InternationalStringType values in. The server should return appropriately localized strings, if possible. 831

8322.8.4 Optional Input 833The element can appear multiple times in a request. It indicates additional 834profiles which modify the main profile specified by the Profile attribute (thus the Profile attribute 835MUST be present; see sections 3.1 and 4.1 for details of this attribute). The interpretation of additional 836profiles is determined by the main profile. 837

8382.8.5 Optional Input 839The element provides an in band mechanism for communicating XML schemas required for 840validating an XML document. 841 842 843 844 845 846 847 848 849An XML schema is itself an XML document, however, only the following attributes, defined in 850dss:DocumentType, are meaningful for the element: 851ID 852 Used by relying XML document to identify a schema. 853RefURI 854 The target namespace of the schema (i.e. the value of the targetNamespace attribute). 855RefType 856 MUST NOT be used. 857SchemaRefs 858 MUST NOT be used.

61oasis-dss-core-spec-v1.0-os 11 April 2007 62Copyright © OASIS® 2007. All Rights Reserved. Page 21 of 62 859Note: It is recommended to use xml:id as defined in [xml:id] as id in the payload being referenced by a 860, because the schema then does not have to be supplied for identifying the ID 861attributes.

8622.9 Common Optional Outputs 863These optional outputs can be used with both the signing protocol and the verifying protocol.

8642.9.1 Optional Output 865The element is typically used as an optional input in a . However, there 866are situations where it may be used as an optional output. For example, a service that makes use of the 867 mechanism may, after verifying a signature over an input document, 868generate a signature over a document of a different schema than the input document. In this case the 869 element MAY be used to communicate the XML schemas required for validating the returned 870XML document. 871For a description of the element see section 2.8.5.

8722.10 Type 873The complex type is the base structure for request elements defined by the core 874protocol or profiles. It defines the following attributes and elements: 875RequestID [Optional] 876 This attribute is used to correlate requests with responses. When present in a request, the server 877 MUST return it in the response. 878Profile [Optional] 879 This attribute indicates a particular DSS profile. It may be used to select a profile if a server supports 880 multiple profiles, or as a sanity-check to make sure the server implements the profile the client 881 expects. 882 [Optional] 883 Any additional inputs to the request. 884 [Optional] 885 The input documents which the processing will be applied to. 886 887 888 889 890 891 893 894

8952.11 Type 896The complex type is the base structure for response elements defined by the 897core protocol or profiles. It defines the following attributes and elements: 898RequestID [Optional] 899 This attribute is used to correlate requests with responses. When present in a request, the server 900 MUST return it in the response. 901Profile [Required]

64oasis-dss-core-spec-v1.0-os 11 April 2007 65Copyright © OASIS® 2007. All Rights Reserved. Page 22 of 62 902 This attribute indicates the particular DSS profile used by the server. It may be used by the client for 903 logging purposes or to make sure the server implements a profile the client expects. 904 [Required] 905 A code representing the status of the request. 906 [Optional] 907 Any additional outputs returned by the server. 908 909 910 911 912 913 915 916

9172.12 Element 918The element is an instance of the type. This element is useful in 919cases where the DSS server is not able to respond with a special response type. It is a general purpose 920response element for exceptional circumstances. 921E.g.: "The server only supports verification requests.", "The server is currently under maintenance" or 922"The service operates from 8:00 to 17:00". 923Other use cases for this type are expected to be described in special profiles ( e.g. the Asynchronous 924profile ). 925

67oasis-dss-core-spec-v1.0-os 11 April 2007 68Copyright © OASIS® 2007. All Rights Reserved. Page 23 of 62 9263 The DSS Signing Protocol

9273.1 Element 928The element is sent by the client to request a signature or timestamp on some input 929documents. It contains the following attributes and elements inherited from : 930RequestID [Optional] 931 This attribute is used to correlate requests with responses. When present in a request, the server 932 MUST return it in the response. 933Profile [Optional] 934 This attribute indicates a particular DSS profile. It may be used to select a profile if a server supports 935 multiple profiles, or as a sanity-check to make sure the server implements the profile the client 936 expects. 937 [Optional] 938 Any additional inputs to the request. 939 [Optional] 940 The input documents, which the signature will be calculated over. This element, while optional in 941 RequestBaseType, is REQUIRED for the element. 942 943 944 945 946 947 948

9493.2 Element 950The element contains the following attributes and elements inherited from 951: 952RequestID [Optional] 953 This attribute is used to correlate requests with responses. When present in a request, the server 954 MUST return it in the response. 955Profile [Optional] 956 This attribute indicates the particular DSS profile used by the server. It may be used by the client for 957 logging purposes or to make sure the server implements a profile the client expects. 958 [Required] 959 A code representing the status of the request. 960 [Optional] 961 Any additional outputs returned by the server. 962In addition to the element defines the following 963 element: 964 [Optional] 965 The result signature or timestamp or, in the case of a signature being enveloped in an output 966 document (see section 3.5.8), a pointer to the signature. 70oasis-dss-core-spec-v1.0-os 11 April 2007 71Copyright © OASIS® 2007. All Rights Reserved. Page 24 of 62 967 In the case of being used this MUST contain a , having 968 the same XPath expression as in and pointing to a 969 using it’s WhichDocument attribute. 970 971 972 973 974 975 976 977 978 979 980

9813.3 Processing for XML Signatures

9823.3.1 Basic Process for 983A DSS server that produces XML signatures SHOULD perform the following steps, upon receiving a 984. 985These steps may be changed or overridden by procedures defined for the optional inputs (for example, 986see section 3.5.6), or by the profile or policy the server is operating under. 987The ordering of the elements inside the MAY be ignored by the 988server. 9891. For each in the server MUST perform the following steps: 990 a. In the case of (see later sub-sections for other cases), the server base64- 991 decodes the data contained within into an octet stream. This data MUST 992 be a well formed XML Document as defined in [XML] section 2.1. If the RefURI attribute 993 references within the same input document then the server parses the octet stream to 994 NodeSetData (see [XMLDSIG] section 4.3.3.3) before proceeding to the next step. 995 b. The data is processed and transforms applied by the server to produce a canonicalized 996 octet string as required in [XMLDSIG] section 4.3.3.2. 997 Note: Transforms can be applied as a server implementation MAY choose to increase 998 robustness of the Signatures created. These Transforms may reflect idiosyncrasies of 999 different parsers or solve encoding issues or the like. Servers MAY choose not to apply 1000 transforms in basic processing and extract the binary data for direct hashing or 1001 canonicalize the data directly if certain optional inputs (see sections 3.5.8 point 2 and v, 1002 3.5.9 ) are not to be implemented. 1003 Note: As required in [XMLDSIG] if the end result is an XML node set, the server MUST 1004 attempt to convert the node set back into an octet stream using Canonical XML [XML- 1005 C14N]. 1006 c. The hash of the resulting octet stream is calculated. 1007 d. The server forms a with the elements and attributes set as follows: 1008 i. If the has a RefURI attribute, the element’s 1009 URI attribute is set to the value of the RefURI attribute, else this attribute is 1010 omitted. 1011 A signature MUST NOT be created if more than one RefURI is omitted in the set 1012 of input documents and the server MUST report a RequesterError by setting 1013 RequesterError qualified by a .

73oasis-dss-core-spec-v1.0-os 11 April 2007 74Copyright © OASIS® 2007. All Rights Reserved. Page 25 of 62 1014 ii. If the has a RefType attribute, the element’s 1015 Type attribute is set to the value of the RefType attribute, else this attribute is 1016 omitted. 1017 iii. The element is set to the hash method used. 1018 iv. The element is set to the hash value that is to be 1019 calculated as per [XMLDSIG]. 1020 v. The element is set to the sequence of transforms applied by 1021 the server in step b. This sequence MUST describe the effective transform as a 1022 reproducible procedure from parsing until hash. 10232. References resulting from processing of optional inputs MUST be included. In doing so, the server 1024 MAY reflect the ordering of the elements. 10253. The server creates an XML signature using the elements created in Step 1.d, 1026 according to the processing rules in [XMLDSIG].

10273.3.2 Process Variant for 1028In the case of an input document which contains Step 3.3.1 a is replaced with the 1029following step: 10301. 1031 a. The XML document is extracted from the DSS protocol envelope, without taking inherited 1032 namespaces and attributes. Exclusive Canonical XML [XML-xcl-c14n] MUST be applied to 1033 extract data AND assure context free extraction. 1034 If signed data is to be echoed back to the client and hence details could get lost refer to Error: 1035 Reference source not found. 1036In Step 3.3.1 step v, the element MUST begin with the canonicalization transform 1037applied under revised step 3.3.2 a above.

10383.3.3 Process Variant for 1039In the case of an input document which contains Step 3.3.1 a is replaced with the 1040following: 10411. 1042 In the case of the server unescapes the data contained within 1043 into a character string. If the RefURI references within the same input document the server 1044 parses the unescaped character content to NodeSetData if necessary. If the RefURI does not 1045 reference within the same input document then the server canonicalizes the characters or 1046 parsed NodeSetData (see [XMLDSIG] section 4.3.3.3) to octet stream if necessary before 1047 proceeding to the next step. 1048 1049 Note: If the characters are converted to an octet stream directly a consistent encoding 1050 including ByteOrderMark has to be ensured. 1051In Step 3.3.1 v, the element MUST begin with the canonicalization transform applied 1052under revised step 3.3.3 ?? above.

10533.3.4 Process Variant for 1054In the case of an input document which contains Step 1 a and Step 1 b are replaced 1055with the following: 10561. 1057 a. The server base64-decodes the data contained within into an octet string.

76oasis-dss-core-spec-v1.0-os 11 April 2007 77Copyright © OASIS® 2007. All Rights Reserved. Page 26 of 62 1058 b. No transforms or other changes are made to the octet string before hashing. 1059 1060 Note: If the RefURI references within the same input document the Document MUST also be 1061 referenced by in section 3.5.6 to include the object as base64 data 1062 inside a otherwise a (section 2.6) issuing a 1063 RequesterError qualified by a NotParseableXMLDocument.

10643.3.5 Process Variant for 1065In the case of an input document which contains Step 3.3.1 1 is replaced with the 1066following: 10671. For each in the server MUST perform the following 1068 steps: 1069 b. The server base64-decodes the data contained within of 1070 into an octet string. 1071 c. Omitted. 1072 d. The hash over of the octet stream extracted in step a is calculated. 1073 e. as in 3.3.1 step 1d updated as follows 1074 replace the word "" by otherwise as in as 3.3.1 1075 step 1d.i. 1076 replace the word "" by otherwise as in as 3.3.1 1077 step 1d.ii. 1078 same as 3.3.1 step 1d.iii. 1079 The element is set to the sequence of transforms indicated by 1080 the client in the element within the . This 1081 sequence MUST describe the effective transform as a reproducible procedure from 1082 parsing until digest input.

10833.3.6 Process Variant for 1084In the case of an input document which is provided in the form of a hash value in Step 10853.3.1 1 is replaced with the following: 10861. For each in the server MUST perform the following steps: 1087 a. Omitted. 1088 b. Omitted. 1089 c. Omitted. 1090 d. as in 3.3.1 step 1d updated as follows 1091 i. replace the word "" by otherwise as in as 3.3.1 step 1092 1d.i. 1093 ii. replace the word "" by otherwise as in as 3.3.1 step 1094 1d.ii. 1095 iii. The element is set to the value of in 1096 1097 iv. The element is set to the value of in 1098 . 1099 v. The element is set to the sequence of transforms indicated by 1100 the client in the element within , if any such

79oasis-dss-core-spec-v1.0-os 11 April 2007 80Copyright © OASIS® 2007. All Rights Reserved. Page 27 of 62 1101 transforms are indicated by the client. This sequence MUST describe the effective 1102 transform as a reproducible procedure from parsing until hash.

11033.4 Basic Processing for CMS Signatures 1104A DSS server that produces CMS signatures [RFC 3852] SHOULD perform the following steps, upon 1105receiving a . These steps may be changed or overridden by the optional inputs, or by 1106the profile or policy the server is operating under. With regard to the compatibility issues in validation / 1107integration of PKCS#7 signatures and CMS implementations please refer to [RFC 3852] section 1.1.1 1108“Changes Since PKCS #7 Version 1.5”. 1109The MUST contain either a single not having RefURI, RefType set or 1110a single not having RefURI, RefType, set: 11111. If a is present, the server hashes its contents as follows: 1112 a. If the contains , the server extracts the ancestry context free text 1113 content of the as an octet stream by base64 decoding it’s contents. 1114 b. If the contains , the server extracts the ancestry context free text 1115 content of the as an octet stream as explained in (section 3.3.2 a ). This octet 1116 stream has to be returned as / . For CMS 1117 signatures this only has to be returned in the case of CMS signatures that are 1118 external/detached/"without eContent", as these return the signed Data anyway. 1119 c. If the contains , the server unescapes the content of the 1120 as a character stream and converts the character stream to an octet stream 1121 using an encoding as explained in (section 3.3.3). 1122 d. If the contains , the server base64-decodes the text content of 1123 the into an octet stream. 1124 e. The server hashes the resultant octet stream. 11252. The server forms a SignerInfo structure based on the input document. The components of the 1126 SignerInfo are set as follows: 1127 a. The digestAlgorithm field is set to the OID value for the hash method that was used in 1128 step 1.c (for a ), or to the OID value that is equivalent to the input document’s 1129 (for a ). 1130 b. The signedAttributes field’s message-digest attribute contains the hash value that was 1131 calculated in step e (for a ), or that was sent in the input document’s 1132 (for a ). Other signedAttributes may be added 1133 by the server, according to its profile or policy, or according to the optional 1134 input (see section 3.5.5). 1135 c. The remaining fields (sid, signatureAlgorithm, and signature) are filled in as per a 1136 normal CMS signature. 11373. The server creates a CMS signature (i.e. a SignedData structure) containing the SignerInfo that 1138 was created in Step 2. The resulting SignedData should be detached (i.e. external or “without 1139 eContent”) unless the client sends the optional input (see section 3.5.9).

11403.4.1 Process Variant for 1141 In the case of a the processing by the server is as follows: 11421. Omitted. 1143 a. Omitted. 1144 b. Omitted. 1145 c. Omitted. 82oasis-dss-core-spec-v1.0-os 11 April 2007 83Copyright © OASIS® 2007. All Rights Reserved. Page 28 of 62 1146 d. Omitted. 1147 e. Omitted. 11482. Same as in 3.4 step 2 1149 a. Unchanged. 1150 b. Unchanged. 1151 c. Unchanged. 11523. As in 3.4 step 3, with the requirement that the signature has to be external/detached/"without 1153 eContent", since is incompatible with optional input (see 1154 3.5.7).

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

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

11653.5.2 Optional Input 1166The element indicates that the client wishes the server to embed a timestamp token 1167as a property or attribute of the resultant or the supplied signature. The timestamp token will be applied to 1168the signature value in the case of CMS/PKCS7 signatures or the element in the 1169case of XML signatures. 1170Note: Procedures for handling other forms of timestamp may be defined in profiles of the Core. In 1171particular, the DSS AdES profile [DSS-AdES-P] defines procedures for generating timestamps over the 1172content which is about to be signed (sometimes called content timestamps), and the DSS Timestamp 1173profile [DSS-TS-P] defines procedures for handling standalone timestamps. 1174The schema definition of this optional input is as follows: 1175 1176 1177 1178 1179 1181 1182 1183 1184The type UpdateSignatureInstructionType is defined as follows: 1185 1186 1187 1188The Type attribute, if present, indicates what type of timestamp to apply. Profiles that use this optional 1189input MUST define the allowed values, and the default value, for the Type attribute (unless only a single 1190type of timestamp is supported, in which case the Type attribute can be omitted).

85oasis-dss-core-spec-v1.0-os 11 April 2007 86Copyright © OASIS® 2007. All Rights Reserved. Page 29 of 62 1191Two scenarios for the timestamping of both CMS and XML signatures are supported by this Optional 1192Input. They are as follows: 1193a) Create and embed a timestamp token into the signature being created as part of this SignRequest. 1194b) Create and embed a timestamp token into an existing signature, without verification, which is passed in 1195the element of this SignRequest. 1196The following subsections specify the use of RFC 3161 timestamps with CMS signatures and the use of 1197XML Timestamps or RFC 3161 timestamps with XML Signature. These subsections address both 1198scenarios.

11993.5.2.1 Processing for CMS signatures time-stamping 1200In both scenarios, the timestamp token created by the server SHALL be created according to [RFC 3161]. 1201The MessageImprint field within the TstInfo structure of the timestamp token will be derived from the 1202signature value of the just-created or incoming signature depending on the scenario. The timestamp 1203SHALL be embedded in the CMS signature as an unsigned attribute with the object identifier (see 1204Appendix A of [RFC 3161]): 1205{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14} 1206The signature and its embedded timestamp is returned in the of the 1207. 1208In scenario b) the incoming signature is passed in a element, with the MimeType 1209attribute set to application/pkcs7-signature. 1210The Type attribute of the optional input SHALL be set to: 1211 "urn:ietf:rfc:3161". 1212Note: In scenario b) the server SHOULD not verify the signature before adding the timestamp. If a client 1213wishes that its signatures be verified as a condition of time stamping, the client SHOULD use the 1214 optional input of the Verify protocol.

12153.5.2.2 Processing for XML Timestamps on XML signatures 1216If the type attribute in this optional input is 1217urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken and signature being 1218timestamped is an XML signature, then the XML signature MUST contain as defined 1219in 5.1, placed in a within a 1220 as defined in [XAdES]. 1221The MUST contain with at least two 1222elements: 1223- One with the Type attribute set to 1224 "urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken". and referencing a 1225 element whose content is a element. 1226- The other referencing the being timestamped. 1227The present specification defines a format for XML timestamp tokens. In addition XAdES defines a 1228mechanism for incorporating signature timestamps in XML signatures. The present document mandates 1229that signature timestamps in XML format MUST follow the syntax defined in section 5.1 of this document. 1230These time-stamp tokens MUST be added to XML signatures as specified by XAdES. 1231The signature and its embedded timestamp SHALL be returned in the of the 1232. 1233In scenario b) the incoming signature MUST be passed in on one of the following three elements 1234, or .

88oasis-dss-core-spec-v1.0-os 11 April 2007 89Copyright © OASIS® 2007. All Rights Reserved. Page 30 of 62 1235Note: In scenario b) the server SHOULD not verify the signature before adding the timestamp. If a client 1236wishes that its signatures be verified as a condition of time stamping, the client SHOULD use the 1237 optional input of the Verify protocol. 1238The Type attribute of the optional input SHALL be set to: 1239 "urn: oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken”.

12403.5.2.3 Processing for RFC 3161 Timestamps on XML signatures 1241If the type attribute in this optional input is urn:ietf:rfc:3161 and signature being timestamped is an 1242XML signature then the XML signature MUST contain an RFC 3161, placed in a 1243 within a as defined in 1244[XAdES]. 1245In scenario b) the incoming signature MUST be passed in on one of the following three elements 1246, or . 1247Note: In scenario b) the server SHOULD not verify the signature before adding the timestamp. If a client 1248wishes that its signatures be verified as a condition of time stamping, the client SHOULD use the 1249 optional input of the Verify protocol.

12503.5.3 Optional Input 1251The element tells the server who the target audience of this signature is. The 1252server MAY use this to parameterize any aspect of its processing (for example, the server MAY choose to 1253sign with a key that it knows a particular recipient trusts). 1254 1255 1256 1257 1259 1260 1261

12623.5.4 Optional Input 1263The element tells the server which key to use. 1264 1265 1266 1267 1268 1269 1270 1271

12723.5.5 Optional Input 1273The element is used to request that the server add certain signed or unsigned properties 1274(aka “signature attributes”) into the signature. The client can send the server a particular value to use for 1275each property, or leave the value up to the server to determine. The server can add additional properties, 1276even if these aren’t requested by the client. 1277The element contains: 1278 [Optional] 1279 These properties will be covered by the signature.

91oasis-dss-core-spec-v1.0-os 11 April 2007 92Copyright © OASIS® 2007. All Rights Reserved. Page 31 of 62 1280 [Optional] 1281 These properties will not be covered by the signature. 1282Each element contains: 1283 [Required] 1284 A URI reference identifying the property. 1285 [Optional] 1286 If present, the value the server should use for the property. 1287This specification does not define any properties. Profiles that make use of this element MUST define the 1288allowed property URIs and their allowed values. 1289 1290 1291 1292 1294 1296 1297 1298 1299 1300 1301 1302 1303 1304 1305 1306 1307 1308 1309 1310 1312 1313 1314

13153.5.6 Optional Input 1316Optional input is used to request the creation of an XMLSig enveloping signature as 1317follows. Multiple occurrences of this optional input can be present in a single message. 1318Each occurrence will cause the inclusion of an object inside the signature being created. 1319The attributes of are: 1320WhichDocument [Required] 1321 Identifies the input document which will be inserted into the returned signature (see the ID attribute in 1322 section 2.4.1). 1323hasObjectTagsAndAttributesSet 1324 If True indicates that the contains a element which has been prepared 1325 ready for direct inclusion in the . 1326ObjId [optional] 1327 Sets the Id attribute on the returned . 1328createReference

94oasis-dss-core-spec-v1.0-os 11 April 2007 95Copyright © OASIS® 2007. All Rights Reserved. Page 32 of 62 1329 This attribute set to false inhibits the creation, carried by the Basic Processing specified in section 1330 3.3.1, of the associated to the RefURI attribute of the input document referred by 1331 the WhichDocument attribute, effectively allowing clients to include elements not 1332 covered/protected by the signature being created. 1333 1334 1335 1336 1338 1340 1342 1343

13443.5.6.1 XML Signatures Variant Optional Input 1345An enveloping signature is a signature having s which are referenced by 1346s having a same-document URI. 1347For each the server creates a new element containing the document, 1348as identified using the WhichDocument attribute, as its child. This object is carried within the enveloping 1349signature. The ordering of the optional inputs MAY be ignored by the server. 1350This MUST include a “same-document” RefURI attribute (having a value starting with “#”) 1351which references either: 1352 The whole newly-created . 1353 The relevant parts of the newly-created ’s contents to be covered/protected by the 1354 signature (only applicable when the element contains either , 1355 or ) 1356If the result of evaluating the expression included in the RefURI attribute doesn’t fit in any of the options 1357described above, the server MUST reject the request using a RequesterError which 1358MAY be qualified by a 1359urn:oasis:names:tc:dss:1.0:resultminor:InvalidRefURI 1360Note :If the server does not support the ordering of , it is recommended either to use ID- 1361based referencing to the (using the client-generated ID included in the ObjId attribute) or 1362to rely on expressions based on 's contents that allow to unambigously refer to the 1363included object or their relevant parts. 1364The URI in the RefURI attribute of this should at least reference the relevant parts of the 1365Object to be included in the calculation for the corresponding reference. Clients MUST generate requests 1366in a way that some ’s URI values actually will reference the generated 1367by the server once this element will have been included in the produced by the server. 13681. For each the server MUST carry out the following steps before performing Basic 1369 Processing (as specified in section 3.3.1): 1370 a. The server identifies the that is to be placed into a as indicated by 1371 the WhichDocument attribute. 1372 b. The data to be carried in the enveloping signature is extracted and decoded as described in 1373 3.3.1 Step 1 a (or equivalent step in variants of the basic process as defined in 3.3.2 onwards 1374 depending of the form of the input document). 1375 c. if the hasObjectTagsAndAttributesSet attribute is false or not present the server builds the 1376 as follows:

97oasis-dss-core-spec-v1.0-os 11 April 2007 98Copyright © OASIS® 2007. All Rights Reserved. Page 33 of 62 1377 i. The server generates the new and sets its Id attribute to the value 1378 indicated in ObjId attribute of the optional input if present. 1379 ii. In the case of the Document pointed at by WhichDocument having Base64Data, 1380 ('s) MIME Type is to be set to the value of ('s) MIME 1381 Type value and the Encoding is to be set to http://www.w3.org/TR/xmlschema- 1382 2/#base64Binary 1383 d. The server splices the to-be-enveloped documents as (s) into the 1384 , which is to be returned. 1385 e. If CreateReference is set to true generate a ds:Reference element referencing the 1386 spliced and exclude this from the set of s ready for 1387 further processing. Otherwise just exclude this from the set of s 1388 ready for further processing. 13892. The server then continues with processing as specified in section 3.3.1 for the rest of the documents.

13903.5.7 Optional Input 1391In the case of the optional input (that stands for include enveloped or 1392encapsulated content) section 3.4 step 3 is overridden as follows. 13933. The server creates a CMS signature (i.e. a SignedData structure) containing the SignerInfo that 1394 was created in Step 3. The resulting SignedData is now internal, as the document is enveloped in 1395 the signature. 1396For CMS details in this context please refer to [RFC 3852] sections 5.1 “SignedData Type” and 5.2 1397“EncapsulatedContentInfo Type”.

13983.5.8 Enveloped Signatures, Optional Input and 1399 Output 1400Optional input is used to request the creation of an XMLSig enveloped 1401signature placed within an input document. The resulting document with the enveloped signature is 1402placed in the optional output . 1403The server places the signature in the document identified using the WhichDocument attribute. 1404In the case of a non-XML input document then the server will return an error unless alternative 1405procedures are defined by a profile or in the server policy for handling such a situation. 1406The element contains the following attributes and elements: 1407WhichDocument [Required] 1408 Identifies the input document which the signature will be inserted into (see the ID attribute in section 1409 2.4.1). 1410CreateEnvelopedSignature 1411 If this is set to true a reference having an enveloped signature transform is created. 1412 [Optional] 1413 Identifies an element, inside the XML input document, after which the signature will be inserted. (The 1414 rules for XPath evaluation are those stated in section 2.5 SignatureObject) 1415 [Optional] 1416 Identifies an element, in the XML input document, which the signature will be inserted as the first child 1417 of. For details on the evaluation of The XPath expression see above (). The 1418 signature is placed immediately after the start tag of the specified element. 1419 1420

100oasis-dss-core-spec-v1.0-os 11 April 2007 101Copyright © OASIS® 2007. All Rights Reserved. Page 34 of 62 1421 1422 1423 1425 1426 1427 1429 1430 1431The optional output contains the input document with the signature 1432inserted. It has one child element: 1433 [Required] 1434This contains the input document with a signature inserted in some fashion. 1435 1436 1437 1438 1439 1440 1441 1442For an XMLSig enveloped signature the client produces a request including elements set as follows: 14431. The WhichDocument attribute is set to identify the to envelope the signature. 14442. The RefURI attribute MUST be set to include a “same-document” URI which references either: 1445 - The whole containing the signature (by using a RefURI=””) 1446 - The relevant parts of the to be covered/protected by the signature (by using a “same- 1447 document” RefURI attribute having a value starting with “#”, like RefURI=”#some-id”, 1448 RefURI=”#xpointer(/)”, RefURI=”#xpointer(/DocumentElement/ToBeSignedElement)” or the like). 1449 If the result of evaluating the expression included in the RefURI attribute doesn’t fit in any of the 1450 options described above, the server MUST reject the request using a 1451 RequesterError which MAY be qualified by a 1452 urn:oasis:names:tc:dss:1.0:resultminor:InvalidRefURI. 14533. The createEnvelopedSignature is set to true (or simply omitted). 1454If the element is present the server processes it as follows before performing 1455Basic Processing (as specified in section 3.3.1): 14561. The server identifies the in which the signature is to be enveloped as indicated by the 1457 WhichDocument attribute. 14582. This document is extracted and decoded as described in 3.3.1 Step 1.a (or equivalent step in variants 1459 of the basic process as defined in 3.3.2 onwards depending of the form of the input document). 14603. The server splices the to-be-enveloped into the document. 14614. If createEnvelopedSignature equals true, 1462 a. Perform Basic Processing for the enveloping , as described in section 3.3.1 with the 1463 following amendments: 1464 1. 1465 a. Omitted 1466 b. As in 3.3.1 1.b, with the additional requirement of adding an 1467 EnvelopedSignatureTransform as the first transform in the list 1468 (even preceding transforms used for extraction). 1469 Note: This is necessary because the EnvelopedSignatureTransform would not work 1470 if there was a Canonicalization before it. Similar problems apply to transforms using the

103oasis-dss-core-spec-v1.0-os 11 April 2007 104Copyright © OASIS® 2007. All Rights Reserved. Page 35 of 62 1471 here() function. If such are to be supported, the use of Base64XML or EscapedXML MAY 1472 be required. 1473 c. Unchanged 1474 d. Unchanged 1475 i. Unchanged 1476 ii. Unchanged 1477 iii. Unchanged 1478 iv. Unchanged 1479 v. Unchanged (Note: the requirement imposed in 1.b of having the 1480 EnvelopedSignatureTransform as the first transform in the 1481 list MUST be observed). 1482 2. Omitted 1483 3. Omitted 1484 b. After creating the due to the modified Basic Processing, make it available for 1485 the Basic Processing, as required in 3.3.1 Step 2. 14865. Add the returned as required in 3.3.1 Step 2 of Basic processing.

14873.5.9 Optional Input 1488The element gives the client greater control over how the 1489elements are formed. When this element is present, step 1 of Basic Processing (section 3.3.1) is 1490overridden. Instead of there being a one-to-one correspondence between input documents and 1491 elements, now each element controls the creation of a 1492corresponding . 1493Since each refers to an input document, this allows multiple 1494elements to be based on a single input document. Furthermore, the client can request additional 1495transforms to be applied to each , and can set each element’s Id 1496or URI attribute. These aspects of the can only be set through the 1497 optional input; they cannot be set through the input documents, since they are 1498aspects of the reference to the input document, not the input document itself. 1499Each element contains: 1500WhichDocument [Required] 1501 Which input document this reference refers to (see the ID attribute in section 2.4.1). 1502RefId [Optional] 1503 Sets the Id attribute of the corresponding . 1504RefURI [Optional] 1505 If this attribute is present, the corresponding element’s URI attribute is set to its 1506 value. If it is not present, the URI attribute is omitted in the corresponding 1507RefType [Optional] 1508 overrides the RefType of 1509 [Optional] 1510 Requests the server to perform additional transforms on this reference. 1511 When the optional input is present, basic processing 3.3.1 step 1 is 1512 performed for each overriding steps a., b., c. and d.: 1513If the element is present the server processes it as follows:

106oasis-dss-core-spec-v1.0-os 11 April 2007 107Copyright © OASIS® 2007. All Rights Reserved. Page 36 of 62 1514 For each in 15151. The server identifies the referenced as indicated by the WhichDocument attribute. 15162. If RefURI is present create an additional for the document in question by 1517 performing basic processing as in section 3.3.1 Step 1 amended as follows: 1518 1. 1519 a. Unchanged. 1520 b. Applies the transforms indicated in . Afterwards, the server may apply 1521 any other transform it considers appropriate as per its policy and then generates a 1522 canonicalized octet string as required in step b. of basic Processing before hashing. 1523 c. Unchanged. 1524 d. The server forms a with the elements and attributes set as follows: 1525 i. Use this RefURI attribute from the if present instead of 1526 RefURI from in step i. of Basic Processing. 1527 The Id attribute is set to the element’s RefId attribute. If the 1528 has no RefId attribute, the element’s 1529 Id attribute is omitted. 1530 ii. Unchanged. 1531 iii. Unchanged. 1532 iv. Unchanged. 1533 v. The used here will have to be added to of 1534 step v. of basic processing so that this element describes the sequence of transforms 1535 applied by the server and describing the effective transform as a reproducible 1536 procedure from parsing until hash. 1537 2. Add the returned as required in 3.3.1 Step 2 of Basic processing. 15383. If RefURI is not present perform basic processing for the input document not creating an additional 1539 amending Step 1 as follows: 1540 1. 1541 a. Unchanged. 1542 b. Applies the transforms indicated in . Afterwards, the server may apply 1543 any other transform it considers as appropriate as per its policy and then generates 1544 generating a canonicalized octet string as required in step b. of basic Processing before 1545 hashing. 1546 c. Unchanged. 1547 d. The server forms a with the elements and attributes set as follows: 1548 i. Perform step i. of Basic Processing and the Id attribute is set to the 1549 element’s RefId attribute. If the has 1550 no RefId attribute, the element’s Id attribute is omitted. 1551 ii. Unchanged 1552 iii. Unchanged 1553 iv. Unchanged 1554 v. The used here will have to be added to of 1555 step v. of basic processing so that this element describes the sequence of transforms 1556 applied by the server and describing the effective transform as a reproducible 1557 procedure from parsing until hash. 15584. The server continues with processing as specified in section 3.3.1 for the rest of the documents.

109oasis-dss-core-spec-v1.0-os 11 April 2007 110Copyright © OASIS® 2007. All Rights Reserved. Page 37 of 62 1559 1560 1561 1562 1564 1565 1566 1567 1568 1569 1570 1571 1572 1573 1574 1575 1576 1577

112oasis-dss-core-spec-v1.0-os 11 April 2007 113Copyright © OASIS® 2007. All Rights Reserved. Page 38 of 62 15784 The DSS Verifying Protocol

15794.1 Element 1580The inherits from . This element is sent by the client to verify 1581a signature or timestamp on some input documents. It contains the following additional elements: 1582 [Optional] 1583 This element contains a signature or timestamp, or else contains a that points to 1584 an XML signature in one of the input documents. If this element is omitted, there must be only a single 1585 which the server will search to find the to-be-verified signature(s). Either a 1586 or a single and no MUST be used 1587 whenever the to-be-verified signature is an XML signature which uses an Enveloped Signature 1588 Transform; otherwise the server would have difficulty locating the signature and applying the 1589 Enveloped Signature Transform. 1590 1591 1592 1593 1594 1595 1596 1597 1598 1599 1600

16014.2 Element 1602The inherits from . This element defines no additional 1603attributes and elements. 1604

16054.3 Basic Processing for XML Signatures 1606A DSS server that verifies XML signatures SHOULD perform the following steps, upon receiving a 1607. These steps may be changed or overridden by the optional inputs, or by the profile 1608or policy the server is operating under. For more details on multi-signature verification, see section 4.3.1. 16091. The server retrieves one or more objects, as follows: If the 1610 is present, the server retrieves either the that is a child 1611 element of the (see: Note at the end of this section), or those 1612 objects which are pointed to by the in the 1613 . 1614 a. If the points to an input document but not a specific element in that document, 1615 the pointed-to input document must be a element containing XML either in an 1616 , or element. 1617 If the document is inside or it is decoded and parsed as 1618 described in 3.3.1 Step 1.a or 3.3.3 Step 1a respectively. 1619 If the document is inside the document is extracted using exclusive 1620 canonicalization. The corresponding to the document MUST have a

115oasis-dss-core-spec-v1.0-os 11 April 2007 116Copyright © OASIS® 2007. All Rights Reserved. Page 39 of 62 1621 chain of transforms (at least one ds:Transform inside ds:Transforms) that anticipates 1622 and reflects this. If this is not the case the server MUST throw an Error 1623 (urn:oasis:names:tc:dss:1.0:resultminor:inappropriate:signature). 1624 Note: Otherwise false negatives due to namespace conflicts may appear. 1625 b. If the is omitted, there MUST be only a single element. 1626 This case is handled as if a pointing to the single was 1627 present: the server will search and find every element in this input 1628 document, and verify each according to the steps below. 16292. For each in the , the server finds the input document with 1630 matching RefURI and RefType values (omitted attributes match omitted attributes). If the 1631 uses a same-document URI, the XPointer should be evaluated against the input 1632 document the is contained within, or against the itself if it is 1633 contained within the element. The element or optional input 1634 of the input document or will be used, if present, to identify ID 1635 attributes when evaluating the XPointer expression. If the uses an external URI 1636 and the corresponding input document is not present, the server will skip the , and 1637 later return a result code such as ReferencedDocumentNotPresent to indicate this. The RefURI 1638 MAY be omitted in at most one of the set of Input documents. 1639 a. If the input document is a , the server extracts and decodes as described in 1640 3.3.1 Step 1.a (or equivalent step in variants of the basic process as defined in 3.3.2 onwards 1641 depending of the form of the input document). 1642 b. If the input document is a , the server MAY check that the 1643 (if supplied) match between the and the 1644 and then hashes the resultant data object according to 1645 , and MUST check that the result matches . 1646 c. If the input document is a , the server MAY check that the 1647 , (if supplied) and elements 1648 match between the and the . 1649 d. If the combination of RefURI and RefType matches more than one input document all of 1650 them MUST be either a or a otherwise a 1651 RequesterError is issued qualified by result minor of 1652 ReferencedDocumentNotPresent. 1653 Only one of them is allowed to have a WhichReference value that matches the order of the 1654 within the in question otherwise a RequesterError 1655 is issued qualified by result minor of ReferencedDocumentNotPresent. Using this input 1656 document either variant b. or c. is applied respectively before continuing with step 3. 16573. The server shall verify the validity of the signature at a particular time (i.e. current time, assumed 1658 signing time or other time), depending on the server policy. This behaviour MAY be altered by using 1659 the optional input (see section 4.5.2). 16604. If the signature validates correctly, the server returns one of the first three codes 1661 listed in section 4.4, depending on the relationship of the signature to the input documents (not 1662 including the relationship of the signature to those XML elements that were resolved through XPointer 1663 evaluation; the client will have to inspect those relationships manually). If the signature fails to 1664 validate correctly, the server returns some other code; either one defined in section 4.4 of this 1665 specification, or one defined by some profile of this specification. 1666Note: The extraction of the from the should be performed 1667without namespace inheritance. If the signature does not use exclusive 1668canonicalization for it's there can appear problems caused by 1669namespace declarations moved by gateways or protocol processors of outer protocol bindings that alter 1670the signature object and cause false negatives on validation. Problems appearing due to different

118oasis-dss-core-spec-v1.0-os 11 April 2007 119Copyright © OASIS® 2007. All Rights Reserved. Page 40 of 62 1671behavior of xml parsers in schema validating parsing vs. non-validating parsing like data type 1672normalizations would have to be healed by canonicalization only as no transforms are available for 1673ds:SignedInfo. As currently available specifications of canonicalization are not aware of schema data 1674types a solution to heal these defects is currently not possible. Beware, these problems can already occur 1675on parsing the whole request including protocol bindings like SOAP. Implementors are encouraged to 1676make use of or instead.

16774.3.1 Multi-Signature Verification 1678If a client requests verification of an entire input document, either using a without an 1679 or a missing (see section 4.3 step 1), then the server MUST determine 1680whether the input document contains zero, one, or more than one elements. If zero, 1681the server should return a code of RequesterError. 1682If more than one elements are present, the server MUST either reject the request with 1683a code of RequesterError and a code of NotSupported, or 1684accept the request and try to verify all of the signatures. 1685If the server accepts the request in the multi-signature case (or if only a single signature is present) and 1686one of the signatures fails to verify, the server should return one of the error codes in section 4.4, 1687reflecting the first error encountered. 1688If all of the signatures verify correctly, the server should return the Success code and 1689the following code: 1690urn:oasis:names:tc:dss:1.0:resultminor:ValidMultiSignatures 1691 Note: These procedures only define procedures for handling of multiple signatures on 1692 one input document. The procedures for handling multiple signatures on multiple 1693 documents are not defined in this core specification, but however such procedures, along 1694 with any optional elements that may be required, may be defined in profiles of this 1695 specification. 1696Only certain optional inputs and outputs are allowed when performing multi-signature verification. See 1697section 4.6 for details.

16984.3.2 Signature Timestamp verification procedure 1699The following sub-sections will describe the processing rules for verifying: 1700- RFC 3161 timestamp tokens on CMS Signatures 1701- XML timestamp tokens on XML Signatures 1702- RFC 3161 timestamp tokens on XML Signatures 1703This section describes signature timestamp processing when the timestamp is embedded in the incoming 1704signature. 1705Note: procedures for handling other forms of timestamp may be defined in profiles of the Core. In 1706particular, the DSS AdES profile [DSS-AdES-P] defines procedures for handling timestamps against the 1707document being signed, and the DSS Timestamp profile defines procedures for handling standalone 1708timestamps. 1709For a definition of the element see section 5.1 Details of the XML timestamp token can be 1710found in subsection 5.1.1.

17114.3.2.1 Processing for RFC 3161 Timestamp tokens on CMS Signatures. 1712The present section describes the processing rules for verifying a CMS RFC3161 timestamp token 1713passed in on a Verify call within the of the element. In the 1714CMS case, since the "signature timestamp" is embedded in the signature as an unsigned attribute, only 1715the time stamped signature is required for verification processing. As such, no additional input is required.

121oasis-dss-core-spec-v1.0-os 11 April 2007 122Copyright © OASIS® 2007. All Rights Reserved. Page 41 of 62 1716The processing by the server is broken down into the following steps: 17171. The signature timestamp is embedded in the incoming signature as an unsigned attribute whose 1718 object identifier is 1.2.840.11359.1.9.16.2.14. Extract and verify the timestamp token. 17192. Verify that the token's public verification certificate is authorized for time stamping by examining the 1720 Extended Key Usage field for the presence of the time stamping OID "1.3.6.1.5.5.7.3.8". 17213. Validate that the TstInfo structure has a valid layout as defined in [RFC 3161]. 17224. Extract the MessageImprint hash value and associated algorithm from the TstInfo structure 1723 which will be compared against the hash value derived in the next step. 17245. Recalculate the hash of the signature value field of the signature in which the timestamp is 1725 embedded. 17266. Compare the hash values from the two previous steps, and if they are equivalent, then this timestamp 1727 is valid for the signature that was time stamped. 17287. Verify that the public verification certificate conforms to all relevant aspects of the relying-party's 1729 policy including algorithm usage, policy OIDs, time accuracy tolerances, and the Nonce value. 17308. Set the dss:Result element as defined in this specification. Minor Error 1731 urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTim 1732 estamp MAY be used to indicate that the signature is valid but the timestamp against that signature 1733 is invalid.

17344.3.2.2 Processing for XML timestamp tokens on XML signatures 1735The present section describes the processing rules for verifying and XML Signature timestamp token 1736embedded within an XML signature using the incorporation mechanisms specified in XAdES (i.e., in the 1737 element's child). This XML signature may 1738be passed in on a Verify call within the or embedded within a ’s 1739child. 1740The server shall verify the timestamp token performing the steps detailed below. If any one of them 1741results in failure, then the timestamp token SHOULD be rejected. 17429. Extract the timestamp token embedded in the incoming signature as defined in 3.5.2.2. 174310. Verify that the verification key and algorithms used conforms to all relevant aspects of the applicable 1744 policy. Should this key come within a public certificate, verify that the certificate conforms to all 1745 relevant aspects of the applicable policy including algorithm usage, policy OIDs, and time accuracy 1746 tolerances. 174711. Verify that the aforementioned verification key is consistent with the 1748 ds:SignedInfo/SignatureMethod/@Algorithm attribute value. 174912. Verify the timestamp token signature in accordance with the rules defined in [XMLDSIG]. 175013. Verify that the element contains at least two elements. 175114. Verify that one of the elements has its Type attribute set to 1752 “urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken”. Take this one and proceed as 1753 indicated below: 1754 a. Retrieve the referenced data object. Verify that it references a element, which 1755 in turn envelopes a element. 1756 b. Verify that the element has a valid layout as per the present specification. 1757 c. Extract the digest value and associated algorithm from its and 1758 elements respectively. 1759 d. Recalculate the digest of the retrieved data object as specified by [XMLDSIG] with the digest 1760 algorithm indicated in , and compare this result with the contents of 1761 .

124oasis-dss-core-spec-v1.0-os 11 April 2007 125Copyright © OASIS® 2007. All Rights Reserved. Page 42 of 62 176215. Take each of the other elements and for each validate the hash as specified in 1763 [XMLDSIG]. 176416. Check that for one of the elements the retrieved data object is actually the 1765 element and that it contains its digest after canonicalization. 176617. Set the element as appropriate. Minor Error 1767 urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTim 1768 estamp MAY be used to indicate that the signature is valid but the timestamp against that signature 1769 is invalid.

17704.3.2.3 Processing for RFC 3161 timestamp tokens on XML Signatures 1771The present section describes the processing rules for verifying an RFC 3161 timestamp token 1772embedded within an XML signature as an unsigned property. This XML signature may be passed in on a 1773Verify call within the or embedded within a ’s child. 1774The server shall verify the timestamp token performing the steps detailed below. If any one of them 1775results in failure, then the timestamp token SHOULD be rejected. 177618. Extract the timestamp token embedded in the incoming signature as defined in 3.5.2.3. 177719. Verify that the token's public verification certificate is authorized for time stamping by examining the 1778 Extended Key Usage field for the presence of the time stamping OID "1.3.6.1.5.5.7.3.8". 177920. Process the signature timestamp as defined in [XAdES] Annex G.2.2.16.1.3. 178021. Verify that the public verification certificate conforms to all relevant aspects of the relying-party's 1781 policy including algorithm usage, policy OIDs, time accuracy tolerances, and the Nonce value. 178222. Set the dss:Result element as appropriate. 1783 urn:oasis:names:tc:dss:1.0:resultminor:valid:signature:InvalidSignatureTim 1784 estamp MAY be used to indicate that the signature is valid but the timestamp against that signature 1785 is invalid.

17864.4 Basic Processing for CMS Signatures 1787A DSS server that verifies CMS signatures SHOULD perform the following steps, upon receiving a 1788. These steps may be changed or overridden by the optional inputs, or by the profile 1789or policy the server is operating under. 17901. The server retrieves the CMS signature by decoding the child of 1791 . 17922. The server retrieves the input data. If the CMS signature is detached, there must be a single input 1793 document: i.e. a single or element. Otherwise, if the CMS signature 1794 is enveloping, it contains its own input data and there MUST NOT be any input documents present. 17953. The CMS signature and input data are verified in the conventional way (see [RFC 3852] for details). 17964. If the signature validates correctly, the server returns the first code listed in section 1797 4.4. If the signature fails to validate correctly, the server returns some other code; either one defined 1798 in section 4.4 of this specification, or one defined by some profile of this specification.

17994.5 Optional Inputs and Outputs 1800This section defines some optional inputs and outputs that profiles of the DSS verifying protocol might find 1801useful. Section 2.8 defines some common optional inputs that can also be used with the verifying 1802protocol. Profiles of the verifying protocol can define their own optional inputs and outputs, as well. 1803General handling of optional inputs and outputs is discussed in section 2.7.

127oasis-dss-core-spec-v1.0-os 11 April 2007 128Copyright © OASIS® 2007. All Rights Reserved. Page 43 of 62 18044.5.1 Optional Input and Output 1805The presence of this element instructs the server to validate manifests in an XML signature. 1806On encountering such a document in step 2 of basic processing, the server shall repeat step 2 for all the 1807 elements within the manifest. In accordance with [XMLDSIG] section 5.1, DSS 1808Manifest validation does not affect a signature's core validation. The results of verifying individual 1809's within a are returned in the 1810optional output. 1811For example, a client supplies the optional input , then the returned 1812 is 1813urn:oasis:names:tc:dss:1.0:resultminor:valid:hasManifestResults if XMLSig core 1814validation succeeds and the optional output is returned indicating the 1815status of the manifest reference verification. In case of a negative XMLSig core validation no attempt is 1816made to verify manifests. 1817The optional input is allowed in multi-signature verification. The 1818 is comprised of one or more s that contain the 1819following: 1820 [Required] 1821 Identifies the manifest reference, in the XML signature, to which this result pertains. 1822 [Required] 1823 Indicates the manifest validation result. It takes one of the values 1824 urn:oasis:names:tc:dss:1.0:manifeststatus:Valid or urn:oasis:names:tc:dss:1.0:manifeststatus:Invalid. 1825 1827 1828 1829 1830 1831 1832 1833 1834 1835 1836 1837 1838 1839 1840 1841

18424.5.2 Optional Input 1843This element instructs the server to attempt to determine the signature’s validity at the specified time, 1844instead of a time determined by the server policy. 1845Note: In order to perform the verification of the signature at a certain time, the server MUST obtain the 1846information necessary to carry out this verification (e.g. CA certificates, CRLs) applicable at that time. 1847 [Optional] 1848 Instructs the server to use its current time (normally the time associated with the server-side request 1849 processing). 1850 [Optional] 1851 Allows the client to manage manually the time instant used in the verification process. It SHOULD be 1852 expressed as UTC time (Coordinated Universal Time) to reduce confusion with the local time zone 1853 use. 130oasis-dss-core-spec-v1.0-os 11 April 2007 131Copyright © OASIS® 2007. All Rights Reserved. Page 44 of 62 1854Profiles MAY define new child elements associated to other different behaviors. 1855 1856 1857 1858 1859 1860 1861 1862 1863If the verification time is a significant period in the past the server MAY need to take specific steps for this, 1864and MAY need to ensure that any cryptographic weaknesses over the period do not affect the validation. 1865This optional input is allowed in multi-signature verification.

18664.5.3 Optional Input/Output / 1867 1868This element allows the client to obtain the time instant used by the server to validate the signature. 1869 1870Optionally, in addition to the verification time, the server MAY include in the 1871response any other relevant time instants that may have been used when determining the verification 1872time or that may be useful for its qualification. 1873 [Required] 1874 The time instant used by the server when verifying the signature. It SHOULD be expressed as UTC 1875 time (Coordinated Universal Time) to reduce confusion with the local time zone use. 1876 [Optional] 1877 Any other time instant(s) relevant in the context of the verification time determination. 1878The Type attribute qualifies the kind of time information included in the response. The Ref attribute allows 1879to establish references to the source of the time information, and SHOULD be used when there is a need 1880to disambiguate several elements with the same Type attribute. 1881This specification defines the following base types, whose values MUST be of type xs:dateTime and 1882SHOULD be expressed as UTC time (Coordinated Universal Time). Profiles MAY include and define new 1883values for the Type attribute. 1884urn:oasis:names:tc:dss:1.0:additionaltimeinfo:signatureTimestamp 1885 The time carried inside a timestamp applied over the signature value. 1886urn:oasis:names:tc:dss:1.0:additionaltimeinfo:signatureTimemark 1887 The time instant associated to the signature stored in a secure record in the server. 1888urn:oasis:names:tc:dss:1.0:additionaltimeinfo:signedObjectTimestamp 1889 The time carried inside a timestamp applied over a signed object. 1890Note that XML Signatures can be produced over multiple objects (via multiple ds:Reference 1891elements), and therefore it's possible to have multiple timestamps, each one applied over each object. 1892In this case, the Ref attribute MUST include the value of the Id attribute of the ds:Reference element. 1893urn:oasis:names:tc:dss:1.0:additionaltimeinfo:claimedSigningTime 1894 The time claimed by the signer to be the signature creation time. 1895 1896 1897 1898 1899

133oasis-dss-core-spec-v1.0-os 11 April 2007 134Copyright © OASIS® 2007. All Rights Reserved. Page 45 of 62 1900 1901 1902 1903 1904 1906 1907 1908 1909 1911 1912 1913In the case of multi-signature verification, it’s a matter of server policy as to whether this element is 1914supported. 1915This optional input is not allowed in multi-signature verification.

19164.5.4 Optional Input 1917This element provides the server with additional data (such as certificates and CRLs) which it can use to 1918validate the signature. 1919This optional input is not allowed in multi-signature verification. 1920 1921 1922 1923 1924 1925 1926

19274.5.5 Optional Input and Output 1928 1929The presence of the optional input instructs the server to return a 1930 output. 1931These options are not allowed in multi-signature verification. 1932 1933The optional output elaborates on what signature verification steps succeeded 1934or failed. It may contain the following child elements: 1935 [Any Number] 1936 A verification detail that was evaluated and found to be valid. 1937 [Any Number] 1938 A verification detail that could not be evaluated or was evaluated and returned an indeterminate result. 1939 [Any Number] 1940 A verification detail that was evaluated and found to be invalid. 1941 1942 1943 1944 1946

136oasis-dss-core-spec-v1.0-os 11 April 2007 137Copyright © OASIS® 2007. All Rights Reserved. Page 46 of 62 1947 type=”dss:DetailType” 1948 minOccurs=”0” maxOccurs=”unbounded”/> 1949 1951 1952 1953 1954Each detail element is of type dss:DetailType. A dss:DetailType contains the following child 1955elements and attributes: 1956Type [Required] 1957 A URI which identifies the detail. It may be a value defined by this specification, or a value defined by 1958 some other specification. For the values defined by this specification, see below. 1959Multiple detail elements of the same Type may appear in a single . For 1960example, when a signature contains a certificate chain that certifies the signing key, there may be details 1961of the same Type present for each certificate in the chain, describing how each certificate was processed. 1962 [Optional] 1963 A URI which more precisely specifies why this detail is valid, invalid, or indeterminate. It must be a 1964 value defined by some other specification, since this specification defines no values for this element. 1965 [Optional] 1966 A human-readable message which MAY be logged, used for debugging, etc. 1967 1968 1969 1970 1972 1974 1975 1976 1977The values for the Type attribute defined by this specification are the following: 1978urn:oasis:names:tc:dss:1.0:detail:IssuerTrust 1979 Whether the issuer of trust information for the signing key (or one of the certifying keys) is considered 1980 to be trustworthy. 1981urn:oasis:names:tc:dss:1.0:detail:RevocationStatus 1982 Whether the trust information for the signing key (or one of the certifying keys) is revoked. 1983urn:oasis:names:tc:dss:1.0:detail:ValidityInterval 1984 Whether the trust information for the signing key (or one of the certifying keys) is within its validity 1985 interval. 1986urn:oasis:names:tc:dss:1.0:detail:Signature 1987 Whether the document signature (or one of the certifying signatures) verifies correctly. 1988urn:oasis:names:tc:dss:1.0:detail:ManifestReference 1989 Whether a manifest reference in the XML signature verified correctly.

19904.5.6 Optional Input and Output 1991 1992This element allows the client to obtain the time instant associated to the signature creation.

139oasis-dss-core-spec-v1.0-os 11 April 2007 140Copyright © OASIS® 2007. All Rights Reserved. Page 47 of 62 1993Note: The signing time may be derived, for example, from a claimed signing time signed signature 1994attribute. 1995 1996Sometimes, depending on the applicable server policy, this signing time needs to be qualified, in order to 1997avoid unacceptable measurement errors or false claims, using time boundaries associated to trustworthy 1998time values (based on timestamps or time-marks created using trusted time sources). In this case, the 1999server MAY include these values in the and elements, 2000respectively. 2001Criteria for determining when a time instant can be considered trustworthy and for determining the 2002maximum acceptable delays between the signing time and their boundaries (if any) is outside the scope 2003of this specification. 2004When there's no way for the server to determine the signing time, the server MUST omit the 2005 output. 2006 [Required] 2007 The time value considered by the server to be the signature creation time. 2008 [Optional] 2009 The trusted time values considered as lower and upper limits for the signing time. If this element is 2010 present, at least one of the and elements MUST be 2011 present. 2012 2013 2014 2015 2016 2017 2018 2019 2021 2023 2024 2025 2026 2027 2028This optional input is not allowed in multi-signature verification.

20294.5.7 Optional Input and Output 2030The presence of the optional input instructs the server to return a 2031 output. 2032This optional input and output are not allowed in multi-signature verification. 2033 2034The optional output contains an indication of who performed the signature. 2035

142oasis-dss-core-spec-v1.0-os 11 April 2007 143Copyright © OASIS® 2007. All Rights Reserved. Page 48 of 62 20364.5.8 Optional Input and Outputs 2037 , 2038The presence of the optional input instructs the server to return an 2039 output, containing a new or updated signature. 2040The Type attribute on , if present, defines exactly what it means to 2041“update” a signature. For example, the updated signature may be the original signature with some 2042additional unsigned signature properties added to it (such as timestamps, counter-signatures, or 2043additional information for use in verification), or the updated signature could be an entirely new signature 2044calculated on the same input documents as the input signature. Profiles that use this optional input 2045MUST define the allowed values and their semantics, and the default value, for the Type attribute (unless 2046only a single type of updated signature is supported, in which case the Type attribute can be omitted). 2047Multiple occurrences of this optional input can be present in a single verify request message. If multiple 2048occurrences are present, each occurrence MUST have a different Type attribute. Each occurrence will 2049generate a corresponding optional output. These optional outputs SHALL be distinguishable based on 2050their Type attribute, which will match each output with an input. 2051/ [Optional] 2052 The resulting updated signature or timestamp or, in the case of a signature being enveloped in an 2053 output document, a pointer to the signature. This is used in steps 2. and 3. in the processing 2054 described below.These options are not allowed in multi-signature verification. 2055 2056 2057 2058 2059 2060The optional output contains the returned signature. 2061 2062The is as follows. 2063 2064 2065 2066 2067 2068 2069A DSS server SHOULD perform the following steps, upon receiving a . 2070These steps may be changed or overridden by a profile or policy the server is operating under. (e.g For 2071PDF documents enveloping cms signatures) 20721. If the signature to be verified and updated appears within a 's 2073 (detached or enveloping) or then the 2074 optional ouput MUST contain the modified with the 2075 corresponding (detached or enveloping) or child 2076 containing the updated signature. 20772. If the signature to be verified and updated is enveloped, and if the contains a 2078 with a pointing to an (, 2079 , ) enveloping the signature then the server MUST produce the 2080 following TWO optional outputs, first a optional output containing the 2081 document that envelopes the updated signature, second an optional output 2082 containing a having a element that MUST point to the 2083 former .

145oasis-dss-core-spec-v1.0-os 11 April 2007 146Copyright © OASIS® 2007. All Rights Reserved. Page 49 of 62 20843. If there is no at all in the request then the server MUST produce only a 2085 optional output containing the document with the updated signature. 2086 No element will be generated. 2087As appears in steps 2. and 3. of the processing above it is explained 2088here again: 2089The optional output (for the schema refer to section 3.5.8) contains the 2090input document with the given signature inserted. 2091It has one child element: 2092 [Required] 2093 This returns the given document with a signature inserted in some fashion. 2094The resulting document with the updated enveloped signature is placed in the optional output 2095. The server places the signature in the document identified using the 2096/'s WhichDocument attribute. 2097This MUST include a same-documentRefURI attribute which references the data updated 2098(e.g of the form RefURI).

20994.5.9 Optional Input and Output 2100 2101The optional input instructs the server to return an input document to 2102which the XML signature transforms specified by a particular have been applied. The 2103 is indicated by the zero-based WhichReference attribute (0 means the first 2104 in the signature, 1 means the second, and so on). Multiple occurrences of this 2105optional input can be present in a single verify request message. Each occurrence will generate a 2106corresponding optional output. 2107These options are not allowed in multi-signature verification. 2108 2109 2110 2112 2113 2114The optional output contains a document corresponding to the specified 2115, after all the transforms in the reference have been applied. In other words, the hash 2116value of the returned document should equal the element’s . To 2117match outputs to inputs, each will contain a WhichReference attribute 2118which matches the corresponding optional input. 2119 2120 2121 2122 2123 2124 2125 2127

148oasis-dss-core-spec-v1.0-os 11 April 2007 149Copyright © OASIS® 2007. All Rights Reserved. Page 50 of 62 21284.5.10 Optional Input and Outputs 2129 , 2130The element within a message indicates that 2131the client wishes the server to update the signature after its verification by embedding a signature 2132timestamp token as an unauthenticated attribute (see "unauthAttrs" in section 9.1 [RFC 3852]) or 2133*unsigned* property (see section 6.2.5 "The UnsignedSignatureProperties element" and section 7.3 "The 2134SignatureTimeStamp element" [XAdES]) of the supplied signature. 2135The timestamp token will be on the signature value in the case of CMS/PKCS7signatures or the 2136 element in the case of XML signatures. 2137The Type attribute, if present, indicates what type of timestamp to apply. This document defines two 2138values for it, namely: 2139a. urn:ietf:rfc:3161 for generating a RFC 3161 timestamp token on the signature 2140b. urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken, for generating a XML 2141 timestamp token as defined in section 5 of this document. 2142Profiles that use this optional input MUST define the allowed values, and the default value, for the Type 2143attribute (unless only a single type of timestamp is supported, in which case the Type attribute can be 2144omitted). 2145Below follows the schema definition for these elements. 2146 2148 2149 2150 2151 2152 2153 2154 2155 2156 2157A DSS server SHOULD perform the steps 1. - 3. as indicated in 4.5.8 upon receiving a 2158 replacing by 2159. 2160Procedures for handling RFC 3161 and XML timestamps are as defined in 3.5.2.3 and 3.5.2.2. 2161Note: Procedures for handling other forms of timestamp may be defined in profiles of the Core. In 2162particular, the DSS XAdES profile [DSS-XAdES-P] defines procedures for handling timestamps against 2163the document being signed, and the DSS Timestamp profile [DSS-TS-P] defines procedures for handling 2164standalone timestamps.

151oasis-dss-core-spec-v1.0-os 11 April 2007 152Copyright © OASIS® 2007. All Rights Reserved. Page 51 of 62 21655 DSS Core Elements 2166This section defines two XML elements that may be used in conjunction with the DSS core protocols.

21675.1 Element 2168This section defines an XML timestamp. A contains some type of timestamp token, such 2169as an RFC 3161 TimeStampToken [RFC 3161] or a (aka an “XML timestamp token”) 2170(see section 5.1.1). Profiles may introduce additional types of timestamp tokens. Standalone XML 2171timestamps can be produced and verified using the timestamping profile of the DSS core protocols [XML- 2172TSP]. 2173An XML timestamp may contain: 2174 [Optional] 2175 This is an enveloping XML signature, as defined in section 5.1.1. 2176 [Optional] 2177 This is a base64-encoded TimeStampToken as defined in [RFC3161].

2178 2179 2180 2181 2182 2184 2185 2186 2187

21885.1.1 XML Timestamp Token 2189An XML timestamp token is similar to an RFC 3161 TimeStampToken, but is encoded as a 2190element (see section 5.1.2) inside an enveloping . This allows conventional XML 2191signature implementations to validate the signature, though additional processing is still required to 2192validate the timestamp properties (see section 4.3.2.2). 2193The following text describes how the child elements of the MUST be used: 2194 [Required] 2195 The element SHALL identify the issuer of the timestamp and MAY be used to 2196 locate, retrieve and validate the timestamp token signature-verification key. The exact details of 2197 this element may be specified further in a profile. 2198/ [Required] 2199 There MUST be a single element whose URI attribute references the 2200 containing the enveloped element, and whose Type attribute is equal 2201 to urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken. 2202 [Required] 2203 A element SHALL be contained in a element. 2204Additional elements MUST appear for data objects [XMLDSIG] being time-stamped. 2205For details on further use of time-stamps, please refer to appropriate profiles.

154oasis-dss-core-spec-v1.0-os 11 April 2007 155Copyright © OASIS® 2007. All Rights Reserved. Page 52 of 62 22065.1.2 Element 2207A element is included in an XML timestamp token as a / 2208 child element. A element has the following children: 2209 [Required] 2210 This element SHALL contain a serial number produced by the timestamp authority (TSA). It 2211 MUST be unique across all the tokens issued by a particular TSA. 2212 [Required] 2213 The time at which the token was issued. 2214 [Optional] 2215 This element SHALL identify the policy under which the token was issued. The TSA’s policy 2216 SHOULD identify the fundamental source of its time. 2217 [Optional] 2218 The TSA’s estimate of the maximum error in its local clock. 2219 [Default=”false”] 2220 This element SHALL indicate whether or not timestamps issued by this TSA, under this policy, 2221 are strictly ordered according to the value of the CreationTime element value. 2222TSA [Optional] 2223 The name of the TSA.

2224 2225 2226 2227 2228 2229 2230 2232 2234 2236 2237 2238

22395.2 Element 2240This section contains the definition of an XML Requester Identity element. This element can be used as a 2241signature property in an XML signature to identify the client who requested the signature. 2242This element has the following children: 2243Name [Required] 2244 The name or role of the requester who requested the signature be performed. 2245SupportingInfo [Optional] 2246 Information supporting the name (such as a SAML Assertion [SAMLCore1.1], Liberty Alliance 2247 Authentication Context, or X.509 Certificate). 2248The following schema fragment defines the element: 2249 2250

157oasis-dss-core-spec-v1.0-os 11 April 2007 158Copyright © OASIS® 2007. All Rights Reserved. Page 53 of 62 2251 2252 2253 2255 2256 2257

160oasis-dss-core-spec-v1.0-os 11 April 2007 161Copyright © OASIS® 2007. All Rights Reserved. Page 54 of 62 22586 DSS Core Bindings 2259Mappings from DSS messages into standard communications protocols are called DSS bindings. 2260Transport bindings specify how DSS messages are encoded and carried over some lower-level transport 2261protocol. Security bindings specify how confidentiality, authentication, and integrity can be achieved for 2262DSS messages in the context of some transport binding. 2263Below we specify an initial set of bindings for DSS. Future bindings may be introduced by the OASIS 2264DSS TC or by other parties.

22656.1 HTTP POST Transport Binding 2266In this binding, the DSS request/response exchange occurs within an HTTP POST exchange [RFC 2616]. 2267The following rules apply to the HTTP request: 2268The client may send an HTTP/1.0 or HTTP/1.1 request. 2269The Request URI may be used to indicate a particular service endpoint. 2270The Content-Type header MUST be set to “application/xml”. 2271The Content-Length header MUST be present and correct. 2272The DSS request message MUST be sent in the body of the HTTP Request. 2273The following rules apply to the HTTP Response: 2274The Content-Type header MUST be set to “text/xml”. 2275The Content-Length header MUST be present and correct. 2276The DSS response message MUST be sent in the body of the HTTP Response. 2277The HTTP status code MUST be set to 200 if a DSS response message is returned. Otherwise, the 2278status code can be set to 3xx to indicate a redirection, 4xx to indicate a low-level client error (such as a 2279malformed request), or 5xx to indicate a low-level server error.

22806.2 SOAP 1.2 Transport Binding 2281In this binding, the DSS request/response exchange occurs using the SOAP 1.2 message protocol 2282[SOAP]. The following rules apply to the SOAP request: 2283A single DSS or element will be transmitted within the body of the 2284SOAP message. 2285The client MUST NOT include any additional XML elements in the SOAP body. 2286The UTF-8 character encoding must be used for the SOAP message. 2287Arbitrary SOAP headers may be present. 2288The following rules apply to the SOAP response: 2289The server MUST return either a single DSS or element within 2290the body of the SOAP message, or a SOAP fault code. 2291The server MUST NOT include any additional XML elements in the SOAP body. 2292If a DSS server cannot parse a DSS request, or there is some error with the SOAP envelope, the server 2293MUST return a SOAP fault code. Otherwise, a DSS result code should be used to signal errors. 2294The UTF-8 character encoding must be used for the SOAP message. 2295Arbitrary SOAP headers may be present. 2296On receiving a DSS response in a SOAP message, the client MUST NOT send a fault code to the DSS 2297server.

163oasis-dss-core-spec-v1.0-os 11 April 2007 164Copyright © OASIS® 2007. All Rights Reserved. Page 55 of 62 22986.2.1 SOAP Attachment Feature and Element 2299Applications MAY support SOAP 1.2 attachment feature [SOAPAtt] to transmit documents in the context 2300of a or a and can take advantage of 2301/. 2302AttRefURI 2303 SOAP 1.2 attachment feature [SOAPAtt] states that any secondary part ("attachment") can be 2304 referenced by a URI of any URI scheme. 2305 AttRefURI refers to such a secondary part ("attachment") and MUST resolve within the 2306 compound SOAP message. The default encapsulation mechanism is MIME as specified in the 2307 WS-I Attachments Profile [WS-I-Att] (cf. swaRef, http://www.ws-i.org/Profiles/AttachmentsProfile- 2308 1.0.html#Referencing_Attachments_from_the_SOAP_Envelope). 2309MimeType [Optional] 2310 Declares the MIME type of the referred secondary part of this SOAP compound message. 2311 Note: If MIME is used as encapsulation mechanism, the MIME content-type is available via a 2312 MIME header. However, the MIME headers may not be available to implementations and the 2313 SOAP 1.2 attachment feature is not restricted to MIME. Further the MIME header is not secured 2314 by the AttachmentReference's DigestValue, which is calculated over the binary attachment 2315 data (not including the MIME headers). 2316 [Optional Sequence] 2317 2318 These optional elements can be used to ensure the integrity of the attachment data. 2319 If these elements are supplied the server SHOULD compute a message digest using the 2320 algorithm given in over the binary data in the octet stream and compare it 2321 against the supplied . 2322 If the comparison fails then a RequesterError qualified by a GeneralError and an 2323 appropriate message containing the AttRefURI is returned. 2324 Note: The attachments digest value(s) can be included in the primary SOAP part to allow the 2325 entire request (including secondary parts) to be secured by WSS. However, the MIME headers 2326 are not covered by the digest value and therefore can be included into the 2327 dss:AttachmentReference (which is relevant for the processing of dss:IncludeObject 2328 referring to an dss:AttachmentReference). 2329 The digest value may be computed while the data is read from the attachment. After the last byte 2330 being read from the attachment the server compares the calculated digest value against the 2331 supplied .

2332 2333 2334 2335 2336 2337 2338 2339 2340

166oasis-dss-core-spec-v1.0-os 11 April 2007 167Copyright © OASIS® 2007. All Rights Reserved. Page 56 of 62 23416.2.1.1 Signing Protocol, Processing for XML Signatures, Process Variant for 2342 2343In the case of an input document which contains the server retrieves the 2344MIME type from the MimeType attribute (if present) otherwise from the content-type MIME header of the 2345attachment referred by AttRefURI. If the MimeType attribute diverges from the attachment's MIME 2346header content-type, an implementation MAY either ignore the MIME header's content-type or issue a 2347RequesterError qualified by a GeneralError and an appropriate message containing the 2348AttRefURI. 2349IF the MIME type indicates that it contains XML continue with processing as in section 3.3.1 and Step 1 a 2350is replaced with the following: 23511. 2352a. The server retrieves the data from the attachment referred by AttRefURI as an octet stream. This 2353data MUST be a well formed XML Document as defined in [XML] section 2.1. If the RefURI attribute 2354references within the same input document then the server parses the octet stream to NodeSetData 2355(see [XMLDSIG] section 4.3.3.3) before proceeding to the next step. 2356ELSE continue with processing as in section 3.3.4 and Step 1 a is replaced with the following: 23571. 2358a. The server retrieves the data from the attachment referred by AttRefURI as an octet stream. 2359Note: In the first case attachmentReference is always treated like Base64XML in the latter like 2360Base64Data for further processing. (E.g. In the case of dss:IncludeObject, the MimeType attribute 2361is copied from dss:AttachmentReference to ds:Object.)

23626.2.1.2 Verifying Protocol, Processing for XML Signatures, Process Variant for 2363 2364Perform section 4.3 Basic Processing for XML Signatures amending step 2 a as follows: 23652. 2366a. If the input document is a , the server extracts and decodes as described in 3.3.1 Step 1 2367a (or equivalent step in variants of the basic process as defined in 3.3.2 onwards depending of the form of 2368the input document) or in the case of as described in section 6.2.1.1.

23696.2.1.3 Signing Protocol, Basic Processing for CMS Signatures, Process Variant 2370 for 2371Perform section 3.4 Basic Processing for CMS Signatures adding the following variant 1. d' after d and 2372before e: 23731. 2374d'. If the contains , the server retrieves the data from the 2375attachment referred by AttRefURI as an octet stream.

23766.2.1.4 Verifying Protocol, Basic Processing for CMS Signatures, Process Variant 2377 for 2378Perform section 4.4 Basic Processing for CMS Signatures amending step 2 as follows: 2379 23802. The server retrieves the input data. (In the case of this is done as in 2381section 6.2.1.3 step 1. d'. If the CMS signature is detached, there must be a single input document: i.e. a 2382single or element. Otherwise, if the CMS signature is enveloping, it 2383contains its own input data and there MUST NOT be any input documents present.

169oasis-dss-core-spec-v1.0-os 11 April 2007 170Copyright © OASIS® 2007. All Rights Reserved. Page 57 of 62 23846.3 TLS Security Bindings 2385TLS [RFC 2246] is a session-security protocol that can provide confidentiality, authentication, and 2386integrity to the HTTP POST transport binding, the SOAP 1.2 transport binding, or others. TLS supports a 2387variety of authentication methods, so we define several security bindings below. All of these bindings 2388inherit the following rules: 2389TLS 1.0 MUST be supported. SSL 3.0 MAY be supported. Future versions of TLS MAY be supported. 2390RSA ciphersuites MUST be supported. Diffie-Hellman and DSS ciphersuites MAY be supported. 2391TripleDES ciphersuites MUST be supported. AES ciphersuites SHOULD be supported. Other 2392ciphersuites MAY be supported, except for weak ciphersuites intended to meet export restrictions, which 2393SHOULD NOT be supported.

23946.3.1 TLS X.509 Server Authentication 2395The following ciphersuites defined in [RFC 2246] and [RFC 3268] are supported. The server MUST 2396authenticate itself with an X.509 certificate chain [RFC 3280]. The server MUST NOT request client 2397authentication. 2398MUST:

2399 TLS_RSA_WITH_3DES_EDE_CBC_SHA 2400SHOULD: 2401 TLS_RSA_WITH_AES_128_CBC_SHA

2402 TLS_RSA_WITH_AES_256_CBC_SHA

24036.3.2 TLS X.509 Mutual Authentication 2404The same ciphersuites mentioned in section 6.2.1 are supported. The server MUST authenticate itself 2405with an X.509 certificate chain, and MUST request client authentication. The client MUST authenticate 2406itself with an X.509 certificate chain.

24076.3.3 TLS SRP Authentication 2408SRP is a way of using a username and password to accomplish mutual authentication. The following 2409ciphersuites defined in [draft-ietf-tls-srp-08] are supported. 2410MUST:

2411 TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA 2412SHOULD: 2413 TLS_SRP_SHA_WITH_AES_128_CBC_SHA 2414 TLS_SRP_SHA_WITH_AES_256_CBC_SHA

24156.3.4 TLS SRP and X.509 Server Authentication 2416SRP can be combined with X.509 server authentication. The following ciphersuites defined in [draft-ietf- 2417tls-srp-08] are supported. 2418MUST:

2419 TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA 2420SHOULD: 2421 TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA 2422 TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA 172oasis-dss-core-spec-v1.0-os 11 April 2007 173Copyright © OASIS® 2007. All Rights Reserved. Page 58 of 62 24237 DSS-Defined Identifiers 2424The following sections define various URI-based identifiers. Where possible an existing URN is used to 2425specify a protocol. In the case of IETF protocols the URN of the most current RFC that specifies the 2426protocol is used (see [RFC 2648]). URI references created specifically for DSS have the following stem: 2427urn:oasis:names:tc:dss:1.0:

24287.1 Signature Type Identifiers 2429The following identifiers MAY be used as the content of the optional input (see 2430section 3.5.1).

24317.1.1 XML Signature 2432  URI: urn:ietf:rfc:3275 2433  This refers to an XML signature per [XMLDSIG].

24347.1.2 XML TimeStampToken 2435  URI: urn:oasis:names:tc:dss:1.0:core:schema:XMLTimeStampToken 2436  This refers to an XML timestamp containing an XML signature, per section 5.1.

24377.1.3 RFC 3161 TimeStampToken 2438  URI: urn:ietf:rfc:3161 2439  This refers to an XML timestamp containing an ASN.1 TimeStampToken, per [RFC 3161].

24407.1.4 CMS Signature 2441  URI: urn:ietf:rfc:3369 2442  This refers to a CMS signature per [RFC 3852] or prior versions of CMS.

24437.1.5 PGP Signature 2444  URI: urn:ietf:rfc:2440 2445  This refers to a PGP signature per [RFC 2440].

175oasis-dss-core-spec-v1.0-os 11 April 2007 176Copyright © OASIS® 2007. All Rights Reserved. Page 59 of 62 2446A. Use of Exclusive Canonicalization

2447Exclusive Canonicalization of dereferenced and transformed data can be achieved by appending 2448exclusive canonicalization as the last transform in the element of 2449 or . 2450In the case of being used this can be done by adding exclusive canonicalization as the last 2451transform in the of a pointing to that . 2452By doing this the resulting data produced by the chain of transforms will always be octet stream data 2453which will be hashed without further processing on a level by the server as indicated 2454by basic processing section 3.3.1 step 1 b. and c. 2455Another possibility to apply exclusive canonicalization on level is the freedom given to 2456servers to apply additional transforms to increase robustness. This however implies that only trustworthy 2457transformations are appended by a server. 2458As in section 3.3.1 step 1 b an implementation can choose to use exclusive canonicalization: "... 2459Transforms are applied as a server implementation MAY choose to increase robustness of the Signatures 2460created. These Transforms may reflect idiosyncrasies of different parsers or solve encoding issues or the 2461like. ..." 2462In such a case that the exclusive canonicalization is to be included in the as well (cf. 2463section 3.3.1 step v.) 2464The standards default is however in line with [XMLDSIG] as indicated in the Note in section 3.3.1 step 1 2465b. 2466However after the server formed a (section 3.3.1 step 3.) this information to be 2467signed also needs to be canonicalized and digested, here [XMLDSIG] offers the necessary element 2468 directly and can be used to specify exclusive canonicalization.

178oasis-dss-core-spec-v1.0-os 11 April 2007 179Copyright © OASIS® 2007. All Rights Reserved. Page 60 of 62 2469B. More Complex Example

2470To further explain the use of the element which is useful in cases where the DSS server is 2471not able to respond with a special response type a more complex example is given in the following 2472paragraph. 2473Consider for example a client sends a to a service that only supports 2474's over plain HTTP (as opposed to protocols where some information could be 2475derived from the header ). As the service does not support 's it has to either generate a 2476 with a "bad message" result or fail at the HTTP layer. In the former case, the client 2477will receive a response that does not correspond semantically to the request - it got a 2478 to a . This leaves both parties thinking that the other one is at 2479fault.

181oasis-dss-core-spec-v1.0-os 11 April 2007 182Copyright © OASIS® 2007. All Rights Reserved. Page 61 of 62 2480C. Acknowledgements

2481The following individuals have participated in the creation of this specification and are gratefully 2482acknowledged: 2483Participants: 2484 Dimitri Andivahis, Surety 2485 Glenn Benson, JPMorganChase 2486 Juan Carlos Cruellas, individual 2487 Carlos Gonzalez-Cadenas, Netfocus, S.L 2488 Frederick Hirsch, Nokia 2489 Pieter Kasselman, Cybertrust 2490 Andreas Kuehne, individual 2491 Konrad Lanz, Austria Federal Chancellery 2492 Tommy Lindberg, individual 2493 Paul Madsen, Entrust 2494 John Messing, American Bar Association 2495 Tim Moses, Entrust 2496 Trevor Perrin, individual 2497 Nick Pope, Thales eSecurity 2498 Rich Salz, DataPower 2499 Ed Shallow, Universal Postal Union

184oasis-dss-core-spec-v1.0-os 11 April 2007 185Copyright © OASIS® 2007. All Rights Reserved. Page 62 of 62

Load more

  62

Copy Link