Subject: Re: Time Stamp V7 Data structure

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

The last two drafts of the text also contain serveral incompatible
changes to the asn1 syntaxes, is there some attempt to get an alignment?

> 
> as far as I understand the recent draft of the IETF there is nothing
> mentioning interoperability with the ISO draft, i.e. at least an
> optional data field (mechanism identifier). ISO has that field defined
> as an optional one and that was agreed on in January within ISO members.
> 
> ISO will be happy to specify a default value for PKIX mechanism in their
> data structure.
> 
> Roland

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 31 May 2000 19:12:28 +0200 (MET DST)

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

The 'This' in my message may be misleading: I am refering to
'None of this happened'.
 
> 
> > 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.
> 
> 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.

That seems the point of the dispute. There are TWO proposals.

Both the current text of the IETF standard and the ISO proposal
may be considered supersets of what we had before. 

But: The ISO protocol for the format of a time stamp token
(not just the info) is NOT a superset, since it encapsulates
the signature and data in another sequence. Thus ISO already
has another token format, and the mechanism stuff is an inner detail. 

The IETF proposal is a superset of the original IETF text that
allows to provide the SAME functionality as the ISO proposal. 

It is possible to convert both formats (four cases)

- input IETF signeddata :

  output: a sequence of the content and signeddata without the content 

- input IETF digesteddata

  output: a sequence of the messagedigest and a modified content where
          the digest algo is inserted as 'mechanism in the ISO stamp stamp info

- input ISO sequence without mechanism (thus IETF signature assumed as default)
  output a signeddata where the content is inserted

- input ISO sequence WITH mechanism
  output a digestedData where the mechanism is removed in the content, and
  used as digestalgorithm.

Indeed the last case is somewhat strange because in order to validate the
token you need to insert the algorithm into the data structure first. 

You didn't comment the statements below which are the essential ones.

- The proposed solution is using the following rule:

  1 - you have a time stamp content
  2 - you have a protecting envelope (signature, method based information)

- The method indication is assumed to be logically part of the
  protecting envelope and not of the content.

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