Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )

From: "Juan G. de la Vega" <[email-masked]>
Date: Thu, 13 May 1999 15:50:10 +0200

Michael,

    I mainly agree with you; the time itself is a strictly monotonically
increasing function :-)
    I find this field particularly useful in order to device a relative
temporal relationship amongst TSTs (issued by the same TSA) and in case some
record with references  is implemented as an audit activities support. Using
this, 2 given timestamps can be easily compared (<).
    But I also see that this may not be an issue in some cases such as when
a TSA publishes what has been called "signed time".
    Whether it should be optional or mandatory, I do not have strong
opinion, I think it should be there and I will use it most of the times (if
not all).

bye,

Juan.

----- Mensaje original -----
De: Michael Zolotarev <[email-masked]>
Para: <[email-masked]>
Enviado: jueves 13 de mayo de 1999 2:59
Asunto: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )

> The unique monotonic etc serialNumber is critical when you have to resolve
> 'who was the first' argument between two stamps, having the same time
value.
> This may well happen if the resolution of the clock is relatively low, and
> two requests entered the TS server virtually simultaneously. Think about
> on-line betting, auctions, etc.
>
> Defining serialNumber OPTIONAL will make it very confusing for a client
who
> relies on the sequence as well as on the time itself.
>
> And I would be deadly scared of seeing something like "if more than one
time
> stamp are generated with the same time value, then TSA MUST include
> serialNumber into the TSTInfo. Otherwise, the field may not be
present...".
> MichaelZ

---

From: Robert Zuccherato <[email-masked]>
Date: Tue, 18 May 1999 14:56:57 -0400

Michael;

As I said earlier, the place to solve the "who was first" argument is within
the TSTTime field, not with the serial number.  The serial number should be
used just for token identification, the same way certificate serial numbers
are used for certificate identification.

However, I have yet to see a convincing argument that we really need to
solve this problem (or a lot of support for solving it).  With the increased
resolution that we have provided for TSTTime, I don't think that this is a
concern.  For applications that require the answer to "who was first", they
should use a TSA with increased time resolution and which has specified
(within its policy) that it will never produce two timestamps containing the
same time.  However, not all applications will require this.  Remember, the
reason this draft exists is to support non-repudiation of digital
signatures, for which this is not an issue.

Therefore, I think we are okay the way things are.

	Robert.

> ----------
> From: 	Michael Zolotarev[SMTP:[email-masked]]
> Reply To: 	[email-masked]
> Sent: 	Sunday, May 16, 1999 10:54 PM
> To: 	'Peter Sylvester'; [email-masked]
> Subject: 	RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re:
> serialNumber )
> 
> 
> Peter,
> 
> you wrote:
> --------------------------------------------------------------
> >If SerialNumber is present one might be tempted to deduce that the time
> stamps are unique. BUT that is not the way to >interprete the presence of
> a
> SerialNumber
> 
> One should not start to think:
> 
> - I find serialnumber ==> I have unique time stamps
>   (The result is probably true, but why making the test at all?)
> 
> - I don't have serialnumber ==> Not unique time stamps
>   (This may simply be wrong, again, it depends on the service).
> 
> In order to decide which kind of service ou have, I guess, one needs to
> use
> a policy identifier, configuration knowledge, or
> whatever. You don't use a time stamping authority's signing certificate
> just
> because it looks nice (i.e. has the right
> extension)??
> ---------------------------------------------------------------
> 
> Precisely! This is a sort of ambiguity I am trying to remove by mandating
> the serialNumber. The SerialNumber is ALWAYS there, and the time stamps
> are
> ALWAYS unique. Does not it make the whole lot much easier?
> 
> 
> By the way, treating the serialNumber as a uniqueID will work, i.e. the
> serialNumber can be used as a uniqueID. But not in the opposite direction,
> as ID does not have to be incremental and monotonous.
> 
> Regards
> MichaelZ
>

---

From: Robert Zuccherato <[email-masked]>
Date: Tue, 18 May 1999 16:09:30 -0400

Todd;

As I have stated repeatedly, the purpose of standardizing time stamp
protocols within the PKIX working group is to help support non-repudiation
of digital signatures.  As we state in the document "to verify that a
digital signature was applied to a message before the corresponding
certificate was revoked thus allowing a revoked public key certificate to be
used for verifying signatures created prior to the time of revocation."
This is the publicly stated end-use model.

If we can easily add functionality that makes the protocol useful in other
environments, then we will.  However, that is not the goal.  Thus, much of
what you describe below seems to be a bit more elaborate that what is
required (given that CRLs only represent time with one second granularity).
But I haven't read your draft yet.

	Robert.

> ----------
> From: 	Todd S. Glassey[SMTP:[email-masked]]
> Sent: 	Monday, May 17, 1999 1:21 PM
> To: 	IETF PKIX
> Subject: 	Re: draft-ietf-pkix-time-stamp-01.txt comments ( Re:
> serialNumber )
> 
> All,
> I want to really de-rail this conversation before any issues on the
> precision or the type of timing infrastructure needed are decided without
> a
> publicly stated end-use model, since without this, we cannot erect any
> specific solution and the effort becomes, commercially speaking, IMHO, a
> waste of time.
> 
> To that end,  I suggest that we look at the legal and commercial
> requirements for timestamping *before* consuming anymore of PKIX's
> precious
> time here, because it really seems to me that what is needed here is a set
> of standards to represent:
> 
> 1)    The Token Structures - lets come to standards for representing
> events
> before we define how you get access to the event representation
> mechanisms,
> because one without the other is what we have right now and it seems to be
> to be commercially speaking - of limited value at this time.n This would
> constitute a standard for representing events in space-time (we,
> Meridianus,
> call this GeoSpatial or GeoPositional Timestamping) and it should
> including
> recursive stamping to manage the "Chain of Custody" issues - See our new
> ID
> for details on this (it was filed this AM).
> 
> 2)   The API and distributed access services for validating the
> timestamps;
> that is some technically approved methods of using them - here then is
> where
> Z-C-A-P team's routines are given the once over by the Auditors, so the
> API
> spec is important and fits here. AFTER the TOKENS and their use models are
> defined though.
> 
> 3)   And maybe a standard Document Encapsulation Format for archiving
> (long-term document) storage and authentication.
> 
> This last item, #3, is more important than people know now.  The issues
> going on in XML based document filing system and event management
> processed
> based thereon (see www.receipts.org for one example) are opening new
> opportunities for document processing and control systems. These provide
> mechanism for segmenting content and providing embedded parsing services
> to
> some extent, but they don't encapsulate or timestamp documents.
> 
> I suggest that we maybe in addition to the timestamp token standards, that
> we need a public domain/FSF style model that provides a framework for
> storing and validating a document. So to speak, a document harness, and
> that
> without this tool, that none of us are going to be able to build system
> (that we will get paid for), at least in the big picture.
> 
> Todd Glassey
> 
> --- SNIP ---
>