info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Implementing a SHA-1 ban via Mozilla policy
448 views
Skip to first unread message
Gervase Markham
Nov 7, 2016, 4:53:37 AM11/7/16
to mozilla-dev-s...@lists.mozilla.org
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
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
Nick Lamb
Nov 7, 2016, 5:52:26 AM11/7/16
to mozilla-dev-s...@lists.mozilla.org
On Monday, 7 November 2016 09:53:37 UTC, Gervase Markham wrote:
> 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.
In the ideal world we'd just distrust all CAs which are still signing with SHA-1. This is not the ideal world.
> 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.
Where we don't have another way forward, I think one option is for CAs to replace an existing unconstrained intermediate with a newer one that is suitably constrained, and revoke the old one. This is subject to all the usual caveats about revocation and of course the constraints chosen must be practical for that particular CA in the chosen timeframe.
Constraints don't eliminate the collision threat, but they reduce the value of certificates produced by an attacker, which in turn can make the attack uneconomic and have the effect of preventing it. Being able to produce a working CA:TRUE certificate under your control is worth a lot more than being able to spoof a single chosen email address in S/MIME.
Another economic tactic would be to require CAs to use long random serial numbers even in non-BR certificates. M-D style chosen prefix attacks need to correctly predict this part of the tbsCertificate to work, or to do the work N times where N is the number of certificates they must make on average to get a matching serial number. Thus in theory at least a CA which does this properly is a very unattractive target for the attack. This can also be rationalised as protection for subscribers who aren't even interested in the Web PKI and won't be phasing out SHA-1 until 2018 or beyond when SHA-1 may be very creaky indeed, which makes it a good investment for the sort of CA which has such customers.
Phillip Hallam-Baker
Nov 7, 2016, 8:11:50 AM11/7/16
to Nick Lamb, mozilla-dev-s...@lists.mozilla.org
Remember the DigiNotar incident? At the time, I thought that pulling the
DigiNotar roots was exactly the right thing to do. I didn't say so as it
isn't proper for people to be suggesting putting their competitors out of
business. But I thought it the right thing to do.
Not long after I was sitting in a conference at NIST listening to a talk on
how shutting down DigiNotar had shut down the port of Amsterdam and left
meat rotting on the quays etc. Ooops.
The WebPKI is a complicated infrastructure that is used in far more ways
than any of us is aware of. And when it was being developed it wasn't clear
what the intended scope of use was. So it isn't very surprising that it has
been used for a lot of things like point of sale terminals etc.
It is all very well saying that people shouldn't have done these things
after the facts are known. But right now, I don't see any program in place
telling people in the IoT space what they should be doing for devices that
can't be upgraded in the field.
None of the current browser versions support SHA-1. Yes, people could in
theory turn it back on for some browsers but that isn't an argument because
the same people can edit their root store themselves as well. Yes people
are still using obsolete versions of Firefox etc. but do we really think
that SHA-1 is the weakest point of attack?
If digest functions are so important, perhaps the industry should be
focusing on deployment of SHA-3 as a backup in case SHA-2 is found wanting
in the future.
DigiNotar roots was exactly the right thing to do. I didn't say so as it
isn't proper for people to be suggesting putting their competitors out of
business. But I thought it the right thing to do.
Not long after I was sitting in a conference at NIST listening to a talk on
how shutting down DigiNotar had shut down the port of Amsterdam and left
meat rotting on the quays etc. Ooops.
The WebPKI is a complicated infrastructure that is used in far more ways
than any of us is aware of. And when it was being developed it wasn't clear
what the intended scope of use was. So it isn't very surprising that it has
been used for a lot of things like point of sale terminals etc.
It is all very well saying that people shouldn't have done these things
after the facts are known. But right now, I don't see any program in place
telling people in the IoT space what they should be doing for devices that
can't be upgraded in the field.
None of the current browser versions support SHA-1. Yes, people could in
theory turn it back on for some browsers but that isn't an argument because
the same people can edit their root store themselves as well. Yes people
are still using obsolete versions of Firefox etc. but do we really think
that SHA-1 is the weakest point of attack?
If digest functions are so important, perhaps the industry should be
focusing on deployment of SHA-3 as a backup in case SHA-2 is found wanting
in the future.
Gervase Markham
Nov 7, 2016, 8:53:31 AM11/7/16
to Nick Lamb
On 07/11/16 10:52, Nick Lamb wrote:
> Where we don't have another way forward, I think one option is for
> CAs to replace an existing unconstrained intermediate with a newer
> one that is suitably constrained, and revoke the old one. This is
> subject to all the usual caveats about revocation and of course the
> constraints chosen must be practical for that particular CA in the
> chosen timeframe.
You mean EKU-constrained (e.g. to email, or OCSP only)?
> Where we don't have another way forward, I think one option is for
> CAs to replace an existing unconstrained intermediate with a newer
> one that is suitably constrained, and revoke the old one. This is
> subject to all the usual caveats about revocation and of course the
> constraints chosen must be practical for that particular CA in the
> chosen timeframe.
> Another economic tactic would be to require CAs to use long random
> serial numbers even in non-BR certificates.
Gerv
Gervase Markham
Nov 7, 2016, 9:01:19 AM11/7/16
to Phillip Hallam-Baker, Nick Lamb
On 07/11/16 13:11, Phillip Hallam-Baker wrote:
> Not long after I was sitting in a conference at NIST listening to a talk on
> how shutting down DigiNotar had shut down the port of Amsterdam and left
> meat rotting on the quays etc. Ooops.
Sounds like someone got a lesson in single points of failure, cert
> Not long after I was sitting in a conference at NIST listening to a talk on
> how shutting down DigiNotar had shut down the port of Amsterdam and left
> meat rotting on the quays etc. Ooops.
agility and so on. Let's hope they took it.
I'm not sure I totally understand your point. You are saying that it's
not reasonable to eliminate SHA-1 from the publicly trusted hierarchies
entirely because there are devices out there which are not going to be
upgraded and which don't support SHA-256, and further that these devices
are not web devices and so we shouldn't be purporting to control their
crypto?
> None of the current browser versions support SHA-1.
> If digest functions are so important, perhaps the industry should be
> focusing on deployment of SHA-3 as a backup in case SHA-2 is found wanting
> in the future.
Gerv
Nick Lamb
Nov 7, 2016, 9:26:45 AM11/7/16
to mozilla-dev-s...@lists.mozilla.org
On Monday, 7 November 2016 13:11:50 UTC, Phillip Hallam-Baker wrote:
> None of the current browser versions support SHA-1. Yes, people could in
> theory turn it back on for some browsers but that isn't an argument because
> the same people can edit their root store themselves as well. Yes people
> are still using obsolete versions of Firefox etc. but do we really think
> that SHA-1 is the weakest point of attack?
1. Browsers do still trust SHA-1 certificates.
> None of the current browser versions support SHA-1. Yes, people could in
> theory turn it back on for some browsers but that isn't an argument because
> the same people can edit their root store themselves as well. Yes people
> are still using obsolete versions of Firefox etc. but do we really think
> that SHA-1 is the weakest point of attack?
2. This attack can produce a working CA under the control of the attacker. Thus while it's not the most likely attack it makes up for that by being extremely serious.
Doug Beattie
Nov 7, 2016, 10:34:55 AM11/7/16
to Gervase Markham, Nick Lamb, mozilla-dev-s...@lists.mozilla.org
I'd prefer a requirement for long serial numbers over a total ban on SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend using that for non BR certificates (assuming client applications don't have issues with that).
Doug
-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+doug.beattie=globals...@lists.mozilla.org] On Behalf Of Gervase Markham
Sent: Monday, November 7, 2016 8:53 AM
To: Nick Lamb; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Implementing a SHA-1 ban via Mozilla policy
> Another economic tactic would be to require CAs to use long random
> serial numbers even in non-BR certificates.
How long would you say is long enough?
Gerv
_______________________________________________
Gerv
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
Gervase Markham
Nov 7, 2016, 10:47:02 AM11/7/16
to Doug Beattie
On 07/11/16 15:34, Doug Beattie wrote:
> I'd prefer a requirement for long serial numbers over a total ban on
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications
> don't have issues with that).
Can you list some of the uses you'd still like to use SHA-1 in
> I'd prefer a requirement for long serial numbers over a total ban on
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications
> don't have issues with that).
publicly-trusted hierarchies for?
Gerv
Nick Lamb
Nov 7, 2016, 12:09:26 PM11/7/16
to mozilla-dev-s...@lists.mozilla.org
On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote:
> You mean EKU-constrained (e.g. to email, or OCSP only)?
I was thinking also of a pathlen constraint. Suppose I am able to cause an automated system to issue me arbitrary SHA-1 signed certificates from a particular CA, at least once, and I plan to use this with a chosen plaintext attack to produce a certificate of my choosing:
> You mean EKU-constrained (e.g. to email, or OCSP only)?
With no constraints I get a CA:TRUE certificate and can issue anything I want. This is a more or less a worst case scenario.
With just an S/MIME EKU set, I can get a CA:TRUE certificate but it only lets me spoof any email address (by creating certificates chaining through my fake CA:TRUE intermediate). A disaster for S/MIME, but for 90% of the world it's not even a problem.
With just CA pathlen:0, I can make any one end-entity certificate from my attack. Probably the most valuable thing I can make is a wildcard TLS cert for a major domain that doesn't use key-pinning. Bad, to be sure, but very clearly limited in scope.
With both an S/MIME EKU set and CA pathlen:0 I am reduced to making one fake S/MIME email certificate for each successful attack.
> > Another economic tactic would be to require CAs to use long random
> > serial numbers even in non-BR certificates.
>
> How long would you say is long enough?
As with the constraints idea, the purpose of this rule is to make the expected attack uneconomic and thus dissuade anyone from even trying. Without knowing how much bad guys think such certificates could be worth, nor how much it would cost them to attempt the attack I can't offer even a finger in the air estimate, only observe that more is better.
Jakob Bohm
Nov 8, 2016, 3:03:42 AM11/8/16
to mozilla-dev-s...@lists.mozilla.org
On 07/11/2016 15:00, Gervase Markham wrote:
> On 07/11/16 13:11, Phillip Hallam-Baker wrote:
>> ...
> On 07/11/16 13:11, Phillip Hallam-Baker wrote:
>...
>> None of the current browser versions support SHA-1.
>
> Yes, they do. They won't as of January 2017.
>
Since any policy change has no chance of taking effect before that
>
> Yes, they do. They won't as of January 2017.
>
date, they effectively don't for the purpose of discussing policy
changes.
>> If digest functions are so important, perhaps the industry should be
>> focusing on deployment of SHA-3 as a backup in case SHA-2 is found wanting
>> in the future.
>
> https://yourlogicalfallacyis.com/black-or-white . This is not either/or.
>
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
Gervase Markham
Nov 8, 2016, 6:09:17 AM11/8/16
to Doug Beattie
On 07/11/16 15:34, Doug Beattie wrote:
> I'd prefer a requirement for long serial numbers over a total ban on
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications
> don't have issues with that).
Actually, the BRs state 64 bits of entropy in the serial number, in
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications
> don't have issues with that).
section 7.1. The bit you are thinking of which states 112 is for Random
Values used in validation.
Gerv
Gervase Markham
Nov 8, 2016, 6:17:38 AM11/8/16
to Nick Lamb
On 07/11/16 17:09, Nick Lamb wrote:
> On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote:
>> You mean EKU-constrained (e.g. to email, or OCSP only)?
>
> I was thinking also of a pathlen constraint.
Aha. So what would this look like? Something like this?
> On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote:
>> You mean EKU-constrained (e.g. to email, or OCSP only)?
>
> I was thinking also of a pathlen constraint.
CAs may only issue SHA-1 end-entity certs chaining up to roots in
Mozilla's program if the following is true:
* The certificate is not within the scope of the Baseline Requirements;
* The issuing CA and the certificate itself both have a critical EKU
extension with a single key purpose, which is not id-kp-serverAuth or
anyExtendedKeyUsage;
* The issuing CA has a pathlen:0 constraint
* The certificate has at least 64 bits of entropy from a CSPRNG in the
serial number
I guess it doesn't cover signing other things like OCSP responses.
Perhaps we could add:
* CAs may sign other data (such as OCSP responses) with SHA-1 for
compatibility reasons, as long as all of the signed data is static, or
defined by the CA and not by a customer.
Is this heading in the right direction? Too weak, too strong?
Gerv
Doug Beattie
Nov 8, 2016, 7:37:58 AM11/8/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Right, you are correct, 64 bits.
-----Original Message-----
From: Gervase Markham [mailto:ge...@mozilla.org]
Sent: Tuesday, November 8, 2016 6:09 AM
To: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Implementing a SHA-1 ban via Mozilla policy
-----Original Message-----
From: Gervase Markham [mailto:ge...@mozilla.org]
Sent: Tuesday, November 8, 2016 6:09 AM
To: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Implementing a SHA-1 ban via Mozilla policy
On 07/11/16 15:34, Doug Beattie wrote:
> I'd prefer a requirement for long serial numbers over a total ban on
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications don't
> have issues with that).
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications don't
> have issues with that).
Doug Beattie
Nov 8, 2016, 8:44:40 AM11/8/16
to Gervase Markham, mozilla-dev-s...@lists.mozilla.org
Gerv,
GlobalSign generated some SHA-1 CAs earlier this year as part of normal CA lifecycle management. These CAs were generated to support S/MIME and client authentication products and we don’t intent to use them for SSL certificate issuance. These CAs are not technically constrained and they were disclosed to Mozilla in March 2016, shortly after they were created.
Since these CAs will not be used to issue SSL certificates we didn’t believe that they fall under the BRs, and we didn’t see anything in the Mozilla policy that prohibited the creation of new SHA-1 CAs as long as they were not intended to be used to issue SSL certificates. If we misinterpreted your intent, we apologize, but based on your notes there is some "acknowledged" ambiguity which you appear to be addressing.
Why did we use SHA-1?
- We have several customers using our retail PersonalSign 1, 2, and 3 offering that continue to need SHA-1 S/MIME and/or client certificates including US FDA S/MIME, Belgian government and the Peru government. Not directly related is the need for SHA-1 Code Signing to support those applications that need to be used on older operating systems.
Why did we not technically constrain these CAs?
- Adding EKU to CAs can have unintended consequences, especially in older applications. Since we don't know all the applications that are using the email/client auth certificates it's risk we didn't want to take. Also, there is a minor Thunderbird email issue with using EKUs in CAs: https://bugzilla.mozilla.org/show_bug.cgi?id=1225818
I hope this helps.
Doug
GlobalSign generated some SHA-1 CAs earlier this year as part of normal CA lifecycle management. These CAs were generated to support S/MIME and client authentication products and we don’t intent to use them for SSL certificate issuance. These CAs are not technically constrained and they were disclosed to Mozilla in March 2016, shortly after they were created.
Since these CAs will not be used to issue SSL certificates we didn’t believe that they fall under the BRs, and we didn’t see anything in the Mozilla policy that prohibited the creation of new SHA-1 CAs as long as they were not intended to be used to issue SSL certificates. If we misinterpreted your intent, we apologize, but based on your notes there is some "acknowledged" ambiguity which you appear to be addressing.
Why did we use SHA-1?
- We have several customers using our retail PersonalSign 1, 2, and 3 offering that continue to need SHA-1 S/MIME and/or client certificates including US FDA S/MIME, Belgian government and the Peru government. Not directly related is the need for SHA-1 Code Signing to support those applications that need to be used on older operating systems.
Why did we not technically constrain these CAs?
- Adding EKU to CAs can have unintended consequences, especially in older applications. Since we don't know all the applications that are using the email/client auth certificates it's risk we didn't want to take. Also, there is a minor Thunderbird email issue with using EKUs in CAs: https://bugzilla.mozilla.org/show_bug.cgi?id=1225818
I hope this helps.
Doug
Sent: Monday, November 7, 2016 10:46 AM
To: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Implementing a SHA-1 ban via Mozilla policy
To: Doug Beattie <doug.b...@globalsign.com>; mozilla-dev-s...@lists.mozilla.org
Subject: Re: Implementing a SHA-1 ban via Mozilla policy
On 07/11/16 15:34, Doug Beattie wrote:
> I'd prefer a requirement for long serial numbers over a total ban on
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications don't
> have issues with that).
> SHA-1 Sub CAs. The BRs state 112 bits of entropy, so I'd recommend
> using that for non BR certificates (assuming client applications don't
> have issues with that).
Gervase Markham
Nov 8, 2016, 10:46:18 AM11/8/16
to Doug Beattie
On 08/11/16 13:44, Doug Beattie wrote:
> GlobalSign generated some SHA-1 CAs earlier this year as part of
> normal CA lifecycle management.
Hi Doug,
> GlobalSign generated some SHA-1 CAs earlier this year as part of
> normal CA lifecycle management.
This is helpful information - can you post it to the bug?
https://bugzilla.mozilla.org/show_bug.cgi?id=1315018
> Why did we not technically constrain these CAs? - Adding EKU to CAs
> can have unintended consequences, especially in older applications.
> Since we don't know all the applications that are using the
> email/client auth certificates it's risk we didn't want to take.
component of the new SHA-1 policy - see other thread.
Gerv
Andrew Ayer
Nov 8, 2016, 12:36:14 PM11/8/16
to Gervase Markham, Nick Lamb, mozilla-dev-s...@lists.mozilla.org
On Tue, 8 Nov 2016 11:17:29 +0000
Gervase Markham <ge...@mozilla.org> wrote:
> On 07/11/16 17:09, Nick Lamb wrote:
Gervase Markham <ge...@mozilla.org> wrote:
> On 07/11/16 17:09, Nick Lamb wrote:
> > On Monday, 7 November 2016 13:53:31 UTC, Gervase Markham wrote:
> >> You mean EKU-constrained (e.g. to email, or OCSP only)?
> >
> > I was thinking also of a pathlen constraint.
>
> >> You mean EKU-constrained (e.g. to email, or OCSP only)?
> >
> > I was thinking also of a pathlen constraint.
>
> Aha. So what would this look like? Something like this?
>
>
> CAs may only issue SHA-1 end-entity certs chaining up to roots in
> Mozilla's program if the following is true:
>
> * The certificate is not within the scope of the Baseline
> Requirements;
> * The issuing CA and the certificate itself both have a critical EKU
> extension with a single key purpose, which is not id-kp-serverAuth or
> anyExtendedKeyUsage;
> * The issuing CA has a pathlen:0 constraint
> * The certificate has at least 64 bits of entropy from a CSPRNG in the
> serial number
>
>
> I guess it doesn't cover signing other things like OCSP responses.
> Perhaps we could add:
>
>
> * CAs may sign other data (such as OCSP responses) with SHA-1 for
> compatibility reasons, as long as all of the signed data is static, or
> defined by the CA and not by a customer.
>
>
> Is this heading in the right direction? Too weak, too strong?
Hi Gerv,
>
>
> CAs may only issue SHA-1 end-entity certs chaining up to roots in
> Mozilla's program if the following is true:
>
> * The certificate is not within the scope of the Baseline
> Requirements;
> * The issuing CA and the certificate itself both have a critical EKU
> extension with a single key purpose, which is not id-kp-serverAuth or
> anyExtendedKeyUsage;
> * The issuing CA has a pathlen:0 constraint
> * The certificate has at least 64 bits of entropy from a CSPRNG in the
> serial number
>
>
> I guess it doesn't cover signing other things like OCSP responses.
> Perhaps we could add:
>
>
> * CAs may sign other data (such as OCSP responses) with SHA-1 for
> compatibility reasons, as long as all of the signed data is static, or
> defined by the CA and not by a customer.
>
>
> Is this heading in the right direction? Too weak, too strong?
Thanks for kicking this off. I think this is heading in the right
direction.
The rule about other data could be clarified. We want to make sure
there is no room for misinterpretation. Here's some suggested text:
Keys used by CAs chaining up to a root in Mozilla's program may only
sign non-certificate data (e.g. OCSP responses, CRLs) with SHA-1 if all
the following is true:
* Doing so is necessary for a documented compatibility reason;
* All of the signed data is static, or defined by the CA and not another party
Regards,
Andrew
Gervase Markham
Nov 9, 2016, 5:08:45 AM11/9/16
to Nick Lamb
On 08/11/16 11:17, Gervase Markham wrote:
> Aha. So what would this look like? Something like this?
And we would need phase-in periods for both the requirements on
> Aha. So what would this look like? Something like this?
intermediate certs, and the requirements on end-entity certs. And the
former may have to be a bit longer than the latter, as cutting new
intermediates, testing compatibility and switching to them takes time.
Gerv
Gervase Markham
Nov 28, 2016, 9:57:36 AM11/28/16
to mozilla-dev-s...@lists.mozilla.org
I took this discussion to the CAB Forum public list, where a couple of
significant things happened.
Firstly, Erwann pointed out that (in clients other than Firefox, which
doesn't implement the necessary exceptions to the normal rules), you can
use a "self-issued" cert to leverage a SHA-1 collision into a clone of
the issuing intermediate for which you hold the private key :-|
Secondly, there was significant pushback on Nick Lamb's proposal of
requiring SHA-1-issuing intermediates to have a single EKU, because EKUs
often need to come in groups - e.g. id-kp-emailProtection and
id-kp-clientAuth. I can certainly see the use case for that.
The first of these makes EKU constraints on intermediates even more of a
good idea, and the second of these makes them rather difficult :-|
At the moment, the new draft just says "no id-kp-serverAuth", but leaves
email out in the cold somewhat. It seems like it might be tricky to
write a sane set of EKU rules which both provided meaningful protection
and didn't get in the way of sensible use cases.
Of course, it could be that perhaps the email ecosystem also needs a
SHA-1 ban :-). I've asked CAs to tell me why I shouldn't just do that,
so we'll see what they say.
Gerv
significant things happened.
Firstly, Erwann pointed out that (in clients other than Firefox, which
doesn't implement the necessary exceptions to the normal rules), you can
use a "self-issued" cert to leverage a SHA-1 collision into a clone of
the issuing intermediate for which you hold the private key :-|
Secondly, there was significant pushback on Nick Lamb's proposal of
requiring SHA-1-issuing intermediates to have a single EKU, because EKUs
often need to come in groups - e.g. id-kp-emailProtection and
id-kp-clientAuth. I can certainly see the use case for that.
The first of these makes EKU constraints on intermediates even more of a
good idea, and the second of these makes them rather difficult :-|
At the moment, the new draft just says "no id-kp-serverAuth", but leaves
email out in the cold somewhat. It seems like it might be tricky to
write a sane set of EKU rules which both provided meaningful protection
and didn't get in the way of sensible use cases.
Of course, it could be that perhaps the email ecosystem also needs a
SHA-1 ban :-). I've asked CAs to tell me why I shouldn't just do that,
so we'll see what they say.
Gerv
0 new messages