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
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
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
>
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
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
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
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
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
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
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
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
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
> 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
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
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
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
> 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
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
> 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,
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
20 matches
Mail list logo