Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
On 03/09/2019 00:54, Ryan Sleevi wrote: > On Mon, Sep 2, 2019 at 2:14 PM Alex Cohn via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> If an OCSP server supports returning (or always returns) properties of >>> the actual cert, such as the CT proofs, then it really cannot do its >>> usual "good" responses until the process of retrieving CT proofs and >>> creating the final TBScertificate (and possibly signing it) has been >>> completed. >>> >>> Thus as a practical matter, treating a sign-CT-sign-CT in-process state >>> as "unknown serial, may issue in future" may often be the only practical >>> solution. >>> >> >> Waiting until CT submission of the final certificate is complete to return >> "good" OCSP responses is definitely wrong. OCSP should return "good" at the >> moment the final certificate is issued, which means in practice that there >> might be a "good" OCSP response that doesn't contain SCTs yet. >> >> I don't know if any log does this, but RFC6962 allows logs to check for >> certificate revocation before issuing a SCT; if the OCSP responder doesn't >> return "good" the CA might never get the needed SCTs? > > > Correct. Which is why I recommend CAs ignore Jakob Bohm’s advice here, as > it can lead to a host of complications for CAs, Subscribers, and Relying > Parties. > I was not advising either cause of action, I was trying to explore conflicting requirements between the BRs, PKIX and the CT spec, which has apparently lead to confusion as to the what OCSP should return for soon-to-be-issued and not-yet-issued certificates. This particular CT requirement contradicted a common Google practice across its services, which made me suspect it might be a specification oversight rather than intentional. > >> >> Also, if a CA is signing a precert, getting SCTs for that precert, then >> embedding the SCTs in the final cert, they are already satisfying the >> browsers' CT requirements. It would not be necessary for them to >> additionally embed SCTs for the final cert in their OCSP responses. >> >> Now depending on interpretations, I am unsure if returning "revoked" for >>> the general case of "unknown serial, may issue in future" would violate >>> the ban on unrevoking certificates. >>> >> >> RFC6960 section 2.2 documents a technique for indicating "unknown serial, >> may issue in future" that involves returning "revoked" with a revocation >> date of 1970-1-1 and a reason of certificateHold. I don't know if this >> technique is used anywhere in practice - IIRC it requires the OCSP signing >> key to be online and able to sign responses for arbitrary serial numbers in >> real time. > > > The BRs explicitly prohibit this. > > You cannot unrevoke or suspend. > That was my interpretation too. > (Are any CAs even using the OCSP SCT delivery option? I haven't come across >> this technique in the wild) > > > Yes, several are. > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
On Mon, Sep 2, 2019 at 2:14 PM Alex Cohn via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > If an OCSP server supports returning (or always returns) properties of > > the actual cert, such as the CT proofs, then it really cannot do its > > usual "good" responses until the process of retrieving CT proofs and > > creating the final TBScertificate (and possibly signing it) has been > > completed. > > > > Thus as a practical matter, treating a sign-CT-sign-CT in-process state > > as "unknown serial, may issue in future" may often be the only practical > > solution. > > > > Waiting until CT submission of the final certificate is complete to return > "good" OCSP responses is definitely wrong. OCSP should return "good" at the > moment the final certificate is issued, which means in practice that there > might be a "good" OCSP response that doesn't contain SCTs yet. > > I don't know if any log does this, but RFC6962 allows logs to check for > certificate revocation before issuing a SCT; if the OCSP responder doesn't > return "good" the CA might never get the needed SCTs? Correct. Which is why I recommend CAs ignore Jakob Bohm’s advice here, as it can lead to a host of complications for CAs, Subscribers, and Relying Parties. > > Also, if a CA is signing a precert, getting SCTs for that precert, then > embedding the SCTs in the final cert, they are already satisfying the > browsers' CT requirements. It would not be necessary for them to > additionally embed SCTs for the final cert in their OCSP responses. > > Now depending on interpretations, I am unsure if returning "revoked" for > > the general case of "unknown serial, may issue in future" would violate > > the ban on unrevoking certificates. > > > > RFC6960 section 2.2 documents a technique for indicating "unknown serial, > may issue in future" that involves returning "revoked" with a revocation > date of 1970-1-1 and a reason of certificateHold. I don't know if this > technique is used anywhere in practice - IIRC it requires the OCSP signing > key to be online and able to sign responses for arbitrary serial numbers in > real time. The BRs explicitly prohibit this. You cannot unrevoke or suspend. (Are any CAs even using the OCSP SCT delivery option? I haven't come across > this technique in the wild) Yes, several are. > > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
On Mon, Sep 2, 2019 at 1:36 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 02/09/2019 20:13, Alex Cohn wrote: > > On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > Waiting until CT submission of the final certificate is complete to > return > > "good" OCSP responses is definitely wrong. OCSP should return "good" at > the > > moment the final certificate is issued, which means in practice that > there > > might be a "good" OCSP response that doesn't contain SCTs yet. > > > > I don't know if any log does this, but RFC6962 allows logs to check for > > certificate revocation before issuing a SCT; if the OCSP responder > doesn't > > return "good" the CA might never get the needed SCTs? > > > > This seems to be an unfortunate aspect of the CT spec that wasn't > thought through properly. In particular, it should cause unnecessary > delay if a CA updates its OCSP servers using "eventual consistency" > principles. Maybe it should be fixed in the next update of the spec. > > The BRs have the following requirements that are best satisfied by > delayed update of OCSP servers: > > BR4.10.2 The OCSP servers must be up 24x7 . Thus rolling out updates to > different servers at different times would be a typical best practice. > > BR4.9.10 The OCSP servers only need to be updated twice a week (4 days) > .. This could only satisfy the CT requirement if issued certificates > were somehow withheld from the subscriber for up to 4 days. > Withholding certificates for four days would be a huge competitive disadvantage for a CA. If I were a CA relying on OCSP delivery of SCTs, I would try to make absolutely sure my OCSP responders could be updated with SCTs in a timely manner after initial issuance. Since this SCT delivery method relies on OCSP stapling to work, I could even tell my customers to configure their web servers with a special OCSP server URL (using, e.g., nginx's ssl_stapling_responder directive) that would block until a response with embedded SCTs could be created. > > RFC6960 section 2.2 documents a technique for indicating "unknown serial, > > may issue in future" that involves returning "revoked" with a revocation > > date of 1970-1-1 and a reason of certificateHold. I don't know if this > > technique is used anywhere in practice - IIRC it requires the OCSP > signing > > key to be online and able to sign responses for arbitrary serial numbers > in > > real time. > > > > The question was if this technique would be in violation of the BRs, as > those generally prohibit the use of "certificateHold" . > Where is this prohibition in the BRs? The only relevant section I could find is 4.9.13, which prohibits suspension of certificates. This isn't suspension of a certificate; the certificate doesn't exist. Alex ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
On 02/09/2019 20:13, Alex Cohn wrote: On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: If an OCSP server supports returning (or always returns) properties of the actual cert, such as the CT proofs, then it really cannot do its usual "good" responses until the process of retrieving CT proofs and creating the final TBScertificate (and possibly signing it) has been completed. Thus as a practical matter, treating a sign-CT-sign-CT in-process state as "unknown serial, may issue in future" may often be the only practical solution. Waiting until CT submission of the final certificate is complete to return "good" OCSP responses is definitely wrong. OCSP should return "good" at the moment the final certificate is issued, which means in practice that there might be a "good" OCSP response that doesn't contain SCTs yet. I don't know if any log does this, but RFC6962 allows logs to check for certificate revocation before issuing a SCT; if the OCSP responder doesn't return "good" the CA might never get the needed SCTs? This seems to be an unfortunate aspect of the CT spec that wasn't thought through properly. In particular, it should cause unnecessary delay if a CA updates its OCSP servers using "eventual consistency" principles. Maybe it should be fixed in the next update of the spec. The BRs have the following requirements that are best satisfied by delayed update of OCSP servers: BR4.10.2 The OCSP servers must be up 24x7 . Thus rolling out updates to different servers at different times would be a typical best practice. BR4.9.10 The OCSP servers only need to be updated twice a week (4 days) .. This could only satisfy the CT requirement if issued certificates were somehow withheld from the subscriber for up to 4 days. Also, if a CA is signing a precert, getting SCTs for that precert, then embedding the SCTs in the final cert, they are already satisfying the browsers' CT requirements. It would not be necessary for them to additionally embed SCTs for the final cert in their OCSP responses. Now depending on interpretations, I am unsure if returning "revoked" for the general case of "unknown serial, may issue in future" would violate the ban on unrevoking certificates. RFC6960 section 2.2 documents a technique for indicating "unknown serial, may issue in future" that involves returning "revoked" with a revocation date of 1970-1-1 and a reason of certificateHold. I don't know if this technique is used anywhere in practice - IIRC it requires the OCSP signing key to be online and able to sign responses for arbitrary serial numbers in real time. The question was if this technique would be in violation of the BRs, as those generally prohibit the use of "certificateHold" . (Are any CAs even using the OCSP SCT delivery option? I haven't come across this technique in the wild) Alex Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
On Mon, Sep 2, 2019 at 12:42 PM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > If an OCSP server supports returning (or always returns) properties of > the actual cert, such as the CT proofs, then it really cannot do its > usual "good" responses until the process of retrieving CT proofs and > creating the final TBScertificate (and possibly signing it) has been > completed. > > Thus as a practical matter, treating a sign-CT-sign-CT in-process state > as "unknown serial, may issue in future" may often be the only practical > solution. > Waiting until CT submission of the final certificate is complete to return "good" OCSP responses is definitely wrong. OCSP should return "good" at the moment the final certificate is issued, which means in practice that there might be a "good" OCSP response that doesn't contain SCTs yet. I don't know if any log does this, but RFC6962 allows logs to check for certificate revocation before issuing a SCT; if the OCSP responder doesn't return "good" the CA might never get the needed SCTs? Also, if a CA is signing a precert, getting SCTs for that precert, then embedding the SCTs in the final cert, they are already satisfying the browsers' CT requirements. It would not be necessary for them to additionally embed SCTs for the final cert in their OCSP responses. Now depending on interpretations, I am unsure if returning "revoked" for > the general case of "unknown serial, may issue in future" would violate > the ban on unrevoking certificates. > RFC6960 section 2.2 documents a technique for indicating "unknown serial, may issue in future" that involves returning "revoked" with a revocation date of 1970-1-1 and a reason of certificateHold. I don't know if this technique is used anywhere in practice - IIRC it requires the OCSP signing key to be online and able to sign responses for arbitrary serial numbers in real time. (Are any CAs even using the OCSP SCT delivery option? I haven't come across this technique in the wild) Alex ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
If an OCSP server supports returning (or always returns) properties of the actual cert, such as the CT proofs, then it really cannot do its usual "good" responses until the process of retrieving CT proofs and creating the final TBScertificate (and possibly signing it) has been completed. Thus as a practical matter, treating a sign-CT-sign-CT in-process state as "unknown serial, may issue in future" may often be the only practical solution. Now depending on interpretations, I am unsure if returning "revoked" for the general case of "unknown serial, may issue in future" would violate the ban on unrevoking certificates. On 31/08/2019 17:07, 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. > > From: dev-security-policy on > behalf of Jeremy Rowley via dev-security-policy > > Sent: Saturday, August 31, 2019 9:05:24 AM > To: Tomas Gustavsson ; > 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. > ... Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Intent to Ship: Move Extended Validation Information out of the URL bar
Am Sonntag, 1. September 2019 04:27:04 UTC+2 schrieb Peter Gutmann: > Since the value to criminals of EV web certs is low, it seems they're not > doing much to stop what the criminals are doing. If they did have any value > then criminals would be prepared to pay more for them, like they already do > for EV code-signing certs. But the target audience for phishing are uninformed people. People which have no idea what a EV cert is. People who don't even blink if the English on the phishing page is worse than a 5-year old could produce. You cannot base the decision if a EV indication in the browser is useful on those people. Same as you all, I don't have any “official” data to base these beliefs on. But for example there are studies which conclude that email scammers intentionally use unbelievable stories and bad grammar. Why do they do this? Because sending mails is free but interacting with replies is costly. They only want the most gullible people to answer in the first place. In the same way, I argue, even if criminals would create scam websites with EV certificates, fewer people would notice immediately that the page is wrong. But this people are not the target group of the scammer anyway. This are the users that are already aware of the dangers on the internet. If they wouldn't leave the page because of the missing EV certificate, they would most likely find another sign that the page is fake and still leave. The reason why criminals don't need EV certificates is: The people caring about EV indicators are not their target group. The problem is that the data actually needed is missing and many here just use the easily available data and pretend it is possible to draw any valid conclusions from that. The data we would need is: How many people do leave a malicious webpage because the EV indicator is missing? The only data I have seen here is: (Estimated) how many people do enter their data in malicious websites. It is just simply not possible to draw any information about the first question from answers to the second. Using the same logic applied by many in favor of removing the EV indication one could argue against almost anything. E.g. for arguing against DUI laws: 1. Find a point in time when no DUI laws existed in a jurisdiction and there were fewer cases of drunk drivers than now. (trivial, because at some time there even where fewer drivers in total than drunk drivers now) 2. Argue that the DUI laws obviously don't prevent drunk driving, because not only are there still people driving drunken, but there are even a lot more of them than at the time found in 1. I hope no one would believe that drunk driving wouldn't increase a lot if the laws were removed now. For the EV indicator, we just don't know how many people prevented being scammed because of this. And removing a security feature because we don't know if it is successful is a dangerous thing to do. The better way would be to find out if it is really so useless as argued by some here. If it is that obvious that it is not helping, producing this data should be an easy task. But the information “some people fall for scams with DV certificates” is not the right information to decide this. The interesting people are the ones NOT falling for a scam because it is using a DV certificate and I haven't seen anyone giving any data about them here. - Josef ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
On Friday, August 30, 2019 at 8:58:17 PM UTC+2, Ryan Sleevi wrote: > On Fri, Aug 30, 2019 at 11:26 AM Jeremy Rowley via dev-security-policy < > Despite all of the writing above, I'm too lazy to copy/paste my comment > from the Let's Encrypt issue, but I would hope any CA contemplating things > should look at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652#c3 in > terms of a possible 'ideal' flow, and to share concerns or considerations > with that. Even better would be CAs that have suggestions on how best to > codify and memorialize that suggestion, if it's sensible and correct. I added a comment to the bugzilla. I think there are several ways the process can be made safe, depending on the way a CA operates and which technologies are used. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: 2019.08.28 Let’s Encrypt OCSP Responder Returned “Unauthorized” for Some Precertificates
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 on > behalf of Jeremy Rowley via dev-security-policy > > Sent: Saturday, August 31, 2019 9:05:24 AM > To: Tomas Gustavsson ; > 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 on > behalf of Tomas Gustavsson via dev-security-policy > > Sent: Saturday, August 31, 2019 9:00:08 AM > To: 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
