Subject: Time Stamp V7 Data structure

From: Roland Mueller <[email-masked]>
Date: Tue, 30 May 2000 22:34:43 -0500

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.

The answer I received from the eeditor on the change of the data
structure was  from my point of view sufficient for it only meant an
endorsement to use additional elements in  the ISO data structure: "For
the request the additional element will be in the ISO request, NOT in
the IETF request."

That means, ISO gets endorsement for its data structure. I was asking
for a change in the IETF data structure, the mechanism Identifier
element ALREADY exists in the ISO Time stamp request data structure.

On the other hand I have to express that the adoption of a mechanism
identifier into the time stamp token is required to allow proper
interpretation by the recipient of such a token. If the mechanism used
for generating the token cannot be identified then the validity of a
time stamp cannot be checked if it is not the IETF mechanism. If time
stamps are generated using a mechanism different from the IETF draft and
there is no information provided within the token what mechanism was
used to generate the time stamp then a verifier does not know how to
proceed. If the time stamp was generated with one of the mechanisms
proposed in the ISO draft then information is needed to successfully
verify the validity of the time stamp. Otherwise an ISO time stamp is
not usable by  recipients of the time stamp for they cannot verify its
validity.

Let me explain the need for the mechanism identifier in the request also
in an example: A client using the IETF protocol may communicate with
either an ISO or an IETF TSA when requesting a time stamp; this will
cause no problem for the ISO TSA will understand the request of the
client.

The situation gets more difficult if the client uses the ISO protocol. A
TSA only understanding IETF requests will detect general incompatibility
and answer with an error; this leaves the client without a time stamp if
he cannot switch to the other protocol. And this is not called
alignement but downward compatibility. And we should try to achieve
interoperability which means an agreed minimum level of communications.
The accepted changes do not allow communications in both directions.

And that does not help any of the standardisation bodies, neither the
IETF nor ISO.

That's in short why I am convinced that the discussion on the acceptance
of these topics has to be reopened. 

What is needed most urgently is a mechanism identifier in the time stamp
request and in the time stamp response (i.e. within the time stamp
token). And that is the only way I can imagine that allows
interoperability between the two approaches.  Thanks again for your
patience and support.

Roland

---

From: Denis Pinkas <[email-masked]>
Date: Wed, 31 May 2000 19:00:18 +0200

Roland,

> the request the additional element will be in the ISO request, NOT in

The structure of the request in the (next) version of the TSP
document that I am maintaining is the following:

TimeStampReq ::= SEQUENCE  {
     version               INTEGER  { v1(1) },
     messageImprint        MessageImprint,
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
     reqPolicy             PolicyInformation        OPTIONAL,
     nonce                 INTEGER                  OPTIONAL,
     certReq               BOOLEAN                  DEFAULT FALSE,
     extensions            [0] IMPLICIT Extensions  OPTIONAL
}

The ISO document *could* use an additional default parameter
(defaulted to mean the IETF protocol where only signed TSTs exist)
to signal
that this is the ISO protocol and then *could* signal the OID of the
mechanism in the extensions field (if there are more than one). An
*example* of that case would be:

TimeStampReq ::= SEQUENCE  {
     version               INTEGER  { v1(1) },
     protocolIdentifier    ProtocolIdentifier DEFAULT v1,
     messageImprint               MessageImprint,
       --a hash algorithm OID and the hash value of the data to be
       --time stamped
     reqPolicy             PolicyInformation        OPTIONAL,
     nonce                 INTEGER                  OPTIONAL,
     certReq               BOOLEAN                  DEFAULT FALSE,
     extensions            [0] IMPLICIT Extensions  OPTIONAL
}

   ProtocolIdentifier  ::=  INTEGER  {  v1(0), v2(1), v3(2) }
     -- v1 means the IETF protocol defined in TSP.
     -- v2 means the ISO protocol for the response 
     -- as defined in ISO XXXX-2.
     -- v3 means the ISO protocol for the response 
     -- as defined in ISO XXXX-3.

Another simpler *example* would be to use the following addition
(instead of protocolIdentifier) between the fields version and
messageImprint:

     protocolISO           BOOLEAN DEFAULT FALSE,

-- when the boolean is true, this means the ISO protocols
-- as defined in ISO XXXX-2 and ISO XXXX-3.
-- when the boolean is false, this means the IETF protocol 
-- as defined in the document TSP in RFC XXXX.

In this way, an IETF client talking to an ISO/IETF compliant server
still uses the current request (without any addition) as defined in
the TSP document. The ISO/IETF compliant server will compile the ISO
description of the request and thus can easily detect which of the
two options is being used. 

An ISO client talking to an IETF server will not get any service and
will be returned with an error.

An ISO client talking to an ISO server can obtain whatever ISO
decides.

There are many other ways. Among them, a much simpler (but not
cleaner !) solution, without the addition of any other parameter: If
ISO starts version numbers of their protocols with, let us say, 100,
then there is very little chance that IETF versions will ever reach
that number. :-)

Note: we have to make sure that there exists at least one solution,
but this is not a task of the IETF to decide which solution to pick
up for ISO. So once ISO has made a decision, it would be "nice" 
for the IETF to know about it.

> not usable by  recipients of the time stamp for they cannot verify its

About the structure of the response, 

On May 2, I responded privately to you with the following:

A proposal has been made to use DigestInfo, which solves your
concern, not in the way that was originally requested, but which
allows a server to send back a response that may be either IETF
conformant or ISO conformant.

On April 19, I responded privately to you with the following:

TimeStampToken is defined in the document as:

TimeStampToken ::= ContentInfo
  -- contentType is id-signedData ([CMS])
  -- content is SignedData ([CMS])

It has been proposed that ISO uses DigestInfo instead of SignedData
as defined in the CMS structure. This also means that ISO will have
to register the algorithm(s) that are needed to describe what kind
of crypto technique will be used.

When this will be done, we (i.e. the PKIX WG) might extend the
definition of the id-signatureTimeStampToken defined in the annex A
to support DigestInfo in addition to SignedData.

As the IETF process mandates to wait at least 6 months after the I-D
is issued and to have two interoperable independent implementations,
we could make the change at that time, provided that your data
structure is well defined at that time and your algorithm(s) is/are
registered.

This explains why no change to the response in the IETF document is
needed at that time and also explains that a change to the annex A
might be done 6 months from now.

Denis

Note: Do not expect another E-mail from me soon. I will only be back
in my office next monday.