Criticality and SCVP Extensions

["Housley, Russ" <rhousley@xxxxxxxxxxxxxxx>]

The open issues section in SCVP has highlighted extension criticality for 
many months.  Yet, it has not really been discussed.  Recently, Denis 
Pinkas raised this issue as part of a much longer posting.  I think it 
deserves a thread of its own.

In SCVP, there are two extensions levels: reqExtension and queryExtensions. 
Extensions are there to allow for future unplanned standard extensions 
and/or for private extensions.

Denis pointed out that a similar discussion was held in the context of RFC 
3161, where the interpretation of the criticality bit was the following:

   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

In RFC 3161bis, this has been changed to:

   A server that does not recognize a non-critical extension SHALL ignore
   the extension and SHALL NOT return an error for this. A server that
   recognizes an extension SHALL process the extension regardless of
   the value of the criticality flag. A server MUST reject the request if it
   encounters a critical extension it does not recognize and in that case
   SHALL return a failure.

This represents the current consensus for TSP. This is different from the 
treatment that is indicated in the SCVP draft:

   In a request, if the critical item is TRUE, the server MUST NOT
   process the request unless it understands the extension.

   In a reply, if the critical item is TRUE, the client MUST NOT process
   the response unless it understands the extension.

It would be nice if all of the PKIX WG protocols had a common extension 
approach, but that is not absolutely mandatory.

What should we do in SCVP?

Russ