Subject: Criticality and SCVP Extensions

From: "Housley, Russ" <[email-masked]>
Date: Sun, 03 Nov 2002 14:12:41 -0500

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

---

From: "Santosh Chokhani" <[email-masked]>
Date: Sun, 3 Nov 2002 21:02:22 -0500

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Housley, Russ
Sent: Sunday, November 03, 2002 2:13 PM
To: [email-masked]
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:

    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 reply, if the critical item is TRUE, the client MUST NOT
process
    the response unless it understands the extension.

Russ

---

From: Denis Pinkas <[email-masked]>
Date: Mon, 04 Nov 2002 15:18:24 +0100

Russ,

The major problem with SCVP is that extensions are used in a way for which 
they were not intended for. It is some kind of "new way" of programming, 
where nearly all requests and responses have OIDs, even for the standard 
requests and responses that are defined in the draft ! With that programming 
style, the criticality bit is loosing its original meaning.

We already have a common approach which is the one consistant with both
RFC 3280 and RFC 3161. We do not need a new one.

However, we do not need the new way of programming of SCVP. So we can get 
rid of this issue by changing the programming style from SCVP.

Denis

---

From: "Ambarish Malpani" <[email-masked]>
Date: Mon, 4 Nov 2002 07:38:51 -0800

The intent in SCVP was the same as 3161bis.

I agree.

Ambarish

---------------------------------------------------------------------
Ambarish Malpani                                         650.759.9045
Malpani Consulting Services                      [email-masked]
http://www.malpani.biz

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Housley, Russ
> Sent: Sunday, November 03, 2002 11:13 AM
> To: [email-masked]

---

From: "Housley, Russ" <[email-masked]>
Date: Mon, 04 Nov 2002 12:29:31 -0500

Denis:

I think that the authors agree that there is an issue with the extensions 
semantics, that is why it is on the open issues list in the document.

The use of OIDs in the "checks" and "wantBack" areas reduces the need for 
extensions.  By defining additional OIDs for these areas, the server can 
perform additional checks and provide additional information.  I think this 
is desirable.

Personally, I agree that the approach taken for criticality in RFC 3280 is 
the appropriate approach.  This statement has not been coordinated with the 
other SCVP authors...

Russ

At 03:18 PM 11/4/2002 +0100, Denis Pinkas wrote:
>requests and responses that are defined in the draft ! With that 
>programming style, the criticality bit is loosing its original meaning.
>
>>for many months.  Yet, it has not really been discussed.  Recently, Denis 
>>queryExtensions. Extensions are there to allow for future unplanned 
>>standard extensions and/or for private extensions.
>>RFC 3161, where the interpretation of the criticality bit was the following:
>>the treatment that is indicated in the SCVP draft: