Re: Intent to Ship: Move Extended Validation Information out of the URL bar
Last week I posted reasons why Mozilla shouldn’t remove the EV UI from Firefox. In addition to the discussion on how the EV UI can inform users when a website does or does not have confirmed identity before they choose to type in their password or credit card number (after a little user training), I also mentioned that EV certificate Subject information (organization name, etc.) is currently used by browser phishing filters and by anti-phishing services. I was then asked to corroborate that, and so I have communicated with some of our sources (the Labor Day holiday has slowed things down) to ask them for an authorized statement. As some have suggested on this list, there may be reluctance by some services that use EV cert data to repeat on a public list what they have told us in private over the years both for competitive reasons and also to avoid giving phishers clues as to how to beat their algorithms. However, I did receive authority to post the following statement from someone who works for a major browser phishing filter (but without disclosing the person's name or company). Here is the authorized statement: “A browser phishing filter representative has confirmed that (1) their research teams do look at EV certificate attributes and do feel there is signal there for phish/malware detection, and (2) they would like to have continued access to this EV data.” I think this establishes the point I made last week – that EV data is valuable for anti-phishing efforts and so EV should be supported by the browsers. I’m still concerned that removing the EV UI in Firefox could cause some EV sites to stop using EV certificates which in turn would eliminate the availability of their EV website data from the security ecosystem. This possible adverse outcome should be considered by Mozilla before it removes its EV UI. If and when I am authorized to post more statements from others, I will. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Audit Reminders for Intermediate Certs
Forwarded Message Subject: Summary of September 2019 Outdated Audit Statements for Intermediate Certs Date: Tue, 3 Sep 2019 14:00:41 + (GMT) CA Owner: Government of The Netherlands, PKIoverheid (Logius) - Certificate Name: KPN BV PKIoverheid Organisatie Server CA - G3 SHA-256 Fingerprint: 5679A431E79D4EB9EE967C60D8703C7C78F443F71DB97157E43059DE42D850DF Standard Audit Period End Date (mm/dd/): 05/31/2018 BR Audit Period End Date (mm/dd/): 05/31/2018 - Certificate Name: KPN CM PKIoverheid EV CA SHA-256 Fingerprint: 4B24C521C47600E83800A3FF0C2D58DC02C8177EF7DA697C5A80C1D4867A66DD Standard Audit Period End Date (mm/dd/): 05/31/2018 BR Audit Period End Date (mm/dd/): 05/31/2018 EV SSL Audit Period End Date (mm/dd/): 05/31/2018 - Certificate Name: KPN PKIoverheid EV CA SHA-256 Fingerprint: 5DB1D22D706684F0719E8902FB86B346B3FC9E4D1A1F92283A488BC3D1A0484B Standard Audit Period End Date (mm/dd/): 05/31/2018 BR Audit Period End Date (mm/dd/): 05/31/2018 EV SSL Audit Period End Date (mm/dd/): 05/31/2018 - Certificate Name: KPN PKIoverheid Organisatie CA - G2 SHA-256 Fingerprint: 8F2566A8FCCF6AE8C358B0B8A6D8C7FF0AB16341636478C8BB544E9DD6AA6011 Standard Audit Period End Date (mm/dd/): 05/31/2018 BR Audit Period End Date (mm/dd/): 05/31/2018 - Certificate Name: KPN Corporate Market CSP Organisatie CA - G2 SHA-256 Fingerprint: CB37E05DBC455A09481F3EF56AAC7E887676A4B61346394E6EE6A9447EA8D6BD Standard Audit Period End Date (mm/dd/): 05/31/2018 BR Audit Period End Date (mm/dd/): 05/31/2018 - Certificate Name: KPN PKIoverheid Organisatie Persoon CA - G3 SHA-256 Fingerprint: 3F785025BCCFACA4701A1734CE0F7B30CE4106942C8D92F41B70B067ED65D354 Standard Audit Period End Date (mm/dd/): 05/31/2018 - Certificate Name: KPN BV PKIoverheid Organisatie Server CA - G3 SHA-256 Fingerprint: 7E082BBC56976B159D4696540A96B60148614BA9B5E29B2035F789BECFBF0657 Standard Audit Period End Date (mm/dd/): 05/31/2018 BR Audit Period End Date (mm/dd/): 05/31/2018 - Certificate Name: KPN BV PKIoverheid Organisatie Services CA - G3 SHA-256 Fingerprint: F22DB657A1A929841ABCAC52671A5CEE8A7D069586AF85CE16DE2B05DDA22252 Standard Audit Period End Date (mm/dd/): 05/31/2018 - Certificate Name: KPN BV PKIoverheid Organisatie Persoon CA - G3 SHA-256 Fingerprint: A9B5698C5263BEFF3D60720DC1844CB95D16F06E04268BCE3BE4D60282B01EF9 Standard Audit Period End Date (mm/dd/): 05/31/2018 CA Owner: LuxTrust - Certificate Name: LuxTrust Corporate CA SHA-256 Fingerprint: AE373E488DD13DEF71611D52F0B5179DD648241A381F67A80734F6615FF6E6CA Standard Audit Period End Date (mm/dd/): 03/30/2018 Bug Filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1578505 ___ 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 Tue, Sep 3, 2019 at 2:18 PM Santhan via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, August 29, 2019 at 4:37:04 PM UTC-7, Jacob Hoffman-Andrews > wrote: > > Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652 > > > > On 2019.08.28 we read Apple’s bug report at > https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s > OCSP responder returning incorrect results for a precertificate. This > prompted us to run our own investigation. We found in an initial review > that for 35 of our precertificates, we were serving incorrect OCSP results > (“unauthorized” instead of “good”). Like DigiCert, this happened when a > precertificate was issued, but the corresponding certificate was not issued > due to an error. > > > > We’re taking these additional steps to ensure a robust fix: > > - For each precertificate issued according to our audit logs, verify > that we are serving a corresponding OCSP response (if the precertificate is > currently valid). > > - Configure alerting for the conditions that create this problem, so > we can fix any instances that arise in the short term. > > - Deploy a code change to Boulder to ensure that we serve OCSP even if > an error occurs after precertificate issuance. > > Out of curiosity, what software is checking OCSP for a pre-cert and why? > Why does any software need the OCSP status of a pre-cert when it doesn't > have the corresponding final cert? It's a good question, and worth asking, although when framing, it might be useful to think/explore why *shouldn't* software be able to do so. There's no requirement to log the corresponding final certificate to CT Logs, and some CAs may choose to not do so in order to minimize the rate limits or the baseline growth rate of CT Logs, especially if those final certificates are functionally short-lived (e.g. some CAs issuing at 8 hour intervals). Yet those examining CT Logs for compliance issues have a reasonable basis for examining whether or not an associated pre-certificate is revoked, regardless of its overall compliance status with the requirements. That is, it's useful not only to know what's bad and is/isn't revoked, but also what is good, and is/isn't revoked. The latter is useful, for example, when examining impact to the ecosystem for changes, such as changes in a trust status for CAs, by examining whether or not the associated certificate(s) are still valid or have been revoked. Another reason is for revocation systems that try to comprehensively determine the status of published certificates, since CRLs are not inherently required to be used (example: CRLlite) In terms of process/flow though, my earlier point is that CT Logs define their incorporation timelines in terms of Maximum Merge Delay, rather than Minimum. It's entirely possible for a CT Log to incorporate (and publicize) a pre-cert within seconds, allowing CT Log Monitors to pick it up. If those Monitors then query the status information, it's possible that they could cause one or more intermediaries to return that cached information, even after the 'final' certificate has been issued. This was part of the operational complexity I was mentioning and mentioned on the associated bug. By ensuring publication of the 'correct'/'expected' information prior to the publication of the pre-cert (if pre-certs are used) or the final cert, this minimizes the risk of getting into an intermittent bad state. Is it possible to defer publishing and still get the correct result? Absolutely. It just requires much more care, and given situations like "Default City" and "Some State" in certificates, perhaps it's better to be safe by default. ___ 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 Thursday, August 29, 2019 at 4:37:04 PM UTC-7, Jacob Hoffman-Andrews wrote: > Also filed at https://bugzilla.mozilla.org/show_bug.cgi?id=1577652 > > On 2019.08.28 we read Apple’s bug report at > https://bugzilla.mozilla.org/show_bug.cgi?id=1577014 about DigiCert’s OCSP > responder returning incorrect results for a precertificate. This prompted us > to run our own investigation. We found in an initial review that for 35 of > our precertificates, we were serving incorrect OCSP results (“unauthorized” > instead of “good”). Like DigiCert, this happened when a precertificate was > issued, but the corresponding certificate was not issued due to an error. > > We’re taking these additional steps to ensure a robust fix: > - For each precertificate issued according to our audit logs, verify that > we are serving a corresponding OCSP response (if the precertificate is > currently valid). > - Configure alerting for the conditions that create this problem, so we can > fix any instances that arise in the short term. > - Deploy a code change to Boulder to ensure that we serve OCSP even if an > error occurs after precertificate issuance. Out of curiosity, what software is checking OCSP for a pre-cert and why? Why does any software need the OCSP status of a pre-cert when it doesn't have the corresponding final cert? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
