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: DRAFT January 2018 CA Communication

Friday was the deadline for responding to this survey. Responses are now published at https://wiki.mozilla.org/CA/Communications#January_2018_Responses I would like to thank everyone who took the time to respond, and especially those who provided detailed answers to Action 2 regarding methods 1

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

On 26/01/2018 18:11, Wayne Thayer wrote: 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

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 Fri, Jan 26, 2018 at 5:24 AM Gervase Markham via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 24/01/18 22:19, Jonathan Rudenberg wrote: > > While these CAs might want six months, it’s not clear that a good > > argument has been made for this. Let’s Encrypt stopped

Re: DRAFT January 2018 CA Communication

On 24/01/18 22:19, Jonathan Rudenberg wrote: > While these CAs might want six months, it’s not clear that a good > argument has been made for this. Let’s Encrypt stopped validating > using the TLS-SNI-01 method under two hours after learning that there > was a *potential* security vulnerability in

Re: DRAFT January 2018 CA Communication

On Thu, Jan 25, 2018 at 4:20 PM, Peter Bowen via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Thu, Jan 25, 2018 at 1:02 PM, Ryan Sleevi via dev-security-policy > wrote: > > On Thu, Jan 25, 2018 at 3:34 PM, Wayne Thayer

Re: DRAFT January 2018 CA Communication

On Thu, Jan 25, 2018 at 3:34 PM, Wayne Thayer wrote: > On Thu, Jan 25, 2018 at 11:48 AM, Jonathan Rudenberg < > jonat...@titanous.com> wrote: > >> This is a great improvement. I think we should also ask that any CAs >> using these methods immediate disclose that they are and

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

> On Jan 25, 2018, at 13:09, Wayne Thayer via dev-security-policy > wrote: > > Tim - I will add a reference to TLS-SNI-02 as you suggested. I think an > explanation of the new method 12 is too much detail for this message, and > it can be found in the

Re: DRAFT January 2018 CA Communication

Tim - I will add a reference to TLS-SNI-02 as you suggested. I think an explanation of the new method 12 is too much detail for this message, and it can be found in the ballot that I've referenced. In order to move ahead with this communication to CAs while our timeline for the deprecation of BR

Re: DRAFT January 2018 CA Communication

On Wed, Jan 24, 2018 at 4:05 PM, Ryan Sleevi 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 on the ballot? >> > Given what we know

Re: DRAFT January 2018 CA Communication

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 on the ballot? > > Given what we know about how the vulnerable methods are used in the wild, > > they have the same

Re: DRAFT January 2018 CA Communication

> On Jan 24, 2018, at 17:05, Wayne Thayer via dev-security-policy > wrote: > > We could still choose to set that date in our own policy if the ballot were > to fail. The reasoning behind that date has been discussed on the > CA/Browser Forum lists. I

Re: DRAFT January 2018 CA Communication

On Wed, Jan 24, 2018 at 1:50 PM, Jonathan Rudenberg 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 concerns were raised about the reliability > > of the

Re: DRAFT January 2018 CA Communication

> On Jan 24, 2018, at 15:20, Wayne Thayer via dev-security-policy > wrote: > > 2. On 19-December, significant concerns were raised about the reliability > of the domain validation methods specified in BR 3.2.2.4.1 and 3.2.2.4.5. > [3] Since then,

RE: DRAFT January 2018 CA Communication

Wayne, You might want to highlight that method 1 sub-method 3 would survive even if ballot 218 passes, as a new method 12 with some changes and improvements that CAs who use sub-method 3 should pay close attention to. With regards to TLS-SNI-01, I believe TLS-SNI-02 is also affected by the same