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

[Gervase Markham via dev-security-policy]

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.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

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 example if the existing CA
setup uses all bits of the old serial number length for non-random
values, then the required 64 random bits can simply be appended or
prepended.


Requiring randomness in the serial number is only appropriate when some
of the certificate contents are attacker-controlled. This is not true
for an intermediate issued by a CA. And if the CA is an attacker,
restricting them to a serial number of the same length (i.e. not
arbitrary) makes it harder for them to engineer a collision.

Gerv



However as a best practice, a CA may establish internal countermeasures
involving adding entropy even for internal requests for intermediary
certificates.  My proposal was to simply not ban that.

For external requests, the issue would be if a specific CA certificate
was previously used to sign certificates whose serial number consisted
of e.g. a 128 bit internally computed value (such as AES128(fixed key,
counter)) and a few bits of fresh entropy (such as 20 bits), then
moving to to the higher requirement of 64 fresh CSPRNG bits might be
best implemented (for some such CA) by changing to those same 128 bits
(for continued uniqueness), plus 64 bits of CSPRNG output.  Again my
proposal was not to ban that.

More generally, there might be a Mozilla policy requirement that the
length should be fixed in the (updated) CP/CPS, and the serial number
should be mostly generated by the issuing CA (except for cross-certs).


Strike that exception, the serial number is not dictated by the
requester, even for cross-certs.


While such length-growing security improvements might be hampered by
the need to support legacy parties with hard limits on serial number
length, that would be for each CA to consider and decide.




Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm via dev-security-policy]

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 bits of the old serial number length for non-random
values, then the required 64 random bits can simply be appended or
prepended.


Requiring randomness in the serial number is only appropriate when some
of the certificate contents are attacker-controlled. This is not true
for an intermediate issued by a CA. And if the CA is an attacker,
restricting them to a serial number of the same length (i.e. not
arbitrary) makes it harder for them to engineer a collision.

Gerv



However as a best practice, a CA may establish internal countermeasures
involving adding entropy even for internal requests for intermediary
certificates.  My proposal was to simply not ban that.

For external requests, the issue would be if a specific CA certificate
was previously used to sign certificates whose serial number consisted
of e.g. a 128 bit internally computed value (such as AES128(fixed key,
counter)) and a few bits of fresh entropy (such as 20 bits), then
moving to to the higher requirement of 64 fresh CSPRNG bits might be
best implemented (for some such CA) by changing to those same 128 bits
(for continued uniqueness), plus 64 bits of CSPRNG output.  Again my
proposal was not to ban that.

More generally, there might be a Mozilla policy requirement that the
length should be fixed in the (updated) CP/CPS, and the serial number
should be mostly generated by the issuing CA (except for cross-certs).

While such length-growing security improvements might be hampered by
the need to support legacy parties with hard limits on serial number
length, that would be for each CA to consider and decide.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham]

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 problems that are caused by the former?

It may seem that way, but no :-) The reason is that the BRs ban SHA-1
issuance entirely, so a CA cannot be advantaged if it tries to dodge
this policy by claiming "actually, this cert is within the scope of the
BRs and so your SHA-1 restrictions do not apply".

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham]

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 apply when there's no intermediate cert.

> 3) Any intermediate between the Mozilla trusted CA root and the issuing
> intermidiate:
> * Has an appropriate pathlen: constraint consistent with the pathlen to
> all its EE issuing lower intermediate certs.
> * Is used only for issuing lower intermediate certs, OCSP signing certs
> and CRLs.  The OCSP signing certs and CRLs being used exclusively for
> revocation checking certs issued by the intermediate itself.

Please provide rationale for your suggested changes.

>> CAs may only sign SHA-1 hashes over intermediate certificates which
>> chain up to roots in Mozilla's program if the certificate to be signed
>> is a duplicate of an existing SHA-1 intermediate certificate with the
>> only changes being all of:
>> * a new key (of the same size);
> 
> or larger
> 
>> * a new serial number (of the same length);
> 
> or longer

No; identical. The logic is that allowing length changes makes it more
possible for someone to construct a collision.

> None of the above applies to root certificates voluntarily
> withdrawn from the Mozilla root program.

This is implied everywhere.

> 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 interoperate with such older
> software.

This would be a different matter, and one for the CCADB policy. We would
need to have a very good reason for requiring CAs to keep information in
the CCADB which did not relate to our root program.

Gerv
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Ryan Sleevi]

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
elimination of the rule that prevents direct issuance of the Root.

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.

The downside to this is that it does leave another loophole (both present
and in the modified version) in which if a given issuing CA has multiple
associated certificates, they could be argued as complying with the letter
but not the spirit.

Perhaps "All certificates sharing the same key and whose issuer matches the
certificate subject" but that's... a mouthful :)
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[okaphone . elektronika]

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
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm]

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
maintain or service software that are or interoperate with such older
software.


No.  Root certificates do NOT report anything.  The certification
authorities that own the root certificates do the reporting.

Confusing certificates with their owners propagates into confusion among
subscribers, developers, and users.  This is also seen with "CA".   That
acronym means "certification authority", but it is too often seen to
mean "root certificate".

Enforceable policies require that all terminology be accurate and
unambiguous.



Ok, prefix that last sentence by "Operators of" then.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[David E. Ross]

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 interoperate with such older
> software.

No.  Root certificates do NOT report anything.  The certification
authorities that own the root certificates do the reporting.

Confusing certificates with their owners propagates into confusion among
subscribers, developers, and users.  This is also seen with "CA".   That
acronym means "certification authority", but it is too often seen to
mean "root certificate".

Enforceable policies require that all terminology be accurate and
unambiguous.

-- 
David E. Ross


Paraphrasing Mark Twain, who was quoting someone else:
There are three kinds of lies: lies, damned lies, and
alternative truths.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Jakob Bohm]

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 certs in publicly-trusted hierarchies
in those cases where the cert is not within scope of the BRs (e.g. email
certs).

* The scope of the BRs is a matter of debate, and so there are grey
areas, as well as areas clearly outside scope, where SHA-1 issuance
could happen.

* Even when the latest version of Firefox stops trusting SHA-1 certs
very soon, a) that block is overrideable, and b) that doesn't address
risks to older versions.

Therefore, we would like to update Mozilla's CA policy to implement a
"proper" SHA-1 ban. At the moment, it seems difficult to define a SHA-1
ban for email, so the current text leaves that for a future update.

Here is some draft text, which would be added to the Maintenance section
of the policy, bullet 6. It has been discussed here, and discussed on
the CABF public list as well, so it's been pretty carefully analyzed.


CAs may only sign SHA-1 hashes over end-entity certificates which chain
up to roots in Mozilla's program if all the following are true:

1) The end-entity certificate:
* is not within the scope of the Baseline Requirements;
* contains an EKU extension which does not contain either of the id-kp-
  serverAuth or anyExtendedKeyUsage key purposes;
* has at least 64 bits of entropy from a CSPRNG in the serial number.

2) The issuing intermediate:
* contains an EKU extension which does not contain either of the id-kp-
  serverAuth or anyExtendedKeyUsage key purposes;
* has a pathlen:0 constraint.

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)

Add a point 3)

3) Any intermediate between the Mozilla trusted CA root and the issuing
intermidiate:
* Has an appropriate pathlen: constraint consistent with the pathlen to
all its EE issuing lower intermediate certs.
* Is used only for issuing lower intermediate certs, OCSP signing certs
and CRLs.  The OCSP signing certs and CRLs being used exclusively for
revocation checking certs issued by the intermediate itself.



CAs may only sign SHA-1 hashes over intermediate certificates which
chain up to roots in Mozilla's program if the certificate to be signed
is a duplicate of an existing SHA-1 intermediate certificate with the
only changes being all of:
* a new key (of the same size);


or larger


* a new serial number (of the same length);


or longer


* the addition of an EKU and/or a pathlen constraint to meet the
requirements outlined above.

CAs may only sign SHA-1 hashes over OCSP responses if the signing
certificate contains an EKU extension which contains only the
id-kp-ocspSigning EKU.

CAs may only sign SHA-1 hashes over CRLs for roots and intermediates
which have issued SHA-1 certificates.

CAs may not sign SHA-1 hashes over other data, including CT
pre-certificates.


Add:

None of the above applies to root certificates voluntarily
withdrawn from the Mozilla root program.  CAs are encouraged to
indicate in their withdrawal requests if the withdrawn certificate will
continue to operate as a compatibility root for older software needing
e.g. SHA-1 certificates and Mozilla should indicate that withdrawal
reason when removing such a root certificate from its trust list.

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 interoperate with such older
software.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

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

[Gervase Markham]

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 cases where the cert is not within scope of the BRs (e.g. email
certs).

* The scope of the BRs is a matter of debate, and so there are grey
areas, as well as areas clearly outside scope, where SHA-1 issuance
could happen.

* Even when the latest version of Firefox stops trusting SHA-1 certs
very soon, a) that block is overrideable, and b) that doesn't address
risks to older versions.

Therefore, we would like to update Mozilla's CA policy to implement a
"proper" SHA-1 ban. At the moment, it seems difficult to define a SHA-1
ban for email, so the current text leaves that for a future update.

Here is some draft text, which would be added to the Maintenance section
of the policy, bullet 6. It has been discussed here, and discussed on
the CABF public list as well, so it's been pretty carefully analyzed.


CAs may only sign SHA-1 hashes over end-entity certificates which chain
up to roots in Mozilla's program if all the following are true:

1) The end-entity certificate:
* is not within the scope of the Baseline Requirements;
* contains an EKU extension which does not contain either of the id-kp-
  serverAuth or anyExtendedKeyUsage key purposes;
* has at least 64 bits of entropy from a CSPRNG in the serial number.

2) The issuing intermediate:
* contains an EKU extension which does not contain either of the id-kp-
  serverAuth or anyExtendedKeyUsage key purposes;
* has a pathlen:0 constraint.

Point 2 does not apply if the certificate is an OCSP signing certificate
manually issued directly from a root.

CAs may only sign SHA-1 hashes over intermediate certificates which
chain up to roots in Mozilla's program if the certificate to be signed
is a duplicate of an existing SHA-1 intermediate certificate with the
only changes being all of:
* a new key (of the same size);
* a new serial number (of the same length);
* the addition of an EKU and/or a pathlen constraint to meet the
requirements outlined above.

CAs may only sign SHA-1 hashes over OCSP responses if the signing
certificate contains an EKU extension which contains only the
id-kp-ocspSigning EKU.

CAs may only sign SHA-1 hashes over CRLs for roots and intermediates
which have issued SHA-1 certificates.

CAs may not sign SHA-1 hashes over other data, including CT
pre-certificates.



This is: https://github.com/mozilla/pkipolicy/issues/25

---

This is a proposed update to Mozilla's root store policy for version
2.4. Please keep discussion in this group rather than on Github. Silence
is consent.

Policy 2.3 (current version):
https://github.com/mozilla/pkipolicy/blob/2.3/rootstore/policy.md
Update process:
https://wiki.mozilla.org/CA:CertPolicyUpdates
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy