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

From: Peter Sylvester <[email-masked]>
Date: Fri, 14 May 1999 10:58:05 +0200

> 
> 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.
This is right if you want service.

> 
> Defining serialNumber OPTIONAL will make it very confusing for a client who
> relies on the sequence as well as on the time itself.
No, because the authority has defined their service in advance. 
if the authority defines a service that guarantees strict sequencing,
then this is known in advance.  

> 
> 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 ...".
Me, too. but probably not for the same reasons. 

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  

The authority first defines that it provides a certain service, 
and THEN it uses a certain technology. Whatever you find in the stamp, 
it does'nt matter. if the authority considers never to deliver more than
4.000.000.000 time stamps per second, you may not need a sequence number.

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)??

---

From: "Todd S. Glassey - ELN" <[email-masked]>
Date: Fri, 14 May 1999 08:36:50 -0700

----- Original Message -----
From: Peter Sylvester <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Sent: Friday, May 14, 1999 1:58 AM
Subject: RE: draft-ietf-pkix-time-stamp-01.txt comments ( Re: serialNumber )

> This is right if you want service

I don't think that this is a real-world example.

What this example pre-supposes is that the point of legal contact with the
auction process is distributed or is part of a distributed auction event
processing systems where there are multiple servers all operating on the
same event pool.

This will as likely as not, NEVER happen commercially. With bandwidth and
heavy iron and clustering/SSI being what it is why would anyone try to erect
such a costly system to use.

This is exactly why I have been ranting about the use models for the time
stamping system.

> > serialNumber into the TSTInfo. Otherwise, the field may not be present
...".

This is a problem that will get larger as faster and faster machines are
created. At somepoint, the timebase resolution of the stamp may not be
sufficiently large enough to deal with the speed at which two or more
transactions vie for the queue. And as to two times created by the same
server with the same timestamp, that sounds impossible to me since they
would be served by the same event processing infrastructure so they couldn't
have the same time... unless the time values are represented by too small a
field...

> certificate just because it looks nice (i.e. has the right

What the heck is this stamping system for? Distributed access to stamping
facilities? Critically identifying events, or "authenticating signatures" as
described - I have to ask the burning question - why would I use that? what
would give me a financial interest in doing this? Who is going to pay me to
timestamp stuff?

There is only so much business for TTP's and at some point saturation is
going to occur (it may have already!)

So then what is timestamping really going to be used for? I suggest that the
issue is how to create culpable timestamping process models that people can
operate on a single system, what that means is addressing the following
issues:

    1)    The physical source of time and its
            believability properties (HW and SW timebase services)
    2)    The token structure used to represent the events
            and its proofing facilities
    3)    The crypto services to keep #1 honest and #2 secure
    4)    The remote query/proofing services so that I can
           dispute a timestamp...

Don't get the wrong impression now -
------------------------------------
I think that while the routines described in the Zuceratto/Pinkas/Cain/Adams
Draft are fantastic, but from my perspective, they are putting the cart
before the horse.

What I propose is that the concept and the user requirements for
timestamping are more mundane than distributed processing as proposed in the
initial and revised Time Stamp and Notary Services Drafts to date. That we
should really understand exactly what it is we are trying to accomplish
here, and that the end users want systems not pieces of systems. With that
in mind, what I want to propose is that this timestamping issue is about the
4 issues listed above and not as much, about distributed systems.

If anyone doubts this commercially, then answer the riddle on Fisher and
Bellcore's mind - why hasn't Surety gone public with all the money they are
making?.

The answer is Distributed Systems (whether operated by a TTP or used as
embedded systems) are not what people want,
    A) they want to own it themselves
    B) it has to fit seamlessly into their legacy apps alreay in production,
and
    C) they must have a compelling reason for buying secure time and since
most of them think that they already have it anyway, thanks to the OS
marketing people.

Let me tell you, selling time and timeservices is hard. As the founder of
Coastek and the new Meridianus effort, I can attest to this first hand. So
what I propose is that the use model issue is paramount here and it is still
unaddressed as of today.

The Solution
-------------
What we should do as a standards org, is to create a suite of basic event
representation tokens, and then promugate them to the higher level standards
orgs, as well as the service routines to make and validate them.
But make no mistake, it is the tokens that tie this all together, not the
API routines, they are just a pathway to the token, and this has been the
disconnect in this timestamping process all along.

----

Lets give this wheel another spin - any comments?

Todd

---

From: "Michael Zolotarev" <[email-masked]>
Date: Mon, 17 May 1999 12:54:44 +1000

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

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: "Todd S. Glassey" <[email-masked]>
Date: Mon, 17 May 1999 10:21:14 -0700

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 ---

---

From: Stephen Kent <[email-masked]>
Date: Tue, 18 May 1999 17:28:07 -0400

Todd,

>for details on this (it was filed this AM).

We're doing time stamping.  We are not necessarily adopting the time
stamping architecture of your current employer.  Since there are various
ways that a time stamp authority may establish its credentials, I don't
think we should assume the recursive structure you are proposing.  I'd like
to see a concise and focused characterization of the "chain of custody"
issues before we consider anything along those lines.  When I say "concise
and focused" I mean something with a lot more credibility than typical,
high level marketing text.

>spec is important and fits here. AFTER the TOKENS and their use models are

In general, the IETF does not standardize APIs.  I am not yet persuaded
that this is one of the rare occaisons where we should violate this general
rule.  Look at RFC 2459 (PKIX Part 1). We don't sp[ecify an API for cert
and CRL processing.  For exmaple, one may choose to employ CDSA as na API,
but that's not a requirement.

>(long-term document) storage and authentication.

This is almost certainly too general to be addressed by this PKIX work
item.  Different applications adopts different formats for documents.  We
have not IETF-wide standard for document representation.  Thus it seems
unlikely that we would create a standard format for archiving documents.  I
think the basic model here is that we time stamp a hash of something, and
return a token that can be used to validate the existance of the hashed
thing at some time in the future.  The format of the thing represented by
the hash is outside the scope of this work.

Steve