>From RFC6962: “As above, the Precertificate submission MUST be accompanied by the Precertificate Signing Certificate, if used, and all additional certificates required to verify the chain up to an accepted root certificate. The signature on the TBSCertificate indicates the certificate authority's intent to issue a certificate. This intent is considered binding (i.e., misissuance of the Precertificate is considered equal to misissuance of the final certificate). Each log verifies the Precertificate signature chain and issues a Signed Certificate Timestamp on the corresponding TBSCertificate.”
>From 7.1.2.5 of the baseline requirements: “For purposes of clarification, a Precertificate, as described in RFC 6962 – Certificate Transparency, shall not be considered to be a “certificate” subject to the requirements of RFC 5280 - Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile under these Baseline Requirements” >From 6960: The "good" state indicates a positive response to the status inquiry. At a minimum, this positive response indicates that no certificate with the requested certificate serial number currently within its validity interval is revoked. This state does not necessarily mean that the certificate was ever issued or that the time at which the response was produced is within the certificate's validity interval. Response extensions may be used to convey additional information on assertions made by the responder regarding the status of the certificate, such as a positive statement about issuance, validity, etc. The "revoked" state indicates that the certificate has been revoked, either temporarily (the revocation reason is certificateHold) or permanently. This state MAY also be returned if the associated CA has no record of ever having issued a certificate with the certificate serial number in the request, using any current or previous issuing key (referred to as a "non-issued" certificate in this document). The "unknown" state indicates that the responder doesn't know about the certificate being requested, usually because the request indicates an unrecognized issuer that is not served by this responder.” Mozilla Policy: 1. Does not define a precertificate. Instead Mozilla policy covers everything with serverAuth (1.1) 2. Requires functioning OCSP if the certificate contains an AIA (5.2) 3. Must provide revocation information via the AIA for the cert (6) Argument for responding “Good”: A pre-certificate is a certificate and contains an AIA. Per the Mozilla policy, the CA must provide services. Providing revoked or unknown is incorrect because the pre-cert did issue. Although the BRs define the pre-cert as out of scope of the BRs for CRLs and 5280, that just means the serial number can repeat. Responding anything other than good would provide wrong information about the status of the pre-cert. Argument for responding “Revoked”, “Unknown”, or “Invalid”: A pre-certificate is not a cert. The BRs define it as a not a cert as does RFC 6962. A pre-cert is an intent to issue a certificate. RFC6960 specifically calls out that the CA may use revoke as a response for certificates without a record of being issued and unknown where there isn’t a status yet. Although the Mozilla policy is silent on the status of whether a pre-cert is a certificate, section 2.3 incorporates the baseline requirements. As such, the Mozilla policy implicitly defines a precertificate as “not a certificate”. Because it’s not a certificate the OCSP service does not know how to respond so any response is okay because there is no certificate with that serial number until the ‘intent to issue’ is fulfilled. Note that even if you argue that “revoked”, “invalid”, or “unknown” are appropriate, the RFC still permits “good” as a response because no certificates with that serial number are revoked. Good is the safe answer. ________________________________ From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> on behalf of Tomas Gustavsson via dev-security-policy <dev-security-policy@lists.mozilla.org> Sent: Saturday, August 31, 2019 5:01:42 AM To: mozilla-dev-security-pol...@lists.mozilla.org <mozilla-dev-security-pol...@lists.mozilla.org> Subject: Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
