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.
<quote>
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
