Re: Implementing a SHA-1 ban via Mozilla policy

[Gervase Markham]

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

Re: Implementing a SHA-1 ban via Mozilla policy

[Gervase Markham]

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

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

Re: Implementing a SHA-1 ban via Mozilla policy

[Andrew Ayer]

On Tue, 8 Nov 2016 11:17:29 +
Gervase Markham  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. 
> 
> 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,

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

Re: Implementing a SHA-1 ban via Mozilla policy

[Gervase Markham]

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,

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.

You may want to do some testing, then, as this is certainly a potential
component of the new SHA-1 policy - see other thread.

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

RE: Implementing a SHA-1 ban via Mozilla policy

[Doug Beattie]

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

-Original Message-
From: Gervase Markham [mailto:g...@mozilla.org] 
Sent: Monday, November 7, 2016 10:46 AM
To: Doug Beattie <doug.beat...@globalsign.com>; 
mozilla-dev-security-pol...@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).

Can you list some of the uses you'd still like to use SHA-1 in publicly-trusted 
hierarchies for?

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

Re: Implementing a SHA-1 ban via Mozilla policy

[Gervase Markham]

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?


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

Re: Implementing a SHA-1 ban via Mozilla policy

[Jakob Bohm]

On 07/11/2016 15:00, Gervase Markham 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
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.



He wasn't claiming that.


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: Implementing a SHA-1 ban via Mozilla policy

[Gervase Markham]

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
publicly-trusted hierarchies for?

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

Re: Implementing a SHA-1 ban via Mozilla policy

[Gervase Markham]

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

Yes, they do. They won't as of January 2017.

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

Gerv


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

Re: Implementing a SHA-1 ban via Mozilla policy

[Gervase Markham]

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)?

> 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

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

Re: Implementing a SHA-1 ban via Mozilla policy

[Phillip Hallam-Baker]

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

Implementing a SHA-1 ban via Mozilla policy

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