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

[[e-mail] (Martin Rex)]

Erwann Abalea wrote:
> 
> 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.

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


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

This rationale is a non-sequitur.

An attacker can substitute any response with any kind of error.
Or make the DNS lookup of the OCSP responder fail, or insert
a ICMP error or TCP on the connection attempt to the OCSP responder.

The purpose of the change here is to have the proper OCSP responder
return completely useless responses in a situation where the OCSP
responder has access to the CA issue logs and can determine that
the cert in the request has not been issued (yet).



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

You're absolutely NOT lying at all.  The cert with that serial has
not been issued yet, but a cert with that cert may get issued in the
future.  The CertificateHold is perfectly appropriate to describe
this situation.


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


I was saying that the spec should advise against OCSP response recipients
to draw conclusions (about causes), and take the response as what it is,
a description of state, *NOT* an indicator of any precice cause.


-Martin