Re: Certinomis Issues

2019-04-17 Thread Paul Kehrer via dev-security-policy
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)

2019-02-28 Thread Paul Kehrer via dev-security-policy
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

2019-02-25 Thread Paul Kehrer via dev-security-policy
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

2018-03-09 Thread Paul Kehrer via dev-security-policy
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: Following up on Trustico: reseller practices and accountability

2018-03-04 Thread Paul Kehrer via dev-security-policy
On March 4, 2018 at 5:06:41 PM, Eric Mill via dev-security-policy ( dev-security-policy@lists.mozilla.org) wrote: It's also clear from the experience that rules of the road for resellers are unclear, and that accountability is limited. It seems possible, or likely, that other resellers may also

Re: Google OCSP service down

2018-02-21 Thread Paul Kehrer via dev-security-policy
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.

2018-02-15 Thread Paul Kehrer via dev-security-policy
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

2018-02-13 Thread Paul Kehrer via dev-security-policy
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

2018-02-08 Thread Paul Kehrer via dev-security-policy
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

2018-02-06 Thread Paul Kehrer via dev-security-policy
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: Google OCSP service down

2018-01-21 Thread Paul Kehrer via dev-security-policy
I can confirm that the endpoint embedded in the certificate ( http://clients1.google.com/ocsp) is giving a 404 to OCSP requests at this time. crt.sh's OCSP monitoring page also shows this. -Paul On January 21, 2018 at 9:07:48 AM, sjw--- via dev-security-policy (

Re: Serial number length

2017-12-29 Thread Paul Kehrer via dev-security-policy
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

2017-11-14 Thread Paul Kehrer via dev-security-policy
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

2017-11-01 Thread Paul Kehrer via dev-security-policy
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

2017-09-21 Thread Paul Kehrer via dev-security-policy
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

2017-09-08 Thread Paul Kehrer via dev-security-policy
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

2017-09-05 Thread Paul Kehrer via dev-security-policy
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

2017-08-31 Thread Paul Kehrer via dev-security-policy
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

2017-08-30 Thread Paul Kehrer via dev-security-policy
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

2017-08-30 Thread Paul Kehrer via dev-security-policy
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

2017-08-29 Thread Paul Kehrer via dev-security-policy
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)

2017-08-11 Thread Paul Kehrer via dev-security-policy
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

2017-08-10 Thread Paul Kehrer via dev-security-policy
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

2017-08-09 Thread Paul Kehrer via dev-security-policy
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

2017-08-09 Thread Paul Kehrer via dev-security-policy
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