Subject: Re: TSP interop update

From: [email-masked] (Peter Gutmann)
Date: Fri, 1 Feb 2002 21:17:44 +1300 (NZDT)

Margus Freudenthal <[email-masked]> writes:

>In addition, this makes the protocol more complex as the client must implement
>procedures for dealing with time stamps with funny and unexpected policy
>identifiers.

It's far easier to compare the returned ID with a known-good set than to submit
a string of requests going down a list of acceptable policies trying to find
one the TSA won't reject.

Peter.

---

From: Peter Sylvester <[email-masked]>
Date: Wed, 30 Jan 2002 11:01:02 +0100 (MET)

>  
> If we transpose this sentence in the context of TSP then we should have:
> 
> A server MUST reject the request if it encounters a critical extension 
> it does not recognize and in that case SHALL return a failure
> (unacceptedExtension); however, non-critical extensions MAY be ignored, 
> if not recognized.

X509 has an additional requirement which was added in a defect report, 
i.e., if an extension is known, then the interpretation is independant
of the value of the critical bit.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 1 Feb 2002 12:03:24 +0100 (MET)

folks,

May I remind that my intervention addressed the situation that
there are several phrases 3161 regarding the Policy ID,
one of them was changed to a MUST which seems to me 
having the effect that the three sentences are no longer
consistent. 

If nobody agrees with me then I might take a break and
a course in IETF English or else.

If people agree that the three phrases need to be changed,
then :

I had expressed my preference of a solution.

Note also that in earlier drafts the OID was a "PolicyInformation".

Peter

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 01 Feb 2002 00:33:47 +0100

Peter Sylvester wrote:

> A client can never 'prove' that
> a response is not conformant to what he had requested for the simple
> reason that a client cannot prove to someone else that he had send
> a particular request.

If people really need this kind of proof that means it could be an interesting
extension to require the server to include the hash of the request inside an
extension in the token.

---

From: Jean-Marc Desperrier <[email-masked]>
Date: Fri, 18 Jan 2002 10:25:10 +0100

Peter Gutmann wrote:

> The RFC doesn't
> specify any particular extensions which you have to (MUST/SHALL/SHOULD) handle
> and says the critical bit is ignored (in violation of RFC 2459), so it looks
> like accepting/ignoring anything that you "recognise" is fine.

The text in the RFC sounds a lot more like any extension should be handled as if it
had the critical flag, and the request rejected if you don't know exactly the
meaning of the extension.

---

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: [email-masked] (Peter Gutmann)
Date: Fri, 1 Feb 2002 14:57:19 +1300 (NZDT)

Denis Pinkas <[email-masked]> writes:

>It is simmple: if a client requests a policy and if the server supports that
>policy, why should the server choose a different policy ? Just to annoy the
>client ?

What if the client prefers policy X, but will accept anything if that's not
available?  This is standard procedure for restaurants, libraries, ...

Twitchen: "We'll have the duck".
Fawlty: "Duck's off, sorry".
Twitchen: "We'll have the trifle then".

TSP however requires:

Twitchen: "We'll have the duck".
Fawlty: "You ponce in here expecting to be waited on hand and foot. Well, I'm
         trying to run a TSA here. Have you any idea how much there is to do?
         Go away".

Ah, we have an RFC which standardises Fawlty Towers.

Peter.

---

From: Peter Sylvester <[email-masked]>
Date: Fri, 25 Jan 2002 19:06:29 +0100 (MET)

> 
> So the standard will be modified to consider the criticality flag.
This sentence may be misleading.

Do we follow X509's latest version, or is it allowed
to have some behaviour as in 2459 for the extendedkeyusage.

> > 
> > My understanding is that extension processing follows
> > those described for certificate extensions.
Which have recently be changed in X509. 

I suggest something like:

  If an extension is known it is treated independantly of
  the value of the criticality bit.
  Otherwise, i.e., if the extension is not known, 
  and the criticality flag is set, the request is
  rejected.
  Otherwise, i.e. when the criticality flag is false
  the extension is simply ignored.
  The definition of an extension MUST NOT indicate
  different treatment depending on the criticality bit.