Subject: Re: WG Last Call Comment for 3280bis

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Dec 2006 04:51:42 -0500

David,

The problem we face is that support for the full range of hold 
instruction codes imposes a significant burden on RPs, in general. 
The only instruction code that does not do this is reject, because it 
says that the RP treats the cert as revoked.

Use of reject allows CAs to do what CRLs otherwise prohibit (as 
Sharon noted), i.e., to temporarily revoke a cert. Of course real 
revocation does not allow a CA to change its mind and undo the 
revocation, which makes life easier for RPs.

  I believe that what we see here is CAs externalizing their costs on 
all RPs, by being allowed to undo revocation. Frankly I'm opposed to 
that, in principle. However, I've been persuaded that there are some 
circumstances where this "cheat" may be merited, despite the barrage 
of bad arguments that have accompanied this discussion. So, I agree 
with Russ's proposal to require support for the reject instruction 
code.

I also agree with Russ's call for RPs to treat the other, cited hold 
instruction codes equivalently, just to accommodate existing use of 
these other codes, for now. In the long run, we want to discourage 
CAs against using ANY of the other codes, because of the burdens they 
place on RPs. Thus we want to admonish CAs from using other 
instruction codes, and want to NOT require RPs to process them as 
other than rejects.

Call issuer is an even more egregious example of externalization, and 
so I cannot agree with your conclusion that it is the only meaningful 
one.

Steve

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 1 Dec 2006 20:10:40 +0800

I am ok with this change.

If possible, I would prefer the WG to deprecate the whole use of
the hold instruction extension but only allow the use of "certificateHold"
and "removeFromCRL" CRL reason code. Doing that will
make certificate suspension mechanism more simple and more
interoperable.

Wen-Cheng Wang

----- Original Message ----- 
From: "Russ Housley" <[email-masked]>
To: <[email-masked]>
Sent: Friday, December 01, 2006 2:23 AM
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.
>

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 01 Dec 2006 09:58:31 -0500

Steve,

I don't understand your claim that support for the full range of hold 
instruction codes imposes a significant burden on relying parties.

Given the text that is in RFC 3280, could you please explain how a 
relying party that can process the holdInstruction extension might be 
expected to respond differently to the following three scenarios (In 
each scenario, the certificate is listed on the CRL with a reasonCode 
extension that specifies certificateHold):

    * Scenario 1:  holdInstruction extension is not present

    * Scenario 2: holdInstruction extension is present and specifies 
id-holdinstruction-none

    * Scenario 3: holdInstruction extension is present and specifies 
id-holdinstruction-reject

I can't see where a relying party would treat these three scenarios 
differently, so I don't see any reason to include the holdInstruction 
extension if the id-holdinstruction-reject hold instruction is going to 
be asserted, nor do I see how the inclusion of the holdInstruction 
extension with one value imposes any more of a burden on relying parties 
than the inclusion of the extension with any other value.

At least with the id-holdinstruction-callissuer hold instruction, it is 
clear how a relying party MIGHT do something different than if the 
holdInstruction extension were not present.  I am not saying that I am a 
big fan of this hold instruction, but at least I can understand that 
including this hold instruction conveys some information that would not 
be conveyed if the holdInstruction extension were omitted.  As for 
burden on relying parties: support for the holdInstruction extension is 
optional and RFC 3280 states that even relying parties that choose to 
support the extension may simply reject any certificate where the hold 
instruction is id-holdinstruction-callissuer, so I don't see how the 
presence of this hold instruction creates a significant (or any) 
burden.  The inclusion of this hold instruction simply provides the 
relying party with another option.  I think we all agree that it is an 
option that will rarely be used, but indicating in a non-critical 
extension that an additional option is available does not impose a 
burden on the relying party since the relying party is only affected if 
it chooses to make use of that option.  For this reason, I don't see the 
compelling reason for suddenly changing this section of the profile 
after last call has been closed, especially given that the text in this 
section has remained unchanged since RFC 2459.

> with Russ's proposal to require support for the reject instruction code.
While I can understand you concerns about the use of certificate 
suspension, I do not understand what that has to do with Russ's 
proposal.  The holdInstruction extension is not used to suspend 
certificates, the reasonCode extension is.  The holdInstruction 
extension simply allows the CRL issuer to provide additional information 
to the relying party in the case that a certificate has been suspended.  
So, I don't see how changing the text associated with the 
holdInstruction extension addresses people's concerns about the 
complexity of supporting certificate suspension.

> Use of reject allows CAs to do what CRLs otherwise prohibit (as Sharon 
> noted), i.e., to temporarily revoke a cert.
Again, the use of the certificateHold value for the reasonCode extension 
is what allows this, not some value in the holdInstruction extension.

Dave

Stephen Kent wrote:
> instruction codes imposes a significant burden on RPs, in general. The 
> only instruction code that does not do this is reject, because it says 
> that the RP treats the cert as revoked.
>
> Use of reject allows CAs to do what CRLs otherwise prohibit (as Sharon 
> noted), i.e., to temporarily revoke a cert. Of course_ real_ 
> with Russ's proposal to require support for the reject instruction code.
>
> these other codes, for now. In the long run, we want to discourage CAs 
> against using ANY of the other codes, because of the burdens they 
> so I cannot agree with your conclusion that it is the only meaningful one.
>
> Steve

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 01 Dec 2006 15:25:19 +0000

Hi David,

Maybe there's another way to look at this. If we want 3280bis to be
a candidate for DS then we'll want >=2 implementations of this.

Do two interoperable implementations of these things exist?

I'd bet not,
S.

---

From: "David A. Cooper" <[email-masked]>
Date: Fri, 01 Dec 2006 11:09:35 -0500

Stephen,

What does it mean to implement the holdInstruction extension?  According 
to 3280bis, a client that processes the extension may simply reject the 
certificate if the holdInstruction extension is present and any of the 
three mentioned hold instructions are used.  A client can even 
legitimately claim to support the id-holdinstruction-callissuer hold 
instruction if it simply rejects the certificate.  So, how does one 
demonstrate that there are >=2 implementations of the holdInstruction 
extension (or of the three particular values specified for the 
extension) when a client that supports the extension may not do anything 
differently than a client that does not recognize the extension.

How is it any easier to demonstrate support for the revised language?  
It states that clients that support the extension MUST recognize the 
id-holdinstruction-reject hold instruction.  Which means what?  Reject 
the certificate.  What is a client expected to do if one of the other 
hold instructions is encountered?  Reject the certificate.  What is a 
client expected to do if it does not recognize the holdInstruction 
extension or if the holdInstruction extension is not present?  Reject 
the certificate.  So, what would be needed to demonstrate two 
implementations of the proposed text versus demonstrating two 
implementations of the current text?

If something needs to be changed in order to allow 3280bis to advance to 
Draft Standard, it seems that the only thing that would help would be to 
eliminate the extension from 3280bis entirely.  I don't see how the 
proposed language helps.

Dave

Stephen Farrell wrote:
>> extension if the id-holdinstruction-reject hold instruction is going 
>> to be asserted, nor do I see how the inclusion of the holdInstruction 
>> extension with one value imposes any more of a burden on relying 
>> parties than the inclusion of the extension with any other value.
>>
>> At least with the id-holdinstruction-callissuer hold instruction, it 
>> is clear how a relying party MIGHT do something different than if the 
>> holdInstruction extension were not present.  I am not saying that I 
>> am a big fan of this hold instruction, but at least I can understand 
>> that including this hold instruction conveys some information that 
>> would not be conveyed if the holdInstruction extension were omitted.  
>> As for burden on relying parties: support for the holdInstruction 
>> extension is optional and RFC 3280 states that even relying parties 
>> that choose to support the extension may simply reject any 
>> certificate where the hold instruction is 
>> id-holdinstruction-callissuer, so I don't see how the presence of 
>> this hold instruction creates a significant (or any) burden.  The 
>> inclusion of this hold instruction simply provides the relying party 
>> with another option.  I think we all agree that it is an option that 
>> will rarely be used, but indicating in a non-critical extension that 
>> an additional option is available does not impose a burden on the 
>> relying party since the relying party is only affected if it chooses 
>> to make use of that option.  For this reason, I don't see the 
>> after last call has been closed, especially given that the text in 
>> this section has remained unchanged since RFC 2459.
>>
>> extension simply allows the CRL issuer to provide additional 
>> information to the relying party in the case that a certificate has 
>> been suspended.  So, I don't see how changing the text associated 
>> with the holdInstruction extension addresses people's concerns about 
>> the complexity of supporting certificate suspension.
>>
>>> Sharon noted), i.e., to temporarily revoke a cert.
>> Again, the use of the certificateHold value for the reasonCode 
>> extension is what allows this, not some value in the holdInstruction 
>> extension.
>>
>> Dave
>>
>> Stephen Kent wrote:
>>> David,
>>>
>>> The only instruction code that does not do this is reject, because 
>>> it says that the RP treats the cert as revoked.
>>>
>>> Sharon noted), i.e., to temporarily revoke a cert. Of course_ real_ 
>>> CAs against using ANY of the other codes, because of the burdens 
>>> they place on RPs. Thus we want to admonish CAs from using other 
>>> Call issuer is an even more egregious example of externalization, 
>>> and so I cannot agree with your conclusion that it is the only 
>>> meaningful one.
>>>
>>> Steve
>>
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 01 Dec 2006 16:25:10 +0000

David A. Cooper wrote:

> eliminate the extension from 3280bis entirely.  

That'd be my preference. Simpler is better, here as elsewhere.

 > I don't see how the proposed language helps.

Fair point. But IMO the more of it we can deprecate now, the better,
though I recognise that that's not a particularly lucid line of
argument:-)

S.

---

From: Stephen Kent <[email-masked]>
Date: Wed, 6 Dec 2006 13:05:21 -0500

At 9:58 AM -0500 12/1/06, David A. Cooper wrote:
>Steve,
>
>I don't understand your claim that support for the full range of 
>hold instruction codes imposes a significant burden on relying 
>parties.
>
>relying party that can process the holdInstruction extension might 
>be expected to respond differently to the following three scenarios 
>(In each scenario, the certificate is listed on the CRL with a 
>reasonCode extension that specifies certificateHold):
>

If there is no hold instruction, a software developer has no idea 
what to do with the cert in an automated fashion. The fact that 3280 
says he MAY reject it is not definitive.

>     * Scenario 2: holdInstruction extension is present and specifies 

just as useful as scenario 1, but has the advantage of wasting 
additional bits in the CRL :-) that convey no extra meaning.

>id-holdinstruction-reject

This is a clear instruction; it says "treat this just like any 
revoked cert, for now."

I am confused by your comments re suspension. When I look at 3280, I 
see NO reason code called "suspension."  In fact, the words "suspend" 
or "suspension" appear nowhere in 3280. So, on what basis should RPs 
figure put that the reason code is used to effect suspension?

In looking at other PKIX RFCs, the term "suspension" appears only in 
our informational documents on CP/CPS.  Those document never specify 
how to achieve suspension, not are they standards track document.

Steve