Digital Signature Service Core Protocols and Elements · oasis-dss-1.0-core-spec-wd-07 25 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 4 of 34 111 1 Introduction

oasis-dss-1.0-core-spec-wd-07 25 November 2003 Copyright © OASIS Open 2003. All Rights Reserved. Page 1 of 34

1

Digital Signature Service Core 2

Protocols and Elements 3

Working Draft 07, 25 November 2003 4

Document identifier: 5 oasis-dss-1.0-core-spec-wd-07 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


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 <OptionalInputs> 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 Option <SignatureType>...........................................................................................14 62

3.4.5 Option <AddTimestamp>..........................................................................................14 63 3.4.6 Option <IntendedAudience> .....................................................................................14 64 3.4.7 Option <KeySelector>...............................................................................................15 65

3.4.8 Option <SignedReferences>.....................................................................................15 66 3.4.9 Option <Properties> .................................................................................................15 67

3.4.10 Option <SignaturePlacement> and Output <OutputDocument>...............................16 68 4 The DSS Verifying Protocol ...............................................................................................18 69

4.1 Element <VerifyRequest> ................................................................................................18 70

4.2 Element <VerifyResponse> .............................................................................................18 71 4.3 Basic Processing.............................................................................................................19 72

4.4 Result Codes...................................................................................................................19 73 4.5 Options and Outputs........................................................................................................20 74

4.5.1 Option <ServiceProfile>............................................................................................20 75


4.5.2 Option <ServicePolicy> ............................................................................................20 76 4.5.3 Option <ClaimedIdentity> .........................................................................................20 77

4.5.4 Option <IgnoreMissingInputDocuments> ..................................................................20 78 4.5.5 Option <VerifyManifests>..........................................................................................20 79

4.5.6 Option <VerificationTime> ........................................................................................21 80 4.5.7 Option <AdditionalKeyInfo> ......................................................................................21 81 4.5.8 Option <ReturnProcessingDetails> and Output <ProcessingDetails> ........................21 82

4.5.9 Option <ReturnSigningTime> and Output <SigningTime> .........................................22 83 4.5.10 Option <ReturnSignerIdentity> and Output <SignerIdentity> ...................................22 84

4.5.11 Option <ReturnUpdatedSignature> and Output <UpdatedSignature>......................22 85 4.5.12 Option <ReturnTransformedDocument> and Output <TransformedDocument>.......23 86

5 Timestamp........................................................................................................................24 87 5.1 Schema Header and Namespace Declarations ................................................................24 88 5.2 Element <Timestamp>.....................................................................................................24 89

5.3 Element <XMLTimeStampToken> ...................................................................................24 90 5.4 Element <TstInfo> ...........................................................................................................25 91

5.5 ComplexType TstInfoType...............................................................................................25 92 5.6 Timestamp verification procedure ....................................................................................26 93

6 Requester Identity .............................................................................................................27 94

7 DSS-Defined Identifiers.....................................................................................................28 95 7.1 Name Format Identifiers ..................................................................................................28 96

7.1.1 Unspecified ..............................................................................................................28 97 7.1.2 Email Address ..........................................................................................................28 98 7.1.3 X.509 Subject Name.................................................................................................28 99

7.1.4 Windows Domain Qualified Name.............................................................................28 100 7.1.5 URI...........................................................................................................................28 101

7.2 Signature Type Identifiers ................................................................................................28 102 7.2.1 XML Signature..........................................................................................................29 103

7.2.2 CMS Signature.........................................................................................................29 104 8 Editorial Issues..................................................................................................................30 105 9 References .......................................................................................................................31 106

9.1 Normative........................................................................................................................31 107 Appendix A. Revision History.....................................................................................................33 108

Appendix B. Notices ..................................................................................................................34 109

110


1 Introduction 111

This specification defines the XML syntax and semantics for the Digital Signature Service core 112 protocols, and for some associated core elements. The core protocols support signing and 113 verifying of XML documents and other data. The core elements extend XML Signatures 114 [XMLSig] to contain time-stamps and representations of the client’s identity. 115

The core protocol messages are typically bound into other structures for transport, such as XML-116 encoded SOAP messages. The core protocols are also typically profiled to constrain optional 117 features and add additional features. A companion document provides an initial set of bindings 118 and profiles [DSSBind]. A file containing just the core schema [Core-XSD] is also available. 119

The following sections describe how to understand the rest of this specification. 120

1.1 Notation 121

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 122 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be 123 interpreted as described in IETF RFC 2119 [RFC2119]. These keywords are capitalized when 124 used to unambiguously specify requirements over protocol and application features and 125 behaviour that affect the interoperability and security of implementations. When these words are 126 not capitalized, they are meant in their natural-language sense. 127

Listings of DSS schemas appear like this. 128 129

Example code listings appear like this. 130

In cases of disagreement between the the DSS schema file [Core-XSD] and this specification, 131 the schema file takes precedence. 132

Conventional XML namespace prefixes are used throughout the listings in this specification to 133 stand for their respective namespaces (see Section 1.2) as follows, whether or not a namespace 134 declaration is present in the example: 135

• The prefix dss: stands for the DSS namespace. 136

• The prefix ds: stands for the W3C XML Signature namespace [XMLSig-XSD]. 137

• The prefix xs: stands for the W3C XML Schema namespace [Schema1]. 138

This specification uses the following typographical conventions in text: <DSSElement>, 139 <ns:ForeignElement>, Attribute, Datatype, OtherCode. 140

1.2 Schema Organization and Namespaces 141

The DSS core structures are defined in a schema [Core-XSD] associated with the following XML 142 namespace: 143

urn:oasis:names:tc:dss:1.0:core:schema 144

Imported into this schema are schemas for XML Signatures [XMLSig-XSD] and Timestamps (see 145 section 5) which are associated with the following XML namespaces: 146

http://www.w3.org/2000/09/xmldsig# 147 urn:oasis:names:tc:dss:1.0:timestamp:schema 148

149


150

1.3 DSS Overview (Non-normative) 151

[This text will be revised as the document matures] 152

This specification outlines an XML based protocol and common XML schema structures 153 necessary to support a delegated XML signing and verification service, as well as a time 154 stamping service. One of the goals is to define an XML-based protocol that can support a variety 155 of signature and timestamp server implementations, supporting both XML signature and non-XML 156 signature services, for example, with a single XML-based protocol. Application profiles and 157 server implementations may constrain what is supported in a specific deployment. The protocol 158 and core elements are designed to be flexible and extensible through the use of an open XML 159 schema. 160

There are two major services supported by this specification – signature and time stamp 161 services. Signature services include signing and verification and may include time mark attributes 162 in signatures. Time mark signature attributes may include the time of signing, for example. The 163 time stamp service is different in that it defines requests, responses and XML schema formats to 164 support authoritative timestamps analogous to the TimeStampToken defined in RFC 3161, 165 supporting proof that a datum existed before a specific point in time. 166

Options are used to allow a variety of complex choices to be uniformly expressed and managed. 167 Signing options include the kind of signature to be returned (e.g. CMS, XML Signature), how an 168 XML signature is to be delivered (detached, enveloped, enveloping), where it is to be placed in a 169 document when not detached, and which signature attributes are to be generated by the server, 170 for example. It is expected that this specification will be profiled to constrain the options and 171 define necessary extensions to support specific applications in an interoperable manner. This 172 specification assumes that protocol requests either succeed or fail, avoiding the complexity of 173 partial success when some options are not met. It is anticipated that application profiles will 174 define meaningful sets of supported options and appropriate defaults. 175

One example of a possible profile is a DSS Web Service Security Profile, defining how the DSS 176 protocol may be used to request SOAP Message security headers containing XML Signatures 177 and the supporting tokens used to convey the corresponding keys. Another example would be a 178 “Corporate Seal” profile, defining how the protocol and structures may be used to support an 179 application that uses a single corporate key to sign documents for data origin authentication. 180

One of the specific goals of this specification is to support interoperation between DSS server 181 implementations as well as interoperability of the signatures and timestamps between DSS-based 182 and non-DSS aware signature and timestamp implementations. 183

How this protocol is used with an underlying protocols is defined by the appropriate protocol 184 bindings document. Use with SOAP, for example, will be defined in the DSS SOAP Bindings 185 specification. 186

This specification does not define general policy mechanisms, but does define interoperable 187 means to specify policies in requests and signatures, using policy QNames that can also be used 188 to specify OIDs. Explicit processing steps may be specified in requests such as “verify an 189 existing signature” before countersigning. 190

Return options include the ability to return supporting information (such as OCSP responses) as 191 well as the information on processing steps followed enabling a client to verify correct operation. 192 A DSS server ultimately determines what actions are taken according to an application profile. 193

194

195


2 Common Protocol Structures 196

The following sections describe XML structures that are common to both the signing and verifying 197 protocols. 198

2.1 Schema Header and Namespace Declarations 199

The following schema fragment defines the XML namespaces and other header information for 200 the DSS schema: 201

<xs:schema 202 targetNamespace="http://www.oasis-open.org/tc/DSS/1.0/core/schema" 203 xmlns:dss="http://www.oasis-open.org/tc/DSS/1.0/core/schema" 204 xmlns:xs="http://www.w3.org/2001/XMLSchema" 205 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 206 elementFormDefault="qualified" 207 attributeFormDefault="unqualified"> 208

2.2 Type <AnyType> 209

The AnyType complex type allows arbitrary XML content within an element: 210

<xs:complexType name="AnyType"> 211 <xs:sequence> 212 <xs:any processContents="lax" maxOccurs="unbounded"/> 213 </xs:sequence> 214 </xs:complexType> 215

2.3 Type <NameType> 216

The NameType complex type is used where different types of names are needed. It consists of a 217 string with the following attribute: 218

Format [Optional] 219

A URI reference representing the format in which the string is provided. See section 6.1 for 220 some URI references that MAY be used as the value of the Format attribute. If the Format 221 attribute is not included, the identifier urn:oasis:names:tc:dss:1.0:name-format:unspecified (see 222 section 6.1.1) is in effect. 223

<xs:complexType name="NameType"> 224 <xs:simpleContent> 225 <xs:extension base="xs:string"> 226 <xs:attribute name="Format" type="xs:anyURI"/> 227 </xs:extension> 228 </xs:simpleContent> 229 </xs:complexType> 230

231

232

233

234

235


2.4 Element <InputDocuments> 236

The <InputDocuments> element is used to send documents to a DSS server, whether for 237 signing, verifying, or time-stamping. It consists of any number of the following elements: 238

<Document> [Any Number] 239

An XML document or some other data. 240

<DocumentHash> [Any Number] 241

A hash value of an XML document or some other data. 242

The following schema fragment defines the <InputDocuments> element: 243

<xs:element name="InputDocuments"> 244 <xs:complexType> 245 <xs:sequence> 246 <xs:choice maxOccurs="unbounded"> 247 <xs:element ref="dss:Document"/> 248 <xs:element ref="dss:DocumentHash"/> 249

<xs:any processContents="lax"/> 250 </xs:choice> 251 </xs:sequence> 252 </xs:complexType> 253 </xs:element> 254

2.4.1 Commonality between <Document> and <DocumentHash> 255

Both the <Document> and <DocumentHash> elements contain the following attributes and child 256 elements: 257

ID [Optional] 258

The identifier used to refer to this input document within the protocol message. 259

RefURI [Optional] 260

This specifies the value for the <ds:Reference> element’s URI attribute when referring to 261 this input document. 262

RefType [Optional] 263

This specifies the value for the <ds:Reference> element’s Type attribute when referring to 264 this input document. 265

<ds:Transforms> [Optional] 266

This specifies the value for the <ds:Reference> element’s <ds:Transforms> child 267 element when referring to this input document. 268

2.4.2 Element <Document> 269

The <Document> element may contain the following elements (in addition to the common ones 270 listed in 2.2.1): 271

<XMLData> [Optional] 272

This contains arbitrary XML content. 273

<Base64Data> [Optional] 274

This contains a base64 encoding of an XML document or some other data. The type of data is 275 specified by its MimeType attribute. 276


The following schema fragment defines the <Document>, <XMLData>, and <Base64Data> 277 elements: 278

<xs:element name="Document"> 279 <xs:complexType> 280 <xs:sequence> 281 <xs:choice> 282 <xs:element ref="dss:XMLData"/> 283 <xs:element ref="dss:Base64Data"/> 284 </xs:choice> 285 <xs:element ref="ds:Transforms" minOccurs="0"/> 286 </xs:sequence> 287 <xs:attribute name="ID" type="xs:ID" use="optional"/> 288 <xs:attribute name="RefURI" type="xs:anyURI" use="optional"/> 289 <xs:attribute name="RefType" type="xs:anyURI" use="optional"/> 290 </xs:complexType> 291 </xs:element> 292 293 <xs:element name="XMLData" type="dss:AnyType"/> 294 295 <xs:element name="Base64Data"> 296 <xs:complexType> 297 <xs:simpleContent> 298 <xs:extension base="xs:base64Binary"> 299 <xs:attribute name="MimeType" type="xs:string"> 300 </xs:extension> 301 </xs:simpleContent> 302 </xs:complexType> 303 </xs:element> 304

2.4.3 Element <DocumentHash> 305

The <DocumentHash> element contains the following elements (in addition to the common ones 306 listed in 2.2.1): 307

<ds:DigestMethod> [Required] 308

This identifies the digest algorithm used to hash the document. 309

<ds:DigestValue> [Required] 310

This gives the document’s hash value. 311

The following schema fragment defines the <DocumentHash> element: 312

<xs:element name="Document"> 313 <xs:complexType> 314 <xs:sequence> 315 <xs:element ref="ds:DigestMethod"/> 316 <xs:element ref="ds:DigestValue"/> 317 <xs:element ref="ds:Transforms" minOccurs="0"/> 318 </xs:sequence> 319 <xs:attribute name="ID" type="xs:ID" use="optional"/> 320 <xs:attribute name="RefURI" type="xs:anyURI" use="optional"/> 321 <xs:attribute name="RefType" type="xs:anyURI" use="optional"/> 322 </xs:complexType> 323 </xs:element> 324


2.5 Element <Signature> 325

The <Signature> element is returned in a sign response, and sent in a verify request. It may 326 contain one of the following elements: 327

<ds:Signature> [Optional] 328

An XML Signature [XMLSig]. 329

<tst:Timestamp> [Optional] 330

An XML Timestamp (see section 5). 331

<Base64Signature> [Optional] 332

A base64 encoding of some non-XML signature, such as a PGP [PGP] or CMS [CMS] 333 signature. The type of signature is specified by its Type attribute (see section 6.2). 334

<SignaturePtr> [Optional] 335

This points to an XML Signature that may be in one of the input documents, or one of the 336 outputs. 337

A <SignaturePtr> contains the following elements: 338

WhichDocument [Required] 339

This identifies the document being pointed at. 340

XPath [Optional] 341

This identifies the element being pointed at. It may be omitted if there is only a single 342 <ds:Signature> element in the pointed-to document. 343

The following schema fragment defines the <Signature>, <Base64Signature>, and 344 <SignaturePtr> elements: 345

<xs:element name="Signature"> 346 <xs:complexType> 347 <xs:choice> 348 <xs:element ref="ds:Signature"/> 349 <xs:element ref="tst:Timestamp"/> 350 <xs:element ref="dss:Base64Signature"/> 351 <xs:element ref="dss:SignaturePtr"/> 352 <xs:any processContents="lax"/> 353 </xs:choice> 354 </xs:complexType> 355 </xs:element> 356 357 <xs:element name="Base64Signature"> 358 <xs:complexType> 359 <xs:simpleContent> 360 <xs:extension base="xs:base64Binary"> 361 <xs:attribute name="Type" type="xs:anyURI"/> 362 </xs:extension> 363 </xs:simpleContent> 364 </xs:complexType> 365 </xs:element> 366 367 <xs:element name="SignaturePtr"> 368 <xs:complexType> 369 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 370 <xs:attribute name="XPath" type="xs:string"/> 371 </xs:complexType> 372 </xs:element> 373


2.6 Elements <OptionalInputs> and <Outputs> 374

All request messages can contain an <OptionalInputs> element, and all response messages 375 can contain an <Outputs> element. The <OptionalInputs> contains all options about the 376 request. Profiles will specify which options are allowed and what their default values are. All 377 options SHOULD have some default value, so that a client may omit the <OptionalInputs> 378 element yet still get service from any DSS server. If a server doesn’t recognize or can’t handle 379 any option, it MUST reject the request outright. Options can appear in any order within the 380 <OptionalInputs> element. 381

The <Outputs> element contains additional protocol outputs. The client MAY request the server 382 to respond with certain outputs by sending certain options. The server MAY also respond with 383 outputs the client didn’t request, depending on the server’s profile and policy. Outputs can 384 appear in any order within the <Outputs> element. 385

The following schema fragment defines the <OptionalInputs> and <Outputs> elements: 386

<xs:element name="OptionalInputs" type="dss:AnyType"/> 387 388 <xs:element name="Outputs" type="dss:AnyType"/> 389

2.7 Element <Result> 390

The <Result> element is returned with every response message. It contains the following 391 elements: 392

<ResultMajor> [Required] 393

The most significant component of the result code. 394

<ResultMinor> [Optional] 395

The least significant component of the result code. 396

<ResultMessage> [Optional] 397

A message which MAY be returned to an operator. 398

The following schema fragment defines the <Result> element: 399

<xs:element name="Result"> 400 <xs:complexType> 401 <xs:sequence> 402 <xs:element name="ResultMajor" type="xs:QName"/> 403 <xs:element name="ResultMinor" type="xs:QName" 404 minOccurs="0"/> 405 <xs:element name="ResultMessage" type="xs:string" 406 minOccurs="0"/> 407 </xs:sequence> 408 </xs:complexType> 409 </xs:element> 410

411

The <ResultMajor> and <ResultMinor> elements each contain an XML Schema QName. A 412 namespace prefix MUST be provided. The <ResultMajor> QName MUST be one of these 413 values: 414

Success 415

The protocol executed succesfully. 416 Requester 417


The request could not be performed due to an error on the part of the requester. 418

Responder 419

The request could not be performed due to an error on the part of the responder. 420

The <ResultMinor> QName may be a value defined by this specification, or a value defined by 421 some other specification, in some other namespace. 422

The Requester <ResultMajor> code may be followed by: 423

NotAuthorized 424

The client is not authorized to perform the request. 425

NotSupported 426

The server didn’t recognize or doesn’t support some aspect of the request. 427

The Success <ResultMajor> code on a verify response message SHALL be followed by a 428 <ResultMinor> code which indicates the status of the signature. See section 4 for details. 429


3 The DSS Signing Protocol 430

3.1 Element <SignRequest> 431

The <SignRequest> element is sent by the client to request a signature on some input 432 documents. It contains the following elements and attributes: 433

<OptionalInputs> [Optional] 434

This element contains all options about the request. 435

<InputDocuments> [Required] 436

A lists of input documents which the signature will be calculated over. 437

RequestID [Optional] 438

This attribute is used to correlate requests with responses. When present in a request, the 439 server MUST return it in the response. 440

The following schema fragment defines the <SignRequest> element: 441

<xs:element name="SignRequest"> 442 <xs:complexType> 443 <xs:sequence> 444 <xs:element ref="dss:OptionalInputs" minOccurs="0"/> 445 <xs:element ref="dss:InputDocuments"/> 446 </xs:sequence> 447 <xs:attribute name="RequestID" type="xs:string" 448 use="optional"/> 449 </xs:complexType> 450 </xs:element> 451

3.2 Element <SignResponse> 452

The <SignResponse> element contains: 453

<Result> [Required] 454

A code representing the status of the request. 455

<Signature> [Optional] 456

The resultant signature, if the request succeeds. 457

<Outputs> [Optional] 458

Any additional outputs returned by the server. 459



The following schema fragment defines the <SignResponse> element: 463

464

465

466

467


<xs:element name="SignResponse"> 468 <xs:complexType> 469 <xs:sequence> 470 <xs:element ref="dss:Result"/> 471 <xs:element ref="dss:Signature" minOccurs="0"/> 472 <xs:element ref="dss:Outputs" minOccurs="0"/> 473 </xs:sequence> 474 <xs:attribute name="RequestID" type="xs:string" 475 use="optional"/> 476 </xs:complexType> 477 </xs:element> 478

3.3 Basic Processing 479

With no options, a server receiving a <SignRequest> should produce an XML Signature by 480 performing the following steps: 481

1. The server hashes each input <Document>. 482

2. The server forms a <ds:Reference> for each input document out of its RefURI, RefType, 483 <ds:Transforms>, and hash value. 484

3. The server forms a <ds:SignedInfo> out of the <ds:Reference> elements. 485

4. The server forms a <ds:Signature> by signing the <ds:SignedInfo>. 486

5. The server returns the <ds:Signature>. 487

Additional processing may be carried out as specified by the options, or as implied by the profile 488 the server is operating under. 489

3.3.1 Enveloping Signatures 490

To create an XML Signature that envelopes one or more of the input documents, the client simply 491 splices the appropriate input document(s) into the returned <ds:Signature>. 492

3.3.2 Enveloped Signatures 493

To create an XML Signature that is enveloped by one of the input documents, the client simply 494 indicates an Enveloped Signature Transform [XMLSig] on the appropriate input document, and 495 splices the returned <ds:Signature> into the Input Document. 496

3.4 Options and Outputs 497

This document defines some options and outputs that might be useful in multiple profiles. 498 Profiles can define their own options and outputs, as well. Handling of these is discussed in 499 section 2.5. 500

3.4.1 Option <ServiceProfile> 501

The <ServiceProfile> element indicates a particular profile. This may be used to select a 502 profile if a server supports multiple profiles, or as a sanity-check to make sure the server 503 implements the profile the client thinks he does. 504

The following schema fragment defines the <ServiceProfile> element: 505

<xs:element name="ServiceProfile" type="xs:anyURI"/> 506


3.4.2 Option <ServicePolicy> 507

The <ServicePolicy> element indicates a particular policy associated with the DSS service. 508 The policy may include information on the characteristics of the server that are not necessarily 509 covered by the <ServiceProfile> element. This may be used to select a specific policy if a 510 service supports multiple policies for a specific profile, or as a sanity-check to make sure the 511 server implements the policy the client thinks he does. 512

The following schema fragment defines the <ServicePolicy> element: 513

<xs:element name="ServicePolicy" type="xs:anyURI"/> 514

3.4.3 Option <ClaimedIdentity> 515

The <ClaimedIdentity> element indicates the identity of the client who is requesting the 516 signature. The server should check this against the client’s authentication credentials, and then 517 may use this to parameterize any aspect of its processing. 518

The following schema fragment defines the <ClaimedIdentity> element: 519

<xs:element name="ClaimedIdentity" type="dss:NameType"/> 520

3.4.4 Option <SignatureType> 521

The <SignatureType> element indicates the type of signature to apply. See section 6.2 for 522 some URI references that MAY be used as the value of this element. 523

The following schema fragment defines the <SignatureType> element: 524

<xs:element name="SignatureType" type="xs:anyURI"/> 525

3.4.5 Option <AddTimestamp> 526

The <AddTimestamp> element indicates that the client wishes the server to provide a timestamp 527 as a signature property. The Type attribute, if present, indicates what type of timestamp to apply. 528 Profiles may define allowed values for this attribute. 529

The following schema fragment defines the <AddTimestamp> element: 530

<xs:element name="AddTimestamp"/> 531 <xs:complexType> 532 <xs:attribute name="Type" type="xs:anyURI" use="optional"/> 533 </xs:complexType> 534 </xs:element> 535

3.4.6 Option <IntendedAudience> 536

The <IntendedAudience> element tells the server who the signature is meant for. 537

The following schema fragment defines the <IntendedAudience> element: 538

<xs:element name="IntendedAudience"> 539 <xs:complexType> 540 <xs:sequence> 541 <xs:element name="Recipient" type="dss:NameType" 542 maxOccurs="unbounded"/> 543 </xs:sequence> 544 </xs:complexType> 545


</xs:element> 546

3.4.7 Option <KeySelector> 547

The <KeySelector> element tells the server which key to use. 548

The following schema fragment defines the <KeySelector> element: 549

<xs:element name="KeySelector"> 550 <xs:complexType> 551 <xs:sequence> 552 <xs:element ref="ds:KeyInfo"/> 553 </xs:sequence> 554 </xs:complexType> 555 </xs:element> 556

3.4.8 Option <SignedReferences> 557

The <SignedReferences> element gives the client greater control over how the 558 <ds:Reference> elements are formed. When this element is present, the second step of 559 “Basic Processing” is overridden, and instead each <SignedReference> element within 560 <SignedReferences> controls the creation of a corresponding <ds:Reference>. Each 561 <SignedReference> element contains: 562


Which input document this reference refers to. 564

<RefId> [Optional] 565

Sets the Id attribute on the corresponding <ds:Reference>. 566

<ds:Transforms> [Optional] 567

Requests the server to perform additional transforms on this reference. 568

The following schema fragment defines the <SignedReferences> element: 569

<xs:element name="SignedReferences"> 570 <xs:complexType> 571 <xs:sequence> 572 <xs:element ref="dss:SignedReference" minOccurs="0"/> 573 </xs:sequence> 574 </xs:complexType> 575 </xs:element> 576 577 <xs:element name="SignedReference"> 578 <xs:complexType> 579 <xs:sequence> 580 <xs:element ref="ds:Transforms" minOccurs="0"/> 581 </xs:sequence> 582 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 583 <xs:attribute name="RefId" type="xs:string" use="optional"/> 584 </xs:complexType> 585 </xs:element> 586

3.4.9 Option <Properties> 587

The <Properties> element is used to request that the server add certain signed or unsigned 588 properties (aka “attributes”) into the signature. The client can send the server a particular value 589


to use for each property, or leave that up to the server to determine. The <Properties> 590 element contains: 591

<SignedProperties> [Optional] 592

These properties will be covered by the signature. 593

<UnsignedProperties> [Optional] 594

These properties will not be covered by the signature. 595

Each <Property> element contains: 596

<Identifier> [Required] 597

A QName identifying the property. 598

<Value> [Optional] 599

If present, the value the server should use for the property. 600

The following schema fragment defines the <Properties> element: 601

<xs:element name="Properties"> 602 <xs:complexType> 603 <xs:sequence> 604 <xs:element name="SignedProperties" 605 type="dss:PropertiesType" minOccurs="0"/> 606 <xs:element name="UnsignedProperties" 607 type="dss: PropertiesType" minOccurs="0"/> 608 </xs:sequence> 609 </xs:complexType> 610 </xs:element> 611 612 <xs:complexType name="PropertiesType"> 613 <xs:sequence> 614 <xs:element ref="dss:Property" maxOccurs="unbounded"/> 615 </xs:sequence> 616 </xs:complexType> 617 618 <xs:element name="Property"> 619 <xs:complexType> 620 <xs:sequence> 621 <xs:element name="Identifier" type="xs:QName"/> 622 <xs:element name="Value" type="dss:AnyType"/> 623 </xs:sequence> 624 </xs:complexType> 625 </xs:element> 626

3.4.10 Option <SignaturePlacement> and Output <OutputDocument> 627

The <SignaturePlacement> element instructs the server to place the signature inside one of 628 the input documents, and return the resulting document. The <SignaturePlacement> element 629 contains the following attributes and elements: 630


Identifies the input document which the signature will be inserted into. 632

<XPathAfter> [Optional] 633

Identifies an element, in the input document, which the signature will be inserted after. 634

<XPathFirstChildOf> [Optional] 635


Identifies an element, in the input document, which the signature will be inserted as the first 636 child of. 637

The <DocumentWithSignature> element contains the XML input document with the signature 638 inserted. It has one child element: 639

<XMLData> [Optional] 640

This contains arbitrary XML content. 641

The following schema fragment defines the <SignaturePlacement> and 642 <DocumentWithSignature> elements: 643

<xs:element name="SignaturePlacement"> 644 <xs:complexType> 645 <xs:choice> 646 <xs:element name="XPathAfter" type="xs:string"/> 647 <xs:element name="XPathFirstChildOf" type="xs:string"/> 648 </xs:choice> 649 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 650 </xs:complexType> 651 </xs:element> 652 653 <xs:element name="DocumentWithSignature"> 654 <xs:complexType> 655 <xs:sequence> 656 <xs:element ref="XMLData"/> 657 <xs:sequence> 658 </xs:complexType> 659 </xs:element> 660

661

662

663

664

665

666

667

668

669

670 671

672

673

674

675


4 The DSS Verifying Protocol 676

4.1 Element <VerifyRequest> 677

The <VerifyRequest> element is sent by the client to verify a signature on some input 678 documents. It contains the following elements and attributes: 679

<OptionalInputs> [Optional] 680

This element contains all options about the request. 681

<Signature> [Required] 682

This element contains a signature or points to an XML Signature in one of the Input 683 Documents. 684

<InputDocuments> [Required] 685

A lists of input documents which the signature was calculated over. 686



The following schema fragment defines the <VerifyRequest> element: 690

<xs:element name="VerifyRequest"> 691 <xs:complexType> 692 <xs:sequence> 693 <xs:element ref="dss:OptionalInputs" minOccurs="0"/> 694 <xs:element ref="dss:Signature" minOccurs="0"/> 695 <xs:element ref="dss:InputDocuments"/> 696 </xs:sequence> 697 <xs:attribute name="RequestID" type="xs:string" 698 use="optional"/> 699 </xs:complexType> 700 </xs:element> 701

4.2 Element <VerifyResponse> 702

The <VerifyResponse> element contains: 703

<Result> [Required] 704

A code representing the status of the corresponding request. 705

<Outputs> [Optional] 706

Any outputs that were requested by the presence of a corresponding option in the 707 <VerifyRequest> message. 708



The following schema fragment defines the <VerifyResponse> element: 712

713

714


<xs:element name="VerifyResponse"> 715 <xs:complexType> 716 <xs:sequence> 717 <xs:element ref="dss:Result"/> 718 <xs:element ref="dss:Outputs" minOccurs="0"/> 719 </xs:sequence> 720 <xs:attribute name="RequestID" type="xs:string" 721 use="optional"/> 722 </xs:complexType> 723 </xs:element> 724

4.3 Basic Processing 725

With no options, a server receiving a <VerifyRequest> proceeds as follows: 726

1. The server dereferences the <Signature> element to retrieve the [XMLSig] signature. 727

2. For each <ds:Reference> in the signature, the server finds the input document with 728 matching RefURI and RefType values. 729

3. If the input document is a <DocumentHash>, the server checks that the 730 <ds:Transforms>, <ds:DigestMethod>, and <ds:DigestValue> elements match 731 between the <DocumentHash> and the <ds:Reference>. 732

4. If the input document is a <Document>, the server applies any transforms specified by the 733 <ds:Reference>, and then hashes the resultant data object according to 734 <ds:DigestMethod>, and checks that the result matches <ds:DigestValue>. 735

5. The server then validates the signature according to section 3.2.2 in [XMLSig]. 736

Additional processing may be carried out as specified by the options, or as implied by the profile 737 the server is operating under. 738

4.4 Result Codes 739

Whether the signature succeeds or fails to verify, the server will return the Success 740 <ResultMajor> code. The <ResultMinor> QName must be one of the following values, or 741 some other value defined by some profile of this specification: 742

ValidSignature 743

The signature is valid. 744

IndeterminateKey 745

The server could not determine whether the signing key is valid. For example, the server 746 might not have been able to construct a certificate path to the signing key. 747

UntrustedKey 748

The signature is performed by a key the server considers suspect. For example, the signing 749 key may have been revoked, or it may be a different key from what the server is expecting the 750 signer to use. 751

IncorrectSignature 752

The signature fails to verify, indicating that the message was modified in transit, or that the 753 signature was performed incorrectly. 754

755

756


4.5 Options and Outputs 757

This document defines some options and outputs that might be useful in multiple profiles. 758 Profiles can define their own options and outputs, as well. 759

4.5.1 Option <ServiceProfile> 760

The <ServiceProfile> element indicates a particular profile. This may be used to select a 761 profile if a server supports multiple profiles, or as a sanity-check to make sure the server 762 implements the profile the client thinks he does. 763

The following schema fragment defines the <ServiceProfile> element: 764

<xs:element name="ServiceProfile" type="xs:anyURI"/> 765

4.5.2 Option <ServicePolicy> 766

The <ServicePolicy> element indicates a particular policy associated with the DSS service. 767 The policy may include information on the characteristics of the server that are not necessarily 768 covered by the <ServiceProfile> element. This may be used to select a specific policy if a 769 service supports multiple policies for a specific profile, or as a sanity-check to make sure the 770 server implements the policy the client thinks he does. 771

The following schema fragment defines the <ServicePolicy> element: 772

<xs:element name="ServicePolicy" type="xs:anyURI"/> 773

4.5.3 Option <ClaimedIdentity> 774

The <ClaimedIdentity> element indicates the identity of the client who is requesting the 775 verification. The server should check this against the client’s authentication credentials, and then 776 may use this to parameterize any aspect of its processing. 777

The following schema fragment defines the <ClaimedIdentity> element: 778

<xs:element name="ClaimedIdentity" type="dss:NameType"/> 779

4.5.4 Option <IgnoreMissingInputDocuments> 780

The presence of this element instructs the server not to give an error if he can’t find an input 781 document that matches a particular <ds:Reference>, but instead to assume that the client has 782 already validated this <ds:Reference> himself. 783

The following schema fragment defines the <IgnoreMissingInputDocuments> element: 784

<xs:element name="IgnoreMissingInputDocuments"/> 785

4.5.5 Option <VerifyManifests> 786

The presence of this element instructs the server to attempt to validate any input documents it 787 encounters whose Type attribute equals 788 http://www.w3.org/2000/09/xmldsig#Manifest. Such an input document MUST 789 contain an XML element of type ds:ManifestType. On encountering such a document in step 2 790 of basic processing, the server should repeat step 2 for all the <ds:Reference> elements within 791 the manifest. 792

793


The following schema fragment defines the <VerifyManifests> element: 794

<xs:element name="VerifyManifests"/> 795

4.5.6 Option <VerificationTime> 796

This element instructs the server to attempt to determine the signature’s validity at the specified 797 time, instead of the current time. 798

The following schema fragment defines the <VerificationTime> element: 799

<xs:element name="VerificationTime" type="xs:dateTime"/> 800

4.5.7 Option <AdditionalKeyInfo> 801

This element provides the server with additional data (such as certificates and CRLs) which it can 802 use to validate the signing key. 803

The following schema fragment defines the <AdditionalKeyInfo> element: 804

<xs:element name="AdditionalKeyInfo"> 805 <xs:complexType> 806 <xs:sequence> 807 <xs:element ref="ds:KeyInfo"/> 808 </xs:sequence> 809 </xs:complexType> 810 </xs:element> 811

4.5.8 Option <ReturnProcessingDetails> and Output 812

<ProcessingDetails> 813

The presence of the <ReturnProcessingDetails> option instructs the server to return a 814 <ProcessingDetails> output, elaborating on what signature verification steps succeeded or 815 failed. The <ProcessingDetails> element may contain the following child elements: 816

<ValidDetail> [Any Number] 817

A verification aspect that was evaluated and found to be valid. 818

<IndeterminateDetail> [Any Number] 819

A verification aspect that could not be evaluated or was evaluated and returned an 820 indeterminate result. 821

<InvalidDetail> [Any Number] 822

A verification aspect that was evaluated and found to be invalid. 823

These elements each contains an XML Schema QName which identifies the detail. A 824 namespace prefix for the QName MUST be provided. The QName may be a value defined by 825 this specification, or a value defined by some other specification, in some other namespace. The 826 values defined by this specification are the following, interpreted as per [XKMS] section 5.18: 827 IssuerTrust, RevocationStatus, ValidityInterval, Signature. 828

The following schema fragment defines the <ReturnProcessingDetails> and 829 <ProcessingDetails> elements: 830

831

832

833


<xs:element name="ReturnProcessingDetails"> 834 835 <xs:element name="ProcessingDetails"> 836 <xs:complexType> 837 <xs:sequence> 838 <xs:element name="ValidDetail" type="xs:QName" 839 minOccurs="0" maxOccurs="unbounded"/> 840 <xs:element name="IndeterminateDetail" type="xs:QName" 841 minOccurs="0" maxOccurs="unbounded"/> 842 <xs:element name="InvalidDetail" type="xs:QName" 843 minOccurs="0" maxOccurs="unbounded"/> 844 </xs:sequence> 845 </xs:complexType> 846 </xs:element> 847

4.5.9 Option <ReturnSigningTime> and Output <SigningTime> 848

The presence of the <ReturnSigningTime> option instructs the server to return a 849 <SigningTime> output. This output contains an indication of when the signature was 850 performed, and a boolean attribute that indicates whether this value should be relied upon or not. 851

The following schema fragment defines the <ReturnSigningTime> and <SigningTime> 852 elements: 853

<xs:element name="ReturnSigningTime"/> 854 855 <xs:element name="SigningTime"> 856 <xs:complexType> 857 <xs:simpleContent> 858 <xs:extension base="xs:dateTime"> 859 <xs:attribute name="Trusted" type="xs:boolean"/> 860 </xs:extension> 861 </xs:simpleContent> 862 </xs:complexType> 863 </xs:element> 864

4.5.10 Option <ReturnSignerIdentity> and Output <SignerIdentity> 865

The presence of the <ReturnSignerIdentity> option instructs the server to return a 866 <SignerIdentity> output. This output contains an indication of who performed the signature. 867

The following schema fragment defines the <ReturnSignerIdentity> and 868 <SignerIdentity> elements: 869

<xs:element name="ReturnSignerIdentity"/> 870 871 <xs:element name="SignerIdentity" type="dss:Name"/> 872

4.5.11 Option <ReturnUpdatedSignature> and Output 873

<UpdatedSignature> 874

The presence of the <ReturnUpdatedSignature> option instructs the server to return an 875 <UpdatedSignature> output. This output contains the original signature with some additional 876 attributes added to it. The Type attribute, if present, indicates which type of timestamp to apply. 877 Profiles may define allowed values for this attribute. 878


The following schema fragment defines the <ReturnUpdatedSignature> and 879 <UpdatedSignature> elements: 880

<xs:element name="ReturnUpdatedSignature"/> 881 <xs:complexType> 882 <xs:attribute name="Type" type="xs:anyURI" use="optional"/> 883 </xs:complexType> 884 </xs:element> 885 886 <xs:element name="UpdatedSignature"> 887 <xs:complexType> 888 <xs:element ref="dss:Signature"> 889 </xs:complexType> 890 </xs:element> 891

4.5.12 Option <ReturnTransformedDocument> and Output 892

<TransformedDocument> 893

The presence of the <ReturnTransformedDocument> option instructs the server to return the 894 specified input document after the XML-DSIG transforms have been applied. The following 895 schema fragment defines the <ReturnTransformedDocument> and 896 <TransformedDocument> elements: 897

<xs:element name="ReturnTransformedDocument"/> 898 <xs:complexType> 899 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 900 </xs:complexType> 901 </xs:element> 902 903 <xs:element name="TransformedDocument"> 904 <xs:complexType> 905 <xs:element ref="dss:Document"> 906 </xs:complexType> 907 <xs:attribute name="WhichDocument" type="xs:IDREF"/> 908 </xs:element> 909

910

911

912

913


5 Timestamp 914

This section contains the definition of an XML timestamp element. 915

5.1 Schema Header and Namespace Declarations 916

The following schema fragment defines the XML namespaces and other header information for 917 the timestamp schema: 918

<xs:schema 919 targetNamespace="urn:oasis:names:tc:dss:1.0:timestamp:schema" 920 xmlns:tst="urn:oasis:names:tc:dss:1.0:timestamp:schema" 921 xmlns:xs="http://www.w3.org/2001/XMLSchema" 922 xmlns:ds="http://www.w3.org/2000/09/xmldsig#" 923 xmlns:dss="urn:oasis:names:tc:dss:1.0:core:schema" 924 elementFormDefault="qualified" 925 attributeFormDefault="unqualified"> 926

5.2 Element <Timestamp> 927

An XML Timestamp can contain various types of timestamp tokens: 928

XMLTimeStampToken [Optional] 929

This element is defined in 5.3. 930

RFC3161TimeStampToken [Optional] 931

This element contains a base64-encoded TimeStampToken as defined in [RFC3161]. 932

<xs:element name="Timestamp"> 933 <xs:complexType> 934 <xs:choice> 935 <xs:element name="XMLTimeStampToken"/> 936 <xs:element name="RFC3161TimeStampToken"/> 937 <xs:any processContents="lax"/> 938 <xs:choice> 939 </xs:complexType> 940 </xs:element> 941

5.3 Element <XMLTimeStampToken> 942

The <XMLTimeStampToken> is similar to an RFC 3161 TimeStampToken, but encoded in 943 XML. 944

<xs:element name="XMLTimeStampToken" type="ds:SignatureType"> 945

The <XMLTimeStampToken> element has the same type-definition as the ds:SignatureType 946 definition. In this way, a timestamp token can be created and validated by a conventional XML 947 Digital Signature implementation. 948

The following sections define how the elements of the <ds:Signature> element MUST be 949 used. 950

ds:KeyInfo/ [Required] 951


The <KeyInfo> element SHALL identify the issuer of the timestamp and MAY be used 952 to locate, retrieve and validate the timestamp token signature-verification key. 953

ds:SignedInfo/Reference [Required] 954

The <Reference> element SHALL contain a bare name XPointer reference to the 955 <tstInfo> element. It MUST also reference the document or documents that are 956 timestamped. 957

ds:Object/ [Required] 958

The <TstInfo> element SHALL be contained in an <Object> element. Any extension 959 elements that are not defined by this specification SHALL also be represented as 960 <Object> elements. 961

5.4 Element <TstInfo> 962

A <TstInfo> element MUST be included in the <XMLTimeStampToken> element as a 963 <ds:Signature/Object> element. The <TstInfo> element is of type TstInfoType. 964

<xs:element name="TstInfo" type="tst:TstInfoType"> 965

5.5 ComplexType TstInfoType 966

This section contains the definition of the TstInfoType complex type. 967

<xs:complexType name="TstInfoType"> 968 <xs:attribute name="SerialNumber" type="xs:integer"/> 969 <xs:attribute name="CreationTime" type="xs:dateTime"/> 970 <xs:attribute name="Policy" type="xs:anyURI" use="optional"/> 971 <xs:attribute name="ErrorBound" type="xs:duration"/> 972 <xs:attribute name="Ordered" type="xs:boolean" default="false"/> 973 <xs:attribute name="TSA" type="dss:Name" use="optional"/> 974 </xs:complexType> 975

This type has the following attributes: 976

SerialNumber [Required] 977

This attribute SHALL contain a serial number produced by the timestamp authority. It 978 MUST be unique across all the tokens issued by a particular TSA. Provided relying 979 parties do not accept timestamp tokens from distinct TSAs that use the same name, the 980 combination of the issuer name and the serial number will uniquely identify a timestamp 981 token to a particular relying party. 982

CreationTime [Required] 983

The time at which the token was issued. It SHALL be a time according to the local clock 984 of the authority, no earlier than the time at which the request was completely received 985 and no later than the time at which the signature process was started. 986

Policy [Optional] 987

This attribute SHALL identify the policy under which the token was issued. If the 988 corresponding element appears in the request, then this element MUST contain one of 989 the values supplied in the request. Amongst other things, the TSA’s policy SHOULD 990 identify the fundamental source of its time. 991

ErrorBound [Optional] 992

The TSA’s estimate of the maximum error in its local clock. 993


Ordered [Default=”false”] 994

This attribute SHALL indicate whether or not timestamps issued by this TSA, under this 995 policy, are strictly ordered according to the value and precision of the creationTime 996 attribute value. 997

TSA [Optional] 998

The name of the TSA. 999

5.6 Timestamp verification procedure 1000

If any one of these steps results in failure, then the timestamp token SHOULD be rejected. 1001

1. Locate and verify the signature-verification key corresponding to the ds:KeyInfo/ 1002 element contents. 1003

2. Verify that the signature-verification key is authorized for verifying timestamps. 1004

3. Verify that the signature-verification key conforms with all relevant aspects of the relying-1005 party’s policy. 1006

4. Verify that all digest and signature algorithms conform with the relying-party’s policy. 1007

5. Verify that the signature-verification key is consistent with the 1008 ds:SignedInfo/SignatureMethod/@Algorithm attribute value. 1009

6. Verify that there is a ds:SignedInfo/Reference/@URI attribute whose value is 1010 “#tstInfo”. 1011

7. Verify that there is a ds:SignedInfo/Reference/@URI attribute that correctly 1012 identifies the timestamped document. 1013

8. Verify that the tstInfo/@policy attribute value is acceptable. 1014

9. Establish a maximum acceptable error bound value and verify that the 1015 tstInfo/@errorBound attribute value is less than or equal to this value. 1016

10. Verify all digests and the signature. 1017

11. If comparing the tstInfo/@creationTime attribute value to another time value, first 1018 verify that they differ by more than the maximum acceptable error bound value. 1019

1020

1021


6 Requester Identity 1022

This section contains the definition of an XML Requester Identity element. This element can be 1023 used as a signature property in an XML signature to identify the client who requested the 1024 signature. 1025

This element has the following children: 1026

Name [Required] 1027

The name or role of the requester who requested the signature be performed. 1028

SupportingInfo [Optional] 1029

Information supporting the name (such as a SAML Assertion, Liberty Alliance Authentication 1030 Context, or X.509 Certificate). 1031

The following schema fragment defines the <RequesterIdentity> element: 1032

<xs:element name="RequesterIdentity"> 1033 <xs:complexType> 1034 <xs:sequence> 1035 <xs:element name="Name" type="dss:Name"/> 1036 <xs:element name="SupportingInfo" type="AnyType" 1037 minOccurs="0"/> 1038 <xs:choice> 1039 </xs:complexType> 1040 </xs:element> 1041

1042


7 DSS-Defined Identifiers 1044

The following sections define various URI-based identifiers. Where possible an existing URN is 1045 used to specify a protocol. In the case of IETF protocols the URN of the most current RFC that 1046 specifies the protocol is used. URI references created specifically for DSS have the following 1047 stem: 1048

urn:oasis:names:tc:dss:1.0: 1049

7.1 Name Format Identifiers 1050

The following identifiers MAY be used in the Format attribute of any NameType element (see 1051 section 2.3) to refer to common formats for the content of the NameType. 1052

7.1.1 Unspecified 1053

URI: urn:oasis:names:tc:name-format:unspecified 1054

The interpretation of the element’s content is left to individual implementations. 1055

7.1.2 Email Address 1056

URI: urn:oasis:names:tc:name-format:emailAddress 1057

Indicates that the element’s content is in the form of an email address, specifically “addr-spec” as 1058 defined in [RFC 2822]. An addr-spec has the form local-part@domain. 1059

7.1.3 X.509 Subject Name 1060

URI: urn:oasis:names:tc:name-format:X509SubjectName 1061

Indicates that the element’s content is in the form specified for the contents of the 1062 <ds:X509SubjectName> element in [XMLSig]. 1063

7.1.4 Windows Domain Qualified Name 1064

URI: urn:oasis:names:tc:name-format:WindowsDomainQualifiedName 1065

Indicates that the element’s content is a Windows domain qualified name. A Windows domain 1066 qualified user name is a string of the form “DomainName\UserName”. The domain name and “\” 1067 separator may be omitted. 1068

7.1.5 URI 1069

URI: urn:oasis:names:tc:name-format:uri 1070

Indicates that the element’s content is in the form of a URI as defined in [RFC 2396]. The URI 1071 MUST be absolute, and MAY have a fragment identifier (i.e., it may be a URI Reference). 1072

7.2 Signature Type Identifiers 1073

The following identifiers MAY be used as the content of the <SignatureType> element (see 1074 section 3.4.4). 1075


7.2.1 XML Signature 1076

URI: urn:ietf:rfc:3275 1077

This refers to an XML signature per [XMLSig]. 1078

7.2.2 CMS Signature 1079

URI: urn:ietf:rfc:3369 1080

This refers to a CMS signature per [CMS]. 1081

1082

1083

1084


8 Editorial Issues 1085

1) Another way of handling the options is to have each option placed within an <Option> 1086 element. This has the advantage that each option could be tagged with a 1087 mustUnderstand attribute, so the server would know whether it was okay to ignore the 1088 option or not. It has the disadvantage of making things a little more verbose. 1089

Resolution: Leave as is, per 10/20/2003 meeting. 1090

2) It is suggested that the RequestID option be put in the top level of the protocol structure 1091 so that it can be used at the basic level of the DSS protocol handler. 1092

Resolution: This has been done, per 10/20/2003 meeting. 1093

3) The utility of the <DocumentURI> element has been questioned. 1094

Resolution: Since Rich, John, Trevor, and perhaps Andreas seem in favor of removing 1095 this, and only Gregor and Juan Carlos, and perhaps Nick, seem in favor of keeping it, it’s 1096 been removed. 1097

4) Should every Output only be returned if the client requests it, through an Option? 1098

Resolution: No - Servers can return outputs on their own initiative, per 11/3/2003 1099 meeting. 1100

5) Should Signature Placement, and elements to envelope, be made Signature Options? 1101

Resolution: Yes - per 11/3/2003 meeting, but hasn’t been done yet. 1102

6) Should <Options> be renamed? To <AdditionalInputs>, <Inputs>, <Parameters>, or 1103 something else? 1104

7) Should we adopt a Timestamp more like Dimitri’s <Tst>? 1105

8) The <ProcessingDetails> are a little sketchy, these could be fleshed out. 1106

9) A <dss:Signature> can contain a <dss:SignaturePtr>, which uses an XPath expression to 1107 point to a signature. This allows a client to send an <InputDocument> to the server with 1108 an embedded signature, and just point to the signature, without copying it. Is it 1109 acceptable to require all servers to support XPath, for this? 1110

1111

1112

1113

1114


9 References 1115

9.1 Normative 1116

[CMS] R. Housley. Cryptographic Message Syntax. IETF RFC 3369, August 2002. 1117 http://www.ietf.org/rfc/rfc2459.txt. 1118

[Core-XSD] T. Perrin et al. DSS Schema. 1119 [RFC2119] S. Bradner, Key words for use in RFCs to Indicate Requirement Levels, 1120

http://www.ietf.org/rfc/rfc2119.txt, IETF RFC 2119, March 1997. 1121 [XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing, World Wide 1122

Web Consortium, February 2003. http://www.w3.org/TR/xmldsig-core. 1123 [XMLSig-XSD] XML Signature Schema. World Wide Web Consortium. 1124

http://w3.org/TR/2000/CR-xmldsig-core-200001031/xmldsig-core-1125 schema.xsd. 1126

[Excl-C14N] J. Boyer et al. Exclusive XML Canonicalization Version 1.0. World Wide 1127 Web Consortium, July 2002. http://www.w3.org/TR/xml-exc-c14n/. 1128

[PGP] J. Callas, L. Donnerhacke, H. Finney, R. Thayer. OpenPGP Message 1129 Format. IETF RFC 2440, November 1998. 1130 http://www.ietf.org/rfc/rfc2440.txt. 1131

[PKIX] R. Housley, W. Ford, W. Polk, D. Solo. Internet X.509 Public Key 1132 Infrastructure Certificate and CRL Profile. IETF RFC 2459, January 1999. 1133 http://www.ietf.org/rfc/rfc2459.txt. 1134

[RFC 2246] T. Dierks, C. Allen. The TLS Protocol Version 1.0. IETF RFC 2246, January 1135 1999. http://www.ietf.org/rfc/rfc2246.txt. 1136

[RFC 2396] T. Berners-Lee et al. Uniform Resource Identifiers (URI): Generic Syntax. 1137 IETF RFC 2396, August, 1998. http://www.ietf.org/rfc/rfc2396.txt. 2000 1138

[RFC 2630] R. Housley. Cryptographic Message Syntax. IETF RFC 2630, June 1999. 1139 http://www.ietf.org/rfc/rfc2630.txt. 1140

[RFC 2822] P. Resnick. Internet Message Format. IETF RFC 2822, April 2001. 2003 1141 http://www.ietf.org/rfc/rfc2822.txt. 2004 1142

[RFC 2945] T. Wu. The SRP Authentication and Key Exchange System. IETF RFC 2945 1143 September 2000. http://www.ietf.org/rfc/rfc2945.txt. 1144

[RFC 3075] D. Eastlake, J. Reagle, D. Solo. XML-Signature Syntax and Processing. 1145 IETF RFC 3075, March 2001. http://www.ietf.org/rfc/rfc3075.txt. 1146

[RFC 3161] C. Adams, P. Cain, D. Pinkas, R. Zuccherato. Internet X.509 Public Key 1147 Infrastructure Time-Stamp Protocol (TSP). IETF RFC 3161, August 2001. 1148 http://www.ietf.org/rfc/rfc3161.txt. 1149

[SAMLCore1.0] E. Maler et al. Assertions and Protocol for the OASIS Security Assertion 1150 Markup Language (SAML). OASIS, November 2002. http://www.oasis- 1151 open.org/committees/download.php/1371/oasis-sstc-saml-core-1.0.pdf. 1152

[Schema1] H. S. Thompson et al. XML Schema Part 1: Structures. World Wide Web 1153 Consortium Recommendation, May 2001. 1154 http://www.w3.org/TR/xmlschema-1/. 1155

[Schema2] P. V. Biron et al. XML Schema Part 2: Datatypes. World Wide Web 1156 Consortium Recommendation, May 2001. 1157 http://www.w3.org/TR/xmlschema-2/. 1158

[UNICODE-C] M. Davis, M. J. Dürst. Unicode Normalization Forms. UNICODE 1159 Consortium, March 2001. 1160 http://www.unicode.org/unicode/reports/tr15/tr15-21.html. 1161


[W3C-CHAR] M. J. Dürst. Requirements for String Identity Matching and String Indexing. 1162 World Wide Web Consortium, July 1998. http://www.w3.org/TR/WD-1163 charreq. 1164

[W3C-CharMod] M. J. Dürst. Character Model for the World Wide Web 1.0. World Wide Web 1165 Consortium, April 2002. http://www.w3.org/TR/charmod/. 1166

1167 [XKMS] W. Ford, P. Hallam-Baker, B. Fox, B. Dillaway, B. LaMacchia, J. Epstein, 1168

J. Lapp. XML Key Management Specification (XKMS). W3C Note 30 1169 March 2001. http://www.w3.org/TR/xkms/. 1170

[XML] T. Bray, et al. Extensible Markup Language (XML) 1.0 (Second Edition). 1171 World Wide Web Consortium, October 2000. http://www.w3.org/TR/REC-1172 xml. 1173

[XMLSig] D. Eastlake et al., XML-Signature Syntax and Processing, World Wide Web 1174 Consortium, February 2002. http://www.w3.org/TR/xmldsig-core/. 1175

[XMLSig-XSD] XML Signature Schema. World Wide Web Consortium. 1176 http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/xmldsig-core-1177 schema.xsd. 1178

1179 1180 1181

1182


Appendix A. Revision History 1183

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

wd-07 2003-11-25 Trevor Perrin URNs, <Timestamp>, other changes.


Appendix B. Notices 1184

OASIS takes no position regarding the validity or scope of any intellectual property or other rights 1185 that might be claimed to pertain to the implementation or use of the technology described in this 1186 document or the extent to which any license under such rights might or might not be available; 1187 neither does it represent that it has made any effort to identify any such rights. Information on 1188 OASIS's procedures with respect to rights in OASIS specifications can be found at the OASIS 1189 website. Copies of claims of rights made available for publication and any assurances of licenses 1190 to be made available, or the result of an attempt made to obtain a general license or permission 1191 for the use of such proprietary rights by implementors or users of this specification, can be 1192 obtained from the OASIS Executive Director. 1193

OASIS invites any interested party to bring to its attention any copyrights, patents or patent 1194 applications, or other proprietary rights which may cover technology that may be required to 1195 implement this specification. Please address the information to the OASIS Executive Director. 1196

Copyright © OASIS Open 2003. All Rights Reserved. 1197

This document and translations of it may be copied and furnished to others, and derivative works 1198 that comment on or otherwise explain it or assist in its implementation may be prepared, copied, 1199 published and distributed, in whole or in part, without restriction of any kind, provided that the 1200 above copyright notice and this paragraph are included on all such copies and derivative works. 1201 However, this document itself does not be modified in any way, such as by removing the 1202 copyright notice or references to OASIS, except as needed for the purpose of developing OASIS 1203 specifications, in which case the procedures for copyrights defined in the OASIS Intellectual 1204 Property Rights document must be followed, or as required to translate it into languages other 1205 than English. 1206

The limited permissions granted above are perpetual and will not be revoked by OASIS or its 1207 successors or assigns. 1208

This document and the information contained herein is provided on an “AS IS” basis and OASIS 1209 DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO 1210 ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1211 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 1212 PARTICULAR PURPOSE. 1213