Document identifier:

oasis-dss-1.0-profiles-timestamping-spec-cd-r2

Location:

http://docs.oasis-open.org/dss/v1.0/

Editor:

Trevor Perrin, individual

Juan Carlos Cruellas, individual <cruellas@ac.upc.edu>

Contributors:

Dimitri Andivahis, Surety

Frederick Hirsch, Nokia

Pieter Kasselman, Betrusted

Andreas Kuehne, individual

Paul Madsen, Entrust

John Messing, American Bar Association

Tim Moses, Entrust

Nick Pope, individual

Rich Salz, DataPower

Ed Shallow, Universal Postal Union

Abstract:

This document profiles the OASIS DSS core protocols for the purpose of creating and verifying XML-encoded time-stamps.

Status:

This is a Public Review Draft produced by the OASIS Digital Signature Service Technical Committee.  Comments may be submitted to the TC by any person by clicking on "Send A Comment" on the TC home page at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Digital Signature Service TC web page at http://www.oasis-open.org/committees/dss/ipr.php.

1     Introduction.. 3

1.1 Notation.. 3

1.2 Namespaces. 3

2     Profile Features.. 4

2.1 Identifier.. 4

2.2 Scope. 4

2.3 Relationship To Other Profiles. 4

2.4 Signature Object.. 4

2.5 Transport Binding.. 4

2.6 Security Binding.. 4

3     Profile of Signing Protocol.. 5

3.1 Element <SignRequest>. 5

3.1.1 Element <OptionalInputs>.. 5

3.1.1.1 Element <SignatureType>. 5

3.1.1.2 Element <RenewTimestamp>. 5

3.1.2 Element <InputDocuments>.. 6

3.2 Element <SignResponse>. 6

3.2.1 Element <Result>.. 6

3.2.2 Element <OptionalOutputs>.. 6

3.2.3 Element <SignatureObject>.. 6

4     Profile of Verifying Protocol.. 8

4.1 Element <VerifyRequest>. 8

4.1.1 Element <OptionalInputs>.. 8

4.1.2 Element <SignatureObject>.. 8

4.1.3 Element <InputDocuments>.. 8

4.2 Element <VerifyResponse>. 8

4.2.1 Element <Result>.. 8

4.2.2 Element <OptionalOutputs>.. 9

4.2.2.1 Element <SigningTimeInfo>. 9

5     Editorial Issues.. 10

6     References.. 11

6.1 Normative. 11

Appendix A. Revision History.. 12

Appendix B. Notices.. 13

The DSS signing and verifying protocols are defined in [DSSCore].  As defined in that document, these protocols have a fair degree of flexibility and extensibility.  This document profiles these protocols to limit their flexibility and extend them in concrete ways.  The resulting profile is suitable for implementation and interoperability.

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

1.1 Notation

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”,

“SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this specification are to be interpreted as described in IETF RFC 2119 [RFC 2119].  These keywords are capitalized when used to unambiguously specify requirements over protocol features and behavior that affect the interoperability and security of implementations.  When these words are not capitalized, they are meant in their natural-language sense.

This specification uses the following typographical conventions in text: <ns:Element>, Attribute, Datatype, OtherCode.

1.2 Namespaces

The structures described in this specification are contained in the schema file [TST-XSD]. All schema listings in the current document are excerpts from the schema file. In the case of a disagreement between the schema file and this document, the schema file takes precedence.

This schema is associated with the following XML namespace:

urn:oasis:names:tc:dss:1.0:profiles:TimeStamp:schema#

Conventional XML namespace prefixes are used in this document:

·         The prefix dss: stands for the DSS core namespace [Core-XSD].

Applications MAY use different namespace prefixes, and MAY use whatever namespace defaulting/scoping conventions they desire, as long as they are compliant with the Namespaces in XML specification [XML-ns].

2.1 Identifier

urn:oasis:names:tc:dss:1.0:profiles:timestamping

2.2 Scope

This document profiles the DSS signing and verifying protocols defined in [DSSCore].

2.3 Relationship To Other Profiles

This profile is based directly on the [DSSCore].

2.4 Signature Object

This profile supports the creation and verification of isolated <dss:Timestamp> elements as defined in [DSSCore]. These elements can wrap different types of time-stamp tokens; this profile does not specify or constrain the internal structure of the <dss:Timestamp>, unless the <dss:SignatureType> optional input is used (see section 3.1.1).

2.5 Transport Binding

This profile is transported using the HTTP POST Transport Binding defined in [DSSCore].

2.6 Security Binding

This profile is secured using the TLS X.509 Server Authentication Binding defined in [DSSCore].

3.1 Element <SignRequest>

3.1.1 Element <OptionalInputs>

The <dss:SignatureType> optional input from [DSSCore] is supported and may be sent by the client. The timestamping specific optional input <RenewTimestamp> may also be supported and may be sent by the client. No other optional inputs are supported.

3.1.1.1 Element <SignatureType>

The <dss:SignatureType> optional input may be one of these values, from section 7. of [DSSCore]:

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

urn:ietf:rfc:3161

Servers may support other values. However, servers are under no obligation to support any particular values. Thus, clients using the <dss:SignatureType> optional input may not interoperate with certain servers.

3.1.1.2 Element <RenewTimestamp>

The <RenewTimestamp> optional input element indicates to the server that the current sign request is a request for the renewal of an existing timestamp on data that were timestamped in the past, so that the validity period of the existing timestamp is effectively extended.

If the <RenewTimestamp> optional input is present in the sign request submitted by the client to the server, and it is supported by the server, the <PreviousTimestamp> element contained in this optional input must also be present as an element of the resulting timestamp generated by the server and returned to the client.  For XML timestamps of type <ds:signature>, processing rules are described in Section 3.2.3.

Before submitting the sign request, the client must verify that the <PreviousTimestamp> element corresponds to the document(s) being re-timestamped, and the client should verify the <PreviousTimestamp> element.

Note: Legitimate reasons to renew a timestamp include (a) the public key certificate used to verify the digital signature in the timestamp is nearing its expiration date, or (b) the client needs to replace the hash value used for the timestamped data in the existing timestamp with a hash value using a stronger hash algorithm.

3.1.2 Element <InputDocuments>

The client MAY send any component of <dss:InputDocument> element as input document. The extraction and processing of these elements MUST be carried out as indicated in the core document, with the changes mentioned in the present document.

If the client is not sending the <dss:SignatureType> optional input, then the client SHOULD only send a single input document, since some types of time-stamps (e.g. RFC 3161) can only cover one document per time-stamp.

If the client is sending the <dss:SignatureType> optional input, then the client MAY send multiple input documents, if the client knows that the specified time-stamp type can handle them.

3.2 Element <SignResponse>

3.2.1 Element <Result>

This profile defines no additional <ResultMinor> codes.

3.2.2 Element <OptionalOutputs>

The server MUST NOT return any optional outputs.

3.2.3 Element <SignatureObject>

The server MUST return a <dss:Timestamp> signature object.

If the <RenewTimestamp> optional input is present in the sign request submitted by the client to the server, and it is supported by the server, the <PreviousTimestamp> element contained in this optional input must also be present as an element of the resulting timestamp generated by the server and returned to the client.  Specifically, for XML processing rules for XML timestamps of type <ds:signature>, the server must include the <PreviousTimestamp> element contained in the optional input as a child of an additional <ds:Signature>/<ds:Object> in the newly generated timestamp (i.e. in addition to the <ds:object> containing the <TstInfo>). An additional <ds:SignedInfo>/<ds:Reference> referencing the <ds:Object>/<dss:PreviousTimestamp> must be included in the signature of the new timestamp signature.

The server generating the new timestamp in response to a request carrying the <RenewTimestamp> optional input need make no assertions about the validity of the <PreviousTimestamp> element submitted to it within this optional input. 

A server that does not support the <RenewTimestamp> optional input must reject the sign request with a <ResultMajor> code of RequesterError and a <ResultMinor> code urn:oasis:names:tc:dss:1.0:resultminor:NotSupported.

4.1 Element <VerifyRequest>

4.1.1 Element <OptionalInputs>

The client may submit the <UseVerificationTime> optional input to instruct the server to determine the timestamp's validity at the specified time, instead of the current time.  No other optional inputs are supported.

4.1.2 Element <SignatureObject>

The client MUST send a <dss:Timestamp> signature object.

Note: A timestamp T₂ that was generated by a server in response to a renewal request for timestamp T₁, that is, in response to a sign request on the same data as for timestamp T₁ and carrying timestamp T₁ within the <PreviousTimestamp> element of the <RenewTimestamp> optional input, may be used to assert current time validity for timestamp T₁.  This situation applies when timestamp T₁'s current time validity can no longer be asserted independently, for example, because the cryptographic primitives in timestamp T₁ are considered compromised.  Specifically, the client may:

·         submit a verify request for timestamp T₂,

·         submit a verify request for timestamp T1 and include the optional input <UseVerificationTime> with a value set to the issue time of timestamp T2 (i.e. using element <SpecificTime>).

If the result codes in the server verify responses indicate that both timestamps are valid as requested, the client may assert that timestamp T₁ is currently valid, as supported by the fact that timestamp T₁ is considered valid at the issue time of timestamp T_2, and timestamp T₂ is considered valid currently.  This process may be generalized to timestamps that were generated after multiple renewal requests on the same data, that is, timestamp T₁, renewed by timestamp T₂, renewed by timestamp T₃, and so on.

4.1.3 Element <InputDocuments>

The client MAY send any component of <dss:InputDocuments> element as input documents. The extraction and processing of these elements MUST be carried out as indicated in the core document, with the changes mentioned in the present document.

4.2 Element <VerifyResponse>

4.2.1 Element <Result>

This profile defines no additional <dss:ResultMinor> codes.

4.2.2 Element <OptionalOutputs>

The server MUST return the <dss:SigningTimeInfo> optional output.

4.2.2.1 Element <SigningTimeInfo>

The server MUST return this optional output profiled as detailed below:

1. Its <dss:SigningTime> child will contain the time indicated in the timestamp token (the value in <dss:CreationTime> element of DSS XML timestamps or the genTime field in RFC 3161 timestamp tokens).
2. If the timestamp token verified includes an indication of the deviation around the time present in the timestamp token (like the accuracy field in RFC 3161 timestamps or the <dss:ErrorBound> element in DSS XML timestamps), its <dss:SigningTimeBoundaries> child MUST be present and it MUST contain the lower and the upper boundaries suitably computed within its children.

The server MUST NOT return any other optional outputs.

1)       What type of signature object should be supported?  An <XMLTimeStampToken> (like now) or a more generic <Timestamp>?

This profile supports a generic Timestamp; a profile of this profile could make it more specific.

2)       What bindings should be used?  A SOAP binding (like now) or a simple HTTP POST binding?

We’re referencing an HTTP POST binding, for now.

3)       Are the clients required to verify received timestamps?  Does this eliminate the need for an authenticated binding in the signing profile?

Right now it says no.

6.1 Normative

 [Core-XSD]            T. Perrin et al.  DSS Schema.  OASIS, (MONTH/YEAR TBD)

[DSSCore]              T. Perrin et al.  Digital Signature Service Core Protocols and Elements.  OASIS, (MONTH/YEAR TBD)

[TST-XSD]              T. Perrin et al. Timestamping Profile Schema, OASIS, (MONTH/YEAR TBD)

[RFC 2119]              S. Bradner.  Key words for use in RFCs to Indicate Requirement Levels. IETF RFC 2396, August 1998.

http://www.ietf.org/rfc/rfc2396.txt.

[XML-ns]                 T. Bray, D. Hollander, A. Layman.  Namespaces in XML.  W3C Recommendation, January 1999.

http://www.w3.org/TR/1999/REC-xml-names-19990114

[XMLSig]                D. Eastlake et al.  XML-Signature Syntax and Processing.  W3C Recommendation, February 2002.

http://www.w3.org/TR/1999/REC-xml-names-19990114

Rev	Date	By Whom	What
wd-01	2004-01-06	Trevor Perrin	Initial version
wd-02	2004-01-20	Trevor Perrin	Added “Type of Signature Object” section, and editorial issues 1-3; organized references
wd-03	2004-02-03	Trevor Perrin	Reorganized; based around <dss:Timestamp> instead of XMLTimeStampToken.
Wd-04	2004-02-29	Trevor Perrin	Changed Verify Response to use <SigningTime> optional output.
Wd-06	2004-06-28	Trevor Perrin	Mentioned as committee draft
Wd-07	2006-04-06	Trevor Perrin	Added optional input RenewTimestamp
Wd-08	2006-08	Juan Carlos Cruellas	Alignment with version 46 of the core
Wd-09	2006-09	Juan Carlos Cruellas	Addition of material for dealing with RenewTimestamp.
Wd-10	2006-09	Juan Carlos Cruellas	Small modification of XML tag for alignment with core.

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

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

Copyright  © OASIS Open 2006. All Rights Reserved.

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

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

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