Re: Summary of Camerfirma's Compliance Issues

On Tue, Jan 19, 2021 at 6:37 PM Jonathan Rudenberg via dev-security-policy wrote: > > On Tue, Jan 19, 2021, at 12:01, Andrew Ayer via dev-security-policy wrote: > > Camerfirma was warned in 2018 that trust in their CA was in jeopardy, > > yet compliance problems continued. There is no reason to

Re: Policy Module Ownership

This is a sad loss for the community, but thank you for everything you've done these past years! -Paul On Wed, Jan 22, 2020 at 6:10 AM Wayne Thayer via dev-security-policy wrote: > > I have decided to leave Mozilla, effective this Friday. > > I expect Mozilla to hire a replacement, but that

Re: Certinomis Issues

A publicly trusted CA is expected to demonstrate technical competence around validation, issuance, and security of their infrastructure. When non-compliant issuance occurs the community should expect any well operated CA to rapidly detect, remediate the issue, and perform a root cause analysis

Re: 答复: Certificate Problem Report (9WG: CFCA certificate with invalid domain)

Hi Jonathan, When something like this occurs the Mozilla community asks for an incident report explaining how the incident occurred, what was done to remediate it, and what procedures and technical controls have been put in place to prevent a future recurrence of the problem. You can see

Re: DarkMatter Concerns

Hi Scott, Comments inline. On February 25, 2019 at 4:58:00 PM, Scott Rea via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: G’day Corey, To follow up on this thread, we have confirmed with the developers of the platform that the approach used to include 64-bit output from

Re: TunRootCA2 root inclusion request

In addition to the issues Ryan has listed, during the root inclusion process multiple issues with their OCSP responder and CRL endpoints were observed and fixed only after the flaws were documented in the bug ( https://bugzilla.mozilla.org/show_bug.cgi?id=1233645). I believe any CA seeking

Re: Google OCSP service down

Thank you for this comprehensive incident report Ryan. Your team's decision to improve the documentation around the right address for reporting is great to see! I wonder if it might also make sense to pull the contact information directly on https://pki.goog above the fold? -Paul (reaperhulk) On

Re: TLS everywhere has a major flaw and needs refining to the page level.

Clock skew issues are not an overlooked problem. The Chrome team has published research around this in the past ( https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/owc7DJkg098/d8k0LyrgAgAJ) that led to a plan ( https://www.chromium.org/developers/design-documents/sane-time). I

Re: Public trust of VISA's CA

On February 14, 2018 at 4:17:16 AM, Wayne Thayer via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: > The most recent BR audit report for the Visa eCommerce Root contains 3 qualifications: http://enroll.visaca.com/WTBR%20eComm.pdf Does Mozilla have any guidelines or official

Re: Misissuance/non-compliance remediation timelines

On February 9, 2018 at 1:24:12 AM, Wayne Thayer (wtha...@mozilla.com) wrote: On Tue, Feb 6, 2018 at 6:03 PM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > So, how long is too long? > This is the crux of the issue for me. If a CA (that rea

Misissuance/non-compliance remediation timelines

A bit over 5 months ago I reported a series of OCSP responders that were violating BRs (section 4.9.10) by returning GOOD on unknown serial numbers. Since that time the majority of those responder endpoints have been fixed, but several are still non-compliant; either with little communication or

Re: Serial number length

On December 29, 2017 at 12:27:35 PM, David E. Ross via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: On 12/28/2017 10:33 PM, Peter Bowen wrote: > On Thu, Dec 28, 2017 at 10:24 PM, Jakob Bohm via dev-security-policy > wrote: >> After

RE: Violations of Baseline Requirements 4.9.10

Hi Ben, DN: CN=Cartão de Cidadão 001, OU=ECEstado, O=SCEE - Sistema de Certificação Electrónica do Estado, C=PT Downloading the issuer (https://crt.sh/?id=8949008) and then running: openssl ocsp -issuer 8949008.crt -serial 101010101010101101010101010 -no_nonce -url

RE: Francisco Partners acquires Comodo certificate authority business

On November 1, 2017 at 2:23:17 PM, westmail24--- via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: Hello, If I understand correctly, at the time of the public discussion for new root certificates SSL.com (RA Comodo) Mozilla concealed information about the acquisition of

Re: Public trust of VISA's CA

I can confirm that as of this moment the VISA OCSP responders are still responding GOOD for non-existent certificates. VISA was originally contacted by me on August 29 so it has now been over 21 days since initial report. -Paul On September 21, 2017 at 9:32:12 PM, Gervase Markham via

Re: Violations of Baseline Requirements 4.9.10

On September 9, 2017 at 2:16:38 AM, Kathleen Wilson via dev-security-policy (dev-security-policy@lists.mozilla.org) wrote: Bugs filed… ~ Thanks, Kathleen Thank you very much Kathleen! If I receive additional responses I will update the bugs directly. -Paul

Re: Violations of Baseline Requirements 4.9.10

I have updated the list again to note the additional responders fixed (in this update: CA Disig, PKIoverheid, Izenpe). To make this email slightly less enormous I've also started removing everything but the CA's name when I have confirmed that all the reported responders are now properly

Re: Violations of Baseline Requirements 4.9.10

I have updated the list below to try to capture all the information provided in this thread about which responders have been fixed (and verified using another random serial number), which ones have a date, and removed the ones that are actually under technical constraint that I missed. I have

RE: Violations of Baseline Requirements 4.9.10

On August 30, 2017 at 4:53:54 AM, Ben Wilson via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: This CA is technically constrained: DN: C=CH, L=Zurich, O=ABB, CN=ABB Issuing CA 6 Hi Ben, ABB Intermediate CA 3 (https://crt.sh/?id=7739892), which issued ABB Issuing CA

Re: Violations of Baseline Requirements 4.9.10

Hi David, If you use the cert at https://crt.sh/?id=1616324 as issuer (the root itself) and run this command: openssl ocsp -issuer 1616324.crt -serial 10101010101010111101001101 -url http://ocsp.izenpe.com -noverify You will get back This Update: Jun 22 11:06:43 2017 GMT Next Update: Jun

Violations of Baseline Requirements 4.9.10

I've recently completed a scan of OCSP responders with a focus on checking whether they are compliant with BR section 4.9.10's requirement: "Effective 1 August 2013, OCSP responders for CAs which are not Technically Constrained in line with Section 7.1.5 MUST NOT respond with a "GOOD" status for

Re: Certificates issued with HTTPS OCSP responder URL (IdenTrust)

On Friday, August 11, 2017 at 3:43:17 PM UTC-5, iden...@gmail.com wrote: > IdenTrust is fully aware of the situation and has consulted with internal and > external parties to ensure that our course of action is appropriate and > commensurate with our business practices and accommodates our

Re: Misissued certificates

On August 10, 2017 at 9:44:01 PM, Jakob Bohm via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: On 11/08/2017 00:29, Jonathan Rudenberg wrote: > >> On Aug 10, 2017, at 17:04, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: >> >> Can anyone

Re: Certificates with invalidly long serial numbers

On Wednesday, August 9, 2017 at 9:20:02 AM UTC-5, Jeremy Rowley wrote: > All CAS are required to maintain the capability to process and receive > revocation requests 24x7 under the baseline requirements. The headache is not > with the CA. Rather, it's notifying the customer that their

Re: Certificates with invalidly long serial numbers

On Tuesday, August 8, 2017 at 7:03:19 PM UTC-5, Jeremy Rowley wrote: > 24 hours is super short when it's a Saturday morning at 4 am and it’s a > European government entity. I agree that is what the policy says now, but, > for lower risk items, the policy should change, preferably to at least one