Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

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

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 09/02/2017 18:20, Jakob Bohm wrote: On 09/02/2017 10:59, Gervase Markham wrote: On 08/02/17 11:25, Jakob Bohm wrote: My logic is that adding additional entropy to a serial number whose length is fully controlled by CA procedures can increase the mitigations against SHA-1 weaknesses. For

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 09/02/2017 10:59, Gervase Markham wrote: On 08/02/17 11:25, Jakob Bohm wrote: My logic is that adding additional entropy to a serial number whose length is fully controlled by CA procedures can increase the mitigations against SHA-1 weaknesses. For example if the existing CA setup uses all

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 07/02/17 21:02, okaphone.elektron...@gmail.com wrote: > You start by noticing "The scope of the BRs is a matter of > debate..." > > And then you use that same "scope of the BRs" in 1) to specify > Mozilla's requirements. Isn't that somewhat strange, if what you are > trying to do is solve some

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 07/02/17 19:15, Jakob Bohm wrote: >> Point 2 does not apply if the certificate is an OCSP signing certificate >> manually issued directly from a root. > > Should be point 1 (on OCSP signing certificate is an EE cert) Nope, I'm fairly sure I mean point 2. Rules about intermediate certs don't

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On Tue, Feb 7, 2017 at 9:25 AM, Gervase Markham wrote: > > > 2) The issuing intermediate: > It may be worth clarifying this as "the issuing certificate" The subtlety/nuance here being is that if the end entity deemed out of scope of the Baseline Requirements, then you are

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

Hi Gerv, You start by noticing "The scope of the BRs is a matter of debate..." And then you use that same "scope of the BRs" in 1) to specify Mozilla's requirements. Isn't that somewhat strange, if what you are trying to do is solve some problems that are caused by the former? CU Hans

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 07/02/2017 20:49, David E. Ross wrote: On 2/7/2017 11:15 AM, Jakob Bohm wrote: Root certificates previously withdrawn for this purpose are encouraged to report this fact to Mozilla by and to maintain valid entries in the CCADB for such roots, all for the benefit of organizations that

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 2/7/2017 11:15 AM, Jakob Bohm wrote: > Root certificates previously withdrawn for this purpose are encouraged > to report this fact to Mozilla by and to maintain valid entries in > the CCADB for such roots, all for the benefit of organizations that > maintain or service software that are

Re: Policy 2.4 Proposal: Implement "proper" SHA-1 ban

On 07/02/2017 18:25, Gervase Markham wrote: 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. However, implementing the ban via the BRs is problematic for a number of reasons: * It allows the issuance of SHA-1

Policy 2.4 Proposal: Implement "proper" SHA-1 ban

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. However, implementing the ban via the BRs is problematic for a number of reasons: * It allows the issuance of SHA-1 certs in publicly-trusted hierarchies in those