Subject: Re: on-hold certificates in CRLs

From: Stephen Kent <[email-masked]>
Date: Fri, 1 Dec 2006 00:52:10 -0500

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

---

From: "Wen-Cheng Wang" <[email-masked]>
Date: Fri, 1 Dec 2006 19:59:33 +0800

Re: on-hold certificates in CRLsSteve,
  Stephen Kent wrote:

  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 did not suggested that. Maybe it is my awkward English make you
misinterpret my words. What I want to suggested is "the real world
demands certificate suspension mechanism, and thus this WG should
not depracate the use of that mechanism".

The reason that I took government-run PKIs as examples is simply due
to it is the area I was involved in more deeply. This has nothing to do
whether we would be compelled to accommodate any government-run
PKI "demands". The are just the examples that came across my mind.

If you do not like government-run PKIs, then please take a little time
to enter "certificate suspension" as keyword into your favorite search
engine. You will find that there are many PKIs that claim they provide
certificate suspension service. Some of them are government-run PKIs,
and the others are commercial PKIs. Even VeriSign claim they provide
certificate suspension service in their CP. (although I have no idea how
they implement it.)

BTW, even if government-run PKIs is the only parties that demand certificate
suspension mechanism, do we need to disdain their demands and behave in
such an anti-government manner? Please remember that currently governments
all over the world are the major driven force of PKI deployments. I agree that the
IETF has no obligation to accommodate government demands, while I also
believe that the IETF is not an anti-government society.
  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.
This is your wrong conjecture. What I have posted in this list has nothing to
do with my employer' business. I jumped in this thread of discussions because
I were trying to share my own experiences learnt from my professional career.
You are free to disagree with my opinions, but please do not make this kind
of hurting conjecture.

BTW, it is ture that the CP of Taiwan Government PKI does not
mandate government-run CAs to offer certificate suspension
service, the CP let government agencies to decide whether
to offer certificate suspension service. Eventually, all CAs
in Taiwan Government PKI offer certificate suspension services
because all government agencies running CAs determine
that there are demands to suspend certificates in some situations.
The CP is an important document of the PKI, but there are other
laws/regulations make  government agencies decide to offer
certificate suspension services.

I think there is not need to shift our focus to how Taiwan Govenrment
PKI offer certificate suspension services, we should focus on whether
the real world demands certificate suspension mechanism.

  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.
This is not my 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.
Well, it is a consolation.

  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.

I have never ever had the intention to ask relying parties to support
any hold instruction. 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. This make certificate suspension
mechanism as simple as certificate revocation mechansim is. By doing
this, I do not see why certificate suspension can not be used to protect
relying parties as certificate revocation does.

Wen-Cheng Wang