Subject: RE: WG Last Call Comment for 3280bis

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 30 Nov 2006 13:55:22 -0800

Russ,

4.2 of the 3280 Bis says "Communities may elect to use additional
   extensions; however, caution ought to be exercised in adopting any
   critical extensions in certificates that might prevent use in a
   general context."

Given the context preceding in Section 4.2, I understand that one.   

The phrase "that might prevent use in a general context" is still
unclear in the context of hold instruction.  I suspect you mean that the
relying party may not understand the hold instruction.  Note that
Section 5.3.2 states that the hold instruction is non-critical and hence
in my reading it can be ignored.  Further, Section 6.3.3 says nothing
about processing hold instruction.

So:
The statement is not clear; and the statement can not be analogous to
treatment of critical unrecognized extensions.

-----Original Message-----
From: Russ Housley [mailto:[email-masked]] 
Sent: Thursday, November 30, 2006 4:31 PM
To: Santosh Chokhani; [email-masked]
Subject: RE: WG Last Call Comment for 3280bis

Santosh:

This is the same thing we say about using extensions that are not 
defined in RFC 3280.

Russ

At 03:09 PM 11/30/2006, Santosh Chokhani wrote:
>Russ,
>
>The phrase "that might prevent use in a general context" is not clear.
>
>Do you mean prevent use of certificate, of hold reason code, or hold
>instruction, or something else?
>
>May be the following makes sense:
>
>     "Communities may elect to use additional hold instruction codes;
>     however, caution ought to be exercised in adopting any additional
>     hold instruction codes since additional hold instruction codes may
>not be understood by all the relying parties"
>
>-----Original Message-----
>From: [email-masked]
[mailto:[email-masked]]
>On Behalf Of Russ Housley
>Sent: Thursday, November 30, 2006 1:24 PM
>To: [email-masked]
>Subject: WG Last Call Comment for 3280bis
>
>
>I know that Steve Kent called the 3280bis closed on 11/7/2006, but
>the recent thread regarding on-hold needs to become a concrete
>proposal for a change in the text.  Here is my suggestion.
>
>OLD TEXT:
>
>     The following instruction codes have been defined.  Conforming
>     applications that process this extension MUST recognize the
>following
>     instruction codes.
>
>     holdInstruction    OBJECT IDENTIFIER ::=
>                      { iso(1) member-body(2) us(840) x9-57(10040) 2 }
>
>     id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction
1}
>     id-holdinstruction-callissuer
>                               OBJECT IDENTIFIER ::= {holdInstruction
2}
>     id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction
3}
>
>     Conforming applications that encounter an id-holdinstruction-
>     callissuer MUST call the certificate issuer or reject the
>     certificate.  Conforming applications that encounter an id-
>     holdinstruction-reject MUST reject the certificate.  The hold
>     instruction id-holdinstruction-none is semantically equivalent to
>the
>     absence of a holdInstructionCode, and its use is strongly
deprecated
>     for the Internet PKI.
>
>PROPOSED REPLACEMENT TEXT:
>
>     The following instruction codes have been defined.  Conforming
>     applications that process this extension MUST recognize the
>     id-holdinstruction-reject instruction code.
>
>     holdInstruction    OBJECT IDENTIFIER ::=
>                      { iso(1) member-body(2) us(840) x9-57(10040) 2 }
>
>     id-holdinstruction-none   OBJECT IDENTIFIER ::= {holdInstruction
1}
>     id-holdinstruction-callissuer
>                               OBJECT IDENTIFIER ::= {holdInstruction
2}
>     id-holdinstruction-reject OBJECT IDENTIFIER ::= {holdInstruction
3}
>
>     Conforming CAs MUST NOT make use of the
>     id-holdinstruction-callissuer instruction code.
>
>     Conforming applications that encounter any of these hold
instruction
>     codes MUST reject the certificate.
>
>     Communities may elect to use additional hold instruction codes;
>     however, caution ought to be exercised in adopting any additional
>     hold instruction codes that might prevent use in a general
context.