Re: [pkix] New draft-ietf-pkix-rfc2560bis-06

[Denis Pinkas <[e-mail]>]

Martin,

Erwann said:

"I don't think it's wise to use one reason code to cover two reasons.

The latest CAs we deployed want to have certificates issued in a
suspended state until the smartcard has been delivered, whence
"certificateHold" reason code, with CRLs filled in that way. For these
CAs, an OCSP responder will respond "certificateHold" for legitimate
certificates, and you're proposing to also reply "certificateHold" for
random serial numbers".

You said:

"CertificateHold is EXACTLY the correct ReasonCode:
It indicates that the CA has not issued a cert with the given serial
*YET*, but it MAY eventually issue such a cert in the future
(sometimes even in the_very_next_future_  ... i.e. it is about
  to become visible to the OCSP responder, but not visible yet)".

I am sorry, but I agree with Erwann and thus I disagree with you.

The certificateHold state was not created to have certificates issued
in a suspended state. It was created to allow a user to suspend its certificates
rather than revoking its certificates, in case a smart card was temporarily lost and
since after a revocation it may take a while to get a new smart card.

Some people, then used also the certificateHold state to have certificates issued
in a suspended state. This is legitimate since it complies with the semantics of
the certificateHold state.

We should not change/overload the meaning of CertificateHold.
.
Denis