Hi, I find and hear a few non conclusive, sometimes contradictory, messages about OCSP responder handling of pre-certificates without final certificates. Reading this thread I don't find a firm conclusion either (albeit I may have missed it). I'm not saying anything others have not said before, so I don't claim to say anything new, just to summarize what I believe to be a safe behavior.
(I'm merely interested in the technical behavior of an OCSP responder) My position dates back to 2013 during CT implementation. Discussions back then: https://groups.google.com/forum/m/#!searchin/certificate-transparency/tomas/certificate-transparency/1tWzSXKe3gQ "a Precertificate is arguably not a Certificate". as well as: "The precertificate contains a critical extension that no verifier should understand, and therefore will not verify." In combination with RFC6960 (introduction): "The Online Certificate Status Protocol (OCSP) enables applications to determine the (revocation) state of identified certificates." and Ballot 80: https://cabforum.org/2012/08/02/ballot-80-response-for-non-issued-certificates/ For an OCSP server a query is neither for a "pre certificate" nor a "certificate", the OCSP responder just sees an issuer (hash) and a serial number. It's a query for revocation status about the issuer and serial number pair passed in the request. >From this my conclusion was, and still is: - A pre certificate is not an issued certificate in the Web PKI. As such an OCSP responder should answer "anything but good" for this issuer/serialnumber combination if a "real" certificate has not been (yet) issued. >From a RP perspective, any RP that queries OCSP during an attempt, with >intent, to use a pre certificate (with poison extension) is broken and the >only safe goal is to try to prevent this RP from using the pre certificate. >Again my conclusion is that the safe way is to answer "anything but good". For OCSP there are at least two corner cases here: 1. A pre certificate has been issued, but the real certificate has not and never will be 2. There is a time gap period between the issuance of the pre certificate and the real certificate For 1, the "intended to be issued" certificate should be revoked asap in any case, so "anything but good" is the proper answer. For 2, there is a short period where someone monitoring log servers may discover the pre certificate and poison any OCSP response cache by querying for this issuer/serial (getting a "anything but good" for the not yet issued real certificate). After cache expiry the response will be good. The same can happen by shotgunning the OCSP responder with random serials, albeit it's hard to hit a "real" upcoming serial number in the >64bit random serial number space, or if there is a delay between releasing the real certificate and fully distributing it to OCSP responders. When direct updates to OCSP is used this periods is measured in seconds maximum, and milliseconds optimally. Making a long story short: - I belive answering "anything but good" is a proper answer for pre certificates (issuer/serialno) where no real certificate was issued or distributed. Did I miss anything? Regards, Tomas _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
