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

[[e-mail] (Martin Rex)]

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.

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


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


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



-Martin