Subject: Time-stamping: IETF / ISO

From: Manuel Heras Gilsanz <[email-masked]>
Date: Thu, 10 Feb 2000 21:23:39 +0000

Dear Mr Pinkas,

> Roland,
> 
> Since you said that you want multiple mechanisms to be used and that
> it is NOT the intention of the ISO working group to introduce
> patented mechanisms, would you be able to provide at least one
> useful example of such a binding mechanism that is not patented ?
> 
> Denis

I would like to express some opinions on the management of this draft
with respect to ISO interoperability.

From my point of view, what ISO is trying to do is to leave the
specification open, so that (in principle) *any* mechanism can be used,
either patented or non-patented. The fact that all the protocols we know
of today are or are not patented (something not at all clear, on the
other hand) is inessential, irrelevant and a pure contingency.

Imagine that we discover life outside Earth and we have to exchange
time-stamp tokens with a (possibly more advanced and therefore
patent-less) civilisation: we don't care whether their TS protocols are
patented or not; what we do is to evaluate the _mechanisms_ for
production of time-stamp tokens they use, and whether they can
interoperate with us. It would be a pity for you to see that aliens can
exchange time-stamps via ISO TS-standard but not via IETF TS-standard!
;-)

As I understand the issue, there is no problem in having several
different time-stamping standards (although this complicates the life of
many people, is inefficient, and creates artificial demand for security
consultants); what is really problematic is to have several
_incompatible_ standards (this should be punished with jail, and with
the death penalty when development of both standards took place in
parallel!!). What ISO is trying to do, from my point of view, is to
minimise the number and the degree of the incompatibilities between IETF
and ISO approaches.

The obstination that you are exercising from your position as IETF draft
editor is totally unacceptable to me. Your decisions should be based on
technical grounds, with the goal of benefiting the whole Internet
community. Don't try to convince us that you discovered two days ago
that ISO is working on a time-stamping standard, because you are also
taking a seat in the ISO working group, and taking good notes of the
discussions held therein.

I have not seen any technical reason why you don't accept ISO approach,
and it is my opinion that as an I-D editor your decisions should be
merely (or, at least, mostly) technical, as opposed to guided by
political or personal interests. The single technical responses of
relevance have been to propose the use the policy field as a way of
choosing the final format (ISO/IETF) of the item, which is other way of
saying "we don't want to be interoperable, you just put another layer on
the onion, and write the format there". (Policy identifiers cannot be
used for that -- nobody has yet agreed how policy identifiers from
different TSA relate, and how to know whether a certain policy-id is ISO
or IETF-oriented.)

Let me finally remind to you that Mr Roland Mueller is not a bored
newcomer suggesting funny changes in the last minute because he doesn't
know what to do in his spare time: he is coordinating the ISO
time-stamping effort, and as such his comments deserve a bit (more) of
attention and dissection on your part. I don't believe in authorities,
but at least we should recognise that his opinions reflect what many
experts have agreed after long, deep discussions, and his motivation is
to promote the compatibility between standards. I think you have
redirected his polite messages to /dev/null as if they came from "just
another one", something very inappropriate from your side. On the other
hand, ISO has been promoting interoperability since its earliest draft,
something I have not seen "from the other side". [Now let me clarify
that I am not a friend of Mr Mueller or part of his family, but I think
he is doing an excellent work as coordinator of the ISO ad-hoc group,
trying to listen to everybody's needs and opinions.]

It is very funny that, being ISO thought of as a "monolythic institution
suffering a lot of bureaucreacy and political influence, where strict
country representation rules govern", and the IETF as "the paradigm of
informal, electronic, open standards without heavy bureaucratic or
political influence, where anyone can participate and an individual can
influence the future of the net" [this is the mental image shared by
many people on both institutions], what we see here is that the "roles"
have been exchanged, and while ISO is warmly promoting easy
interoperation, and dialog, the IETF draft editors coldly find
themselves unable to incorporate the changes due to the proximity of the
closing date or simply dismissing the comments with dubious responses to
which they didn't give a couple of minutes' thought.

I encourage you to reconsider your position, as you might do a great
favour to all the Internet and security communities with the
introduction of the minor changes identified by the ISO working group as
potentially problematic, or at least participating in the dialogue after
leaving the ego at home.

If not in the benefit of human beings, please do it in the benefit of
interoperability with alien civilisations!!

Best regards,

       - Manuel Heras -
     [ I hate flaming, but this was too much! ]

Manuel Heras-Gilsanz
Security Consultant

---

From: [email-masked]
Date: Fri, 11 Feb 2000 17:16:22 -0500

Surely no apology is necessary.  If everyone who produced ASN.1 which
was later revised were considered at fault, no one would use it (which
perhaps would be a good thing, or perhaps not).  However, this leaves open
the question of whether the IETF specification should accomodate the ISO
one somewhat.  First, should the mechanismNotSupported bit be added to
PKIFailureInfo in the PKIX draft?  Second, should the ISO ASN.1 format for
TimeStampReq and TSTInfo be documented in an appendix to the PKIX draft,
pointing out that these are fully compatible with the PKIX definitions
within the existing draft?
     I realize that these suggestions come after last call completion, and
thus may be ruled out of order.

          Tom Gindin

Roland Mueller <[email-masked]> on 02/11/2000 04:16:52 PM

To:   Tom Gindin/Watson/IBM@IBMUS
cc:   Manuel Heras Gilsanz <[email-masked]>, [email-masked],
      [email-masked]
Subject:  Re: Time-stamping: IETF / ISO

This is a good idea and I apologize for not thinking of that. We will
set it up this way that the IETF mechanism is the default mechanism and
thus having away to add mechanisms if required.

Roland

---

From: Peter Williams <[email-masked]>
Date: Fri, 11 Feb 2000 15:08:10 -0800

Id suggest specifying a complete reference to the 
IETF mechanism(s) in a high-profile, but NON-normative
annex, only.  

-----Original Message-----
From: Roland Mueller [mailto:[email-masked]]
Sent: Friday, February 11, 2000 1:17 PM
To: [email-masked]
Cc: Manuel Heras Gilsanz; [email-masked]; [email-masked]
Subject: Re: Time-stamping: IETF / ISO

Roland

---

From: "Manger, James H" <[email-masked]>
Date: Mon, 14 Feb 2000 10:34:34 +1100

Please follow the standard ASN.1 extensibility rules if adding a new field
(e.g. mechanism) to a syntax (e.g. TSTInfo).  That is, the new field must be
added to the end of the SEQUENCE and must be optional.

----------
From:	[email-masked] [mailto:[email-masked]]
Sent:	Friday, 11 February 2000 14:09

..ISO include the mechanism identifiers in their ASN.1 definitions and
specify them with default values..