> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+wthayer=godaddy@lists.mozilla.org] On Behalf Of Gervase
> Markham via dev-security-policy
> Here is our proposed remediation plan for GoDaddy.
>
> 1) As with all CAs, update all their domain
On Monday, 13 February 2017 22:40:45 UTC, Steve Medin wrote:
> With de facto use of AIA, there is no issuer installation on the server that
> could be improper. Proper is defined at the moment, either by cache or
> discovery hints.
Much as I should like ubiquitous ambient Internet to be a
On Mon, Feb 13, 2017 at 4:48 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Hi Steve,
>
> On 12/02/17 15:27, Steve Medin wrote:
> > A response is now available in Bugzilla 1334377 and directly at:
> >
On Monday, February 13, 2017 at 3:14:06 PM UTC-8, Santhan Raj wrote:
> On Monday, February 13, 2017 at 4:22:34 AM UTC-8, Gervase Markham wrote:
>
> > That is why, despite some IPR-related tangles, Mozilla will be requiring
> > in its next CA Communication that all CAs move to using only those
> >
On Monday, February 13, 2017 at 4:22:34 AM UTC-8, Gervase Markham wrote:
> That is why, despite some IPR-related tangles, Mozilla will be requiring
> in its next CA Communication that all CAs move to using only those
> documented methods in a fairly short timeframe, regardless of what the
> BRs
On Mon, Feb 13, 2017 at 11:56 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> Patrick, thanks, it appears my attempt at brevity produced density.
>
> - No amount of mantra, training, email notification, blinking text and
> certificate installation
Patrick, thanks, it appears my attempt at brevity produced density.
- No amount of mantra, training, email notification, blinking text and
certificate installation checkers make 100% of IT staff who install
certificates on servers aware that issuing CAs change and need to be
installed with the
On Monday, 13 February 2017 16:18:46 UTC, Steve Medin wrote:
> Getting all user agents with interest is issuance limits to implement the CA
> Issuers form of AIA for dynamic path discovery and educating server operators
> to get out of the practice of static chain installation on servers would
On 2/13/2017 8:17 AM, Steve Medin wrote:
> Getting all user agents with interest is issuance limits to implement
> the CA Issuers form of AIA for dynamic path discovery and educating
> server operators to get out of the practice of static chain
> installation on servers would make CA rollovers
On 13/02/17 14:34, Doug Beattie wrote:
> This was for GlobalSign account used for testing, so it was a
> GlobalSIgn employee. Customers are not, nor have they ever been,
> permitted to add domains without GlobalSign enforcing the domain
> verification process.
OK, then I'm a bit confused. You
On 13/02/17 16:41, Nick Lamb wrote:
> GoDaddy came up with). Thus, even though some of the methods from
> Ballot 169 are not included in the Baseline Requirements today,
> Mozilla intends to oblige root programme members to pick from those
> ten methods.
Yes. And this is permitted by the BRs
On 13/02/17 14:34, Nick Lamb wrote:
> I don't think Ballot 169 represents best practices per se. Instead as
> with the rest of the Baseline Requirements what we have here are
> _minimums_, we aren't asking that CAs should do no more than what is
> described, but that they must do at least what is
On 13/02/2017 16:15, Jürgen Brauckmann via dev-security-policy wrote:
> Gervase Markham via dev-security-policy schrieb:
>> 1) As with all CAs, update all their domain validation code to use one
>> of the 10 approved methods;
>
> I'm probably confused regarding BRs pre/post Ballot 181: Aren't
On Monday, 13 February 2017 15:15:47 UTC, Jürgen Brauckmann wrote:
> I'm probably confused regarding BRs pre/post Ballot 181: Aren't there
> only 4 methods per Ballot 181?
>
> Jürgen
Ballot 169 identified exactly 10 methods. Although this ballot passed
unanimously, meaning that both CA members
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+steve_medin=symantec@lists.mozilla.org] On Behalf Of
> Gervase Markham via dev-security-policy
> Sent: Monday, February 13, 2017 7:23 AM
> To: mozilla-dev-security-pol...@lists.mozilla.org
>
On Mon, Feb 13, 2017 at 4:14 AM, Gervase Markham via
dev-security-policy wrote:
> On 10/02/17 12:40, Inigo Barreira wrote:
>> I see many "should" in this link. Basically those indicating "should notify
>> Mozilla" and "should follow the physical relocation
Yes, I know what happened but it´s not what the document says. Unless there´s
another document, it seems to me that you haven´t acted according to what this
page says. If I understand correcly, a should is a conditional and then it´s
not a requirement. Furthermore there´s no indication on the
Gervase Markham via dev-security-policy schrieb:
> 1) As with all CAs, update all their domain validation code to use one
> of the 10 approved methods;
I'm probably confused regarding BRs pre/post Ballot 181: Aren't there
only 4 methods per Ballot 181?
Jürgen
Hi Steve,
On 12/02/17 15:27, Steve Medin wrote:
> A response is now available in Bugzilla 1334377 and directly at:
> https://bugzilla.mozilla.org/attachment.cgi?id=8836487
Thank you for this timely response. Mozilla continues to expect answers
to all reasonable and polite questions posed in our
The GoDaddy situation raises an additional issue.
Mozilla is neither adding any of the 8951 revoked certificates to
OneCRL, nor untrusting any GoDaddy intermediates. However, a more
serious incident might have led us to consider that course of action. In
that regard, the following information is
As members of the group will be aware, last month GoDaddy filed an
incident report concerning a problem with their domain validation system.
Domain validation is the most important task a CA can undertake, any any
flaws in it are serious. This is why the CAB Forum has been working for
some time
So after reading this, the following auditors aren't trusted by Symantec
anymore:
- E Korea
- E Brazil
The following isn't trusted by Mozilla anymore:
- E Hong Kong
This seems to be a worrying trend to me.
Kurt
On 2017-02-12 20:25, Eric Mill wrote:
Also relevant are Symantec's statements
22 matches
Mail list logo