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

[Erwann Abalea <[e-mail]>]

Bonjour,

2012/10/22 Martin Rex <[e-mail]>:
> Simon Tardell wrote:
>>
>> I suggest that we use your current text plus that, if "revoked" is used
>> to say "never issued/not in database", the revocationReason should be
>> certificateHold and that revocationTime should be set to midnight Jan 1
>> 1950 (or some other time before the rise of PKI).
>
> I support the "revoked, ReasonCode=CertificateHold" for OCSP responders
> that can not find proof/indication that the cert in question was properly
> issued.

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.

> The CertificateHold reason code is vitally important, because otherwise
> the CA would have to keep track of OCSP responses given out from the
> CA's OCSP responder that declared a serial as "permanently revoked"
> in order to ensure that the CA will never issue a cert with that serial
> in the future.  Looks like an unnecessary and easily avoidable burden to me.

This is why I don't think that declaring an unknown and potentially
random serial number as revoked is good. Nor useful.
An attacker will most likely intercept communications with the
responder and reply something like "unauthorized", or any unsigned
error code.

> I don't like the particular date Jan 1, 1950, for safety, a date >= 1970
> ought to be chosen (so that it does not get negative when converted
> to time_t, which has potential to confuse some code).
>
> And since the timestamp is a GeneralizedTime, the date ought to be
> given in exactly that format, e.g.  "700101010101Z"
>
> What also should be noted is that the optional OCSP SingleResponseExtension
> "CrlID" must not be used when this "not issued" certificate was not
> conveyed through a CRL--and there currently is no means to convey
> proof-of-cert-existence through CRLs unless they're revoked, and in the
> latter case there would be no "not issued" OCSP response to convey.

See, by declaring a non-issued certificate as revoked, you're asking
the CA to lie about its revocation date and declare it's not been
issued in a CRL. How can it be right?

> I believe it is very inappropriate for the spec to make any assumptions
> about why exactly the OCSP responder believes that a cert (serial) has not
> ever been issued.  The reason can be manyfold.  Besides an accidental or
> fraudulent deletion (attack), it may be something as simple as a
> database software bug.

Or invalid encoding in client, or wrong issuerKeyHash (the serial
exists, but for another CA), or random serial, or specially crafted
numbers, or unrecognized hash function, ... All these cases have been
spotted on our responders, and we haven't wrongly issued certificates.

-- 
Erwann.