Re: [pkix] Gen-ART review of draft-ietf-pkix-rfc2560bis-15

["Piyush Jain" <[e-mail]>]

> There is *NO* overloading of a revoked status.  The change is making use
of
> an existing temporary revocation status (certificateHold) **EXACTLY** with
> the original semantics for a temporary revocation, originating from X.509
> 08/2005 8.5.2.2 (a):
> 
[Piyush] Revokes status is being used to communicate non-existent
certificates. 

> 
> If you want to describe "an OCSP responder no longer responding 'good'
> for certificate serial numbers for which no records of issuance exist"
> as "breaking compatibility with older clients", then yes, this is what we
want
> to do.

[Piyush] That is not what I implied.  There were alternatives proposed to
address fraudulently-issued certificates in OCSP (none of them solved the
problem completely BTW). 
The reason cited by you along with a few others was that any other proposal
would require clients to be updated. This is what breaking backward
compatibility means.
> 
> But in reality, this is change is about fixing a security problem that was
> documented as such in rfc2560 for the "good" status.
> 
[Piyush] What security problem? I don't see any security problem documented
in RFC 2560 bis and repeated refusal to discuss how 2560bis solves any
security problems. The only vague goal stated is - "it allows responders to
return revoked for non-issued so clients do not fall back to CRL"
I also see a creative way to circumvent responder trust issue by saying that
servers indicate "non-issued" by setting the revocation date to 1970 but
clients should not interpret the response as non-issued.
> 
> > 
> >
> > I believe that Stefan is trying to convey that requiring servers to
> > return revoked in this context will make them non-compliant with 2560
> > and 5019 as opposed to breaking interoperability with legacy clients.


[Piyush] This part I agree with as I stated in my original post. Backward
compatibility is wrong choice of words. Compliance with other standards is
the right choice.
Standards are not backward compatible. Implementations of standards are.
> 
> The proposed change primarily intends to _standardize_ how to report
> revoked/certificateHold for "not-issued" certificate serial numbers,
> something that has been found useful (and already been used) in dealing
> with certain kinds of security breaches of CAs/RAs.
> 
[Piyush] May be so. But that is not the goal cited for this update. Yes a
few CA vendors may have adopted it but that no way indicates consensus among
CA vendors.
If you refer to CAB forum thread, most reputable CA vendors are reluctant to
adopt it.
> 
> Returning an error code response status would be
> just dumb for an authoritative OCSP responder.
> 
[Piyush] Really. And why is that. It actually makes a lot of sense and that
is why CAs "who are not compromised" continue to return an error code for
such responses.
The only requirement for them is to be confident of the certificates they
have issued. The only reason a CA would return a revoked for non-issued is
that it is not sure if certificates are fraudulently issued using its key.

> 
> Should rfc5019 be interpreted to suggest for authoritative OCSP responders
> to returning an error code for "not-issued" certs does not make such
> behaviour any less dumb.
> 
[Piyush] The behavior that you are calling dumb has enabled the CAs to scale
their OCSP infrastructure.
What is dumb IMO is to continue to run the CA after being compromised and
demanding that standards be updated to support such behavior.
> 
> -Martin