Subject: TSP. Version 10

From: Denis Pinkas <[email-masked]>
Date: Fri, 13 Oct 2000 13:02:02 +0200

A new version of the Time Stamping Protocol has been placed on the web
server. A URL for this Internet-Draft is:

http://www.ietf.org/internet-drafts/draft-ietf-pkix-time-stamp-10.txt

This version addresses the comments received during the IESG last call
period.

Besides the changes made to accommodate the 24 comments raised by Russ
Housley, the abstract and the introduction have been modified, by myself and
Steve Kent, in order to address some of the concerns raised by Todd Glassey.

If there are no major editorial errors, this version should (hopefully) be
the version to be published as an RFC. Should there be a few minor errors
left, please tell me, since they can still be corrected directly by myself
when the RFC editor transforms the document into an RFC (there a 48 hours
time window to do so).

FYI, the abstract and the introduction are now as follows:

Abstract

A time stamping service allows to prove that a datum existed before 
a particular time. This document describes the format of a request 
sent to a Time Stamping Authority (TSA) and of the response that is 
returned. It also establishes several security-relevant requirements 
for TSA operation, with regards to processing requests to generate 
responses. A TSA may be operated as a Trusted Third Party (TTP) 
service, though other operational models may be appropriate, e.g. an 
organization might require a TSA for internal time stamping purposes. 

Non-repudiation services [ISONR] require the ability to establish the 
existence of data before specified times. This protocol may be used as 
a building block to support such services. An example of how to prove 
that a digital signature was generated during the validity period of 
a public key certificate is given in an annex.

(...)

1.  Introduction

(...)

This standard does not establish overall security requirements for 
TSA operation, just like other PKIX standards do not establish such 
requirements for CA operation. Rather, it is anticipated that a TSA 
will make know to prospective clients the policies it implements to 
ensure accurate time stamp generation, and clients will make use of 
the services of a TSA only if they are satisfied that these policies 
meet their needs.

Denis

---

From: 김성덕 <[email-masked]>
Date: Fri, 13 Oct 2000 21:17:48 +0900

I think that  id-smime-ct-TSTInfo in Appendix D of new TSP draft should be replaced by id-ct-TSTInfo .

TSP version 10
2.4.2 Response Format
id-ct-TSTInfo  OBJECT IDENTIFIER ::= { iso(1) member-body(2) 
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) ct(1) 4}

 Appendix D 
TimeStampToken ::= ContentInfo
     -- contentType is id-signedData as defined in [CMS]
     -- content is SignedData as defined in([CMS])
     -- eContentType within SignedData is id-ct-TSTInfo 
     -- eContent within SignedData is TSTInfo

-- eContentType for a time stamping token

id-smime-ct-TSTInfo  OBJECT IDENTIFIER ::= { id-smime-ct 4 }
id-smime-ct          OBJECT IDENTIFIER ::= { id-smime 1 }
id-smime             OBJECT IDENTIFIER ::= { iso(1) member-body(2)
                     us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 16 }

---

From: "Parag Namjoshi" <[email-masked]>
Date: Thu, 19 Oct 2000 12:55:13 +0530

Hi Denis,

A few minor details.

1. The PKIXTSP ASN.1 module does not define/import PKIFreeText.
2. The text on page 8 refers to PolicyInformation, which is no longer used.
I believe text should refer to TSAPolicyId instead. (ASN.1 module imports
PolicyInformation too.)

Parag.

---

From: "todd glassey" <[email-masked]>
Date: Tue, 24 Oct 2000 09:34:08 -0700

Denis - I want to rewrite the opening paragraphs and will have my versions
of them out to you and to the list in an hour or so..

Please understand I am not against this as a TSP, it is a very well thought
out scenario but I as you are well aware have some fundamental questions
about

    a)    how it is to be used to satisfy any digital evidence models and
which ones it ascribes to.
    b)    how it is totally leveraged against something it does not address
in the slightest, that being the Timing Practices Statement of the Time
provider, and how this is propagated into the marques that the TSA produces.

What I suggest is rather than advancing this effort to a Draft Standard,
that some thought of what the protocol is supposed to accomplish in the real
world and under what constraints it must be operated to accomplish these
things be added to the draft as well as the processes it already
memorializes.

With that said I am off to rewrite the opening paragraphs of the draft - I
will post them shortly!

Todd