On Saturday, August 31, 2019 at 5:07:48 PM UTC+2, Jeremy Rowley wrote: > 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.
I don't see anything fundamentally wrong with either approach. Since BR 4.9.10 has a four day update window it would typically, within the BR limits, only be an internal exercise for the CA. BR 4.9.10: "For the status of Subscriber Certificates: The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days." > ________________________________ > From: dev-security-policy <[email protected]> on > behalf of Jeremy Rowley via dev-security-policy > <[email protected]> > Sent: Saturday, August 31, 2019 9:05:24 AM > To: Tomas Gustavsson <[email protected]>; > [email protected] > <[email protected]> > 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 <[email protected]> on > behalf of Tomas Gustavsson via dev-security-policy > <[email protected]> > Sent: Saturday, August 31, 2019 9:00:08 AM > To: [email protected] > <[email protected]> > 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 <[email protected]> > > on behalf of Tomas Gustavsson via dev-security-policy > > <[email protected]> > > Sent: Saturday, August 31, 2019 5:01:42 AM > > To: [email protected] > > <[email protected]> > > 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 > > [email protected] > > https://lists.mozilla.org/listinfo/dev-security-policy > > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
