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
dev-security-policy@lists.moz
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 ex
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
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 bits of the old serial number length fo
On 08/02/2017 10:55, Gervase Markham wrote:
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.
On 08/02/17 02:32, Ryan Sleevi wrote:
> By clarifying it as 'issuing certificate', you 'hopefully' avoid a
> misinterpretation that suggests direct issuance by a root is acceptable, so
> long as it meets the leaf criteria.
CAs wanted to be able to manually issue OCSP signing certificates
directly
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
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 ap
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 allowing for the
elimi
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
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
mai
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 or
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 cert
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 cas
14 matches
Mail list logo