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

[[e-mail] (Martin Rex)]

Patching a defect of my last message:

Martin Rex wrote:
> 
> >
> > For me, asking for the OCSP responder (often the CA itself) to declare than
> > a non-existent certificate (Case 1) is revoked is a bad practice, and it
> > even doesn't solve the problem.
> >
> > Asking for OCSP responders to add something to "good" responses proving
> > they have access to a list of issued certificates (like the hash of the
> > certificate) is a better way to solve the problem. It must be backed-up
> > with rules or recommendations applied to RP to avoid a fallback to CRLs.
> 
> 
> The hard-fail option didn't work for the existing OCSP, how likely
> is it that it would work for a brand-new optional protocol extension?
> 
> The "cert hash" option in the reply can not protect against any attacks,
> whereas the "revoked,certificateHold" option for serials not on the
> record of issued certs can at least protect against _some_ attacks.

The "cert hash" in the OCSP response option protects against
hash-collisions and fraudulently issued without record of certs
that re-use the serial of regular valid certs to appear innocent
from not being detectable.

So that cert hash should probably use at least SHA-256.  Being a
new protocol feature, that ought to be easy (we skipped SHA-1
in DANE as well).


-Martin