Re: Technically Constrained Sub-CAs and the BRs

> Certificates that are capable of being used to issue new certificates MUST > either be Technically Constrained in line with section 7.1.5 and audited in > line with section 8.7 only, or Unconstrained and fully audited in line with > all remaining requirements from this section > > Section

Re: Distrusting New WoSign and StartCom Certificates -- Mozilla Security Blog

On Monday, October 24, 2016 at 6:09:50 PM UTC-7, Kathleen Wilson wrote: > The security blog about Distrusting New WoSign and StartCom Certificates has > been published: > > https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/ > > Chinese translations of

Re: Mozilla CT Policy

On Monday, November 7, 2016 at 9:02:37 AM UTC-8, Gervase Markham wrote: > As in, their dishonesty would be carefully targetted and so not exposed > by this sort of coarse checking? (Continuing with Google/Chrome hat on, since I didn't make the previous reply explicit) Yes. An 'evil log' can

Re: Mozilla CT Policy

On 07/11/16 16:13, Ryan Sleevi wrote: > Yes, particularly for logs that may be compelled to be dishonest for > geopolitical reasons. As in, their dishonesty would be carefully targetted and so not exposed by this sort of coarse checking? Gerv ___

Re: Mozilla CT Policy

On Monday, November 7, 2016 at 1:59:31 AM UTC-8, Gervase Markham wrote: > It is correct that there is not yet a plan for when Firefox might > implement inclusion proof fetching. > > One thing I have been pondering is checking the honesty of logs via > geographically distributed checks done by

Re: Implementing a SHA-1 ban via Mozilla policy

On 07/11/16 15:34, Doug Beattie wrote: > I'd prefer a requirement for long serial numbers over a total ban on > SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend > using that for non BR certificates (assuming client applications > don't have issues with that). Can you list some

Re: Mozilla CA Policy 2.3 plan

On 07/11/16 14:34, Kurt Roeckx wrote: > In my experience, pointing to a specific section of the BRs causes > problems because things are moved, renumbered and so on. Other changes > in the document also point to specific sections. The BRs now follow RFC 3647, which AIUI specifies the title and

Re: Mozilla CA Policy 2.3 plan

On 2016-11-07 15:08, Gervase Markham wrote: https://github.com/mozilla/pkipolicy/compare/2.2...master So one of the changes is that you now have: -issuing certificates), as described in [CA/Browser Forum -Baseline Requirement -

Re: Implementing a SHA-1 ban via Mozilla policy

On 07/11/16 13:11, Phillip Hallam-Baker wrote: > Not long after I was sitting in a conference at NIST listening to a talk on > how shutting down DigiNotar had shut down the port of Amsterdam and left > meat rotting on the quays etc. Ooops. Sounds like someone got a lesson in single points of

Re: Implementing a SHA-1 ban via Mozilla policy

On 07/11/16 10:52, Nick Lamb wrote: > Where we don't have another way forward, I think one option is for > CAs to replace an existing unconstrained intermediate with a newer > one that is suitably constrained, and revoke the old one. This is > subject to all the usual caveats about revocation and

Re: Implementing a SHA-1 ban via Mozilla policy

Remember the DigiNotar incident? At the time, I thought that pulling the DigiNotar roots was exactly the right thing to do. I didn't say so as it isn't proper for people to be suggesting putting their competitors out of business. But I thought it the right thing to do. Not long after I was

Re: SHA-1 issuances in 2016 That Chain to Mozilla Roots

On 05/11/16 13:49, Ryan Sleevi wrote: > As noted elsewhere, the issuance of SHA-1 allows for an attacker to > pivot the contents of the certificates, and the only mitigation is > the EKU on the sub-CA. > > Are you suggesting this is GA because it wasn't clear enough to CA > members at the time

Re: Mozilla CT Policy

On 05/11/16 19:33, Ryan Sleevi wrote: > My understanding was that Mozilla's implementation status was similar > to Chrome's a year ago - that is, that it doesn't implement inclusion > proof fetching (in the background) and that work hadn't been > scheduled/slated yet. In that case, it's a question

Implementing a SHA-1 ban via Mozilla policy

It has been noted that currently, Mozilla's SHA-1 ban is implemented via the ban in the BRs, which we require all CAs to adhere to. At the moment, Mozilla policy simply says: "We consider the following algorithms and key sizes to be acceptable and supported in Mozilla products: SHA-1 (until

Re: Remediation Plan for WoSign and StartCom

Just came across the following Phishing site which is using a StartCom cert: hXXps://serviices-intl.com/webapps/6fa9b/websrc On 11/2/16, 6:32 PM, "dev-security-policy on behalf of Itzhak Daniel"