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

[Erwann Abalea <[e-mail]>]

2012/10/23 Martin Rex <[e-mail]>

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


No. It indicates that the corresponding (existent) certificate has been put
on hold.
You're asking the CA to assert a status for a non-existent certificate.

What's next? Ask CAs to sign the next OCSP response with a "removeFromCRL"
code for dumb serial numbers for which they replied "certificateHold"? Why
not also add a holdInstructionCode extension to the OCSP response, and
define proper codes?

The number of bogus requests far outweighs the number of bad certificates.
In our case, as a public CA, it even outweighs the number of good public
certificates we produced.

Asking for a signed response to a bogus request gives anonymous attackers
much power. Consider big CAs that receive billions of OCSP requests a week,
or even a day (that's reality). Do you really consider that asking for
billions of signatures a day for bogus requests, asserting an authoritative
status for nonexistent certificate is the right thing to do?

With my "CA" hat, I see that OCSP is a hidden cost, and you want to make it
more costly.
With my "user" hat, I see that revocation checks are not properly done,
pressure is put on certificate issuers but if relying parties don't do
their job it's useless.
The two added together will just build something more costly but still
useless.

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

No sophism here. My point is that I don't think the problem is correctly
addressed.


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

Correct. And? Whatever you ask the CA to do, the attacker can avoid it.
Wrong end of the problem.


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


The OCSP request doesn't match an existent certificate, yet you want the CA
to declare it as revoked, discuss about the correct revocation reason to
use, and a correct revocation date. But this response is not a lie.
Something's wrong.


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

That's the good end of the problem.

-- 
Erwann.