Subject: Re: TSP interop update

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.

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 28 Jan 2002 15:48:38 +0100

Peter,

 
> to have some behaviour as in 2459 for the extendedkeyusage.

The current text is in TSP as follows:

   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).

<draft-ietf-pkix-new-part1-12.txt> states in section 4.2:

 A certificate using system MUST reject the certificate if it encounters
 a critical extension it does not recognize; however, a non-critical
 extension MAY be ignored if it is not recognized. 
 
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.

This new sentence is thus proposed to replace the current text mentioned 
at the top of this e-mail.

Denis