Subject: Re: Time Stamp V7 Data structure

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 May 2000 17:35:05 +0200 (MET DST)

> 
> This is a kind of re-opening the issue of aligning the actual ISO draft
> on time stamping with version 07 of the PKIX time stamping draft.
> 
> I am re-opening it for two reasons: Since the first time (version 5
> discussion) I was expecting a change in the IETF document stating that
> it is optional to have a mechanism identifier (object identifier) in the
> time stamp request and I also expected a modified data structure
> allowing to use the option. None of this happened. This information is a
> prerequisite for developers willing to implement an IETF and ISO
> compatible TSA.
This is not quite true: 

It has been proposed not to indicate a mechanism identifier inside
the information but to allow two different ways secure time
stamps:

- one is using SignedData

- the other one is using DigestedData to support all cases
  where you need a mechanism: The mechanism identifier would
  become the digestalgorithm.

Thus, you have BOTH a way to indicate a mechanism, and a modified
data structure. 

By this proposal one avoids to create another new ASN1 structures
and remains completely in the scope of CMS/PKCS7.

The top level data structure of a 'time stamp token' could
be either :

- a document conforming to a cryptographic message syntax
- a sequence of some data and whatever protection of that data

This anyway a matter of taste.

One could also create a mime multipart/timestamp to allow having
two interpreters for the different parts, etc. 

Peter Sylvester

---

From: Roland Mueller <[email-masked]>
Date: Wed, 31 May 2000 11:02:55 -0500

Hello Peter,

> > prerequisite for developers willing to implement an IETF and ISO
This is a hard statement. There are at least two different ways to have
a default value as it was proposed by Tom: either the default is
interpreted as non-existent or as a pre-set value. And I had the
impression that for the latter at least an indicator is needed to point
out that this field will be used.

> Thus, you have BOTH a way to indicate a mechanism, and a modified

Yes that's a solution but not a straight-forward one. And it does not
lead to interoperability for the the ISO protocol is a superset and we
are trying to achieve a common set. That's why I re-opened the
discussion.
> two interpreters for the different parts, etc.
Roland Mueller