Re: Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

On Tue, Mar 20, 2018 at 8:22 AM, Ryan Sleevi wrote: > > So, one aspect of this is the recently discussed risk - that is, a CA that > provides value for only 10 users presents a substantial amount of risk to > all Mozilla users, for both compromise and non-compliance. This is, >

Re: Policy 2.6 Proposal: Update domain validation requirements

Tim, On Tue, Mar 20, 2018 at 9:57 AM, Tim Hollebeek wrote: > > > * Add a new bullet on IP Address validation that forbids the use of BR > > 3.2.2.5(4) (“any other method”) and requires disclosure of IP Address > > validation processes in the CA’s CP/CPS. > > This is

Re: TURKTRUST Non-compliance

Jakob, On Mon, Mar 19, 2018 at 9:48 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/03/2018 01:23, Wayne Thayer wrote: > > Note, that if it is reasonably certain/validated that the only activity > is maintaining CRLs/OCSP for the remaining unexpired

Policy 2.6 Proposal: Update domain validation requirements

Section 2.2(3) defines very specific requirements for use of the BR 3.2.2.4 domain validation methods. Now that 3.2.2.4.11 (“any other method”) has been removed from the BRs and ballot 218 [1] has passed, the Mozilla policy is out-of-date. I propose the following changes: * Remove the reference

Policy 2.6 Proposal: Move Compliance Date into policy

Historically, the effective dates of new versions of the policy have been maintained separately from the policy itself [1]. In our November Communication, we learned that many CAs weren’t in compliance with policy version 2.5 despite it having been in effect since June [2]. This proposal is simply

Policy 2.6 Proposal: Updated criteria for including new CAs based on recent discussion

A few months ago, we discussed our root inclusion criteria [1], and came to a conclusion that I summarized and proposed in policy as follows: I would like to thank everyone for your constructive input on this topic. > At the outset I stated a desire to ‘establish some objective criteria that >

Policy 2.6 Proposal: Remove temporary exception for unconstrained email subordinates

This new version of the policy won’t be completed until after 15-April, which is the revised deadline for disclosure and auditing of unconstrained email subordinates. I propose removal of the following exception from section 5.3.1: Instead of complying with the above paragraph, intermediate

Re: Root Store Policy 2.6

There are 17 proposed changes in total for version 2.6 of the policy, and I'm about to kick off discussions on the first batch. I expect some of these to be straightforward while others will hopefully generate good dialogues. As always, everyone's constructive input is appreciated. Thanks, Wayne

TURKTRUST Non-compliance

TURKTRUST has the "TÜRKTRUST Elektronik Sertifika Hizmet Sağlayıcısı H5" root included in the Mozilla program with the 'websites' trust bit enabled (not EV). Crt.sh identifies one unexpired and unrevoked subordinate CA [1], and 13 unexpired end-entity certificates signed by this root [2]. The

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: 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: 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: 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: AC Camerfirma Chambers of Commerce and Global Chambersign 2016 Root Inclusion Request

On Fri, Mar 2, 2018 at 3:47 PM, David E. Ross via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 3/2/2018 2:05 PM, Wayne Thayer wrote [in part]: > > [snipped] > > NOTE: The fact that I have snipped some of the items under "==Bad==" > does not mean I consider them

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

This request is for inclusion of the Camerfirma CHAMBERS OF COMMERCE ROOT - 2016 (CCR2016) and GLOBAL CHAMBERSIGN ROOT - 2016 (GCSR2016) as documented in the following bug: https://bugzilla.mozilla.org/show_bug.cgi?id=986854 * BR Self Assessment is here:

Re: Mozilla’s Plan for Symantec Roots

On Fri, Mar 2, 2018 at 11:58 AM, Doug Beattie wrote: > Hi Wayne, > > Is the Firefox 60 update in May the same as the combination of the April > and October Chrome updates, in that all Symantec certificates will be > untrusted on this date (5 months before Chrome)? >

Re: Mozilla’s Plan for Symantec Roots

Update: Mozilla is moving forward with our implementation of the consensus plan for Symantec roots [1]. With the exception of whitelisted subordinate CAs using the keys listed on the wiki [2], Symantec certificates are now blocked by default on Nightly builds of Firefox. The preference

Re: Allowing WebExtensions to Override Certificate Trust Decisions

Thanks everyone for your input on this topic. The consensus seems to be that allowing WebExtensions to muck with certificate validation decisions is a bad idea. The bug [1] has been updated with that sentiment and a link to this discussion. - Wayne [1]

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: 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: 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

Re: Japan GPKI Root Renewal Request

On Wed, Feb 28, 2018 at 9:13 AM, Eric Mill via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Feb 28, 2018 at 12:58 AM, apca2.2013--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > "I would like to again point out that simply waiting

Re: Allowing WebExtensions to Override Certificate Trust Decisions

On Tue, Feb 27, 2018 at 3:40 PM, Peter Saint-Andre via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 2/27/18 3:26 PM, Hanno Böck via dev-security-policy wrote: > > Hi, > > > > On Tue, 27 Feb 2018 09:20:33 -0700 > > Wayne Thayer via dev-

Re: Japan GPKI Root Renewal Request

To conclude this discussion, Mozilla is denying the Japanese Government ApplicationCA2 Root inclusion request. I'd like to thank everyone for your constructive input into the discussion, and I'd like to thank the Japanese Government representatives for their patience and work to address issues as

Re: TunRootCA2 root inclusion request

On Tue, Feb 27, 2018 at 2:40 PM, Jonathan Rudenberg <jonat...@titanous.com> wrote: > > > On Feb 27, 2018, at 16:35, Jonathan Rudenberg via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > >> On Feb 27, 2018, at 16:17,

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 <

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: potential audit delay due to issue with CPA Canada

If you have the letters from your auditor, you can upload them as an attachment to a Bugzilla bug, then submit the links in your CCADB audit case. It's preferable to be able to verify the audit letters via the seal on the WebTrust site, but Mozilla doesn't require it - we can contact the auditor

Re: Code signing and malware

The article also claims that bad actors are selling EV SSL certificates that they obtain for real companies without their knowledge: "to guarantee the issuance and lifespan of the products, all certificates are registered using the information of real corporations. With a high degree of

Re: Need remove OISTE WISeKey Global Root GA CA?

The test site for the root referenced in bug 1172819 is working fine in Firefox: https://gbvalidssl.hightrusted.com/ I am not able to locate any gov.sc websites properly configured for HTTPS to test. - Wayne On Sat, Feb 24, 2018 at 3:45 AM, westmail24--- via dev-security-policy <

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

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

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

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: Public trust of VISA's CA

On Wed, Feb 14, 2018 at 10:47 AM, Tim Smith via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, February 14, 2018 at 8:43:19 AM UTC-8, Wayne Thayer wrote: > > In this particular case, my conclusion is that the existing Mozilla > > process is working. We have

Re: Public trust of VISA's CA

On Tue, Feb 13, 2018 at 11:26 PM, Paul Kehrer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > 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 audi

Re: Public trust of VISA's CA

On Tue, Feb 13, 2018 at 10:49 AM, Jonathan Rudenberg wrote: > > > On Sep 19, 2017, at 11:12, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > In the light of this, I believe it is reasonable to discuss the question > > of

Re: ComSign Root Renewal Request

Hi Yair, On Mon, Feb 12, 2018 at 11:50 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Wayne, > Please realize our situation versus the Israeli market. We are the major > certificate authority and we comply with every piece of local regulation, > we are

Re: Japan GPKI Root Renewal Request

All of my questions regarding the CP/CPS and audits have been answered to my satisfaction. I am left with two concerns: 1. This root was signed on 12-March 2013. The first end-entity certificate that I'm aware of was signed later in 2013. Mozilla began requiring BR audits in 2014, but the first

Re: DRAFT January 2018 CA Communication

-Tugra I will allow a grace period of a few days and then will open incident bugs for those CAs that still haven't responded. - Wayne On Mon, Jan 29, 2018 at 5:14 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > The email has been sent, and we've

Re: Mozilla’s Plan for Symantec Roots

On Thu, Feb 8, 2018 at 7:26 AM, Kai Engert via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 16.10.2017 19:32, Gervase Markham via dev-security-policy wrote: > > The subCAs that we know of that fall into this category belong to Google > > and Apple. If there are any

Re: ComSign Root Renewal Request

On Wed, Feb 7, 2018 at 8:18 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hi Wyane, > resopnding to your notes: > > Section 4.9 states that in any case that Comsign is notified about a > misissuance (no matter if it was notified by a subscriber or in any

Re: Certificate for com and it

On Thu, Feb 8, 2018 at 8:54 AM, Rob Stradling via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 08/02/18 15:50, Gervase Markham via dev-security-policy wrote: > >> On 08/02/18 13:47, Hanno Böck wrote: >> >> OneCRL additions normally have an associated bug but I can't

Re: Misissuance/non-compliance remediation timelines

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 really should have stopped responding 'good' for unknown certs back in 2013) needs to select,

Re: ComSign Root Renewal Request

Yair, > Re Section 3.4, you seem to assume the domain holder is a ComSign > > subscriber. In case of misissuance, that may not be true. > >>> I understand, for that we added on the CPS on section 3.4 the > following: > "For the handling of revocation requests by other than the Subscriber or >

Re: Certificates with 2008 Debian weak key bug

On Mon, Feb 5, 2018 at 4:33 PM, Alex Cohn via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > I logged two of those five certificates (https://crt.sh/?id=308392091 > and https://crt.sh/?id=307753186) to Argon, as part of a project to > log every certificate in the censys.io

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: Certificates with 2008 Debian weak key bug

I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1435770 requesting an incident report from Certum. On Mon, Feb 5, 2018 at 10:07 AM, Eric Mill via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > WoSign and StartCom are untrusted, but Certum is still trusted, right?

Re: Updating Root Inclusion Criteria

I would like to thank everyone for your constructive input on this topic. At the outset I stated a desire to ‘establish some objective criteria that can be measured and applied fairly’. While some suggestions have been made, no clear set of criteria has emerged. At the same time, we’ve heard the

Re: Updating Root Inclusion Criteria

On Fri, Jan 19, 2018 at 3:04 AM, Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 18/01/18 14:24, Ryan Sleevi wrote: > > Isn't this effectively the VISA situation? When were their first audits - > > late 2016 / early 2017? > > I'm not certain; I'll ask

Re: DRAFT January 2018 CA Communication

The email has been sent, and we've published a blog post: https://blog.mozilla.org/security/2018/01/29/january-2018-ca-communication/ On Monday, January 29, 2018 at 1:15:51 PM UTC-7, Wayne Thayer wrote: > You can find a link to the final version of the survey at >

Re: DRAFT January 2018 CA Communication

You can find a link to the final version of the survey at https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication We're planning to send this out to all CAs in the Mozilla program later today. The deadline for responses has been set to 9-February. Thanks to everyone who

Re: Taiwan GRCA Root Renewal Request

Thanks for pointing this out Ryan and Dimitris. You are both correct: we should direct Taiwan GRCA to change their request from including the root to including only the subordinate CAs that comply with the Mozilla policy. The option of adding the non-compliant subordinate CAs to OneCRL does not

Re: ComSign Root Renewal Request

Yair, Will you please provide a detailed response to each of Ryan's points? Also, please provide the specific version of the RSA Certificate Manager in use by ComSign. Thanks, Wayne On Mon, Jan 29, 2018 at 8:43 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote:

Re: DRAFT January 2018 CA Communication

Thanks Jakob. I updated the draft as described below. On Fri, Jan 26, 2018 at 10:42 AM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I think a number of the questions/actions need additional options: > > For ACTION 1: > > (These 3 are between the 1st and

Re: DRAFT January 2018 CA Communication

Based on the feedback we've received, but sticking with the original intent of this communication, I have converted it into a survey. You can find a draft at: https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication I would appreciate your comments on this. I have set the

Re: DRAFT January 2018 CA Communication

On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg wrote: > This is a great improvement. I think we should also ask that any CAs using > these methods immediate disclose that they are and the procedures they are > using, as well as the date they expect to complete a

Re: DRAFT January 2018 CA Communication

d, Jan 24, 2018 at 4:05 PM, Ryan Sleevi <r...@sleevi.com> wrote: > >> >> >> On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy < >> dev-security-policy@lists.mozilla.org> wrote: >>> >>> > Is there a reason to make this depr

Re: DRAFT January 2018 CA Communication

On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleevi <r...@sleevi.com> wrote: > > > On Wed, Jan 24, 2018 at 5:05 PM, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: >> >> > Is there a reason to make this deprecation conditional

Re: DRAFT January 2018 CA Communication

On Wed, Jan 24, 2018 at 1:50 PM, Jonathan Rudenberg <jonat...@titanous.com> wrote: > > > On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > 2. On 19-December, significant concer

Re: Summary of Responses to the November CA Communication

To the best of my knowledge, the only "standard" sanction we have today is complete distrust of a root or intermediate, and in practice that rarely happens. On the surface, the idea of lesser sanctions like removing the EV indicator for some period of time is appealing to me, but I think we need

Re: Summary of Responses to the November CA Communication

On Wed, Jan 24, 2018 at 6:56 AM, Ryan Sleevi wrote: > This seems to be a perennial problem with CAs, and doesn't inspire > confidence in them or their operations. I am also concerned that an > extension of this nature does not inspire confidence in the Mozilla Root > Program,

DRAFT January 2018 CA Communication

I want to directly notify all CAs in the Mozilla program of the recently exposed issues with domain validation methods and of some upcoming deadlines. A draft is available below and at https://wiki.mozilla.org/CA/Communications#January_2018_CA_Communication I would appreciate your prompt and

Re: Summary of Responses to the November CA Communication

On Wed, Jan 24, 2018 at 9:54 AM, Gervase Markham wrote: > We do actually do that, it's just not written in the policy itself. See: > https://wiki.mozilla.org/CA/Root_Store_Policy_Archive > which gives all the publication dates and compliance dates. > > Good. Then all I'm

Re: Summary of Responses to the November CA Communication

In the past, new policy versions have not had a clearly defined future effective date. That seems to have led some CAs to interpret the timing for making changes to be "whenever we get around to it" instead of the intent of "the policy is effective immediately and we expect you to comply with it

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: Google OCSP service down

On Sun, Jan 21, 2018 at 2:14 PM, Ryan Sleevi via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > > I think the whole CA incident reporting question has lots of room for > > improvement. And I think this should be considered in a way that people > > who are not familiar

Re: ComSign Root Renewal Request

Wayne [1] https://ccadb-public.secure.force.com/mozillacommunications/ CACommResponsesOnlyReport?CommunicationId=a051J3mogw7= Q00042,Q00048 On Tue, Jan 16, 2018 at 2:05 PM, Wayne Thayer via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > To recap, we've established that this

Re: TLS-SNI-01 and compliance with BRs

On Fri, Jan 19, 2018 at 1:58 PM, Doug Beattie via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > Given this discussion, there must be no other CAs using method 9 or 10, > else they would have come forward by now with disclosures and have > demonstrated their compliance..

Re: TLS-SNI-01 and compliance with BRs

Peter, On Fri, Jan 19, 2018 at 10:06 AM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > What does Mozilla expect to be verified? We know the 10 methods allow > issuance where "the applicant has registered the domain(s) referenced in > the certificate or

Re: Taiwan GRCA Root Renewal Request

This root inclusion request is currently in the public discussion phase [1] After reviewing Taiwan GRCA's CP, CPS and related documents [2], I have the following comments: ==Good== 1. GRCA has requested that this root be constrained to issuing certificates for .tw domains. 2. The BR Self

Re: Updating Root Inclusion Criteria

On Wed, Jan 17, 2018 at 3:32 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 17/01/2018 23:03, Jonathan Rudenberg wrote: > > You seem to be stuck inside some kind of ivory tower world where > computers are king and everything is done by robots. > > This

Re: Updating Root Inclusion Criteria

On Wed, Jan 17, 2018 at 7:54 AM, Alex Gaynor wrote: > Hi Wayne, > > After some time thinking about it, I struggled to articulate what the > right rules for inclusion were. > > Yes, that is the challenge. So I decided to approach this from a different perspective: which is

Re: Updating Root Inclusion Criteria

On Wed, Jan 17, 2018 at 7:46 AM, Tim Hollebeek wrote: > I support "encouraging" those who are currently using the public web PKI > for > internal uses to move to their own private PKIs. The current situation is > an > artifact of the old notion that there should be a

Re: Camerfirma's misissued certificate

Thank you for reporting this misissuance. Since this is a different issue than described in bug 1390977, I have created a new bug to track this problem and your response: https://bugzilla.mozilla.org/show_bug.cgi?id=1431164 Please also post your incident report here. Also, the crt.sh link above

Updating Root Inclusion Criteria

I would like to open a discussion about the criteria by which Mozilla decides which CAs we should allow to apply for inclusion in our root store. Section 2.1 of Mozilla’s current Root Store Policy states: CAs whose certificates are included in Mozilla's root program MUST: > 1.provide

Re: ComSign Root Renewal Request

To recap, we've established that this root was first BR audited on 26-April 2015 and has received clean period-of-time audits over the next two years. ComSign has disclosed 36 certificates issued by this root prior to the BR point-in-time audit, of which one remains unexpired. This does not

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

On Fri, Jan 12, 2018 at 11:21 AM, Doug Beattie wrote: > > > Normally a web hosting provider should not let you set SNI for a domain > someone else is using, especially on that IP address. I think this is > where method 9 deviates from method 10. > > > I agree, it

Re: Taiwan GRCA Root Renewal Request

On Thursday, June 1, 2017 at 5:03:15 PM UTC-7, Kathleen Wilson wrote: > On Friday, May 26, 2017 at 9:32:57 AM UTC-7, Kathleen Wilson wrote: > > On Wednesday, March 15, 2017 at 5:01:13 PM UTC-7, Kathleen Wilson wrote: > > All, > > > > I requested that this CA perform a BR Self Assessment, and

Re: Possible Issue with Domain Validation Method 9 in a shared hosting environment

Doug, I have some questions: > > c.The hosting company must allow you to manually create and upload > a CSR for a site you don’t own > > Did you mean to say 'certificate' here instead of 'CSR'? d. The user must be able to trick the hosting provider to enable SNI > for this domain

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Thu, Jan 11, 2018 at 3:28 PM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > https://community.letsencrypt.org/t/2018-01-11-update-regard > ing-acme-tls-sni-and-shared-hosting-infrastructure/50188 > > Speaking for myself, this is an excellent game plan that

Re: Incident report: Failure to verify authenticity for some partner requests

Thank you for the report Tim. I just created https://bugzilla.mozilla.org/show_bug.cgi?id=1429639 to track this issue. Please follow up in the bug and on this thread. - Wayne On Wed, Jan 10, 2018 at 2:24 PM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: >

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

On Wed, Jan 10, 2018 at 10:39 AM, Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wed, Jan 10, 2018 at 11:24 AM, Gervase Markham via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > > > I don't think that's true. If your

Re: 5.3.1 Technically Constrained

Ben, I'm about to use the term 'paragraph' to refer to the text within section 5.3.1 that is separated by carriage returns. The prior version of the policy contained the language in the final paragraph of section 5.3.1 - see

Re: Mis-Issuance of a SSL multi-domain certificate

Thank you for reporting this issue. I have created https://bugzilla.mozilla.org/show_bug.cgi?id=1428877 to track the issue and SwissSign's response. - Wayne On Mon, Jan 8, 2018 at 5:08 AM, Reinhard Dietrich via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > To whom it may

Re: Misissued certificate with improper characters in DNSname

Stephen, Thanks for the report. I have a few questions: 1. Did you scan for any additional certificates containing this type of error that Quovadis or your subordinate CAs have issued? What were the findings? 2. Will the linting check be performed pre- or post-issuance? 3. When will the linting

Re: Japan GPKI Root Renewal Request

On Thursday, August 25, 2016 at 8:07:05 PM UTC, Kathleen Wilson wrote: > > This request by the Government of Japan, Ministry of Internal > > Affairs and Communications, is to include the GPKI 'ApplicationCA2 Root' > > certificate and enable the Websites trust bit. This new root certificate > >

Re: ComSign Root Renewal Request

gt; > bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of > > Wayne Thayer via dev-security-policy > > Sent: Tuesday, December 5, 2017 1:44 PM > > To: mozilla-dev-security-pol...@lists.mozilla.org > > Subject: Re: ComSign Root Renewal Request

Re: OCSP Responder monitoring (was Re: Violations of Baseline Requirements 4.9.10)

Thanks Rob! I went through the list and filed a bug for each CA if there wasn't one already open (with one exception that I'm still researching). All open OCSP issues are included in the list at https://wiki.mozilla.org/CA/Incident_Dashboard Wayne On Mon, Dec 11, 2017 at 10:49 PM, Rob Stradling

Re: ComSign Root Renewal Request

On Sun, Dec 10, 2017 at 9:15 AM, YairE via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Thank you for your notes, > Here are the answers to your points. > > all the "bad" points about the CPS were addressed: > Both CPS's are now changed to ver 4.1 > Looks good, thank

Re: On the value of EV

Thank you Ryan for raising this question, and to everyone who has been contributing in a constructive manner to the discussion. A number of excellent points have been raised on the effectiveness of EV in general and on the practicality of solving the problems that exist with EV. While we have

Re: CA generated keys

On Tue, Dec 12, 2017 at 7:45 PM, Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 12/12/2017 19:39, Wayne Thayer wrote: > >> The outcome to be avoided is a CA that holds in escrow thousands of >> private keys used for TLS. I don’t think that a policy

Re: CA generated keys

On Mon, Dec 11, 2017 at 9:43 AM, Tim Hollebeek via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > I don't know but it's worth talking about. I think the discussion should > be > "when should this be allowed, and how can it be done securely?" > > The outcome to be avoided

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

On Sat, Dec 9, 2017 at 7:50 AM, Nick Lamb via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Sat, 9 Dec 2017 09:51:59 +0100 > Hanno Böck via dev-security-policy > <dev-security-policy@lists.mozilla.org> wrote: > > > On Fri, 8 Dec 2017 16:43

Re: Certificate incident: private key leaked for wildcard certificate for *.sandbox.operations.dynamics.com

On Fri, Dec 8, 2017 at 3:55 PM, Hanno Böck via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > So I wonder: If a CA signs an intermediate - are they responsible > making sure that reports brought to the subca are properly handled? > > The root CA is ultimately responsible

Re: ComSign Root Renewal Request

> We can restart the discussion and please review their updated documents and > comment in this discussion if you have further questions or concerns about > this request. > After reviewing Comsign's updated CPS and related documents, I have the following comments: == Good == - CPS follows RFC

Re: Swiss Government root inclusion request

I've placed this discussion on hold pending: 1. Updated audit statement specifying the audit period. 2. Updated CP/CPS including CAA information, BR compliance statement, and clearer specification of the domain validation procedures that are in use. Wayne >On Tuesday, November 28, 2017 at

<    1   2   3   4   5   6   7   >