> 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 _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
