On 06/10/2016 07:46, Peter Bowen wrote:
On Wed, Oct 5, 2016 at 10:02 PM, Michael Ströder <mich...@stroeder.com> wrote:
Dean Coclin wrote:
First Data's customers don't use browsers so Firefox can disable SHA-1 tomorrow
and not affect them.
So why to have your CA certificate trusted in Firefox's cert DB?
First Data has asked for a reasonable extension which doesn't affect browsers.
If it does not "affect browsers" why do you need an extension?
The impact on browsers could be broken down into two parts:
1) An expectation they would work with the resulting certificate
2) The risk that someone uses this to create hash collision allowing
them to create a different certificate that is used with browsers.
I think Dean's point is that #1 is not true here. Presumably these
certificates could even be blacklisted by browsers. However #2 is
where the risk lies.
As we have seen with previous requests, the core challenge here is
that many device vendors have chosen to embed a CA trust list in their
devices that is based on the list used by web browsers. From my own
experience, this is something that continues today with consumer
electronics. They take a point in time snapshot of the Mozilla list,
embed it in the device, and expect anyone interacting with the device
to get a certificate from one of those CAs. This inherently sets up a
conflict -- these same device vendors frequently don't release updates
for the devices, so the assumption is that the CAs they choose (which
is usually a unilateral decision) will continue to issue certs
compatible with the device for the lifetime of the device. With the
transition to SHA-256 or better, this has become a challenge.
I think we can all look back with 20/20 hindsight and say that device
vendors should not use the same roots as browsers and that maybe CAs
should have created "SHA-1 forever" roots for devices that never plan
to update, but that is great hindsight. We have the problem now, so we
need an answer.
Which is why I have repeatedly suggested that maybe the rules should be
changed to promote/demote some of the historic SHA-1 root certs into
"SHA-1 forever" roots that can service older devices and browsers, even
for regular websites concerned about allowing visits from older devices
while transitioning their websites to HTTPS-only.
This should of cause be supplemented by stronger serial number
randomness rules such as at least 100 bits of unpredictable CA-supplied
entropy in the serial number, mandatory numeric high entropy serial
number in the distinguished name, 1 year end certificates issued by 15
month intermediary certs that change quarterly.
The justified comment by someone else that they shouldn't have made
devices then refused to update them is true, but unlike "rent-a-payment-
terminal" financial services (who are big enough to go through
individual applications for CAB/F exceptions), most unupdatable devices
were sold in large numbers to end users in the form of phones, PDAs etc.
Ideally, there should also be a way for TLS servers (such as web
servers) to detect if the TLS client suffers from historic public key
limitations such as SHA-1 only, low maximum DH key size etc., thus
allowing the TLS server to use stronger certificates and FS keys for
new clients.
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
