[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Criticality and SCVP Extensions


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:
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

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