Subject: Re: TSP interop update

From: Peter Sylvester <[email-masked]>
Date: Fri, 18 Jan 2002 16:09:25 +0100 (MET)

> 
> Peter Gutmann wrote:
> > Actually this raises an interesting point, the TSP RFC says that extensions 
> > are handled just like RFC 2459 except when they're not.  In particular it 

I really like the ways you say this :-)

It was in version 3 of the draft that extensions were added, and in version 4
the following text was added:

Version 3:
   "The extensions field is a generic way to add additional information to
   the request in the future. EXTENSIONS is defined in [RFC 2459]."

Version 4:
   "The extensions field is a generic way to add additional information to 
   the request in the future. EXTENSIONS is defined in [RFC 2459]. If an 
   extension, whether it is marked critical or not critical, is used 
   by a requester but is not recognized by a time stamping server, the 
   server SHALL not issue a token and return a failure (badRequest)."

RFC 3161:
   "The extensions field is a generic way to add additional information
   to the request in the future.  Extensions is defined in [RFC 2459].
   If an extension, whether it is marked critical or not critical, is
   used by a requester but is not recognized by a time-stamping server,
   the server SHALL not issue a token and SHALL return a failure
   (unacceptedExtension)."

Well, now, what happened between September and October 1999 (V3 -> V4)

There were some messages, at least one concerning a RESPONSE, what does a
time stamp with an extension mean that has no critical bit. 

One can also interprete the actual text for the response also that all TSAs
MUST by definition able to interprete all possible extensions, and the
default implementation is to create such an error. :-) 

Unless I have overlooked something, I do not see an explanation
or announce for this change. Maybe the editors can comment ??

I tend to think that the change this additional requirement, i.e.,
the  change from 3 -> 4 is not necessary.

Peter Sylvester

---

From: "José A. Mañas" <[email-masked]>
Date: Fri, 18 Jan 2002 19:55:09 +0100

I am not sure about the aim of 3161,
but I know a bit more of the history.

The agreement between ietf and ISO regarding
time-stamping protocols was to use ietf's as default,
and use extensions to requiere different mechanisms
(e.g. linked tokens), additional parameters, ...

The aim is to allow for co-existence of time-stampers.
If a TSA understands N protocols, and there is a new N+1 protocol,
that uses new extensions or new values in extensions,
there are two cases:
1/ the old TSA may ignore non-critical
extensions addressed to the new protocol, and do its best,
and
2/ the old TSA should stop processing upon critical extensions 
that it does not understand.

So, the requester may specify whether it is critical or not
(for its business case) that the TSA understands the extension and
behaves accordingly.

pp