Obviously I think good is the best answer based on my previous posts. A precert is still a cert. But I can see how people could disagree with me. ________________________________ From: dev-security-policy <dev-security-policy-boun...@lists.mozilla.org> on behalf of Jeremy Rowley via dev-security-policy <dev-security-policy@lists.mozilla.org> Sent: Saturday, August 31, 2019 9:05:24 AM To: Tomas Gustavsson <tomasshred...@gmail.com>; 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
I dont recall the cab forum ever contemplating or discussing ocsp for precertificates. The requirement to provide responses is pretty clear, but what that response should be is a little confusing imo. ________________________________ 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 9:00:08 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 On Saturday, August 31, 2019 at 3:13:00 PM UTC+2, Jeremy Rowley wrote: > >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. Was there not a plan in CABF on allowing unathorized for "unknown" responses to save on private key usage? (I'm unable to find it now) > > ________________________________ > 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 _______________________________________________ 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
