1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 Electronic PostMark (EPM) Profile of the OASIS Digital Signature Service Committee Draft, 24 December, 2004 (Working Draft 06) Document identifier: oasis-dss-1.0-profiles-epm-spec-cd-01 Location: http://docs.oasis-open.org/dss/ Editor: Ed Shallow, Universal Postal Union <ed.shallow@rogers.com> Contributors: Trevor Perrin, individual <trevp@trevp.net> Nick Pope, individual <pope@secstan.com Juan Carlos Cruellas, individual <cruellas@ac.upc.es> Abstract: This draft defines a profile of the OASIS DSS protocol for the purpose of creating and verifying signatures and timestamps which support the extended features of the Universal Postal Union s Electronic PostMarking service. Status: This is a Working Draft produced by the OASIS Digital Signature Service Technical Committee. Committee members should send comments on this draft to dss@lists.oasis-open.org. For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Digital Signature Service TC web page at http://www.oasisopen.org/committees/dss/ipr.php. 27 Copyright OASIS Open 2004. All Rights Reserved. Page 1 of 42
27 Table of Contents 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 1 Introduction... 5 1.1 Notation... 5 1.2 Namespaces... 5 2 Profile Features... 6 2.1 Identifier... 6 2.2 Scope... 6 2.3 Relationship To Other Profiles... 6 2.4 Signature Object... 6 2.5 Transport Binding... 6 2.6 Security Binding... 6 2.6.1 Security Requirements... 6 2.7 Common Elements... 6 2.7.1 Element <PostMarkedReceipt> and the PostMarkedReceipt Signature... 6 2.7.2 Input / Output Element <TransactionKey>... 8 2.7.3 Input Element <OrganizationID>... 8 2.7.4 Input Element <ContentIdentifier>... 9 2.7.5 Input / Output Element <ClientApplicationID>... 9 2.7.6 Input Element <ContentMetaData>... 9 3 Profile of Signing Protocol... 10 3.1 Element <SignRequest>... 10 3.1.1 Constraints on Element <OptionalInputs>... 10 3.1.1.1 Element SignatureType...10 3.1.1.2 Element <KeySelector>...10 3.1.1.3 Element <SignedReferences> not Supported...10 3.1.1.4 Element <AddTimestamp>...11 3.1.1.5 Element <InputDocuments>...12 3.1.1.6 Element <SignaturePlacement>...12 3.1.2 EPM-specific <OptionalInputs>... 13 3.1.2.1 Element <DocumentWithTemplate>...13 3.1.2.2 Element <TransactionKey>...13 3.1.2.3 Element <ClaimedIdentity>...13 3.1.2.4 Element <OrganizationID>...14 3.1.2.5 Element <ContentIdentifier>...14 3.1.2.6 Element <ClientApplicationID>...14 3.1.2.7 Element <ContentMetaData>...14 3.1.3 <OptionalInputs> Processing Flags... 15 3.1.3.1 Element <ExtendLifecycle>...15 3.1.3.2 Element <EndLifecycle>...15 3.1.3.3 Element <IssuePostMarkedReceipt>...15 3.1.3.4 Element <StoreNonRepudiationEvidence>...16 3.1.3.5 Element <ReturnSignatureInfo>...16 3.1.3.6 Element <ReturnX509Info>...16 3.2 Element <SignResponse>... 16 3.2.1 Element <Result>...16 3.2.2 Element <SignatureObject>... 16 Copyright OASIS Open 2004. All Rights Reserved. Page 2 of 42
73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 3.2.3 EPM-specific <OptionalOutputs>... 16 3.2.3.1 Element <TransactionKey>...16 3.2.3.2 Element <PostMarkedReceipt>...17 3.2.3.3 Element <DocumentWithSignature>...17 3.2.3.4 Element <SignatureInfo>...17 3.2.3.5 Element <X509Info>...17 3.2.4 Timestamp Handling Profile of Sign Protocol... 18 3.2.4.1 Standalone Timestamp from <DocumentHash>...18 3.2.4.2 Standalone Timestamp from <Document>...18 3.2.4.3 Embedding a Signature Timestamp into a user-provided Signature...18 4 Profile of Verifying Protocol...20 4.1 Element <VerifyRequest>... 20 4.1.1 Constraints on Element <OptionalInputs>... 20 4.1.1.1 Element <SignatureObject>...20 4.1.1.2 Element <InputDocuments>...20 4.1.1.3 Element <VerifyManifests>...20 4.1.1.4 Element <VerificationTime>...20 4.1.1.5 Element <AdditionalKeyInfo>...20 4.1.1.6 Element <ReturnProcessingDetails>...20 4.1.1.7 Element <ReturnSigningTime>...20 4.1.1.8 Element <ReturnSignerIdentity>...20 4.1.1.9 Element <ReturnUpdatedSignature>...20 4.1.1.10 Element <ReturnTransformedDocument>...20 4.1.2 EPM-specific <OptionalInputs>... 21 4.1.2.1 Element <TransactionKey>...21 4.1.2.2 Element <OrganizationID>...21 4.1.2.3 Element <ContentIdentifier>...21 4.1.2.4 Element <ClientApplicationID>...21 4.1.2.5 Element <ContentMetaData>...21 4.1.3 <OptionalInputs> Processing Flags... 21 4.1.3.1 Element <ExtendLifecycle>...21 4.1.3.2 Element <EndLifecycle>...21 4.1.3.3 Element NodeName...21 4.1.3.4 Element <IssuePostMarkedReceipt>...22 4.1.3.5 Element <StoreNonRepudiationEvidence>...22 4.1.3.6 Element <ReturnSignatureInfo>...22 4.1.3.7 Element <ReturnX509Info>...22 4.2 Element <VerifyResponse>... 22 4.2.1 Element <Result>...22 4.2.2 Element <SignatureObject>... 23 4.2.3 Element <OptionalOutputs>... 23 4.2.3.1 Element <DocumentWithSignature>...23 4.2.4 Element <EPM-specific OptionalOutputs>... 23 4.2.4.1 Element <TransactionKey>...23 4.2.4.2 Element <PostMarkedReceipt>...23 4.2.4.3 Element <SignatureInfo>...23 4.2.4.4 Element <X509Info>...23 5 Signing Template Examples... 24 6 PostMarkedReceipt Examples... 28 7 Element cross-reference Table... 33 Copyright OASIS Open 2004. All Rights Reserved. Page 3 of 42
123 124 125 126 8 References... 40 8.1 Normative... 40 Appendix A. Revision History... 41 Appendix B. Notices... 42 127 Copyright OASIS Open 2004. All Rights Reserved. Page 4 of 42
128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 1 Introduction The Electronic PostMarking service is a Universal Postal Union (UPU) endorsed standard aimed at providing generalized signature creation, signature verification, timestamping, and receipting services for use by and across Postal Administrations and their target customers. Although the total scope and functional coverage of the EPM s service offering are outside the immediate scope of the DSS initiative, the UPU wishes to offer its client base a DSS-compliant subset of the EPM for clients who wish to maintain OASIS compliance in the core areas of signature and timestamp, creation and verification. This profile can be used directly as the basis for implementing interoperable systems. 1.1 Notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in IETF RFC 2119 [RFC 2119]. These keywords are capitalized when used to unambiguously specify requirements over protocol features and behavior that affect the interoperability and security of implementations. When these words are not capitalized, they are meant in their natural-language sense. This specification uses the following typographical conventions in text: <ns:element>, Attribute, Datatype, OtherCode. 1.2 Namespaces The structures described in this specification are contained in the schema file [EPM]. All schema listings in the current document are excerpts from that schema file. In the case of a disagreement between the schema file and this document, the schema file takes precedence. This schema is associated with the following XML namespace: http://www.docs.oasis-open.org/dss/oasis-dss-1.0-profiles-epm-cd-01# If a future version of this specification is needed, it will use a different namespace. Conventional XML namespace prefixes are used in this document: The prefix dss: (or no prefix) stands for the DSS core namespace [Core-XSD]. The prefix dsig: stands for the W3C XML Signature namespace [XMLSig]. The prefix xs: stands for the W3C XML Schema namespace [Schema1]. The prefix saml: stands for the OASIS SAML Schema namespace [SAMLCore1.1]. The prefix epm: stands for the EPM Schema namespace [EPM]. The prefix xades: stands for ETSI XML Advanced Electronic Signatures (XAdES) document [XAdES]. Applications MAY use different namespace prefixes, and MAY use whatever namespace defaulting/scoping conventions they desire, as long as they are compliant with the Namespaces in XML specification [XML-ns]. Copyright OASIS Open 2004. All Rights Reserved. Page 5 of 42
160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 2 Profile Features 2.1 Identifier urn:oasis:names:tc:dss:1.0:profiles:epm 2.2 Scope This document profiles the DSS signing and verifying protocols defined in [DSSCore] and provides an OASIS DSS-compliant interface to selected services of the EPM. The EPM profile supports the creation and verification of both CMS/PKCS7 and [XMLSig] signature types. Additional services within the EPM are supported through the extensibility mechanisms provided by the optional inputs and outputs of the [DSSCore]. This includes: Easy to use EPM Signing Templates PostMarked receipts Embedding of signatures in documents Extended support of both XMLSig and CMS signature creation and verification Certificate validation data Revocation references Certificate references Online Certificate Status Protocol (OCSP) responses Support for the chaining of complex business lifecycle events Timestamping from a CA-independent TimeStamp Authority 2.3 Relationship To Other Profiles The profiles in this document are based directly on the [DSSCore]. 2.4 Signature Object This profile supports the creation and verification of both XMLSig and CMS signatures as defined in [DSSCore]. 2.5 Transport Binding This profile is transported using either an XML-based HTTP payload POSTed to the EPM Server, or via a SOAP Transport Binding as defined in the OASIS EPM Profile Web Service Description language (WSDL). 2.6 Security Binding 2.6.1 Security Requirements The TLS X.509 Server Authentication security binding as described in section 6.2.1 in [DSSCore] must be used. 2.7 Common Elements This section describes elements used and referenced within both the Sign and Verify protocols. 2.7.1 Element <PostMarkedReceipt> and the PostMarkedReceipt Signature Copyright OASIS Open 2004. All Rights Reserved. Page 6 of 42
192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 A PostMarkedReceipt is a signature attesting to the validity of either the signature just created (Sign protocol) or the signature just verified (Verify protocol). It requires an additional profile element not part of [DSSCore] and that is the <PostMarkedReceipt> element. This element describes the EPM s receipt structure, which works in conjunction with the standard <TstInfo> element of [DSSCore]. A PostMarkedReceipt signature is returned whenever the optional input <IssuePostMarkedReceipt> is included in either the Sign or Verify request. The PostMarkedReceipt is a superset of the DSS <Timestamp> element and carries specific meaning within the specific context of EPM service provisioning. Semantics as follows: Sign When a PostMarkedReceipt signature is issued as a result of a Sign operation, the EPM is attesting to the origin of the signature and the validity of the certificate used to create it. Verify Correspondingly, when the EPM issues a PostMarkedReceipt as a result of a Verify operation which requested an <IssuePostMarkedReceipt>, the EPM is attesting to the validity of both the verified signature as well as the validity (i.e. revocation status) of the public verification certificate contained therein. See section 6 for a detailed example of a standalone PostMarkedReceipt signature returned after successful verification. The example illustrates a detached receipt signature representing the PostMark covering a signed and verified document. Additionally, all evidence surrounding this event is logged in the EPM s non-repudiation database by default. The EPM supports the issuance of conventional timestamps, both embedded and standalone. The EPM-specific notion of a PostMarked receipt applies in both the embedded and standalone scenarios. Both are valid within the Sign protocol. All receipts are tied to a specific EPM operational transaction as specified by the enclosed <TransactionKey> element. The <PostMarkedReceipt> element is similar to the <dss:timestamp> when applied to XMLSig-based signatures. PostMarkedReceipt signatures returned in XMLSig signatures scenarios, are exactly three (3) <dsig:reference> s which make up the signature associated with the PostMarkedReceipt. They are as follows: <dsig:reference> whose URI attribute references a <dsig:object> containing the <TstInfo> <dsig:reference> whose URI attribute references a <dsig:object> containing the <epm:postmarkedreceipt> <dsig:reference> whose URI attribute references a <dsig:object> containing the <dsig:signaturevalue> of the signature being PostMarked (Sign) or Verified and PostMarked (Verify) EPM-produced <PostMarkedReceipt> s, always bind the receipt to the signature just created or verified. Please refer to the EPM documentation for specific policy and usage guidelines. <xs:element ref="epm:postmarkedreceipt" <!-- imported from the EPM schema --> <xs:element name="postmarkedreceipt" type="epm:postmarkedreceipttype"> <xs:complextype name="postmarkedreceipttype"> <xs:sequence> <xs:element name="receipt" type="epm:receipttype"/> <xs:element name="timestamptoken" type="epm:qualifieddatatype" minoccurs="0"/> <xs:element name="receiptsignature" type="epm:qualifieddatatype" minoccurs="0"/> </xs:sequence> </xs:complextype> Copyright OASIS Open 2004. All Rights Reserved. Page 7 of 42
243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 <xs:complextype name="receipttype"> <xs:sequence> <xs:element name="transactionkey" type="epm:transactionkeytype"/> <xs:element name="tsax509subjectname" type="xs:string"/> <xs:element name="timestampvalue" type="xs:string"/> <xs:element name="revocationstatusqualifier" type="xs:string"/> <xs:element name="clientapplication" type="epm:clientapplicationtype"/> <xs:element name="resourceid" type="xs:string"/> </xs:sequence> </xs:complextype> Note 1: The ReceiptSignature child element of the PostMarkedReceipt is only used when processing CMS/PKCS7 signatures where the receipt is standalone. It is simply used to protect the integrity of this standalone XML structure which contains an encapsulated CMS/PKCS7 <TimeStampToken>. Note 2: The binary <TimeStampToken> element above can be omitted for XMLSig-based <SignatureType> s since the PostMarkedReceipt is itself a signature which covers the <TstInfo> structure. EPM implementations using TimeStamp Authorities (TSAs), are however free to initialized this element with an RFC3161 timestamp token produced by a TSA if they wish. The example is section 6 does not initialize the <TimeStampToken> element. 2.7.2 Input / Output Element <TransactionKey> This complextype is a compound key made up of 3 elements uniquely identifying each event in the an EPM Lifecycle. It is optionally specified on input when Lifecycle support is required, and always returned on output. The EPM generates and returns a new and unique <TransactionKey> with all response operations. This returned Key can be used to tie together events in a business workflow. When users or applications are adding another event to an existing lifecycle they need only supply that particular Key as part of their request. When they are referring to a particular event within the Lifecycle, then both the Key element and the Sequence element are required on input as part of the request. The <Locator> element is used to identify the particular EPM instance when multiple EPM instances are involved, as is the case with cross-border transactions. Please refer to EPM documentation for usage guidelines. <xs:element ref="epm:transactionkey" <!-- imported from the EPM schema --> <xs:element name=" TransactionKey" type="epm:transactionkeytype"> <xs:complextype name="transactionkeytype"> <xs:sequence> <xs:element name="locator" type="epm:locatortype"/> <xs:element name="key" type=" xs:string"/> <xs:element name="sequence" type="xs:string"/> </xs:sequence> </xs:complextype> <xs:complextype name="locatortype"> <xs:sequence> <xs:element name="countrycode" type="xs:string"/> <xs:element name="version" type="xs:string"/> <xs:element name="serviceprovider" type="xs:string" nillable="true"/> <xs:element name="environment" type="xs:string" nillable="true"/> </xs:sequence> </xs:complextype> 293 294 2.7.3 Input Element <OrganizationID> Copyright OASIS Open 2004. All Rights Reserved. Page 8 of 42
295 296 297 298 This element is used when the requester s organization name cannot be derived from the certificate. In those circumstances, this element should be initialized to the requester s organizational name as a xs:string. Please refer to EPM documentation for usage guidelines. <xs:element name="organizationid" type="xs:string" nillable="true"/> 299 300 301 302 303 304 2.7.4 Input Element <ContentIdentifier> This element is used to qualify the nature of the data being signed and is used by the EPM at retrieval time (e.g. RetrieveResults, RetrieveSummary, and Sign for Pickup) to both qualify searches for customer-specific content as well as providing access authorization categories. Please refer to EPM documentation for usage guidelines. <xs:element name="contenttype" type="xs:string" nillable="true"/> 305 306 307 308 309 310 2.7.5 Input / Output Element <ClientApplicationID> This element is an optional input and if initialized is echoed back as part of output responses. It is used to indicate to the EPM service the name of the client s application making the request. When results of previous operations are retrieved, this value is echoed back to the user. Please refer to EPM documentation for usage guidelines. <xs:element name="clientapplication" type="xs:string" nillable="true"/> 311 312 313 314 315 316 317 2.7.6 Input Element <ContentMetaData> This element can be used by the user to provide any additional context surrounding the signing activity that they do not wish to have included in the signature itself. When results of previous operations are retrieved using the extended features of the EPM, this value is echoed back to the user. This element can also be used to refine subsequent customer pickup content searches in a free-form way. Please refer to EPM documentation for usage guidelines. Copyright OASIS Open 2004. All Rights Reserved. Page 9 of 43
318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335 336 337 338 339 340 341 342 343 344 345 346 347 348 349 350 351 352 353 354 3 Profile of Signing Protocol 3.1 Element <SignRequest> 3.1.1 Constraints on Element <OptionalInputs> Details on the constraints and semantics which exist with respect to the optional inputs as described in [DSSCore] follow in this section. All <OptionalInputs> not explicitly mentioned in this section are supported as defined in [DSSCore]. EPM-specific <OptionalInputs> are described below in the section entitled EPM-specific <OptionalInputs>. 3.1.1.1 Element SignatureType The <SignatureType> element MUST be included in the EPM profile s SignRequest. The following <SignatureType> URNs are supported: Signature creation URNs: urn:ietf:rfc:3275 (i.e. an XML Digital Signature) urn:ietf:rfc:3369 (i.e. a CMS/PKCS7 binary Signature) Timestamp creation URNs: oasis:names:tc:dss:1.0:core:schema:xmltimestamptoken urn:ietf:rfc:3161 (i.e. a CMS timestamp token) The first 2 URNs instruct the EPM to create a signature as it s primary objectives. The last 2 URNs instruct the EPM to create a timestamp. The context and processing rules within which the EPM creates signatures is different than the context within which the EPM creates timestamps. These differences will be highlighted below as they apply to each optional input and output, as constrained by the <SignatureType> chosen above. If no restriction is mentioned below, one may assume that the optional input is valid for timestamp <SignatureType> s as well. Specific processing for timestamp types is further described in section 3.2.4 entitled Timestamp Handling Profile of Sign Protocol. 3.1.1.2 Element <KeySelector> The <KeySelector> optional input must be supported by the EPM, but is not required when calling the EPM service as a client user (i.e. is optional). If the EPM cannot derive the key to use for signing from the underlying authentication being used, or if the X509SubjectName is not readily available, the <KeySelector> can be used. When using EPM signing templates, users may initialize the <KeyInfo> element in the signing template with a valid X509SubjectName in the <KeyName> child element of <KeyInfo>. The EPM will utilize the specified certificate/key as defined. See Example 1 in section 5 for an example of signing templates. Note: This optional input does not apply when users are requesting a timestamp <SignatureType>. EPM implementations are, by definition, TimeStamp Authorities and will use TSA-specific signing keys expressly for that purpose. 3.1.1.3 Element <SignedReferences> not Supported The <SignedReferences> optional input element of the <SignRequest> as defined in [DSSCore] is not supported by EPM implementations. If a user requires greater control over signature references, they should use an EPM signing template included as part of the <DocumentWithTemplate> element. Copyright OASIS Open 2004. All Rights Reserved. Page 10 of 42
355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391 392 393 394 395 396 397 398 399 400 401 EPM-supported signing templates contain not only the data to be signed, but also the format and directives on how the signature should be created, expressed as valid [XMLSig] elements. [XMLSig] elements such as <SignatureValue>, <DigestValue>, and <X509Certificate> are populated by the EPM service. The user simply leaves these elements empty, and the EPM service will automatically include the generated content and return the signed document as part of the <SignResponse>. See section 3.1.2.1 for details and section 5 for selected examples. More details are available in the EPM Systems Integrator s Guide and other EPM documentation available at the UPU s Postal Technology Centre http://www.ptc.upu.int/. This signing template may contain as many valid <Reference> structures as are required. All <References> however must be resolved within the scope of the <DocumentWithTemplate> element. Users wishing to sign multiple XML node sets should include them all in the input <DocumentWithTemplate> element as children of the root. <SignedReferences> may be supported in a future version of the EPM profile. Please consult the OASIS DSS site for updates. Note: This optional input is not supported and therefore does not apply when users are requesting a timestamp <SignatureType>. 3.1.1.4 Element <AddTimestamp> The EPM supports this <OptionalInputs> element when used in the Sign protocol. Processing differs based on the <SignatureType> specified in the request. When specified, the EPM will create a timestamp and return this timestamp within the signature being created. In other words, this directive will result in the addition of a timestamp to the resultant signature. The Type attribute of the <AddTimestamp> element may be omitted since the EPM supports only signature timestamps". That is to say the EPM will first generate the signature, and then embed the generated timestamp into that signature. How embedding takes place differs by <SignatureType>. The timestamps are added as follows for each <SignatureType> supported: For <SignatureType> values of urn:ietf:rfc:3369 (i.e. CMS/PKCS7), the timestamp will be produced as follows: The following object identifier identifies the Signature Timestamp attribute: id-aa-signaturetimestamptoken OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) id-aa(2) 14 } i.e. 1.2.840.113549.1.9.16.2.14 The value of messageimprint field within TimeStampToken shall be a hash of the value of signature field within SignerInfo for the signeddata being timestamped. The RFC 3161 timestamp token will be added as an unauthenticated attribute, as defined above, of the generated signature. The result will be returned in <SignatureObject>. This approach is identical to that prescribed by ETSI TS 101 733 and is the convention utilized and supported by the EPM profile. For <SignatureType> values of urn:ietf:rfc:3275 (i.e. [XMLSig]), the timestamp will be produced as follows: the timestamp will be produced as defined in section 5.1 of [DSSCore]. The URI attribute of the first <Reference> element of the timestamp s <SignedInfo> will point to an <Object> containing the <TstInfo> element. The URI attribute of the second <Reference> element of the timestamp s <SignedInfo> will point to an <Object> containing the <SignatureValue> element of the signature just created. This is because the timestamp being added is a signature timestamp and not a content timestamp. The detached timestamp signature will be included as the first child of the XML document root and will immediately precede the generated signature. The <AddTimestamp> optional input is not supported on timestamp-related <SignatureType> s as used within the Signing protocol, since one cannot add a timestamp to a timestamp. Copyright OASIS Open 2004. All Rights Reserved. Page 11 of 42
402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 See also section 3.1.3.3 <IssuePostMarkedReceipt> which delivers different functionality than the <AddTimestamp> and results in the creation of an additional standalone <PostMarkedReceipt> structure which is a superset of a basic timestamp. Both optional inputs are supported on a Sign operation and serve different purposes. On a Verify operation, the <ReturnUpdatedSignature> acts like the <AddTimestamp> described above, and will update the signature being verified. See also <IssuePostMarkedReceipt> which returns a timestamped receipt structure and has different semantic meaning. Please refer to section 4 covering the Verify. Note: Content timestamps, created before signature generation, are currently not supported in the EPM profile (e.g. a pre and a post signature generation timestamp). They may however be added in a subsequent release of the EPM profile. 3.1.1.5 Element <InputDocuments> The EPM profile constrains the <Document> element in that the dss:base64data choice is mandated when formatting the <Document> element. That is to say, that the dss:xmldata choice is not supported on input and never used on output. When manipulating XML content the EPM will employ a MimeType attribute value of "text/xml". The EPM profile also constrains the <InputDocuments> element such that the EPM server presently accepts only one <Document> or <DocumentHash> element (i.e. equivalent of maxoccurs="1"). This may change in a subsequent version of the EPM profile. Users wishing to create signatures with multiple <Reference> elements should use EPM signing templates. See section 3.1.2.1 for details. When the <Document> element is passed in by the user of this profile, it is assumed that it contains only the content to be signed. This is the standard convention used by [DSSCore] when passing in content to be signed and is supported by the EPM profile as the default. When users wish to use the EPM s signing template mechanism, they must pass the document template in on the <DocumentWithTemplate> element. Please refer to section 3.1.2.1 below. The <Document> element is also used to pass in a signature to be timestamped when the <SignatureType> specifies a timestamp type. The MimeType should specify application/pkcs7-signature when passing in a signature to be timestamped. Note: The <InputDocuments> element has special considerations when used in the context of timestamprelated <SignatureType> s. Please refer to section 3.2.4 for more detailed explanation of the timestamping implications on use of the <InputDocuments> element. 3.1.1.6 Element <SignaturePlacement> When creating RFC3275-compliant XML Digital Signatures in the Sign protocol as specified by the <SignatureType> optional input element, the <SignaturePlacement> optional input element is not required. Handling of signature placement is as follows. Enveloped Signatures (XMLSig) The EPM will assume an enveloped signature unless an <EnvelopingSignature> optional input is present. The resultant signature will be inserted after the last child of the root node of the <Document> element of <InputDocuments> and will be returned in the <DocumentWithSignature> element. This is default handling. Enveloping Signatures (XMLSig) For users requesting <EnvelopingSignature> s the EPM will place the <Document> within a Reference d <Object> element inside the signature and therefore requires the <Document> s RefURI attribute in order to construct the <Reference> s URI attribute as well as the corresponding <Object> s Id attribute (without the # symbol). The result will be returned in the <SignatureObject> element as per [DSSCore]. If users wish to specify transforms and other signature features, they should use an EPM signing template. See section 3.1.2.1 for details. Copyright OASIS Open 2004. All Rights Reserved. Page 12 of 42
449 450 451 452 453 454 455 456 457 458 459 460 461 462 463 464 465 466 467 468 469 470 471 472 473 474 475 476 477 478 479 480 481 482 483 484 485 486 487 Enveloping Signatures (CMS/PKCS7) In order to obtain an enveloping CMS/PKCS7 signature, the caller must include the <EnvelopingSignature> optional input. When specified, the input document s content will be encapsulated in the CMS/PKCS7 SignedData signature structure and returned in the <SignatureObject> element. When the <EnvelopingSignature> optional input is specified, only one <InputDocuments> occurrence is supported (i.e. can only have a single child), and the WhichDocument attribute, if present, will be ignored. Detached Signatures (CMS/PKCS7) This is default processing for CMS/PKCS7 signatures and is identical to [DSSCore]. The input document s content will NOT be encapsulated in the CMS/PKCS7 SignedData signature structure as per detached signature conventions. This signature will be returned in the <SignatureObject> element. Same Document Detached Signatures (XMLSig) Callers can obtain detached XMLSig signatures by constructing a signing template reflecting a same document detached signature in the <DocumentWithTemplate> input element. A same document detached XMLSig signature will also be produced under an <IssuePostMarkedReceipt> scenario when the Location attribute is specified as embedded. See section 3.1.3.3. These signatures are returned in the <DocumentWithSignature> element. This optional input does not apply when users are requesting a timestamp <SignatureType> in which case placement is determined by the server. When greater and more direct control of signature placement is required, users must use an EPM signing template. EPM signing templates should be used if user wishes to have a same-document detached XMLSigbased signature created. See section 3.1.2.1 for details. Note: As with [DSSCore], [XMLSig] signatures created from <DocumentHash> will be returned in <SignatureObject>. 3.1.2 EPM-specific <OptionalInputs> The following additional elements are specific to the EPM profile. There specific usage and constraints are documented below. 3.1.2.1 Element <DocumentWithTemplate> The <DocumentWithTemplate> optional input element is used when users elect to utilize the EPM s signing template mechanism. EPM-supported signing templates contain not only the data to be signed, but also the format and directives of the signature to be created, expressed as valid [XMLSig] elements. In this fashion more elaborate signatures involving transforms, signed and unsigned properties, manifests, and multiple <Reference> elements can be supported. [XMLSig] elements such as <SignatureValue>, <DigestValue>, and <X509Certificate> are populated by the EPM service. The user simply leaves the element tags empty, and the EPM service will automatically include the generated content and return the signed document in the <DocumentWithSignature> element of the <SignResponse>. See Example 1 in section 5 for an example of signing templates. More details are available in the EPM Systems Integrator s Guide and other EPM documentation available at the UPU s Postal Technology Centre http://www.ptc.upu.int/. <xs:element name="documentwithtemplate"> type="dss:base64data"/> 488 489 490 491 3.1.2.2 Element <TransactionKey> Please refer to the description in section 2.7.2 entitled Element <TransactionKey> 3.1.2.3 Element <ClaimedIdentity> Copyright OASIS Open 2004. All Rights Reserved. Page 13 of 42
492 493 494 495 496 497 498 499 500 501 502 503 504 505 506 507 508 509 510 511 512 513 514 515 516 517 518 519 520 521 522 523 524 525 526 527 528 529 530 531 532 533 This complextype is an extension of the standard OASIS DSS <ClaimedIdentity> element. This extension to ClaimedIdentity utilizes the OASIS <SupportingInfo> to define EPM-specific additions required to support the authentication and assertion of the requester s identity. The default authentication mechanism of an EPM implementation is external to the EPM profile and is supported by the conventions used in that underlying binding. In this fashion EPM implementations are free to authenticate users using standard approaches like HTTP Basic Authentication (i.e. Authorization: Basic in the HTTP header), or may decide to use stronger techniques involving Digest Authentication, encrypted cookies, one-time password schemes, two-factor tokens, or any of several other authentications schemes they chose. However there are situations where the underlying binding may not support the representation or the transport of the desired token type. For this reason, the EPM profile allows the chosen token type to be passed as Authentication Information as an attestation of, in support of, in addition to, or instead of the underlying authentication scheme and its assertion of identity. As such, it not used solely as additional authentication information, but rather could be used as an adjunct to the authentication mechanism itself. This scheme-specific authentication support is carried in the abstract <AlternateIdentity> type. The <RequesterSignature> element is optional and is used in support of Proof-of-Possession or Proof-of- Delivery in the EPM s non-repudiation context. This element and its use-cases are further defined in the EPM Service Description documentation. <xs:element name="claimedidentity"> <xs:complextype> <xs:sequence> <xs:element name="name" type="saml:nameidentifiertype"/> <xs:element ref="epm:supportinginfo"> </xs:sequence> </xs:complextype> </xs:element> <!-- imported from the EPM schema --> <xs:element name="supportinginfo" type="epm:supportinginfotype"/> <xs:complextype name="supportinginfotype"> <xs:element name="basicauth" type="epm:basicauthtype" nillable="true"/> <xs:element name="requestersignature" type="epm:qualifieddatatype" nillable="true"/> <xs:element name="alternateidentity" type="epm:alternateidentitytype" nillable="true"/> </xs:complextype> <xs:complextype name="epm:qualifieddatatype"> <xs:simplecontent> <xs:extension base="xs:base64binary"> <xs:attribute name="mimetype" type="xs:string"/> </xs:extension> </xs:simplecontent> </xs:complextype> 534 535 536 537 538 539 540 541 542 3.1.2.4 Element <OrganizationID> Please refer to the description in section 2.7.3 entitled Input Element <OrganizationID> 3.1.2.5 Element <ContentIdentifier> Please refer to the description in section 2.7.4 entitled Input Element <ContentIdentifier> 3.1.2.6 Element <ClientApplicationID> Please refer to the description in section 2.7.5 entitled Input / Output Element <ClientApplicationID> 3.1.2.7 Element <ContentMetaData> Please refer to the description in section 2.7.6 entitled Input Element <ContentMetaData> Copyright OASIS Open 2004. All Rights Reserved. Page 14 of 42
543 544 545 546 547 548 549 550 551 552 553 554 555 3.1.3 <OptionalInputs> Processing Flags This section describes the <OptionalInputs> that are simple processing directives for the EPM. Each flag directs the EPM to perform specific functions and/or return specific response information. More detail on each processing option can be found in the EPM documentation. 3.1.3.1 Element <ExtendLifecycle> Including this empty directive element instructs the EPM to extend the LifeCycle referred to in the <TransactionKey> element. Callers must initialize the <TransactionKey> sub-elements when using <ExtendLifecycle>. <xs:element name="extendlifecycle"/> 3.1.3.2 Element <EndLifecycle> Including this empty directive element instructs the EPM to close the LifeCycle and not allow any further events to be included in the LifeCycle identified by this <TransactionKey>. <xs:element name="endlifecycle"/> 556 557 558 559 560 561 562 563 564 565 566 567 568 569 570 571 572 573 574 575 576 577 578 579 580 581 582 583 584 585 586 587 3.1.3.3 Element <IssuePostMarkedReceipt> Including this empty directive element instructs the EPM to return a signed receipt attesting to the origin of the signature as well as the validity of the certificate used in the signature process. Inclusion of this element results in the return of either a standalone <PostMarkedReceipt> signature containing its signed <PostMarkedReceipt> and <TimeStampToken> or one embedded in the signature being created. This element contains a Location attribute instructing the EPM how to return the <PostMarkedReceipt>. Processing differs based on the <SignatureType> and the value of the Location attribute. For a Location attribute value of standalone regardless of the <SignatureType>, processing is as follows: The <PostMarkedReceipt> XML element will be returned as a standalone optional output structure as defined in section 2.7.1. Standalone <PostMarkedReceipt> s are self-contained and contain a timestamp signature which binds the receipt to the signature value of the signature being created as part of this Sign operation. For a Location attribute value of embedded and a <SignatureType> value of urn:ietf:rfc:3275 (i.e. XMLSig), processing is as follows: The EPM will first create an [XMLSig] based detached signature covering the input document. The input document s contents will be outside the produced signature and referenced by it. The EPM will then add a <PostMarkedReceipt> detached signature structure covering the <SignatureValue> of the first signature just created. The resulting signed and PostMarked document will be returned in the <DocumentWithSignature> element. A Location attribute value of embedded with a <SignatureType> value of urn:ietf:rfc:3369 (i.e. CMS/PKCS7) is not supported. A signature timestamp (i.e. an RFC 3161 timestamptoken) however can be embedded in a CMS/PKCS7 signature by using the <AddTimestamp> optional input described in section 3.1.1.4. This timestamp bears the Issuer name of the Post s TimeStamp Authority. Please refer to section 6 for a detailed example of a <PostMarkedReceipt> signature. <xs:element name="issuepostmarkedreceipt"> <xs:complextype> <xs:attribute name="location" type="xs:string"/> </xs:complextype> Copyright OASIS Open 2004. All Rights Reserved. Page 15 of 42
588 589 590 591 592 </xs:element> 3.1.3.4 Element <StoreNonRepudiationEvidence> Including this empty directive element instructs the EPM to store evidence of the operation being performed. This evidentiary information can be subsequently retrieved and used to support challenges as to its authenticity. <xs:element name="storenonrepudiationevidence"/> 593 594 595 596 597 598 3.1.3.5 Element <ReturnSignatureInfo> Including this empty directive element instructs the EPM to return additional response information relating to the signing operation. This directive element results in the return of a <SignatureInfo> structure in the <OptionalOutputs>. <xs:element name="returnsignatureinfo"/> 599 600 601 602 603 604 3.1.3.6 Element <ReturnX509Info> Including this empty directive element instructs the EPM to return additional response information relating to the certificate used for the signing. This directive element results in the return of an <X509Info> structure in the <OptionalOutputs>. <xs:element name="returnx509info"/> 605 606 607 608 609 610 611 612 613 614 615 616 617 618 619 620 621 622 623 624 3.2 Element <SignResponse> 3.2.1 Element <Result> This profile defines an additional <ResultMajor> code as follows: urn:oasis:names:tc:dss:1.0:resultmajor:warning All EPM result codes are always accompanied by a <ResultMessage> element. 3.2.2 Element <SignatureObject> If successful, the server will return a <dsig:signature> with the signature properties as defined in [DSSCore]. Location of the generated signature will be determined based on signature type and envelope type. All CMS/PKCS7 signatures will be returned in the <SignatureObject> element. XMLSig based enveloping signatures will also be returned in the <SignatureObject> element. See also section 3.1.1.6 entitled Element <SignaturePlacement>. Note: Special cases of the <SignatureObject> as an output element exist when specifying timestamp <SignatureType> s and is described further in section 3.2.4.3. 3.2.3 EPM-specific <OptionalOutputs> The following additional elements are specific to the EPM profile. There specific usage and constraints are documented below. 3.2.3.1 Element <TransactionKey> Please refer to section 3.1.2.2 for a description of how the <TransactionKey> element is used on both input and on output as both an identification mechanism and to support the concept of a multi-event LifeCycle. Copyright OASIS Open 2004. All Rights Reserved. Page 16 of 42
625 626 627 628 629 630 631 632 633 634 635 636 637 638 639 640 641 642 643 644 645 646 647 648 649 650 651 652 653 654 655 656 657 658 659 660 661 662 663 664 665 666 667 668 669 670 671 672 3.2.3.2 Element <PostMarkedReceipt> If the <IssuePostMarkedReceipt> optional input is included, then this optional output will be returned. It is essentially a standalone receipt represented as an enveloping signature. See section 2.7.1 for details. 3.2.3.3 Element <DocumentWithSignature> This element will initialized and returned for XMLSig based signatures. Additionally If the caller is using EPM signing templates and has passed in a signing template (See section 3.1.2.1) in the <DocumentWithTemplate> element, then this output element will contain the signed document. See also section 3.1.1.6 entitled Element <SignaturePlacement>. 3.2.3.4 Element <SignatureInfo> This structure can be returned on both the Sign and Verify operations and is returned whenever the <ReturnSignatureInfo> element is included in the request. Together with the <X509Info> element these elements provide more detail on the signature just created or being verified. The element <SignedContent> is used in conjunction with the Verify operation and allows users to extract the signed content from a CMS signature thus alleviating the need to parse the ASN.1 structure. See <VerifyResponse> below. The <SignedContent> element on a CMS Sign response is empty as the user has just passed this content in to be signed, however the <SignedContent> element on an XMLDSig Sign request will contain the transformed content as it existed prior to digest calculation for the user s reference. Detailed explanation of the other <SignatureInfo> elements can be found in the EPM System Integrator s Guide. <xs:element ref="epm:signatureinfo" <!-- imported from the EPM schema --> <xs:element name="signatureinfo" type="epm:signatureinfotype"> <xs:complextype name="signatureinfotype"> <xs:sequence> <xs:element name="signedcontent" type="base64binary" nillable="true"/> <xs:element name="contenthash" type="xs:string"/> <xs:element name="contenthashalgo" type="xs:string"/> <xs:element name="contentencryptalgo" type="xs:string"/> <xs:element name="signingtime" type="xs:string"/> <xs:element name="pkcs1" type="epm:qualifieddatatype" nillable="true"/> </xs:sequence> </xs:complextype> Note: This optional output does not apply when users have requested a timestamp <SignatureType>. 3.2.3.5 Element <X509Info> This structure is returned whenever the <ReturnX509Info> element is included in the request. The <X509ValidationData> element contains the signed OCSP Validation Data (or equivalent) returned by the EPM attesting to the validity of the certificate used in the signing operation. It will contain signed content as per RFC 2560 and also described in RFC 3126 as returned by a standard OCSP Responder. If an EPM DSS implementation is not using an OCSP responder, then sufficient certificate chain and revocation references must be included here. Additionally, many jurisdictions (e.g. the EU) require that this validation info be signed by the Certified Service Provider (CSP). This is not an issue when using an RFC 2560-compliant OCSP Responder. Definitions of the other elements can be found in the EPM Systems Integrator s Guide. Copyright OASIS Open 2004. All Rights Reserved. Page 17 of 42
673 674 675 676 677 678 679 680 681 682 683 684 685 686 687 688 689 690 691 692 693 694 695 696 697 698 699 700 701 702 703 704 705 706 707 708 709 710 711 712 713 714 715 716 717 718 719 720 721 <xs:element ref="epm:x509info" <!-- imported from the EPM schema --> <xs:element name="x509info" type="epm:x509infotype"> <xs:complextype name="x509infotype"> <xs:sequence> <xs:element name="x509subject" type="xs:string"/> <xs:element name="x509issuer" type="xs:string"/> <xs:element name="x509serial" type="xs:string"/> <xs:element name="x509statussource" type="xs:string"/> <xs:element name="x509validfrom" type="xs:string"/> <xs:element name="x509validto" type="xs:string"/> <xs:element name="x509certificate" type="xs:string"/> <xs:element name="x509revocationreason" type="xs:string" nillable="true"/> <xs:element name="x509revocationreason" type="xs:string" nillable="true"/> <xs:element name="x509revocationtime" type="xs:string" nillable="true"/> <xs:element name="x509validationdata" type="xs:base64binary" nillable="true"/> </xs:sequence> </xs:complextype> Note: This optional output does not apply when users have requested a timestamp <SignatureType>. 3.2.4 Timestamp Handling Profile of Sign Protocol When users are requesting a timestamp <SignatureType> using the EPM Sign profile, input to the timestamp operation can be either of several formats depending on the user s requirements. Currently the following 3 options for creating a timestamp token using the EPM s Sign profile are supported. Please note that this explicit request for a timestamp token is different than the EPM s PostMark and receipting mechanism which can be used on both Sign and Verify operations, and carries specific semantics and functional support. It is also different from the <IssuePostMarkedReceipt> option on the Verify which allows for timestamp and receipt embedding. 3.2.4.1 Standalone Timestamp from <DocumentHash> This timestamp creation scenario is supported by the EPM exactly as described in the Timestamping Profile of the Sign Protocol. The <SignatureType> will govern the type of timestamp to be created. Supported values are: oasis:names:tc:dss:1.0:core:schema:xmltimestamptoken urn:ietf:rfc:3161 The timestamp will be returned in a DSS <SignatureObject> of either of the following types: <dss:timestamp> of type RFC3161TimeStampToken <dss:timestamp> of type <dsig:signature> formatted as an XML Timestamp Token as per section 5.1.1 of [DSSCore] 3.2.4.2 Standalone Timestamp from <Document> This timestamp creation scenario is similar to 3.2.4.1 except that the EPM will calculate the hash for the user as a courtesy function, prior to creating and returning the timestamp. As such it s input and output is identical to 3.2.4.1 above, with the one exception that the data to be used as input to the hash calculation is provided on an incoming <Document> element instead of a <DocumentHash> element. The EPM implementation should decide on the hash algorithm to be employed based on its own TSA Policy. 3.2.4.3 Embedding a Signature Timestamp into a user-provided Signature This timestamp creation scenario is used under the Sign protocol when the user has an existing signature object in their possession and wishes to have it timestamped as specified in the incoming <SignatureType>. The timestamp will be embedded in the user s signature object and is handled as follows: Copyright OASIS Open 2004. All Rights Reserved. Page 18 of 42
722 723 724 725 726 727 728 729 730 731 732 733 734 735 736 737 738 739 740 741 742 For <SignatureType> values of urn:ietf:rfc:3161 The EPM detects from the MimeType attribute (of the <Base64Data> element of the <Document> element) that the input is a CMS/PKCS7 signature. The EPM will embed an RFC 3161 timestamp token into the incoming signature and return the resultant CMS/PKCS7 in the <SignatureObject> element. The timestamp will be embedded as an unsigned attribute as specified in section 3.1.1.4 For <SignatureType> values of oasis:names:tc:dss:1.0:core:schema:xmltimestamptoken Users must pass in an XMLSig compliant signature in the <Document> input element. There must be at most a single signature in the <Document> element and the signature value within that signature must be specified as <dsig:signaturevalue>. The EPM will return a <dss:timestamp> as a standalone <dsig:signature> in the <SignatureObject> element. The <dss:timestamp> will be very similar to Example 1 in section 6 except that the 2 nd <Reference> will not be present. The user must splice the returned <dss:timestamp> into the signed document as desired. It should be noted that timestamping in this manner works best when timestamping detached signatures so as not to invalidate the original signature after splicing the timestamp signature back into the original document. It should be noted that no verification is performed on the incoming signature prior to timestamping. A signature timestamp calculated over the signature value of the incoming signature and the subsequent embedding of that timestamp into the incoming signature is all that is performed. For timestamping of verified signatures, please refer to the Verify Protocol below. Copyright OASIS Open 2004. All Rights Reserved. Page 19 of 42