1262993 - The Walt Disney Company Issuing CA issuing certificates using sha1

Status: RESOLVED FIXED

(NSS :: CA Certificates Code, task)

Description

[Dana Keeler (she/her) (use needinfo) [:keeler] (on leave)]

The Walt Disney Company Issuing CA (sub-CA of The Walt Disney Company Root CA, sub-CA of Entrust.net Certification Authority (2048)) is issuing certificates using sha1:

https://crt.sh/?id=13684710&opt=cablint
https://crt.sh/?id=14890944&opt=cablint
https://crt.sh/?id=15959585&opt=cablint

Comment 1

[Ryan Sleevi]

Bruce, could you comment?

Comment 2

[Bruce Morton]

The CA certificate has been revoked as of 22 December 2015.

Comment 3

[Kathleen Wilson]

Bruce, 

I am not finding a Bugzilla Bug about this intermediate certificate revocation.

Eventually we will be using the CA Community in Salesforce to report revocations of intermediate certificates so they can be added to OneCRL, but we are still using Bugzilla to report these.

Please file a Bugzilla Bug against the "CA Certificates" component of the "NSS" product.
https://bugzilla.mozilla.org/enter_bug.cgi?product=NSS&component=CA%20Certificates
For each revoked intermediate cert, please provide the following information in the bug.
+ the revoked certificate itself (e.g. PEM)
+ the rfc5280 revocation reason code
+ Link to the OCSP response for that serial number
+ Link to the CRL that contains that serial number

Thanks,
Kathleen

Comment 4

[Bruce Morton]

Kathleen,

The following bug has been added, https://bugzilla.mozilla.org/show_bug.cgi?id=1263127.

Thanks, Bruce.

Comment 5

[Kathleen Wilson]

Thanks!

Comment 6

[Nick Lamb (tialaramex)]

Kathleen, was Entrust already under an obligation in December 2015 to report such revocations to Mozilla? I'm trying to understand if:

* Mozilla was told by another means but it didn't get filed in Bugzilla so nothing was done
* Entrust didn't realise they were supposed to actually tell anyone beyond updating their CRL
* Mozilla did not (in December 2015) have any policy in place requiring Entrust to report

Somehow we ended up with the situation where as I understand it Disney certificates like this:
https://crt.sh/?id=13184432

... were not only treated as trusted by older Firefox versions (which is unfortunate but not unexpected since they pre-date the revocation) but even by brand new Firefox releases three months later even though such certificates are blatantly non-compliant and the trust root, Entrust, had in fact revoked this subCA the day that was issued.

Comment 7

[Kathleen Wilson]

(In reply to allizom40 from comment #6)

I think the third option is probably the closest. OneCRL is relatively new, so we don't yet have a requirement in Mozilla's CA Certificate Policy saying that CAs must notify us of revoked intermediate certificates. We have previously communicated to CAs about OneCRL, and that revoked intermediate certs should be added to it, but it is not yet a *requirement*. In the recent CA Communication (https://wiki.mozilla.org/CA:Communications#March_2016) we stated that CAs must enter their revoked intermediate cert data into the CA Community in Salesforce by June 30.

It's very disappointing that a CA would behave in this manner -- revoke a subCA that is still issuing SHA-1 certs, but not tell us to add that subCA's issuing cert to OneCRL. But it is not technically yet against Mozilla's policy.

Comment 8

[Nick Lamb (tialaramex)]

I see. Earlier Mozilla CA Certificate Policies do require CAs to publicly disclose all subCAs which are technically capable of issuing trusted certificates in their hierarchy.

Sure enough, Entrust's response to Mozilla's 2014 CA Communication includes a URL for third party subordinate CAs, and the Internet Archive shows that the contents of this URL back in 2014 included mention of Disney along with Experian and several other entities. I note in passing that URL today still lists Experian, but provides a pretty old audit which doesn't seem to cover Experian's actual issuance policies for end entity certificates. It is not clear to me how Mozilla's users can get any comfort from such an audit that doesn't cover this critical aspect, but perhaps it's compliant anyway?

Anyway, back in 2014 Mozilla was told that the Disney subCA existed, and provided with a certificate for it, then that certificate was revoked in December 2015 but Mozilla didn't notice. I understand why Firefox doesn't hard-fail OCSP for end-entities but it seems to me that checks on subordinates by the Mozilla organisation aren't subject to the same considerations. Mozilla certainly _can_ afford the bandwidth of downloading a few dozen CRLs from the programme's roots (mostly non-issuing roots) periodically and shoving any unexpected revocations into, say, Bugzilla to be eyeballed by humans for possible OneCRL treatment. Unlike a policy change, this could take effect immediately.

Comment 9

[Kathleen Wilson]

This issuing CA was added to OneCRL per Bug #1263127.