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 <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

Reply via email to