Subject: Re: Time Stamp V7 Data structure

From: [email-masked]
Date: Wed, 31 May 2000 10:38:56 -0400

May I ask what happened to the suggestion that mechanism identifier in
the ISO version be given a DEFAULT value which would be assigned to the
PKIX mechanism?  That would probably allow the ISO version to be used to
communicate with the current draft.

          Tom Gindin

Roland Mueller <[email-masked]> on 05/30/2000 11:34:43 PM

To:   IETF-PKIX <[email-masked]>
cc:   Wes Doonan <[email-masked]>, "Jose A. Ma~n" <[email-masked]>,
      Stephen Matyas/Poughkeepsie/IBM@IBMUS
Subject:  Time Stamp V7 Data structure

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: Roland Mueller <[email-masked]>
Date: Wed, 31 May 2000 10:22:06 -0500

Tom,

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