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

Reply via email to