> -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 valid
On Mon, Feb 13, 2017 at 2:39 PM, 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.
>
I think this may be the crux of our disagreement. I believe that an ide
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 groun
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:
> > https://bugzilla.mozilla.org/attachment.cgi?id=883
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 sa
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.
CA Issuers AIA resolution of EE to issuer is good enough for government work,
and fortunately the market offers software that c
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 checkers
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 ser
I think rotating intermediates is a good way to limit the impact of
intermediate revocation/compromise, and one we tried to implement a while
ago. We had a policy that every x companies would be put on an intermediate.
I think we even pitched it as a suggested requirement on the Mozilla list
back i
On 13/02/2017 18:25, Ryan Sleevi via dev-security-policy wrote:
> On Mon, Feb 13, 2017 at 8:17 AM, Steve Medin via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Getting all user agents with interest is issuance limits to implement the
>> CA Issuers form of AIA for dyna
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 m
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 fair
On Monday, 13 February 2017 13:23:47 UTC+1, Gervase Markham wrote:
> The GoDaddy situation raises an additional issue.
>
> What can be done about the potential future issue (which might happen
> with any large CA) of the need to untrust a popular intermediate?
> Suggestions welcome.
>
> Gerv
Is
On Mon, Feb 13, 2017 at 8:17 AM, Steve Medin via dev-security-policy <
dev-security-policy@lists.mozilla.org> 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 pr
On 13/02/17 16:18, Peter Bowen wrote:
> In addition to updating it to follow formal policy language, I would
> suggest adding it directly to the policy. As it stands today there
> are 79 pages in the wiki starting with "CA:". It simply isn't
> possible to know which ones are effectively part of t
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 sa
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 becau
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 d
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 ther
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
> Subject
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 section".
>
> It may be that this documen
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 co
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
_
Gerv,
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.
> -Original Message-
> From: Gervase Markham [mailto:g...@mozill
On Monday, 13 February 2017 12:22:34 UTC, Gervase Markham wrote:
> This is why the CAB Forum has been working for
> some time on carefully documenting best practice in domain validation,
> and passed ballot 169 to incorporate them into the Baseline
> Requirements. The problem experienced by GoDadd
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 f
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 w
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 on
Hi Inigo.
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 section".
It may be that this document does need redoing in formal policy
language. In the mean time, anyone unce
On Monday, 13 February 2017 09:06:02 UTC, Kurt Roeckx wrote:
> This seems to be a worrying trend to me.
Almost certainly it would be wrong for us to look at these three data points
and conclude from them that the main problem is EY itself. Not to say they
can't do better, or be a key agent of c
Kurt Roeckx via dev-security-policy
writes:
>So after reading this, the following auditors aren't trusted by Symantec
>anymore:
>- E&Y Korea
>- E&Y Brazil
>
>The following isn't trusted by Mozilla anymore:
>- E&Y Hong Kong
>
>This seems to be a worrying trend to me.
It's OK, E&Y have offices in
So after reading this, the following auditors aren't trusted by Symantec
anymore:
- E&Y Korea
- E&Y Brazil
The following isn't trusted by Mozilla anymore:
- E&Y 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 stateme
34 matches
Mail list logo
