On 01/03/17 10:36, benjaminp...@gmail.com wrote:
> screenshot of the error message: http://imgur.com/a/BIQUm
That error message will not occur if only the root CA is SHA-1 signed,
because Firefox does not check the signatures on root CAs. There must be
some other certificate in the chain that
On 13/02/17 12:23, 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.
Reviewing the discussion, I
Ryan H,
On 23/02/17 04:40, Peter Bowen wrote:
> Both Gerv and I posted follow up questions almost two weeks ago. I
> know you have been busy with CT days. When do you expect to have
> answers available?
Ping? :-)
Gerv
___
dev-security-policy
On 26/02/17 00:50, Itzhak Daniel wrote:
> I talked with Ofer from Incapsula, he said the domain exist at some
> point; Someone have access to domain tools or other tool to verify
> this matter? Based on domaintools I can say the domain did exist but
> I can't tell when it cease to exist.
I think
On 27/02/17 21:41, Ryan Sleevi wrote:
> During a past discussion of precertificates, at
> https://groups.google.com/d/msg/mozilla.dev.security.policy/siHOXppxE9k/0PLPVcktBAAJ
> , Mozilla did not discuss whether or not it considered
> precertificates misissuance, although one module peer (hi! it's
Hi Doug,
On 15/02/17 17:09, Gervase Markham wrote:
> But currently GlobalSign employees still are?
>
> If so, can you help us understand why that's necessary? Given that you
> control the domains used for testing, you should be able to set them up
> to auto-pass some form of automated
On 24/02/17 07:08, blake.mor...@trustis.com wrote:
> Certificates for the HMRC SET Service are issued from the SHA-1 “FPS
> TT Issuing Authority”, which is now only used for this service. The
> replacement server certificate for hmrcset.trustis.com was issued
> from the FPS TT IA, via a manual
On 22/02/17 17:08, Richard Wang wrote:
> I think "apple-id-2.com" is a high risk domain that must be blocked to issue
> DV SSL to those domains.
I don't represent Let's Encrypt, but their policy on such things is
relevant to this discussion, and it is here:
On 22/02/17 14:42, Tony Zhaocheng Tan wrote:
> On 2017-01-03, Let's Encrypt issued a certificate for apple-id-2.com.
> However, until today, the domain apple-id-2.com has apparently never
> been registered. How was the certificate issued?
On Hacker News, Josh Aas writes:
"Head of Let's Encrypt
Hi everyone,
We've now worked our way through all 21 issues which were scheduled for
Mozilla CA Policy 2.4. You can see the current text here:
https://github.com/mozilla/pkipolicy/blob/master/rootstore/policy.md
https://github.com/mozilla/pkipolicy/blob/master/ccadb/policy.md
On 07/02/17 17:45, Gervase Markham wrote:
> We want to update the permitted algorithms and key sizes list.
Resolution: resolved as specced (using English descriptions rather than
AlgorithmIdentifiers).
Gerv
___
dev-security-policy mailing list
On 07/02/17 17:25, Gervase Markham wrote:
> Therefore, we would like to update Mozilla's CA policy to implement a
> "proper" SHA-1 ban.
Resolution: resolved pretty much as drafted.
Gerv
___
dev-security-policy mailing list
On 16/02/17 18:26, blake.mor...@trustis.com wrote:
> Trustis has now revoked the SHA-1 Certificate for hmrcset.trustis.com
> and replaced it with a SHA-256 Certificate. This status is reflected
> in the latest CRL.
Hi Blake,
We are pleased to hear that, but the detail of your report compares
Hi Stephen,
On 16/02/17 18:37, Stephen Davidson wrote:
> Incident Report
Thank you for your prompt and detailed incident report. It seems to me
that this highlights the particular extra care that needs to be taken by
all CAs regarding manual issuances which do not use the normal software
into
On 13/02/17 23:53, Wayne Thayer wrote:
> Gerv - this makes sense and it is GoDaddy's intent to perform these steps
> within 3 months.
No significant objections have been put forward about this action plan,
and so I have filed a Bugzilla bug to track GoDaddy's implementation:
On 13/02/17 19:22, Jeremy Rowley wrote:
> As we tied the intermediate to a specific set of companies (which correlated
> roughly to a specific volume of certificates), renewal and pinning were
> non-issues. As long as each company was identified under the same umbrella,
> an entity renewing,
On 13/02/17 17:34, okaphone.elektron...@gmail.com wrote:
> Isn't this mostly something that CAs should keep in mind when they
> setup "shop"?
>
> I mean it would be nice to have a way of avoiding that kind of impact
> of course, but if they think it's best to put all their eggs in one
> basket...
On 13/02/17 16:17, 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 fairly
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.
But currently GlobalSign employees
On 13/02/17 23:13, Santhan Raj wrote:
> One thing to highlight here is that the WebTrust audits are performed
> against the BRs and not against the root program requirements.
This is true, although (apart from the relative importance of domain
validation) this is similarly true of many items in
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
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
On 11/02/17 12:13, Peter Gutmann wrote:
> Is no-one at Mozilla able to explain why they did this? It's a nontrivial
> piece of code to implement, surely someone must know what the thinking was
> behind doing it this way?
Peter: you are going to have to re-summarise your question. And then, if
Hi Ryan,
On 09/02/17 19:55, Ryan Hurst wrote:
> - The EV OID associated with this permission is associated with GlobalSign
> and not Google and,
Which EV OID are you referring to, precisely?
> - GlobalSign is active member in good standing with the respective root
> programs and,
> - Google
On 10/02/17 05:10, Peter Bowen wrote:
> On Thu, Feb 9, 2017 at 7:41 AM, Gervase Markham via
>> A) The date Google took control of the GlobalSign roots
>> B) The date Google publicly announced GTS
>>
>> you will see there's quite a big delta. If you assume Google told
>> Mozilla about event A)
On 10/02/17 06:15, Richard Wang wrote:
> I think Mozilla should have a very clear policy for:
> (1) If a company that not a public trusted CA acquired a trusted root key,
> what the company must do?
> (2) If a company is a public trusted CA that acquired a trusted root key,
> what the company
On 09/02/17 14:32, Gijs Kruitbosch wrote:
> Would Mozilla's root program consider changing this requirement so that
> it *does* require public disclosure, or are there convincing reasons not
> to? At first glance, it seems like 'guiding' CAs towards additional
> transparency in the CA
401 - 431 of 431 matches
Mail list logo
