Re: on-hold certificates in CRLs

Wen-Cheng Wang,

I agree that the real world can be complex. It can also be irrational, political, and driven by short term solutions that are optimized for the convenience of those who create them. None of these latter characteristics of the real world need influence our standards.

This WG has decided to deprecate some such real world solutions in the past, e.g., a model that required an RP to check a X.500 directory entry to verify cert revocation status. This example was one that involved a government-run PKI. That didn't make it right, and so we "just said no," as Nancy Reagan would have .

Based on the model you suggest, if any government-run PKI "demands" some feature of our standards, even if we believe it is technically a bad idea, we would be compelled to accommodate such demands. That is not the way the IETF works.

I wondered if your emphasis on not disagreeing with government-run PKIs might derive from your employer's (Chungwa Telecom) own PKI business, which issues smart cards and which have to comply with a Taiwan government PKI Cert policy. But I looked at version 1.1 of that CP and it does not require CAs to support suspension; it allows a CA to offer the service and says that the CPS for the CA will define the procedures associated with the service. So, at least in this case, it appears that there is not a government mandate to support suspension, but rather an individual CA decision.

Similarly, your comment "that we should care about the demand[sic] of real world" suggests that if Microsoft adopts a convention for PKI use in their OS we must endorse it too, because their products certainly represent the "real world." Again, wrong standards forum for that rationale.

Your argument is better with regard to the costs of re-issuance of improperly revoked certs for smart cards. That is the only argument you present that merits further consideration.

What really bothers me in the last paragraph is the assertion that "the intention is to protect relying parties."  Sometimes when I use my credit card I am asked to produce a photo ID. I decline. The merchant then says "this is for your protection."  Nonsense. The request for a photo ID is a measure used by the merchant to minimize his risk of fraud, not to protect me against fraudulent charges that might be incurred using my card (for which I would not be responsible). The similarity between your argument and this one is bothersome.

Revocation of a cert protects a relying party just fine. Having to interpret a HOLD instruction introduces more complexity for RPs, and if the outcome is to treat the cert as revoked at the point in time while it is on hold, then the RP has an easier task if the cert IS just revoked.

Steve

Re: WG Last Call Comment for 3280bis

Re: on-hold certificates in CRLs

Re: WG Last Call Comment for 3280bis

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" <housley <at> vigilsec.com>
To: <ietf-pkix <at> imc.org>
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.
>

RE: WG Last Call Comment for 3280bis

I am not ok with Russ's language for the reasons I and David Cooper have
cited.

I am ok with Wen-Cheng suggestion of deprecating the hold instruction.
It is non-critical anyway and the CRL processing logic does not discuss
it now.

-----Original Message-----
From: owner-ietf-pkix <at> mail.imc.org [mailto:owner-ietf-pkix <at> mail.imc.org]
On Behalf Of Wen-Cheng Wang
Sent: Friday, December 01, 2006 7:11 AM
To: ietf-pkix <at> imc.org; Russ Housley
Subject: Re: WG Last Call Comment for 3280bis

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" <housley <at> vigilsec.com>
To: <ietf-pkix <at> imc.org>
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.
>

Re: WG Last Call Comment for 3280bis

Re: WG Last Call Comment for 3280bis

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.

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

Re: WG Last Call Comment for 3280bis

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

Re: WG Last Call Comment for 3280bis

David A. Cooper wrote:

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

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.

RE: WG Last Call Comment for 3280bis

"Santosh Chokhani" <chokhani <at> orionsec.com> writes:

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

It makes sense (in the sense that it parses gramatically), but it still
doesn't correctly convey the intent, which is to say "If you use this
extension, you're on your own, because no two people can agree on how to
handle it".  Perhaps the text could say something like:

  There is no consensus in the community over how to handle this extension
  except for general agreement that it's a bad idea and shouldn't be used.
  Developers should be aware that the semantics of this extension depend
  heavily on individual implementations, and may vary widely across
  implementations.

Peter.