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 a practical collision attack against SHA-1 certificates
is imminent);
...."
Whether or not such an attack is imminent, we have not notified CAs that
it is, and so we cannot claim this clause is a ban. 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 in
January, 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, which we would implement via a CA Communication, and
then later in an updated version of our policy. This message is intended
to start a discussion about how we can reasonably and safely define
"proper".
One option would be to say that there should be no signing of SHA-1
hashes in any circumstances within the hierarchies which chain up to
Mozilla-trusted roots. However, it's possible that such a total ban
would have disproportionate impact, and there are some circumstances
where SHA-1-hash-signing can safely continue (e.g. if all data is
CA-controlled). Or it may be that there isn't. Comments welcome.
We would also need to decide on a timeline for CAs to implement any
changes we require, and comments are welcome on that also.
Gerv
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
