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

[Erwann Abalea <[e-mail]>]

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

> Erwann Abalea wrote:
> >> 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.
>
> Where exactly does X.509 or PKIX require that a serial on a CRL
> will have to refer to an existing cert, i.e. one that the CA has
> positive proof to have issued.  I (now) believe this is a completely
> flawed assumption.
>

X.509, 7.3
revokedCertificates identifies certificates that have been revoked. The
revoked certificates are identified by their serial
numbers.

CRL as in "Certificate Revocation List", not as in "inexistent Certificate
Revocation List".
Fraudulently producing certificates is bad, but producing a CRL for
nonexistent certificate is good?

CRLs and OCSP only assert a state to a certificate serial.
> Infering about existance/noexistance of certs is a logical fallacy.


The certificate is identified by its serial number (along with its issuer
name, of course). What is the meaning/value of a serial number that doesn't
identify anything?


> > 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?
>
> removeFromCRL doesn't make sense in an OCSP response, because OCSP does
> not hand out CRLs.
>

But holdInstructionCode could make sense, right?

> 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.
>
>
> Having an OCSP responder look at cert issuance logs and produce an
> intelligible, risk-reducing response rather that an entirely useless
> response will be a completely optional feature!
>
> Nobody is pushing *YOU* to have your OCSP responder adopt this.
>
> But why are you so obsessed in denying others that possibility?
>
>
> If you're concerned about the load of creating signatures
> for "not issued" requests, you may want to talk to Denis first,
> who proposed to create signatures on errors, and in particular on
> "not authorized" errors (which includes requests for status of
> certs from other CAs).
>

I apologize if I offended you, I'm not pointing at you personally, just
replying to the thread. I choose an anchor and it was one of your posts,
nothing more.

I have nothing against a "positive assertion", maybe the hash of the
certificate for which the responder produces a good answer. If the
responder can have access to an issuance log and pick useful authoritative
information from it and optionally deliver it with the response, I'm fine.
Asking for a signed response from a bogus request is different. The thread
then slept into producing a revoked response for bogus requests, and
discussing about what could a plausible reason code and revocation date be.

I believe that a well-behaving CA shouldn't produce a CRL containing random
serial numbers provided by anonymous requesters.
By extension, I believe that a well-behaving OCSP responder shouldn't
assert anything authoritative (either good or revoked) about a random
serial number. That's a fail for the "good" response because an OCSP
responder can be based on a blacklist, I don't think that changing "good"
into "revoked" is the right way to solve this problem.

-- 
Erwann.