Validation Summit

Gerv and I have made, and the CA/Browser Forum has accepted a proposal to convene a "Validation Summit" on Tuesday March 6th during the next regularly scheduled CA/Browser Forum face-to-face meeting that will be held in the Washington DC area. The intent of this summit is to perform an analysis

Re: DRAFT January 2018 CA Communication

I've opened bugs for the following CAs that still haven't responded: - GoDaddy - Certinomis / Docapost - Deutscher Sparkassen Verlag GmbH (S-TRUST, DSV-Gruppe) - TurkTrust - E-Tugra You can find these bugs on the Incident Dashboard: https://wiki.mozilla.org/CA/Incident_Dashboard

Re: Root Store Policy 2.6

Ryan, On Fri, Feb 16, 2018 at 3:19 PM, Ryan Sleevi wrote: > > Hi Wayne, > > One point of possible clarification that should be undertaken is with > respect to https://github.com/mozilla/pkipolicy/blob/master/rootstor > e/policy.md#8-ca-operational-changes > > While this section

Re: ComSign Root Renewal Request

Based on this discussion, Mozilla is denying the ComSign Global Root CA inclusion request. I'd like to thank everyone for your constructive input into the discussion, and I'd like to thank ComSign for their patience and work to address issues as they have been discovered. ComSign may submit a

Root Store Policy 2.6

I have begun work on version 2.6 of the Root Store Policy by drafting some changes that are [I hope] uncontroversial. The diff can be viewed at https://github.com/mozilla/pkipolicy/compare/2.6 The changes I have already drafted are: - Require disclosure of email validation practices in CPS

Re: TunRootCA2 root inclusion request

The TunrootCA2 root operates under the following CPS: http://www.certification.tn/pub/PC-PDC_AC_RACINE-NG-01-EN.pdf The TunserverCA2 subordinate CA operates under a different CPS: http://www.certification.tn/sites/default/files/documents/CPCPS-PTC-BR-EN-05.pdf I have reviewed the supplied BR

Re: Root Store Policy 2.6

I've added the issue of subordinate CA transfers to the list for policy version 2.6: https://github.com/mozilla/pkipolicy/issues/122 On Tue, Feb 20, 2018 at 4:50 PM, Ryan Sleevi wrote: > > > On Tue, Feb 20, 2018 at 6:19 PM, Wayne Thayer wrote: > >> Ryan,

Re: Root Store Policy 2.6

Version 2.6 of the policy has been reviewed and (with some minor changes to section 7.3) approved by Mozilla's Legal department. I've set the effective date to July 1, 2018 and requested publication of the new version. Meanwhile, it can be found here:

Re: GoDaddy Revocations Due to a Variety of Issues

Thank you for this report Daymion. 3 of the issues were recent: | e_dnsname_not_valid_tld, | | |e_subject_common_name_not_from_san,| | |e_dnsname_bad_character_in_label |4

Re: Telia CA - problem in E validation

Thank you for supplying this incident report. For reference, this is in response to https://bugzilla.mozilla.org/show_bug.cgi?id=1475115 On Fri, Aug 3, 2018 at 1:55 AM pekka.lahtiharju--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Incident report: > > PROBLEM IN

Re: InfoCert Acquisition of Camerfirma

On Wed, Jul 18, 2018 at 1:56 PM Wayne Thayer wrote: > I would like to begin a 3-week public discussion period for InfoCert's > acquisition of Camerfirma [1] as described in section 8.1 of the Mozilla > Root Store Policy. I believe that the intent of our policy in this scenario > is to identify

Re: Possible violation of CAA by nazwa.pl

This discussion has covered a lot of ground. Here are my comments: 1. Nazwa is not independently audited, nor are they a member of the Mozilla root program. I am also unable to locate any information that makes Nazwa an Affiliate of Certum. I believe they are simply a Certum reseller. In this

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

Having received the audit reports covering the period from the creation of this root, I would like to resume this discussion. Please post any remaining comments that you have on this inclusion request by next Friday, 10-August. - Wayne On Tue, Jul 31, 2018 at 2:47 AM Pedro Fuentes via

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

Having received no comments on this proposal, I plan to go ahead and publish version 2.6.1 of the Mozilla Root Store Policy with the third paragraph of section 5.3 clarified as follows: Intermediate certificates created after January 1, 2019, with the exception of cross-certificates that share a

Misissuance and BR Audit Statements

Given the number of incidents documented over the past year [1][2] for misissuance and other nonconformities, I would expect many of the 2018 period-of-time WebTrust audit statements being submitted by CAs to include qualifications describing these matters. In some cases, that is exactly what

Re: AC Camerfirma's organizationName too long incident report

Thank you for the incident report Juan. I created https://bugzilla.mozilla.org/show_bug.cgi?id=1481862 to track this issue. Please update the bug as action items are completed. On Wed, Aug 8, 2018 at 8:41 AM Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: >

DEFCON Talk - Lost and Found Certificates

I'd like to call this presentation to everyone's attention: Title: Lost and Found Certificates: dealing with residual certificates for pre-owned domains Slide deck:

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

The updated 2.6.1 version of the Mozilla Root Store policy resulting from this discussion is now published: https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/ - Wayne On Mon, Aug 6, 2018 at 3:28 PM Wayne Thayer wrote: > Having received no comments on this

Re: Misissuance and BR Audit Statements

32431 > [D] https://crt.sh/?id=351449246 > [E] https://bugzilla.mozilla.org/show_bug.cgi?id=1447192 > [F] https://bugzilla.mozilla.org/show_bug.cgi?id=1465600 > [G] https://bugzilla.mozilla.org/show_bug.cgi?id=1398269#c29 > > On Tue, Aug 7, 2018 at 1:32 PM, Wayne Thayer via dev-securi

Re: OISTE WISeKey Global Root GC CA Root Inclusion Request

://bugzilla.mozilla.org/show_bug.cgi?id=1403591 On Tue, Aug 14, 2018 at 3:49 PM Ryan Sleevi wrote: > Sorry for the delay in responding. I think this resolves the ambiguity as > to the gaps and is a good path forward. > > On Wed, Aug 1, 2018 at 7:37 PM, Wayne Thayer via dev-security-po

Re: DEFCON Talk - Lost and Found Certificates

On Thu, Aug 16, 2018 at 7:25 AM Eric Mill wrote: > > I think this paper provides a good impetus to look at further shortening > certificate lifetimes down to 13 months. That would better match the annual > cadence of domain registration so that there's a smaller window of time > beyond domain

Re: A vision of an entirely different WebPKI of the future...

What problem(s) are you trying to solve with this concept? If it's misissuance as broadly defined, then I'm highly skeptical that Registry Operators - the number of which is on the same order of magnitude as CAs [1] - would perform better than existing CAs in this regard. You also need to consider

Re: Misissuance and BR Audit Statements

Thank you for responding on behalf of ETSI ESI and ACABc! I believe that this is an important topic and I hope that ETSI ESI and ACABc members will continue to participate in the discussion. On Thu, Aug 16, 2018 at 11:11 AM clemens.wanko--- via dev-security-policy <

Re: localhost.megasyncloopback.mega.nz private key in client

The proposed "Revocation Timeline Extension" ballot (formerly #213, soon to become #SC6) [1] includes the following: The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise,

Re: How to submit WebTrust audits in CCADB

I don't think I'm giving away any big secret by revealing that the seal website is just doing an http_referer check. If you are blocked when trying to access an audit report on cert.webtrust.org, just set the referer to the CA's domain name and refresh. You can do this with any number of Firefox

Re: GoDaddy Revocation Disclosure

Thank you for the disclosure Daymion. I have created bug 1484766 to track this issue. I've requested an incident report to help the community better understand what happened and what can and is being done to prevent similar problems in the future, as described in the last two topics [1]: 6.

Re: Certigna Root Renewal Request

Thank you for your response. On Wed, Aug 22, 2018 at 11:51 AM josselin.allemandou--- via dev-security-policy wrote: > We confirm that no, this is not the case. This is what we said in the CP / > CPS because we thought that these constraints could be regularly > encountered and that it could be

Re: Audit Reminder Email Summary

Kurt, Thank your for raising this issue. As documented in the bug you referenced, there was a good deal of confusion about Mozilla's acceptance (or not) of SwissSign's 2017 audit statements. Mozilla rejected the first statements and then asked questions about the second set of statements but

Google Trust Services Root Inclusion Request

This request is for inclusion of the Google Trust Services R1, R2, R3, and R4 roots as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1325532 Google’s application states: Google is a commercial CA that will provide certificates to customers from around the world.

Re: 2018.08.23 Let's Encrypt OCSP Responder Incident

Josh, Thank you for submitting this incident report. I created a bug to track the incident and remediation efforts: https://bugzilla.mozilla.org/show_bug.cgi?id=1486650 - Wayne On Fri, Aug 24, 2018 at 1:07 PM josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > To

Re: Certigna Root Renewal Request

On Wed, Aug 22, 2018 at 2:10 AM josselin.allemandou--- via dev-security-policy wrote: > > > > CPS Section 4.2.1: If the request is valid and allows to obtain with > accuracy the authorization to issue the certificate by

Re: Audit Reminder Email Summary

On Sun, Aug 26, 2018 at 11:25 PM reinhard.dietrich--- via dev-security-policy wrote: > Dear all > > This is a joint answer to Waynes' request. > > it was mentioned that the audit period was exceeded. We would like to > explain the situation and what was undertaken to avoid such situation again.

Re: InfoCert Acquisition of Camerfirma

I would like to begin a 3-week public discussion period for InfoCert's acquisition of Camerfirma [1] as described in section 8.1 of the Mozilla Root Store Policy. I believe that the intent of our policy in this scenario is to identify and consider any risks introduced by the acquisition of

Re: Chunghwa Telecom eCA Root Inclusion Request

While I sincerely appreciate the efforts of Chunghwa Telecom to respond to questions and to remediate some of the issues that were identified here, this discussion ha made it clear that this request should be denied. There is a significant degree of misissuance associated with this root, some of

Re: GlobalSign Root CA - R6 Inclusion Request

Reminder: this request will complete the 3-week minimum discussion period on Thursday. If you have any comments on this request, please post them before July 19th. On Thu, Jun 28, 2018 at 12:16 PM Wayne Thayer wrote: > This request is for inclusion of the GlobalSign Root CA - R6 as documented >

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

On Fri, Jul 13, 2018 at 3:50 PM Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Yeah, I agree I don’t think it was intended. But now that I am aware of > the issue, I think the crossing workaround per EKU is actually a good thing > for people to be doing.

Re: Do We Now Require Separate Cross-certificates for SSL and S/MIME?

Kathleen pointed out that one of the purposes of this section is to require disclosure of cross-certificates, and my first attempted fix seems to violate that purpose. Here is my second attempt to clarify the language in section 5.3:

Re: GlobalSign Root CA - R6 Inclusion Request

3 weeks have passed and no comments have been made on this inclusion request. Meanwhile, I have requested and received additional information from GlobalSign confirming that this root certificate has been included in their BR audits back to its creation [1], in compliance with section 7.1 of

Request to Include SHECA UCA Global G2 Root and UCA Extended Validation Root

This request is for inclusion of the Shanghai Electronic Certification Authority Co., Ltd. UCA Global G2 Root and UCA Extended Validation Root as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1309797 * BR Self Assessment is here:

Re: AC Camerfirma's CP & CPS disclosure

Thank you for this response Ramiro. I have copied this to the bug [1] and have described Mozilla's expectations for point-in-time audits that confirm that these issues have been resolved. [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1478933 On Tue, Sep 4, 2018 at 5:47 AM ramirommunoz--- via

Re: DRAFT September 2018 CA Communication

Thanks for the suggestion Jakob. I will pass it on to the engineering team. On Fri, Sep 7, 2018 at 8:04 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 07/09/2018 15:55, Bruce wrote: > > On Thursday, September 6, 2018 at 7:44:15 PM UTC-4, Wayne Thayer

Re: DRAFT September 2018 CA Communication

Thanks for the response Bruce. On Fri, Sep 7, 2018 at 6:55 AM Bruce via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thursday, September 6, 2018 at 7:44:15 PM UTC-4, Wayne Thayer wrote: > > All, > > > > I've drafted a new email and survey that I hope to send to all

Re: Telia CA - problem in E validation

Telia has described their plans to remediate the qualifications listed in their latest audit reports: https://bugzilla.mozilla.org/show_bug.cgi?id=1475115#c13 In summary: * Telia is planning to obtain point-in-time audit reports to confirm that the issues have been resolved. I have asked Telia

DRAFT September 2018 CA Communication

All, I've drafted a new email and survey that I hope to send to all CAs in the Mozilla program next week. it focuses on compliance with the new (2.6.1) version of our Root Store Policy. I would appreciate your feedback on the draft:

Re: AC Camerfirma's CP & CPS disclosure

Hello Juan, Was this message intended to be a response to the discussion of Camerfirma's qualified audits in https://bugzilla.mozilla.org/show_bug.cgi?id=1478933 ? I am awaiting a full response to comment #7 in which I requested a full remediation plan for the issues identified by these audits.

Re: Chunghwa Telecom eCA Root Inclusion Request

The specific CP/CPS concerns that I identified have been addressed in the latest version of these documents (attached to bug #1341604). Some of the misissuances [1] have been addressed - in particular, the 10 "dedicated server application software certificates" have been revoked and replaced with

Do We Now Require Separate Cross-certificates for SSL and S/MIME?

During a 2.6 policy discussion [1], we agreed to add the following language to section 5.3 "Intermediate Certificates": > Intermediate certificates created after January 1, 2019: > > > * MUST contain an EKU extension; and, > * MUST NOT include the anyExtendedKeyUsage KeyPurposeId; and, > * MUST

Re: Chunghwa Telecom eCA Root Inclusion Request

On Fri, Jul 13, 2018 at 3:03 AM lcchen.cissp--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Dear Wayne, > >Those programs for checking field of ToBeSign SSL certificate are > online on June 22. > >We suggest that CA "in principle" must comply with the string

Summary of Responses to the November CA Communication

Hi Everyone, I have reviewed the responses we received from the November 2017 CA Communication [1], and I have the following comments to share: * Beginning with the good news, no new concerns related to the suspected .tg Registry compromise were reported (Action #8) * The deadline for submitting

Re: TLS-SNI-01 and compliance with BRs

On Sat, Jan 20, 2018 at 1:07 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > Based on this, do we need a ballot to remove them from the BRs, or put in > > a statement in them to the effect that they can be used only if approved > by > > Google on

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

On Tue, Mar 6, 2018 at 4:45 AM, ramirommunoz--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > 1 * The inclusion request references a much older CPS [3] that doesn't > list the 2016 versions of these roots or comply with current policies. I > only reviewed the newer

Re: How do you handle mass revocation requests?

On Wed, Feb 28, 2018 at 12:13 PM, timx84039--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Regarding to our investigation they were only able to send the private > keys for those certificates where the CSR / private key pair were generated > within their online

Allowing WebExtensions to Override Certificate Trust Decisions

I am seeking input on this proposal: Work is underway to allow Firefox add-ons to read certificate information via WebExtensions APIs [1]. It has also been proposed [2] that the WebExtensions APIs in Firefox be enhanced to allow a 3rd party add-on to change or ignore the normal results of

Re: TunRootCA2 root inclusion request

This request has been in public discussion for more than 6 months, so I would like to make a decision soon. If you have comments or concerns with this request, please post them here by 6-March 2018. On Tue, Feb 27, 2018 at 7:33 AM, Olfa Kaddachi via dev-security-policy <

Re: Unrevocation of BT Class 2 CA - G2 CA Certificate

Here is the report Ben filed in the bug. He tried to send it to the list but for some reason it was rejected as spam. Dear Mozilla Community, As part of our efforts to meet the April 15 requirements imposed by the Mozilla Root Store Policy v.2.5, DigiCert has been reviewing

Re: Deadline for whitelisting of the Apple/Google subCAs issued by Symantec?

On Thu, Mar 1, 2018 at 8:17 AM, Alex Gaynor via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Is it practical to remove the Symantec root certificates and (temporarily) > add the Google and Apple intermediates to the trust store? This should > facilitate removing trust in

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

This incident, and the resulting action to "integrate GlobalSign's certlint and/or zlint into our existing cert-checker pipeline" has been documented in bug 1446080 [1] This is further proof that pre-issuance TBS certificate linting (either by incorporating existing tools or using a comprehensive

Re: 2018.03.12 Let's Encrypt Wildcard Certificate Encoding Issue

On Thu, Mar 15, 2018 at 12:22 PM, Tom via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Should another bug be opened for the certificate issued by IdenTrust with > apparently the same encoding problem? > > Yes - this is bug 1446121 (

Re: TunRootCA2 root inclusion request

I think this discussion has made it clear that the request for inclusion of the TunRootCA2 root should be denied. CAs inherently must be trusted, and trust must be earned. A CA can't simply fix one problem after another as we find them during the inclusion process and expect to be rewarded for

Re: FW: Complying with Mozilla policy on email validation

On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Tuesday, April 3, 2018 at 1:17:50 PM UTC-7, Wayne Thayer wrote: > > > I agree that name constraints would be difficult to implement in this > > scenario, but I'm less convinced

Re: Policy 2.6 Proposal: Require English Language Audit Reports

On Wed, Apr 4, 2018 at 2:46 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, April 4, 2018 at 1:58:35 PM UTC-7, Wayne Thayer wrote: > > Mozilla needs to be able to read audit reports in the English language > > without relying on machine

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Wed, Apr 4, 2018 at 3:15 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Some thoughts: > > 1 - Should additional text be included to mandate strong cipher suites ( > http://unmitigatedrisk.com/?p=543) be used; it is not uncommon for me to > find

Re: FW: Complying with Mozilla policy on email validation

On Wed, Apr 4, 2018 at 3:44 PM, Ryan Hurst via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, April 4, 2018 at 3:39:46 PM UTC-7, Wayne Thayer wrote: > > On Wed, Apr 4, 2018 at 2:44 PM, Ryan Hurst via dev-security-policy < > > > My opinion on this method and on

Re: Do Not Accept WebTrust Audit from Deloitte Anjin South Korea

The Korea GPKI MOI CA certificates are in the inclusion process. As I noted in the bug, I've added information on the reported misissuance and OCSP errors to the inclusion request and I've noted the concerns raised about the auditor in their CCADB record. - Wayne On Thu, Apr 5, 2018 at 10:03 AM,

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Thu, Apr 5, 2018 at 4:58 AM, Doug Beattie wrote: > > I don’t think you should include #2 because it's a common practice to > issue one certificate for Secure Mail that is used to both sign and > encrypt, and this would preclude CA key generation for those types of

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos wrote: > My proposal is "CAs MUST NOT distribute or transfer private keys and > associated certificates in PKCS#12 form through insecure physical or > electronic channels " and remove the rest. > > +1 - I support this

Re: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

Thanks everyone for your input. This discussion has reached the conclusion that Mozilla should deny the inclusion request for the AC Camerfirma CHAMBERS OF COMMERCE ROOT - 2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT - 2016 As suggested, AC Camerfirma is welcome to submit a new inclusion request

Re: Do Not Accept WebTrust Audit from Deloitte Anjin South Korea

I've asked the Government of Korea to comment on this news article in their inclusion request (https://bugzilla.mozilla.org/show_bug.cgi?id=1377389). - Wayne On Wed, Apr 11, 2018 at 7:26 AM, jumping2gether--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > According to

Re: Policy 2.6 Proposal: Require audits back to first issuance

Thank you for responding Matthias. On Wed, Apr 11, 2018 at 10:52 AM, m.wiedenhorst--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Hi Wayne > > > Can anyone say if an equivalent public-facing > > report exists for ETSI audits? If so, I think we should require CAs

Re: Policy 2.6 Proposal: Remove obsolete ETSI audit requirements

I've gone ahead and removed references to ETSI TS 101 456 and TS 102 042 from the 2.6 branch of the policy: https://github.com/mozilla/pkipolicy/commit/49a07119a1fd5c887d4b506f60e210fad941b26a - Wayne On Tue, Mar 27, 2018 at 12:44 PM, Wayne Thayer wrote: > There has been

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

As an alternative to requiring newly-issued subCA Certificates to be listed in the relevant CP/CPS prior to issuing certificates, would it be reasonable for Mozilla to require the Certificate Policies extension in these certificates to contain a URL pointing to the relevant policy document(s)? I

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 9:45 AM, Ryan Sleevi wrote: > > > On Thu, Apr 12, 2018 at 12:32 PM, Wayne Thayer > wrote: > >> On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >> >>> Indeed, I

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 10:28 AM, Matthew Hardeman wrote: > > > On Thu, Apr 12, 2018 at 12:24 PM, Ryan Sleevi wrote: > >> >> So Apple Computer is misleading to customers of Apple Records, and Apple >> Records is misleading to customers of Apple Computer, is

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

On Thu, Apr 12, 2018 at 8:10 AM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Indeed, I find it concerning that several CAs were more than happy to take > Ian's money for the issuance, but then determined (without apparent cause > or evidence) to revoke

Re: Sigh. stripe.ian.sh back with EV certificate for Stripe, Inc of Kentucky....

Eric raised an issue distinct from 'the value of EV' that I think is important: Can certificate revocation be used as a form of censorship? As HTTPS becomes the default state of the web, it becomes more important to consider this issue and what should be done about it. I plan to discuss this with

Re: Audits for new subCAs

On Fri, Apr 6, 2018 at 3:09 PM, Peter Bowen wrote: > > A CP is an optional document and may be maintained by an entity other > than the CA. For example there may be a common policy that applies to > all CAs that have a path to a certain anchor. So including the CA > list in

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Thu, Apr 5, 2018 at 12:29 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 05/04/2018 18:55, Wayne Thayer wrote: > >> On Thu, Apr 5, 2018 at 3:15 AM, Dimitris Zacharopoulos >> wrote: >> >> My proposal is "CAs MUST NOT distribute or

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

Getting back to the earlier question about email certificates, I am now of the opinion that we should limit the scope of this policy update to TLS certificates. The current language for email certificates isn't clear and any attempt to fix it requires us to answer the bigger question of "under

Re: Policy 2.6 Proposal: Require English Language Audit Reports

It has been pointed out to me that we should seek to create a policy that meets our needs without imposing a requirement for auditors to adopt the English language. For the CP/CPS, we address this concern by requiring a translation that "...must match the current version..." I am of the opinion

Re: Policy 2.6 Proposal: Require audits back to first issuance

On Mon, Apr 2, 2018 at 9:28 PM, tom.prince--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Monday, April 2, 2018 at 7:12:19 PM UTC-6, Wayne Thayer wrote: > > In section 2.3 (Baseline Requirements Conformance), add a new bullet that > > states "Before being

Policy 2.6 Proposal: Require English Language Audit Reports

Mozilla needs to be able to read audit reports in the English language without relying on machine translations that may be inaccurate or misleading. I suggest adding the following sentence to the end of policy section 3.1.4 “Public Audit Information”: An English language version of the

Policy 2.6 Proposal: Audit requirements for new subCA certificates

In a recent discussion [1] we decided to clarify the audit requirements for new subordinate CA certificates. I’ve drafted a change that requires the new certificate to appear in the next periodic audits and in the CP/CPS prior to issuance:

Policy 2.6 Proposal: Add prohibition on CA key generation to policy

This issue is titled “Make sure Forbidden practices are forbidden” - in other words, make sure they are banned in our policy. The only forbidden practice on our list [1] that’s not already covered by our policy is “Distributing Generated Private Keys in PKCS#12 Files”. It reads: CAs must never

Policy 2.6 Proposal: For new inclusions, require all existing unexpired unrevoked certs in hierarchy to be BR compliant

Last year we held a discussion on this topic [1] that concluded as follows: It is true that in the case of a legacy root, creating a new root with a > cross-sign is not technically all that complex (although it may take > some time organizationally) and then we could embed that new one. > > Given

Policy 2.6 Proposal: Require CAs to support problem reports via email

Section 4.9.3 of the CA/Browser Forum's Baseline Requirements says: "The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud,

Re: RAs and the BRs

On Tue, Apr 17, 2018 at 9:21 PM, Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > There is a way to get zero-validation certs, totally legit, under the BRs. > Currently, the BRs permit pretty much free delegation of Registration > Authorities for everything

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

On Thu, Apr 19, 2018 at 8:40 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/04/2018 20:24, Wayne Thayer wrote: > >> This proposal is to require intermediate certificates to be dedicated to >> specific purposes by EKU. Beginning at some future date,

Re: Policy 2.6 Proposal: Require CAs to support problem reports via email

At this point we have a few choices: 1. Do nothing about requiring email as a problem reporting mechanism. Instead, take on the related issues of disclosure of the reporting mechanism and receipt confirmation in Mozilla policy, via the CAB Forum, or both. 2. Go ahead with the proposal to require

Re: Policy 2.6 Proposal: Add prohibition on CA key generation to policy

On Tue, Apr 17, 2018 at 6:10 AM, Buschart, Rufus via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I believe the wording "insecure electronic channels" leaves a lot of space > for interpretation. In corporate PKIs for email encryption it is quite > common to transfer

Re: Policy 2.6 Proposal: Require audits back to first issuance

The proposed language includes the requirement for compliance with both the BRs and Mozilla policy, so it's a better fit for the section of our policy titled "Inclusions" than the section titled "Baseline Requirements Conformance". To close out this discussion, I added the proposed language to

Re: Policy 2.6 Proposal: Require English Language Audit Reports

To close out this discussion, I've gone ahead with the proposed change, including the addition of the requirement that the English language version of the audit statement be an authoritative version: https://github.com/mozilla/pkipolicy/commit/e4cc785367350a46fc839639a28a92bd17d542e3 - Wayne On

Re: Policy 2.6 Proposal: For new inclusions, require all existing unexpired unrevoked certs in hierarchy to be BR compliant

I will consider this issue to be resolved by the change I made for issue 113: https://github.com/mozilla/pkipolicy/commit/55929f58da98a7af08fbf4bc2eb4537991de481b - Wayne On Wed, Apr 4, 2018 at 2:31 PM, Wayne Thayer wrote: > Last year we held a discussion on this topic

Re: Regional BGP hijack of Amazon DNS infrastructure

Thanks Matthew, I appreciate you bringing this to everyone's attention. Unless I'm misunderstanding the scope of the attack, it would have been trivial for them to get a trusted cert from most any CA. However, according to the following article, "Victims had to click through a HTTPS error

Re: Policy 2.6 Proposal: Define/clarify policy for transfer of intermediate CA certificates

On Tue, Apr 24, 2018 at 9:21 AM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Mon, Apr 23, 2018 at 6:12 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > >> I'm re-sending this with the subject tagged as a 'policy 2.6 p

Re: Transforming a trade name into ASCII in the O field of an OV cert

Section 9.2.1 of the EVGLs is stricter, only permitting abbreviations. If this were an EV cert I would argue that it was misissued. On Mon, Apr 23, 2018 at 12:13 PM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Mon, Apr 23, 2018 at 1:11 PM, Henri

Re: Policy 2.6 Proposal: Audit requirements for new subCA certificates

To close out discussion on this issue, I've updated the change by removing the requirement to list each subCA certificate in the CPS: https://github.com/mozilla/pkipolicy/commit/1bdcd53baf2e8b9006a5e13923ce3d66eeff927e - Wayne On Mon, Apr 16, 2018 at 4:51 PM, Wayne Thayer

Re: Policy 2.6 Proposal: Decide how policy applies to certs under TCSCs

Hearing no objections, I have made the proposed clarification in the version 2.6 branch: https://github.com/mozilla/pkipolicy/commit/def9c711163e0cae6a19866fb551e915e3bcef12 - Wayne On Tue, Apr 17, 2018 at 11:20 AM, Wayne Thayer wrote: > Section 5.3 of Mozilla policy

Re: Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

On Sun, Apr 22, 2018 at 2:56 PM, pfuentes69--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I think you should consider an an exception Issuing CAs including Name > Constraints. This would keep allowing root signing services for corporate > CAs without forcing

Policy 2.6 Proposal: Decide how policy applies to certs under TCSCs

Section 5.3 of Mozilla policy states: All certificates that are capable of being used to issue new certificates, > and which directly or transitively chain to a certificate included in > Mozilla’s CA Certificate Program, MUST be operated in accordance with this > policy and MUST either be

Policy 2.6 Proposal: Require separate intermediates for different usages (e.g. server auth, S/MIME)

This proposal is to require intermediate certificates to be dedicated to specific purposes by EKU. Beginning at some future date, all newly created intermediate certificates containing either the id-kp-serverAuth or id-kp-emailProtection EKUs would be required to contain only a single EKU.

<    1   2   3   4   5   6   7   >