Re: Summary of Camerfirma's Compliance Issues

2021-02-01 Thread Matthias van de Meent via dev-security-policy
On Tue, 26 Jan 2021 at 16:28, Ramiro Muñoz via dev-security-policy wrote: > > El lunes, 25 de enero de 2021 a las 13:31:18 UTC+1, Matthias van de Meent > escribió: > > On Sun, 24 Jan 2021 at 20:58, Ramiro Muñoz via dev-security-policy > > wrote: > > > > > > Thanks everyone for your valuable

Re: Mozilla's Response to Camerfirma's Compliance Issues

2021-01-26 Thread Matthias van de Meent via dev-security-policy
On Tue, 26 Jan 2021 at 06:21, Ben Wilson via dev-security-policy wrote: > > - Do the proposed actions in the Remediation Plan address the underlying > issues? One of the underlying issues is that Camerfirma has multiple SubCAs with each their own control over ICA keys, CPS, certificate profiles,

Re: Summary of Camerfirma's Compliance Issues

2021-01-25 Thread Matthias van de Meent via dev-security-policy
On Sun, 24 Jan 2021 at 20:58, Ramiro Muñoz via dev-security-policy wrote: > > Thanks everyone for your valuable contribution to the discussion. We’ve > prepared a throughful Remediation Plan that addresses all areas of > improvement emerged both in this public discussion as well as direct

Re: FNMT: Public Discussion of Root Inclusion Request

2020-12-04 Thread Matthias van de Meent via dev-security-policy
he same CPS v. 1.6 document.) > Ben > > On Wed, Dec 2, 2020 at 7:15 AM Matthias van de Meent via dev-security-policy > wrote: >> >> On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> &

Re: FNMT: Public Discussion of Root Inclusion Request

2020-12-02 Thread Matthias van de Meent via dev-security-policy
On Fri, 27 Nov 2020 at 11:19, Santiago Brox via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > El jueves, 19 de noviembre de 2020 a las 0:47:03 UTC+1, Matthias van de Meent escribió: > > On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy, > > wrote: > > > > > >

Re: FNMT: Public Discussion of Root Inclusion Request

2020-11-18 Thread Matthias van de Meent via dev-security-policy
On Wed, 18 Nov 2020, 01:06 Ben Wilson via dev-security-policy, wrote: > > All, > > This is to announce the beginning of the public discussion phase of the > Mozilla root CA inclusion process for Fábrica Nacional de Moneda y Timbre > (FNMT)’s request to include the AC RAIZ FNMT-RCM SERVIDORES

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

2020-10-23 Thread Matthias van de Meent via dev-security-policy
On Fri, 23 Oct 2020 at 17:33, Ryan Sleevi wrote: > > On Fri, Oct 23, 2020 at 8:55 AM Matthias van de Meent via dev-security-policy > wrote: >> >> The current MRSP do not bind the requirements on the reporting of >> incidents to the CA that the incident was filed

Re: Policy 2.7.1: MRSP Issue #187: Require disclosure of incidents in Audit Reports

2020-10-23 Thread Matthias van de Meent via dev-security-policy
On Thu, 22 Oct 2020, 20:53 Ben Wilson via dev-security-policy, wrote: > That proposal is to have section 2.4 read as follows: "If > being audited to the WebTrust criteria, the Management Assertion letter > MUST include all known incidents that occurred or were still > open/unresolved at any time

Re: NAVER: Public Discussion of Root Inclusion Request

2020-10-21 Thread Matthias van de Meent via dev-security-policy
Hi, In the CPS v1.4.3 of NAVER, section 4.9.3, I found the following: > 4.9.3 Procedure for Revocation Request > The NAVER BUSINESS PLATFORM processes a revocation request as follows: > [...] > 4. For requests from third parties, The NAVER BUSINESS PLATFORM personnel > begin investigating the

BRs 8.7 Self-Audits - externalizable?

2020-09-30 Thread Matthias van de Meent via dev-security-policy
Hi, BR section 8.7 (specifically the first paragraph) requires CAs to do a self-audit at least every 3 months. Is this audit externalizable, e.g. through hiring an audit firm to perform this 'self-audit', or must this audit be done internally in the CA? The wording implies 'internally', but by

Re: Concerns with Let's Encrpyt repeated issuing for known fraudulent sites

2020-08-14 Thread Matthias van de Meent via dev-security-policy
On Fri, 14 Aug 2020, 21:52 Ronald Crane via dev-security-policy, < dev-security-policy@lists.mozilla.org> wrote: > It could raise legal issues for a CA to refuse to revoke an obvious > phishing domain after notice that it is fraudulent, or at least after > notice that it's actually being used to

Re: CPS URLs

2020-07-06 Thread Matthias van de Meent via dev-security-policy
On Mon, 6 Jul 2020 at 19:30, Ryan Sleevi wrote: > > On Mon, Jul 6, 2020 at 1:22 PM Matthias van de Meent via dev-security-policy > wrote: >> >> ... >> >> 1.) What was the reasoning behind not (also / specifically) allowing >> an HTTPS url? Was there s

CPS URLs

2020-07-06 Thread Matthias van de Meent via dev-security-policy
Hi, As per BR v1.7.0, section 7.1.2.3, a Subscriber Certificate MAY include `certificatePolicies:policyQualifiers:qualifier:cPSuri`, which must then contain: > HTTP URL for the Subordinate CA's Certification Practice Statement, Relying > Party Agreement or other pointer to online information

Re: Status of the bugzilla bug list

2020-05-19 Thread Matthias van de Meent via dev-security-policy
On Tue, 19 May 2020 at 16:22, Ryan Sleevi wrote: > > On Tue, May 19, 2020 at 5:53 AM Matthias van de Meent > wrote: >> >> One of the reasons I did this research was to check the track record >> of CAs with regards to compliance and solving compliance issues. As >> you might expect, this is

Re: Status of the bugzilla bug list

2020-05-19 Thread Matthias van de Meent via dev-security-policy
Hi Ryan, On Tue, 19 May 2020 at 00:47, Ryan Sleevi wrote: > > Hi Matthias, > > We're aware of this. Could you explain what issue or issues this > presents to you? One of the reasons I did this research was to check the track record of CAs with regards to compliance and solving compliance

Re: Status of the bugzilla bug list

2020-05-18 Thread Matthias van de Meent via dev-security-policy
Hi Jeremy, Thanks for responding, On Mon, 18 May 2020 at 21:58, Jeremy Rowley via dev-security-policy wrote: > > There are others in this same group of pending Mozilla closure: > https://bugzilla.mozilla.org/show_bug.cgi?id=1496616 > https://bugzilla.mozilla.org/show_bug.cgi?id=1463975 >

Status of the bugzilla bug list

2020-05-18 Thread Matthias van de Meent via dev-security-policy
All, I have looked at the list of open bugs in the CA compliance dashboard [0], and I was unpleasantly suprised. There's a total of 75 open issues at the moment of writing, of which 31 have not seen an update in 4 weeks, and of which again 23 [1] are not waiting for a planned future CA or Mozilla

Re: Certificate OU= fields with missing O= field

2019-11-01 Thread Matthias van de Meent via dev-security-policy
Hi, I was notified that the attachments were lost in transmission, so here are the links: cert_no_dcv: https://drive.google.com/open?id=1s43AaW5lCkSzbr-If6l2F_gwLkwDVy6w cert_by_issuer_no_dcv: https://drive.google.com/open?id=1-er8R2CfcG8CRK4I3KUXnv8PDgGQKc1Y cert_by_issuer_name_no_dcv:

Certificate OU= fields with missing O= field

2019-11-01 Thread Matthias van de Meent via dev-security-policy
Hi, I recently noticed that a lot of leaf certificates [0] have organizationalUnitName specified without other organizational information such as organizationName. Many times this field is used for branding purposes, e.g. "issued through " or "SomeBrand SSL". BR v1.6.6 § 7.1.4.2.2i has guidance

CPS publications under MRSP section 3.3

2019-04-17 Thread Matthias van de Meent via dev-security-policy
I noticed that the MRSP section 3.3 states that CPs and CPSes must be made available to Mozilla under a CC-BY -compatible licence, or are considered as licenced under CC-BY-SA v4 to Mozilla and the public when this action has not been taken (3.3 requirement 3). 1.) Does Mozilla re-publish the

Re: CAA policy - ComodoCA or Sectigo?

2019-02-05 Thread Matthias van de Meent via dev-security-policy
On Tue, 5 Feb 2019 at 16:58, Ryan Sleevi wrote: > > On Tue, Feb 5, 2019 at 6:37 AM Matthias van de Meent > wrote: >> >> I agree that sectigo hosts a CPS which meets the requirements for them >> to issue a certificate for the website. The issue is different here, >> though. >> >> The apparent

Re: CAA policy - ComodoCA or Sectigo?

2019-02-05 Thread Matthias van de Meent via dev-security-policy
On Tue, 5 Feb 2019 at 18:05, Robin Alden wrote: > > Wayne, Mattias, > We have a post-rebrand CPS which is almost ready to publish and has > a new Certificate Profiles section. Thanks for the heads-up, is there a projected timeframe in which this new CPS will be available? > To the OP's

Re: CAA policy - ComodoCA or Sectigo?

2019-02-05 Thread Matthias van de Meent via dev-security-policy
On Mon, 4 Feb 2019 at 18:06, Ryan Sleevi wrote: > > On Mon, Feb 4, 2019 at 10:46 AM Matthias van de Meent via dev-security-policy > wrote: >> >> Hi, >> >> Today we've bought a wildcard certificate [0] for our cofano.io domain >> from Sectigo (previously C

CAA policy - ComodoCA or Sectigo?

2019-02-04 Thread Matthias van de Meent via dev-security-policy
Hi, Today we've bought a wildcard certificate [0] for our cofano.io domain from Sectigo (previously ComodoCA) via a reseller. Our CAA policy describes that only "comodoca.com" can issue wildcards. The certificate has been issued and signed by Sectigo's 'new' intermediate and root [1] [2]. My