digital signature service core protocols and elements · oasis-dss-1.0-core-spec-wd-06 12 november...
TRANSCRIPT
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 1 of 31
1
Digital Signature Service Core 2
Protocols and Elements 3
Working Draft 06, 12 November 2003 4
Document identifier: 5 oasis-dss-1.0-core-spec-wd-06 6
Location: 7 http://www.oasis-open.org/committees/dss 8
Editor: 9 Trevor Perrin, individual <[email protected]> 10
Contributors: 11 Dimitri Andivahis, Surety 12 Juan Carlos Cruellas, individual 13 Frederick Hirsch, Nokia 14 Pieter Kasselman, Baltimore 15 Andreas Kuehne, individual 16 John Messing, individual 17 Tim Moses, Entrust 18 Nick Pope, individual 19 Rich Salz, DataPower 20 Ed Shallow, Universal Postal Union 21
Abstract: 22 This draft defines XML request/response protocols for signing, verifying, and time-23 stamping of XML documents and other data. It also defines an XML time-stamp format, 24 and an XML signature property through which a signature server can represent the 25 client’s identity. 26
Status: 27 This is a Working Draft produced by the OASIS Digital Signature Service Technical 28 Committee. Committee members should send comments on this draft to 29 [email protected]. 30
For information on whether any patents have been disclosed that may be essential to 31 implementing this specification, and any offers of patent licensing terms, please refer to 32 the Intellectual Property Rights section of the Digital Signature Service TC web page at 33 http://www.oasis-open.org/committees/dss/ipr.php. 34
35
36
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 2 of 31
Table of Contents 36
1 Introduction ........................................................................................................................ 4 37 1.1 Notation............................................................................................................................ 4 38
1.2 Schema Organization and Namespaces ........................................................................... 4 39 1.3 DSS Overview (Non-normative)........................................................................................ 5 40
2 Common Protocol Structures.............................................................................................. 6 41
2.1 Schema Header and Namespace Declarations ................................................................. 6 42 2.2 Type <AnyType> .............................................................................................................. 6 43
2.3 Type <NameType>........................................................................................................... 6 44 2.4 Element <InputDocuments>.............................................................................................. 7 45
2.4.1 Commonality between <Document> and <DocumentHash>....................................... 7 46 2.4.2 Element <Document>................................................................................................ 7 47 2.4.3 Element <DocumentHash>........................................................................................ 8 48
2.5 Element <Signature>........................................................................................................ 9 49 2.6 Elements <Options> and <Outputs> ................................................................................10 50
2.7 Element <Result>............................................................................................................10 51 3 The DSS Signing Protocol.................................................................................................12 52
3.1 Element <SignRequest> ..................................................................................................12 53
3.2 Element <SignResponse> ...............................................................................................12 54 3.3 Basic Processing.............................................................................................................13 55
3.3.1 Enveloping Signatures..............................................................................................13 56 3.3.2 Enveloped Signatures...............................................................................................13 57
3.4 Options and Outputs........................................................................................................13 58
3.4.1 Option <ServiceProfile>............................................................................................13 59 3.4.2 Option <ServicePolicy> ............................................................................................14 60
3.4.3 Option <ClaimedIdentity> .........................................................................................14 61 3.4.4 Options <SignatureTimestamp> and <ContentTimestamp> ......................................14 62
3.4.5 Option <IntendedAudience> .....................................................................................14 63 3.4.6 Option <KeySelector>...............................................................................................14 64 3.4.7 Option <SignedReferences>.....................................................................................15 65
3.4.8 Option <Properties> .................................................................................................15 66 3.4.9 Option <SignaturePlacement> and Output <OutputDocument>.................................16 67
4 The DSS Verifying Protocol ...............................................................................................18 68 4.1 Element <VerifyRequest> ................................................................................................18 69 4.2 Element <VerifyResponse> .............................................................................................18 70
4.3 Basic Processing.............................................................................................................19 71 4.4 Result Codes...................................................................................................................19 72
4.5 Options and Outputs........................................................................................................20 73 4.5.1 Option <ServiceProfile>............................................................................................20 74
4.5.2 Option <ServicePolicy> ............................................................................................20 75
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 3 of 31
4.5.3 Option <ClaimedIdentity> .........................................................................................20 76 4.5.4 Option <IgnoreMissingInputDocuments> ..................................................................20 77
4.5.5 Option <VerifyManifests>..........................................................................................20 78 4.5.6 Option <VerificationTime> ........................................................................................21 79
4.5.7 Option <AdditionalKeyInfo> ......................................................................................21 80 4.5.8 Option <ReturnProcessingDetails> and Output <ProcessingDetails> ........................21 81 4.5.9 Option <ReturnSigningTime> and Output <SigningTime> .........................................22 82
4.5.10 Option <ReturnSignerIdentity> and Output <SignerIdentity> ...................................22 83 4.5.11 Option <ReturnUpdatedSignature> and Output <UpdatedSignature>......................22 84
5 Timestamp token...............................................................................................................24 85 5.1 Schema Header and Namespace Declarations ................................................................24 86
5.2 Element <Tst> .................................................................................................................24 87 5.3 Element <TstInfo> ...........................................................................................................24 88 5.4 ComplexType TstInfoType...............................................................................................25 89
5.5 Timestamp verification procedure ....................................................................................25 90 6 Editorial Issues..................................................................................................................27 91
7 References .......................................................................................................................28 92 7.1 Normative........................................................................................................................28 93
Appendix A. Revision History.....................................................................................................30 94
Appendix B. Notices ..................................................................................................................31 95
96
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 4 of 31
1 Introduction 97
This specification defines the XML syntax and semantics for the Digital Signature Service core 98 protocols, and for some associated core elements. The core protocols support signing, verifying, 99 and time-stamping of XML documents and other data. The core elements extend XML 100 Signatures [XMLSig] to contain time-stamps and representations of the client’s identity. 101
The core protocol messages are typically bound into other structures for transport, such as XML-102 encoded SOAP messages. The core protocols are also typically profiled to constrain optional 103 features and add additional features. A companion document provides an initial set of bindings 104 and profiles [DSSBind]. A file containing just the core schema [Core-XSD] is also available. 105
The following sections describe how to understand the rest of this specification. 106
1.1 Notation 107
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 108 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be 109 interpreted as described in IETF RFC 2119 [RFC2119]. These keywords are capitalized when 110 used to unambiguously specify requirements over protocol and application features and 111 behaviour that affect the interoperability and security of implementations. When these words are 112 not capitalized, they are meant in their natural-language sense. 113
Listings of DSS schemas appear like this. 114 115
Example code listings appear like this. 116
In cases of disagreement between the the DSS schema file [Core-XSD] and this specification, 117 the schema file takes precedence. 118
Conventional XML namespace prefixes are used throughout the listings in this specification to 119 stand for their respective namespaces (see Section 1.2) as follows, whether or not a namespace 120 declaration is present in the example: 121
• The prefix dss: stands for the DSS namespace. 122
• The prefix ds: stands for the W3C XML Signature namespace [XMLSig-XSD]. 123
• The prefix xs: stands for the W3C XML Schema namespace [Schema1]. 124
This specification uses the following typographical conventions in text: <DSSElement>, 125 <ns:ForeignElement>, Attribute, Datatype, OtherCode. 126
1.2 Schema Organization and Namespaces 127
The DSS core structures are defined in a schema [Core-XSD] associated with the following XML 128 namespace: 129
http://www.oasis-open.org/tc/DSS/1.0/core/schema 130
Imported into this schema is the schema for XML Signature [XMLSig-XSD], which is associated 131 with the following XML namespace: 132
http://www.w3.org/2000/09/xmldsig# 133
134
135
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 5 of 31
1.3 DSS Overview (Non-normative) 136
[This text will be revised as the document matures] 137
This specification outlines an XML based protocol and common XML schema structures 138 necessary to support a delegated XML signing and verification service, as well as a time 139 stamping service. One of the goals is to define an XML-based protocol that can support a variety 140 of signature and timestamp server implementations, supporting both XML signature and non-XML 141 signature services, for example, with a single XML-based protocol. Application profiles and 142 server implementations may constrain what is supported in a specific deployment. The protocol 143 and core elements are designed to be flexible and extensible through the use of an open XML 144 schema. 145
There are two major services supported by this specification – signature and time stamp 146 services. Signature services include signing and verification and may include time mark attributes 147 in signatures. Time mark signature attributes may include the time of signing, for example. The 148 time stamp service is different in that it defines requests, responses and XML schema formats to 149 support authoritative timestamps analogous to the TimeStampToken defined in RFC 3161, 150 supporting proof that a datum existed before a specific point in time. 151
Options are used to allow a variety of complex choices to be uniformly expressed and managed. 152 Signing options include the kind of signature to be returned (e.g. CMS, XML Signature), how an 153 XML signature is to be delivered (detached, enveloped, enveloping), where it is to be placed in a 154 document when not detached, and which signature attributes are to be generated by the server, 155 for example. It is expected that this specification will be profiled to constrain the options and 156 define necessary extensions to support specific applications in an interoperable manner. This 157 specification assumes that protocol requests either succeed or fail, avoiding the complexity of 158 partial success when some options are not met. It is anticipated that application profiles will 159 define meaningful sets of supported options and appropriate defaults. 160
One example of a possible profile is a DSS Web Service Security Profile, defining how the DSS 161 protocol may be used to request SOAP Message security headers containing XML Signatures 162 and the supporting tokens used to convey the corresponding keys. Another example would be a 163 “Corporate Seal” profile, defining how the protocol and structures may be used to support an 164 application that uses a single corporate key to sign documents for data origin authentication. 165
One of the specific goals of this specification is to support interoperation between DSS server 166 implementations as well as interoperability of the signatures and timestamps between DSS-based 167 and non-DSS aware signature and timestamp implementations. 168
How this protocol is used with an underlying protocols is defined by the appropriate protocol 169 bindings document. Use with SOAP, for example, will be defined in the DSS SOAP Bindings 170 specification. 171
This specification does not define general policy mechanisms, but does define interoperable 172 means to specify policies in requests and signatures, using policy QNames that can also be used 173 to specify OIDs. Explicit processing steps may be specified in requests such as “verify an 174 existing signature” before countersigning. 175
Return options include the ability to return supporting information (such as OCSP responses) as 176 well as the information on processing steps followed enabling a client to verify correct operation. 177 A DSS server ultimately determines what actions are taken according to an application profile. 178
179
180
181
182
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 6 of 31
2 Common Protocol Structures 183
2.1 Schema Header and Namespace Declarations 184
The following schema fragment defines the XML namespaces and other header information for 185 the DSS schema: 186
<xs:schema 187 targetNamespace="http://www.oasis-open.org/tc/DSS/1.0/core/schema" 188 xmlns:dss="http://www.oasis-open.org/tc/DSS/1.0/core/schema" 189 xmlns:xs="http://www.w3.org/2001/XMLSchema" 190 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 191 elementFormDefault="qualified" 192 attributeFormDefault="unqualified"> 193
2.2 Type <AnyType> 194
The AnyType complex type allows arbitrary XML content within an element: 195
<xs:complexType name="AnyType"> 196 <xs:sequence> 197 <xs:any processContents="lax" maxOccurs="unbounded"/> 198 </xs:sequence> 199 </xs:complexType> 200
2.3 Type <NameType> 201
The NameType complex type is used where different types of names are needed: 202
<xs:complexType name="NameType"> 203 <xs:simpleContent> 204 <xs:extension base="xs:string"> 205 <xs:attribute name="Format" type="xs:QName"/> 206 </xs:extension> 207 </xs:simpleContent> 208 </xs:complexType> 209
The Format attribute contains an XML Schema QName which determines how the string content 210 is interpreted. A namespace prefix for the QName MUST be provided. The QName may be a 211 value defined by this specification, or a value defined by some other specification, in some other 212 namespace. The values defined by this specification are: 213
EmailAddress 214
Indicates that the string content is in the form of an email address, specifically “addr-spec” as 215 defined in [RFC 2822]. An addr-spec has the form local-part@domain. 216
X509SubjectName 217
Indicates that the string content is in the form specified for the contents of the 218 <ds:X509SubjectName> element in [XMLSig]. 219
URI 220
Indicates that the string content is in the form of a URI as defined in [RFC 2396]. The URI 221 MUST be absolute, and MAY have a fragment identifier (i.e., it may be a URI Reference). 222
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 7 of 31
2.4 Element <InputDocuments> 223
The <InputDocuments> element is used to send documents to a DSS server, whether for 224 signing, verifying, or time-stamping. It consists of any number of the following elements: 225
<Document> [Any Number] 226
An XML document or some other data. 227
<DocumentHash> [Any Number] 228
A hash value of an XML document or some other data. 229
The following schema fragment defines the <InputDocuments> element: 230
<xs:element name="InputDocuments"> 231 <xs:complexType> 232 <xs:sequence> 233 <xs:choice maxOccurs="unbounded"> 234 <xs:element ref="dss:Document"/> 235 <xs:element ref="dss:DocumentHash"/> 236
<xs:any processContents="lax"/> 237 </xs:choice> 238 </xs:sequence> 239 </xs:complexType> 240 </xs:element> 241
2.4.1 Commonality between <Document> and <DocumentHash> 242
Both the <Document> and <DocumentHash> elements contain the following attributes and child 243 elements: 244
ID [Optional] 245
The identifier used to refer to this input document within the protocol message. 246
RefURI [Optional] 247
This specifies the value for the <ds:Reference> element’s URI attribute when referring to 248 this input document. 249
RefType [Optional] 250
This specifies the value for the <ds:Reference> element’s Type attribute when referring to 251 this input document. 252
<ds:Transforms> [Optional] 253
This specifies the value for the <ds:Reference> element’s <ds:Transforms> child 254 element when referring to this input document. 255
2.4.2 Element <Document> 256
The <Document> element may contain the following elements (in addition to the common ones 257 listed in 2.2.1): 258
<XMLData> [Optional] 259
This contains arbitrary XML content. 260
<Base64Data> [Optional] 261
This contains a base64 encoding of an XML document or some other data. The type of data is 262 specified by its MimeType attribute. 263
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 8 of 31
The following schema fragment defines the <Document>, <XMLData>, and <Base64Data> 264 elements: 265
<xs:element name="Document"> 266 <xs:complexType> 267 <xs:sequence> 268 <xs:choice> 269 <xs:element ref="dss:XMLData"/> 270 <xs:element ref="dss:Base64Data"/> 271 </xs:choice> 272 <xs:element ref="ds:Transforms" minOccurs="0"/> 273 </xs:sequence> 274 <xs:attribute name="ID" type="xs:ID" use="optional"/> 275 <xs:attribute name="RefURI" type="xs:anyURI" use="optional"/> 276 <xs:attribute name="RefType" type="xs:anyURI" use="optional"/> 277 </xs:complexType> 278 </xs:element> 279 280 <xs:element name="XMLData" type="dss:AnyType"/> 281 282 <xs:element name="Base64Data"> 283 <xs:complexType> 284 <xs:simpleContent> 285 <xs:extension base="xs:base64Binary"> 286 <xs:attribute name="MimeType" type="xs:string"> 287 </xs:extension> 288 </xs:simpleContent> 289 </xs:complexType> 290 </xs:element> 291
2.4.3 Element <DocumentHash> 292
The <DocumentHash> element contains the following elements (in addition to the common ones 293 listed in 2.2.1): 294
<ds:DigestMethod> [Required] 295
This identifies the digest algorithm used to hash the document. 296
<ds:DigestValue> [Required] 297
This gives the document’s hash value. 298
The following schema fragment defines the <DocumentHash> element: 299
<xs:element name="Document"> 300 <xs:complexType> 301 <xs:sequence> 302 <xs:element ref="ds:DigestMethod"/> 303 <xs:element ref="ds:DigestValue"/> 304 <xs:element ref="ds:Transforms" minOccurs="0"/> 305 </xs:sequence> 306 <xs:attribute name="ID" type="xs:ID" use="optional"/> 307 <xs:attribute name="RefURI" type="xs:anyURI" use="optional"/> 308 <xs:attribute name="RefType" type="xs:anyURI" use="optional"/> 309 </xs:complexType> 310 </xs:element> 311
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 9 of 31
2.5 Element <Signature> 312
The <Signature> element is returned in a sign response, and sent in a verify request. It may 313 contain one of the following elements: 314
<ds:Signature> [Optional] 315
An XML Signature [XMLSig]. 316
<Base64Signature> [Optional] 317
A base64 encoding of some non-XML signature, such as a PGP [PGP] or CMS [CMS] 318 signature. The type of signature is specified by its MimeType attribute. 319
<SignaturePtr> [Optional] 320
This points to an XML Signature that may be in one of the input documents, or one of the 321 outputs. 322
A <SignaturePtr> contains the following elements: 323
WhichDocument [Required] 324
This identifies the document being pointed at. 325
XPath [Optional] 326
This identifies the element being pointed at. It may be omitted if there is only a single 327 <ds:Signature> element in the pointed-to document. 328
The following schema fragment defines the <Signature>, <Base64Signature>, and 329 <SignaturePtr> elements: 330
<xs:element name="Signature"> 331 <xs:complexType> 332 <xs:choice> 333 <xs:element ref="ds:Signature"/> 334 <xs:element ref="dss:Base64Signature"/> 335 <xs:element ref="dss:SignaturePtr"/> 336 <xs:any processContents="lax"/> 337 </xs:choice> 338 </xs:complexType> 339 </xs:element> 340 341 <xs:element name="Base64Signature"> 342 <xs:complexType> 343 <xs:simpleContent> 344 <xs:extension base="xs:base64Binary"> 345 <xs:attribute name="MimeType" type="xs:string"/> 346 </xs:extension> 347 </xs:simpleContent> 348 </xs:complexType> 349 </xs:element> 350 351 <xs:element name="SignaturePtr"> 352 <xs:complexType> 353 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 354 <xs:attribute name="XPath" type="xs:string"/> 355 </xs:complexType> 356 </xs:element> 357
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 10 of 31
2.6 Elements <Options> and <Outputs> 358
All request messages can contain an <Options> element, and all response messages can 359 contain an <Outputs> element. The <Options> contains all options about the request. 360 Profiles will specify which options are allowed and what their default values are. All options 361 SHOULD have some default value, so that a client may omit the <Options> element yet still get 362 service from any DSS server. If a server doesn’t recognize or can’t handle any option, it MUST 363 reject the request outright. Options can appear in any order within the <Options> element. 364
The <Outputs> element contains additional protocol outputs. The client MAY request the server 365 to respond with certain outputs by sending certain options. The server MAY also respond with 366 outputs the client didn’t request, depending on the server’s profile and policy. Outputs can 367 appear in any order within the <Outputs> element. 368
The following schema fragment defines the <Options> and <Outputs> elements: 369
<xs:element name="Options" type="dss:AnyType"/> 370 371 <xs:element name="Outputs" type="dss:AnyType"/> 372
2.7 Element <Result> 373
The <Result> element is returned with every response message. It contains the following 374 elements: 375
<ResultMajor> [Required] 376
The most significant component of the result code. 377
<ResultMinor> [Optional] 378
The least significant component of the result code. 379
<ResultMessage> [Optional] 380
A message which MAY be returned to an operator. 381
The following schema fragment defines the <Result> element: 382
<xs:element name="Result"> 383 <xs:complexType> 384 <xs:sequence> 385 <xs:element name="ResultMajor" type="xs:QName"/> 386 <xs:element name="ResultMinor" type="xs:QName" 387 minOccurs="0"/> 388 <xs:element name="ResultMessage" type="xs:string" 389 minOccurs="0"/> 390 </xs:sequence> 391 </xs:complexType> 392 </xs:element> 393
394
The <ResultMajor> and <ResultMinor> elements each contain an XML Schema QName. A 395 namespace prefix MUST be provided. The <ResultMajor> QName MUST be one of these 396 values: 397
Success 398
The protocol executed succesfully. 399 Requester 400
The request could not be performed due to an error on the part of the requester. 401
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 11 of 31
Responder 402
The request could not be performed due to an error on the part of the responder. 403
The <ResultMinor> QName may be a value defined by this specification, or a value defined by 404 some other specification, in some other namespace. 405
The Requester <ResultMajor> code may be followed by: 406
NotAuthorized 407
The client is not authorized to perform the request. 408 NotSupported 409
The server didn’t recognize or doesn’t support some aspect of the request. 410
The Success <ResultMajor> code on a verify response message SHALL be followed by a 411 <ResultMinor> code which indicates the status of the signature. See section 4 for details. 412
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 12 of 31
3 The DSS Signing Protocol 413
3.1 Element <SignRequest> 414
The <SignRequest> element is sent by the client to request a signature on some input 415 documents. It contains the following elements and attributes: 416
<Options> [Optional] 417
This element contains all options about the request. 418
<InputDocuments> [Required] 419
A lists of input documents which the signature will be calculated over. 420
RequestID [Optional] 421
This attribute is used to correlate requests with responses. When present in a request, the 422 server MUST return it in the response. 423
The following schema fragment defines the <SignRequest> element: 424
<xs:element name="SignRequest"> 425 <xs:complexType> 426 <xs:sequence> 427 <xs:element ref="dss:Options" minOccurs="0"/> 428 <xs:element ref="dss:InputDocuments"/> 429 </xs:sequence> 430 <xs:attribute name="RequestID" type="xs:string" 431 use="optional"/> 432 </xs:complexType> 433 </xs:element> 434
3.2 Element <SignResponse> 435
The <SignResponse> element contains: 436
<Result> [Required] 437
A code representing the status of the request. 438
<Signature> [Optional] 439
The resultant signature, if the request succeeds. 440
<Outputs> [Optional] 441
Any additional outputs returned by the server. 442
RequestID [Optional] 443
This attribute is used to correlate requests with responses. When present in a request, the 444 server MUST return it in the response. 445
The following schema fragment defines the <SignResponse> element: 446
447
448
449
450
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 13 of 31
<xs:element name="SignResponse"> 451 <xs:complexType> 452 <xs:sequence> 453 <xs:element ref="dss:Result"/> 454 <xs:element ref="dss:Signature" minOccurs="0"/> 455 <xs:element ref="dss:Outputs" minOccurs="0"/> 456 </xs:sequence> 457 <xs:attribute name="RequestID" type="xs:string" 458 use="optional"/> 459 </xs:complexType> 460 </xs:element> 461
3.3 Basic Processing 462
With no options, a server receiving a <SignRequest> proceeds as follows: 463
1. The server hashes each input <Document>. 464
2. The server forms a <ds:Reference> for each input document out of its RefURI, RefType, 465 <ds:Transforms>, and hash value. 466
3. The server forms a <ds:SignedInfo> out of the <ds:Reference> elements. 467
4. The server forms a <ds:Signature> by signing the <ds:SignedInfo>. 468
5. The server returns the <ds:Signature>. 469
Additional processing may be carried out as specified by the options, or as implied by the profile 470 the server is operating under. 471
3.3.1 Enveloping Signatures 472
To create an XML Signature that envelopes one or more of the input documents, the client simply 473 splices the appropriate input document(s) into the returned <ds:Signature>. 474
3.3.2 Enveloped Signatures 475
To create an XML Signature that is enveloped by one of the input documents, the client simply 476 indicates an Enveloped Signature Transform [XMLSig] on the appropriate input document, and 477 splices the returned <ds:Signature> into the Input Document. 478
3.4 Options and Outputs 479
This document defines some options and outputs that might be useful in multiple profiles. 480 Profiles can define their own options and outputs, as well. Handling of these is discussed in 2.5. 481
3.4.1 Option <ServiceProfile> 482
The <ServiceProfile> element indicates a particular profile. This may be used to select a 483 profile if a server supports multiple profiles, or as a sanity-check to make sure the server 484 implements the profile the client thinks he does. 485
The following schema fragment defines the <ServiceProfile> element: 486
<xs:element name="ServiceProfile" type="xs:anyURI"/> 487
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 14 of 31
3.4.2 Option <ServicePolicy> 488
The <ServicePolicy> element indicates a particular policy associated with the DSS service. 489 The policy may include information on the characteristics of the server that are not necessarily 490 covered by the <ServiceProfile> element. This may be used to select a specific policy if a 491 service supports multiple policies for a specific profile, or as a sanity-check to make sure the 492 server implements the policy the client thinks he does. 493
The following schema fragment defines the <ServicePolicy> element: 494
<xs:element name="ServicePolicy" type="xs:anyURI"/> 495
3.4.3 Option <ClaimedIdentity> 496
The <ClaimedIdentity> element indicates the identity of the client who is requesting the 497 signature. The server should check this against the client’s authentication credentials, and then 498 may use this to parameterize any aspect of its processing. 499
The following schema fragment defines the <ClaimedIdentity> element: 500
<xs:element name="ClaimedIdentity" type="dss:NameType"/> 501
3.4.4 Options <SignatureTimestamp> and <ContentTimestamp> 502
The <SignatureTimestamp> and <ContentTimestamp> elements are boolean flags that 503 indicate the client wishes the server to provide the appropriate type of timestamp as a signature 504 attribute. Both flags may be present simultaneously. 505
The following schema fragment defines both elements: 506
<xs:element name="SignatureTimestamp"/> 507 <xs:element name="ContentTimestamp"/> 508
3.4.5 Option <IntendedAudience> 509
The <IntendedAudience> element tells the server who the signature is meant for. 510
The following schema fragment defines the <IntendedAudience> element: 511
<xs:element name="IntendedAudience"> 512 <xs:complexType> 513 <xs:sequence> 514 <xs:element name="Recipient" type="dss:NameType" 515 maxOccurs="unbounded"/> 516 </xs:sequence> 517 </xs:complexType> 518 </xs:element> 519
3.4.6 Option <KeySelector> 520
The <KeySelector> element tells the server which key to use. 521
The following schema fragment defines the <KeySelector> element: 522
<xs:element name="KeySelector"> 523 <xs:complexType> 524 <xs:sequence> 525 <xs:element ref="ds:KeyInfo"/> 526 </xs:sequence> 527
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 15 of 31
</xs:complexType> 528 </xs:element> 529
3.4.7 Option <SignedReferences> 530
The <SignedReferences> element gives the client greater control over how the 531 <ds:Reference> elements are formed. When this element is present, the second step of 532 “Basic Processing” is overridden, and instead each <SignedReference> element within 533 <SignedReferences> controls the creation of a corresponding <ds:Reference>. Each 534 <SignedReference> element contains: 535
WhichDocument [Required] 536
Which input document this reference refers to. 537
<RefId> [Optional] 538
Sets the Id attribute on the corresponding <ds:Reference>. 539
<ds:Transforms> [Optional] 540
Requests the server to perform additional transforms on this reference. 541
The following schema fragment defines the <SignedReferences> element: 542
<xs:element name="SignedReferences"> 543 <xs:complexType> 544 <xs:sequence> 545 <xs:element ref="dss:SignedReference" minOccurs="0"/> 546 </xs:sequence> 547 </xs:complexType> 548 </xs:element> 549 550 <xs:element name="SignedReference"> 551 <xs:complexType> 552 <xs:sequence> 553 <xs:element ref="ds:Transforms" minOccurs="0"/> 554 </xs:sequence> 555 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 556 <xs:attribute name="RefId" type="xs:string" use="optional"/> 557 </xs:complexType> 558 </xs:element> 559
3.4.8 Option <Properties> 560
The <Properties> element is used to request that the server add certain signed or unsigned 561 properties (aka “attributes”) into the signature. The client can send the server a particular value 562 to use for each property, or leave that up to the server to determine. The <Properties> 563 element contains: 564
<SignedProperties> [Optional] 565
These properties will be covered by the signature. 566
<UnsignedProperties> [Optional] 567
These properties will not be covered by the signature. 568
569
570
571
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 16 of 31
Each <Property> element contains: 572
<Identifier> [Required] 573
A QName identifying the property. 574
<Value> [Optional] 575
If present, the value the server should use for the property. 576
The following schema fragment defines the <Properties> element: 577
<xs:element name="Properties"> 578 <xs:complexType> 579 <xs:sequence> 580 <xs:element name="SignedProperties" 581 type="dss:PropertiesType" minOccurs="0"/> 582 <xs:element name="UnsignedProperties" 583 type="dss: PropertiesType" minOccurs="0"/> 584 </xs:sequence> 585 </xs:complexType> 586 </xs:element> 587 588 <xs:complexType name="PropertiesType"> 589 <xs:sequence> 590 <xs:element ref="dss:Property" maxOccurs="unbounded"/> 591 </xs:sequence> 592 </xs:complexType> 593 594 <xs:element name="Property"> 595 <xs:complexType> 596 <xs:sequence> 597 <xs:element name="Identifier" type="xs:QName"/> 598 <xs:element name="Value" type="dss:AnyType"/> 599 </xs:sequence> 600 </xs:complexType> 601 </xs:element> 602
3.4.9 Option <SignaturePlacement> and Output <OutputDocument> 603
The <SignaturePlacement> element instructs the server to place the signature inside one of 604 the input documents, and return the resulting document. The <SignaturePlacement> element 605 contains the following attributes and elements: 606
WhichDocument [Required] 607
Identifies the input document which the signature will be inserted into. 608
<XPathAfter> [Optional] 609
Identifies an element, in the input document, which the signature will be inserted after. 610
<XPathFirstChildOf> [Optional] 611
Identifies an element, in the input document, which the signature will be inserted as the first 612 child of. 613
The <OutputDocument> element contains the XML input document with the signature inserted. 614 It has one child element: 615
<XMLData> [Optional] 616
This contains arbitrary XML content. 617
618
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 17 of 31
The following schema fragment defines the <SignaturePlacement> and <OutputDocument> 619 elements: 620
<xs:element name="SignaturePlacement"> 621 <xs:complexType> 622 <xs:choice> 623 <xs:element name="XPathAfter" type="xs:string"/> 624 <xs:element name="XPathFirstChildOf" type="xs:string"/> 625 </xs:choice> 626 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 627 </xs:complexType> 628 </xs:element> 629 630 <xs:element name="OutputDocument"> 631 <xs:complexType> 632 <xs:sequence> 633 <xs:element ref="XMLData"/> 634 <xs:sequence> 635 </xs:complexType> 636 </xs:element> 637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 18 of 31
4 The DSS Verifying Protocol 653
4.1 Element <VerifyRequest> 654
The <VerifyRequest> element is sent by the client to verify a signature on some input 655 documents. It contains the following elements and attributes: 656
<Options> [Optional] 657
This element contains all options about the request. 658
<Signature> [Required] 659
This element contains a signature or points to an XML Signature in one of the Input 660 Documents. 661
<InputDocuments> [Required] 662
A lists of input documents which the signature was calculated over. 663
RequestID [Optional] 664
This attribute is used to correlate requests with responses. When present in a request, the 665 server MUST return it in the response. 666
The following schema fragment defines the <VerifyRequest> element: 667
<xs:element name="VerifyRequest"> 668 <xs:complexType> 669 <xs:sequence> 670 <xs:element ref="dss:Options" minOccurs="0"/> 671 <xs:element ref="dss:Signature" minOccurs="0"/> 672 <xs:element ref="dss:InputDocuments"/> 673 </xs:sequence> 674 <xs:attribute name="RequestID" type="xs:string" 675 use="optional"/> 676 </xs:complexType> 677 </xs:element> 678
4.2 Element <VerifyResponse> 679
The <VerifyResponse> element contains: 680
<Result> [Required] 681
A code representing the status of the corresponding request. 682
<Outputs> [Optional] 683
Any outputs that were requested by the presence of a corresponding option in the 684 <VerifyRequest> message. 685
RequestID [Optional] 686
This attribute is used to correlate requests with responses. When present in a request, the 687 server MUST return it in the response. 688
The following schema fragment defines the <VerifyResponse> element: 689
690
691
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 19 of 31
<xs:element name="VerifyResponse"> 692 <xs:complexType> 693 <xs:sequence> 694 <xs:element ref="dss:Result"/> 695 <xs:element ref="dss:Outputs" minOccurs="0"/> 696 </xs:sequence> 697 <xs:attribute name="RequestID" type="xs:string" 698 use="optional"/> 699 </xs:complexType> 700 </xs:element> 701
4.3 Basic Processing 702
With no options, a server receiving a <VerifyRequest> proceeds as follows: 703
1. The server dereferences the <Signature> element to retrieve the [XMLSig] signature. 704
2. For each <ds:Reference> in the signature, the server finds the input document with 705 matching RefURI and RefType values. 706
3. If the input document is a <DocumentHash>, the server checks that the 707 <ds:Transforms>, <ds:DigestMethod>, and <ds:DigestValue> elements match 708 between the <DocumentHash> and the <ds:Reference>. 709
4. If the input document is a <Document>, the server applies any transforms specified by the 710 <ds:Reference>, and then hashes the resultant data object according to 711 <ds:DigestMethod>, and checks that the result matches <ds:DigestValue>. 712
5. The server then validates the signature according to section 3.2.2 in [XMLSig]. 713
Additional processing may be carried out as specified by the options, or as implied by the profile 714 the server is operating under. 715
4.4 Result Codes 716
Whether the signature succeeds or fails to verify, the server will return the Success 717 <ResultMajor> code. The <ResultMinor> QName must be one of the following values, or 718 some other value defined by some profile of this specification: 719
ValidSignature 720
The signature is valid. 721
IndeterminateKey 722
The server could not determine whether the signing key is valid. For example, the server 723 might not have been able to construct a certificate path to the signing key. 724
UntrustedKey 725
The signature is performed by a key the server considers suspect. For example, the signing 726 key may have been revoked, or it may be a different key from what the server is expecting the 727 signer to use. 728
IncorrectSignature 729
The signature fails to verify, indicating that the message was modified in transit, or that the 730 signature was performed incorrectly. 731
732
733
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 20 of 31
4.5 Options and Outputs 734
This document defines some options and outputs that might be useful in multiple profiles. 735 Profiles can define their own options and outputs, as well. 736
4.5.1 Option <ServiceProfile> 737
The <ServiceProfile> element indicates a particular profile. This may be used to select a 738 profile if a server supports multiple profiles, or as a sanity-check to make sure the server 739 implements the profile the client thinks he does. 740
The following schema fragment defines the <ServiceProfile> element: 741
<xs:element name="ServiceProfile" type="xs:anyURI"/> 742
4.5.2 Option <ServicePolicy> 743
The <ServicePolicy> element indicates a particular policy associated with the DSS service. 744 The policy may include information on the characteristics of the server that are not necessarily 745 covered by the <ServiceProfile> element. This may be used to select a specific policy if a 746 service supports multiple policies for a specific profile, or as a sanity-check to make sure the 747 server implements the policy the client thinks he does. 748
The following schema fragment defines the <ServicePolicy> element: 749
<xs:element name="ServicePolicy" type="xs:anyURI"/> 750
4.5.3 Option <ClaimedIdentity> 751
The <ClaimedIdentity> element indicates the identity of the client who is requesting the 752 verification. The server should check this against the client’s authentication credentials, and then 753 may use this to parameterize any aspect of its processing. 754
The following schema fragment defines the <ClaimedIdentity> element: 755
<xs:element name="ClaimedIdentity" type="dss:NameType"/> 756
4.5.4 Option <IgnoreMissingInputDocuments> 757
The presence of this element instructs the server not to give an error if he can’t find an input 758 document that matches a particular <ds:Reference>, but instead to assume that the client has 759 already validated this <ds:Reference> himself. 760
The following schema fragment defines the <IgnoreMissingInputDocuments> element: 761
<xs:element name="IgnoreMissingInputDocuments"/> 762
4.5.5 Option <VerifyManifests> 763
The presence of this element instructs the server to attempt to validate any input documents it 764 encounters whose Type attribute equals 765 http://www.w3.org/2000/09/xmldsig#Manifest. Such an input document MUST 766 contain an XML element of type ds:ManifestType. On encountering such a document in step 2 767 of basic processing, the server should repeat step 2 for all the <ds:Reference> elements within 768 the manifest. 769
770
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 21 of 31
The following schema fragment defines the <VerifyManifests> element: 771
<xs:element name="VerifyManifests"/> 772
4.5.6 Option <VerificationTime> 773
This element instructs the server to attempt to determine the signature’s validity at the specified 774 time, instead of the current time. 775
The following schema fragment defines the <VerificationTime> element: 776
<xs:element name="VerificationTime" type="xs:dateTime"/> 777
4.5.7 Option <AdditionalKeyInfo> 778
This element provides the server with additional data (such as certificates and CRLs) which it can 779 use to validate the signing key. 780
The following schema fragment defines the <AdditionalKeyInfo> element: 781
<xs:element name="AdditionalKeyInfo"> 782 <xs:complexType> 783 <xs:sequence> 784 <xs:element ref="ds:KeyInfo"/> 785 </xs:sequence> 786 </xs:complexType> 787 </xs:element> 788
4.5.8 Option <ReturnProcessingDetails> and Output 789
<ProcessingDetails> 790
The presence of the <ReturnProcessingDetails> option instructs the server to return a 791 <ProcessingDetails> output, elaborating on what signature verification steps succeeded or 792 failed. The <ProcessingDetails> element may contain the following child elements: 793
<ValidDetail> [Any Number] 794
A verification aspect that was evaluated and found to be valid. 795
<IndeterminateDetail> [Any Number] 796
A verification aspect that could not be evaluated or was evaluated and returned an 797 indeterminate result. 798
<InvalidDetail> [Any Number] 799
A verification aspect that was evaluated and found to be invalid. 800
These elements each contains an XML Schema QName which identifies the detail. A 801 namespace prefix for the QName MUST be provided. The QName may be a value defined by 802 this specification, or a value defined by some other specification, in some other namespace. The 803 values defined by this specification are the following, interpreted as per [XKMS] section 5.18: 804 IssuerTrust, RevocationStatus, ValidityInterval, Signature. 805
The following schema fragment defines the <ReturnProcessingDetails> and 806 <ProcessingDetails> elements: 807
808
809
810
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 22 of 31
<xs:element name="ReturnProcessingDetails"> 811 812 <xs:element name="ProcessingDetails"> 813 <xs:complexType> 814 <xs:sequence> 815 <xs:element name="ValidDetail" type="xs:QName" 816 minOccurs="0" maxOccurs="unbounded"/> 817 <xs:element name="IndeterminateDetail" type="xs:QName" 818 minOccurs="0" maxOccurs="unbounded"/> 819 <xs:element name="InvalidDetail" type="xs:QName" 820 minOccurs="0" maxOccurs="unbounded"/> 821 </xs:sequence> 822 </xs:complexType> 823 </xs:element> 824
4.5.9 Option <ReturnSigningTime> and Output <SigningTime> 825
The presence of the <ReturnSigningTime> option instructs the server to return a 826 <SigningTime> output. This output contains an indication of when the signature was 827 performed, and a boolean attribute that indicates whether this value should be relied upon or not. 828
The following schema fragment defines the <ReturnSigningTime> and <SigningTime> 829 elements: 830
<xs:element name="ReturnSigningTime"/> 831 832 <xs:element name="SigningTime"> 833 <xs:complexType> 834 <xs:simpleContent> 835 <xs:extension base="xs:dateTime"> 836 <xs:attribute name="Trusted" type="xs:boolean"/> 837 </xs:extension> 838 </xs:simpleContent> 839 </xs:complexType> 840 </xs:element> 841
4.5.10 Option <ReturnSignerIdentity> and Output <SignerIdentity> 842
The presence of the <ReturnSignerIdentity> option instructs the server to return a 843 <SignerIdentity> output. This output contains an indication of who performed the signature. 844
The following schema fragment defines the <ReturnSignerIdentity> and 845 <SignerIdentity> elements: 846
<xs:element name="ReturnSignerIdentity"/> 847 848 <xs:element name="SignerIdentity" type="dss:Name"/> 849
4.5.11 Option <ReturnUpdatedSignature> and Output 850
<UpdatedSignature> 851
The presence of the <ReturnUpdatedSignature> option instructs the server to return an 852 <UpdatedSignature> output. This output contains the original signature with some additional 853 attributes added to it. 854
The following schema fragment defines the <ReturnUpdatedSignature> and 855 <UpdatedSignature> elements: 856
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 23 of 31
<xs:element name="ReturnUpdatedSignature"/> 857 858 <xs:element name="UpdatedSignature"> 859 <xs:complexType> 860 <xs:element ref="dss:Signature"> 861 </xs:complexType> 862 </xs:element> 863
864
865
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 24 of 31
5 Timestamp token 866
This section contains the definition of the timestamp token. 867
5.1 Schema Header and Namespace Declarations 868
The following schema fragment defines the XML namespaces and other header information for 869 the DSS schema: 870
<xs:schema 871 targetNamespace="http://www.oasis-open.org/tc/DSS/1.0/timestamp-872 token/schema" 873 xmlns:tst="http://www.oasis-open.org/tc/DSS/1.0/timestamp-874 token/schema" 875 xmlns:xs="http://www.w3.org/2001/XMLSchema" 876 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 877 elementFormDefault="qualified" 878 attributeFormDefault="unqualified"> 879
This schema imports definitions from the XML Digital Signature schema. 880
5.2 Element <Tst> 881
The <Tst> element represents a single timestamp token. 882
<xs:element name="Tst" type="ds:SignatureType"> 883
The <Tst> element has the same type-definition as the ds:SignatureType definition. In this 884 way, a timestamp token can be created and validated by a conventional XML Digital Signature 885 implementation. 886
The following sections define how the elements of the <ds:Signature> element MUST be 887 used. 888
ds:KeyInfo/ [Required] 889
The <KeyInfo> element SHALL identify the issuer of the timestamp and MAY be used 890 to locate, retrieve and validate the timestamp token signature-verification key. 891
ds:SignedInfo/Reference [Required] 892
The <Reference> element SHALL contain a bare name XPointer reference to the 893 <tstInfo> element. It MUST also reference the document or documents that are 894 timestamped. 895
ds:Object/ [Required] 896
The <TstInfo> element SHALL be contained in an <Object> element. Any extension 897 elements that are not defined by this specification SHALL also be represented as 898 <Object> elements. 899
5.3 Element <TstInfo> 900
A <TstInfo> element MUST be included in the <Tst> element as a 901 <ds:Signature/Object> element. The <TstInfo> element is of type tstInfoType. 902
<xs:element name="TstInfo" type="tst:TstInfoType"> 903
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 25 of 31
5.4 ComplexType TstInfoType 904
This section contains the definition of the tstInfoType complex type. 905
<xs:complexType name="TstInfoType"> 906 <xs:attribute name="SerialNumber" type="xs:integer"/> 907 <xs:attribute name="CreationTime" type="xs:dateTime"/> 908 <xs:attribute name="Policy" type="xs:anyURI" use="optional"/> 909 <xs:attribute name="ErrorBound" type="xs:duration"/> 910 <xs:attribute name="Ordered" type="xs:boolean" default="false"/> 911 </xs:complexType> 912
Defines the following attributes. 913
SerialNumber [Required] 914
This attribute SHALL contain a serial number produced by the timestamp authority. It 915 MUST be unique across all the tokens issued by a particular TSA. Provided relying 916 parties do not accept timestamp tokens from distinct TSAs that use the same name, the 917 combination of the issuer name and the serial number will uniquely identify a timestamp 918 token to a particular relying party. 919
CreationTime [Required] 920
The time at which the token was issued. It SHALL be a time according to the local clock 921 of the authority, no earlier than the time at which the request was completely received 922 and no later than the time at which the signature process was started. 923
Policy [Optional] 924
This attribute SHALL identify the policy under which the token was issued. If the 925 corresponding element appears in the request, then this element MUST contain one of 926 the values supplied in the request. Amongst other things, the TSA’s policy SHOULD 927 identify the fundamental source of its time. 928
ErrorBound [Optional] 929
The TSA’s estimate of the maximum error in its local clock. 930
Ordered [Default=”false”] 931
This attribute SHALL indicate whether or not timestamps issued by this TSA, under this 932 policy, are strictly ordered according to the value and precision of the creationTime 933 attribute value. 934
5.5 Timestamp verification procedure 935
If any one of these steps results in failure, then the timestamp token SHOULD be rejected. 936
1. Locate and verify the signature-verification key corresponding to the ds:KeyInfo/ 937 element contents. 938
2. Verify that the signature-verification key is authorized for verifying timestamps. 939
3. Verify that the signature-verification key conforms with all relevant aspects of the relying-940 party’s policy. 941
4. Verify that all digest and signature algorithms conform with the relying-party’s policy. 942
5. Verify that the signature-verification key is consistent with the 943 ds:SignedInfo/SignatureMethod/@Algorithm attribute value. 944
6. Verify that there is a ds:SignedInfo/Reference/@URI attribute whose value is 945 “#tstInfo”. 946
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 26 of 31
7. Verify that there is a ds:SignedInfo/Reference/@ attribute that correctly identifies 947 the timestamped document. 948
8. Verify that the tstInfo/@policy attribute value is acceptable. 949
9. Establish a maximum acceptable error bound value and verify that the 950 tstInfo/@errorBound attribute value is less than or equal to this value. 951
10. Verify all digests and the signature. 952
11. If comparing the tstInfo/@creationTime attribute value to another time value, first 953 verify that they differ by more than the maximum acceptable error bound value. 954
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 27 of 31
6 Editorial Issues 955
1) Another way of handling the options is to have each option placed within an <Option> 956 element. This has the advantage that each option could be tagged with a 957 mustUnderstand attribute, so the server would know whether it was okay to ignore the 958 option or not. It has the disadvantage of making things a little more verbose. 959
Resolution: Leave as is, per 10/20/2003 meeting. 960
2) It is suggested that the RequestID option be put in the top level of the protocol structure 961 so that it can be used at the basic level of the DSS protocol handler. 962
Resolution: This has been done, per 10/20/2003 meeting. 963
3) The utility of the <DocumentURI> element has been questioned. 964
Resolution: Since Rich, John, Trevor, and perhaps Andreas seem in favor of removing 965 this, and only Gregor and Juan Carlos, and perhaps Nick, seem in favor of keeping it, it’s 966 been removed. 967
4) Should every Output only be returned if the client requests it, through an Option? 968
Resolution: No - Servers can return outputs on their own initiative, per 11/3/2003 969 meeting. 970
5) Should Signature Placement, and elements to envelope, be made Signature Options? 971
Resolution: Yes - per 11/3/2003 meeting, but hasn’t been done yet. 972
6) Should <Options> be renamed? To <AdditionalInputs>, <Inputs>, <Parameters>, or 973 something else? 974
7) Should we adopt a Timestamp more like Dimitri’s <Tst>? 975
8) The <ProcessingDetails> are a little sketchy, these could be fleshed out. 976
9) A <dss:Signature> can contain a <dss:SignaturePtr>, which uses an XPath expression to 977 point to a signature. This allows a client to send an <InputDocument> to the server with 978 an embedded signature, and just point to the signature, without copying it. Is it 979 acceptable to require all servers to support XPath, for this? 980
981
982
983
984
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 28 of 31
7 References 985
7.1 Normative 986
[CMS] R. Housley. Cryptographic Message Syntax. IETF RFC 3369, August 2002. 987 http://www.ietf.org/rfc/rfc2459.txt. 988
[Core-XSD] T. Perrin et al. DSS Schema. 989 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 990
http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 991 [XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing, World Wide 992
Web Consortium, February 2003. http://www.w3.org/TR/xmldsig-core. 993 [XMLSig-XSD] XML Signature Schema. World Wide Web Consortium. 994
http://w3.org/TR/2000/CR-xmldsig-core-200001031/xmldsig-core-995 schema.xsd. 996
[Excl-C14N] J. Boyer et al. Exclusive XML Canonicalization Version 1.0. World Wide 997 Web Consortium, July 2002. http://www.w3.org/TR/xml-exc-c14n/. 998
[PGP] J. Callas, L. Donnerhacke, H. Finney, R. Thayer. OpenPGP Message 999 Format. IETF RFC 2440, November 1998. 1000 http://www.ietf.org/rfc/rfc2440.txt. 1001
[PKIX] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public Key 1002 Infrastructure Certificate and CRL Profile. IETF RFC 2459, January 1999. 1003 http://www.ietf.org/rfc/rfc2459.txt. 1004
[RFC 2246] T. Dierks, C. Allen. The TLS Protocol Version 1.0. IETF RFC 2246, January 1005 1999. http://www.ietf.org/rfc/rfc2246.txt. 1006
[RFC 2396] T. Berners-Lee et al. Uniform Resource Identifiers (URI): Generic Syntax. 1007 IETF RFC 2396, August, 1998. http://www.ietf.org/rfc/rfc2396.txt. 2000 1008
[RFC 2630] R. Housley. Cryptographic Message Syntax. IETF RFC 2630, June 1999. 1009 http://www.ietf.org/rfc/rfc2630.txt. 1010
[RFC 2822] P. Resnick. Internet Message Format. IETF RFC 2822, April 2001. 2003 1011 http://www.ietf.org/rfc/rfc2822.txt. 2004 1012
[RFC 2945] T. Wu. The SRP Authentication and Key Exchange System. IETF RFC 2945 1013 September 2000. http://www.ietf.org/rfc/rfc2945.txt. 1014
[RFC 3075] D. Eastlake, J. Reagle, D. Solo. XML-Signature Syntax and Processing. 1015 IETF RFC 3075, March 2001. http://www.ietf.org/rfc/rfc3075.txt. 1016
[SAMLCore1.0] E. Maler et al. Assertions and Protocol for the OASIS Security Assertion 1017 Markup Language (SAML). OASIS, November 2002. http://www.oasis- 1018 open.org/committees/download.php/1371/oasis-sstc-saml-core-1.0.pdf. 1019
[Schema1] H. S. Thompson et al. XML Schema Part 1: Structures. World Wide Web 1020 Consortium Recommendation, May 2001. 1021 http://www.w3.org/TR/xmlschema-1/. 1022
[Schema2] P. V. Biron et al. XML Schema Part 2: Datatypes. World Wide Web 1023 Consortium Recommendation, May 2001. 1024 http://www.w3.org/TR/xmlschema-2/. 1025
[UNICODE-C] M. Davis, M. J. Dürst. Unicode Normalization Forms. UNICODE 1026 Consortium, March 2001. 1027 http://www.unicode.org/unicode/reports/tr15/tr15-21.html. 1028
[W3C-CHAR] M. J. Dürst. Requirements for String Identity Matching and String Indexing. 1029 World Wide Web Consortium, July 1998. http://www.w3.org/TR/WD-1030 charreq. 1031
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 29 of 31
[W3C-CharMod] M. J. Dürst. Character Model for the World Wide Web 1.0. World Wide Web 1032 Consortium, April 2002. http://www.w3.org/TR/charmod/. 1033
1034 [XKMS] W. Ford, P. Hallam-Baker, B. Fox, B. Dillaway, B. LaMacchia, J. Epstein, 1035
J. Lapp. XML Key Management Specification (XKMS). W3C Note 30 1036 March 2001. http://www.w3.org/TR/xkms/. 1037
[XML] T. Bray, et al. Extensible Markup Language (XML) 1.0 (Second Edition). 1038 World Wide Web Consortium, October 2000. http://www.w3.org/TR/REC-1039 xml. 1040
[XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing, World Wide Web 1041 Consortium, February 2002. http://www.w3.org/TR/xmldsig-core/. 1042
[XMLSig-XSD] XML Signature Schema. World Wide Web Consortium. 1043 http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-1044 schema.xsd. 1045
1046 1047 1048
1049
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 30 of 31
Appendix A. Revision History 1050
Rev Date By Whom What
wd-01 2003-10-03 Trevor Perrin Initial version
wd-02 2003-10-13 Trevor Perrin Skeleton of verify as well
wd-03 2003-10-19 Trevor Perrin Added TimeStampToken, References
wd-04 2003-10-29 Trevor Perrin Fleshed things out
wd-05 2003-11-9 Trevor Perrin Added Name, clarified options-handling
wd-06 2003-11-12 Trevor Perrin Added more options/outputs
oasis-dss-1.0-core-spec-wd-06 12 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 31 of 31
Appendix B. Notices 1051
OASIS takes no position regarding the validity or scope of any intellectual property or other rights 1052 that might be claimed to pertain to the implementation or use of the technology described in this 1053 document or the extent to which any license under such rights might or might not be available; 1054 neither does it represent that it has made any effort to identify any such rights. Information on 1055 OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS 1056 website. Copies of claims of rights made available for publication and any assurances of licenses 1057 to be made available, or the result of an attempt made to obtain a general license or permission 1058 for the use of such proprietary rights by implementors or users of this specification, can be 1059 obtained from the OASIS Executive Director. 1060
OASIS invites any interested party to bring to its attention any copyrights, patents or patent 1061 applications, or other proprietary rights which may cover technology that may be required to 1062 implement this specification. Please address the information to the OASIS Executive Director. 1063
Copyright © OASIS Open 2003. All Rights Reserved. 1064
This document and translations of it may be copied and furnished to others, and derivative works 1065 that comment on or otherwise explain it or assist in its implementation may be prepared, copied, 1066 published and distributed, in whole or in part, without restriction of any kind, provided that the 1067 above copyright notice and this paragraph are included on all such copies and derivative works. 1068 However, this document itself does not be modified in any way, such as by removing the 1069 copyright notice or references to OASIS, except as needed for the purpose of developing OASIS 1070 specifications, in which case the procedures for copyrights defined in the OASIS Intellectual 1071 Property Rights document must be followed, or as required to translate it into languages other 1072 than English. 1073
The limited permissions granted above are perpetual and will not be revoked by OASIS or its 1074 successors or assigns. 1075
This document and the information contained herein is provided on an “AS IS” basis and OASIS 1076 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1077 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1078 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1079 PARTICULAR PURPOSE. 1080