RE: Criticality and SCVP Extensions

["Santosh Chokhani" <chokhani@xxxxxxxxxxxx>]

Russ:

The new TSP approach is consistent with what X.509 did about 1-2 years
ago.  Thus, both the request and reply in SCVP should also follow that
approach.  The approach (at the risk of repeating Denis and You) is:

1.  If you recognize an extension, you must process it, regardless of
its criticality.

2.  If you encounter an extension that is critical and you do not
recognize it, you must reject the object (i.e., transaction in the case
of SCVP).  Now, in the case of SCVP, there may be some situations where
the criticality of the extension may not matter.  For example, for some
of the statusCode and for some of the replyStatus, it may not matter
what a critical extension says; you know the response is bad and why.
But, rather than a detailed treatment of possibilities, a general
statement about rejection may be sufficient.

3.  If you encounter an extension that is non-critical and you do not
recognize it, you shall process the object by ignoring the extension
(i.e., transaction in the case of SCVP).

-----Original Message-----
From: owner-ietf-pkix@xxxxxxxxxxxx [mailto:owner-ietf-pkix@xxxxxxxxxxxx]
On Behalf Of Housley, Russ
Sent: Sunday, November 03, 2002 2:13 PM
To: ietf-pkix@xxxxxxx
Subject: Criticality and SCVP Extensions



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