Subject: Re: TSP interop update

From: [email-masked] (Peter Gutmann)
Date: Sat, 19 Jan 2002 13:56:44 +1300 (NZDT)

tho <[email-masked]> writes:

>so I think that if the TSA doesn't understand the _semantics_ (not the syntax)
>of the extension it "SHALL not issue a token and SHALL return a failure
>(unacceptedExtension)."

That just confirms my previous point: The RFC never explains what to do with
any extension you find, therefore the semantics of all extensions are unknown
(in the context of the RFC), therefore any request with extensions has to be
rejected.  You could get away with this if the critical flag had been left with
its standard meaning (so you could submit noncritical extensions and things
would work properly), but by both overriding it and not defining the semantics
for any extensions the RFC creates a situation where all extensions have to be
rejected.

Peter.

---

From: tho <[email-masked]>
Date: Mon, 21 Jan 2002 12:50:55 +0000

> Peter Gutmann wrote:
>
> The RFC never explains what to do with any extension you find, therefore the
> semantics of all extensions are unknown (in the context of the RFC),
> therefore any request with extensions has to be rejected.

yes, in the context of the RFC, which wants to be the framework, not the
complete specification of all future extensions of the protocol.

At the state of art from a client perspective we have that if I add an 
extension to my TimeStampReq which is not supported by the this TSA and I 
receive back an `unacceptedExtension' rejection, I have two choices (both not 
so unpractical):

a) if the extension is not essential to me, strip off the extension and try 
   again with this TSA

b) if I consider that extension vital for me, try with another TSA 

unfortunately the client has to pay an extra round trip in case (a) which could
be saved by restoring the standard meaning of the critical flag. 

This is the only real disadvantage that I can see.

ciao, tho
--

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 25 Jan 2002 15:31:14 +0100

Peter,

> for any extensions the RFC creates a situation where all extensions have to be

I am trying to catch the messages exchanged. I share your view on that
point.

It is a good catch.

I believe that the standard should be modified to consider the criticality
flag. However, I have not checked whether this change would have an impact
or no impact on the ISO standard being prepared by SC27/WG 2.

Any opinion from a member of that group ?

Denis

---

From: Phil Griffin <[email-masked]>
Date: Fri, 25 Jan 2002 11:32:34 -0500

Denis,

The ISO 18014-2 Independent Tokens work in JTC 1/SC 27
does define and use extensions in part two. At least
one of these is required to be critical. There is a
key usage extension and one that indicates that a 
MAC is used.

My understanding is that extension processing follows
those described for certificate extensions.

Phil Griffin

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 25 Jan 2002 17:44:42 +0100

Phil,

Thank you for your prompt response.

So the standard will be modified to consider the criticality flag.
If anyone opposes, it is time to speak now.

Denis