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
I did not suggested that. Maybe it is my awkward English make
misinterpret my words. What I want to suggested is "the real
demands certificate suspension mechanism, and thus this WG
not depracate the use of that mechanism".
The reason that I took government-run PKIs as examples is
to it is the area I was involved in more deeply. This has
nothing to do
whether we would be compelled to accommodate any
PKI "demands". The are just the examples that came across my
If you do not like government-run PKIs, then please take a little
to enter "certificate suspension" as keyword into your favorite
engine. You will find that there are many PKIs that claim they
certificate suspension service. Some of them are government-run
and the others are commercial PKIs. Even VeriSign claim they
certificate suspension service in their CP. (although I have no
they implement it.)
BTW, even if government-run PKIs is the only parties that demand
suspension mechanism, do we need to disdain their demands and
such an anti-government manner? Please remember that currently
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
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
do with my employer' business. I jumped in this thread of
I were trying to share my own experiences learnt from my
You are free to disagree with my opinions, but please do not make
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
because all government agencies running CAs determine
that there are demands to suspend certificates in some
The CP is an important document of the PKI, but there are
laws/regulations make government agencies decide to
certificate suspension services.
I think there is not need to shift our focus to how Taiwan
PKI offer certificate suspension services, we should focus on
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
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
any hold instruction. I would prefer the WG to deprecate the
use of the hold instruction extension but only allow the use of
and "removeFromCRL" CRL reason code. This make certificate
mechanism as simple as certificate revocation mechansim is. By
this, I do not see why certificate suspension can not be used to
relying parties as certificate revocation does.