1397830 - EDICOM: Signing SHA-1 OCSP responses with unconstrained certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Andrew Ayer]

Attachment: OCSP Response

I just sent the following to EDICOM's problem reporting address ([e-mail]).  Note that in the April 2017 CA Communication, EDICOM stated that they were no longer using SHA-1 to sign OCSP responses: https://ccadb-public.secure.force.com/mozillacommunications/CACommRespWithTextAndTotalsReport?CommunicationId=a05o000003WrzBC&QuestionId=Q00020&QuestionIdForText=Q00026

Your OCSP responder at http://ocsp.acedicom.edicomgroup.com/acedicom01
signs OCSP responses with SHA-1 using a certificate that is trusted by
Mozilla for server authentication.  This is a violation of section
5.1.1 of Mozilla's Root Store Policy Version 2.5, which states:

"CAs MAY sign SHA-1 hashes over OCSP responses only if the
signing certificate contains an EKU extension which contains only the
id-kp-ocspSigning EKU. ... CAs MUST NOT sign SHA-1 hashes over other
data, including CT pre-certificates."

Furthermore, since the response reflects an attacker-supplied nonce of
arbitrary length, your OCSP responder could allow attackers to forge
SHA-1 SSL certificates using a chosen-prefix attack as described here:
https://www.mail-archive.com/[e-mail]/msg02999.html

I have attached a signed OCSP response as evidence.

A copy of this report will be sent to Mozilla.

Comment 1

[Kathleen Wilson]

Raúl, Please reply in this bug very promptly to acknowledge that you have been informed of this bug, and provide a timeline for resolving the concern.

Then please provide an incident report in this bug, as described here:
https://wiki.mozilla.org/CA/Responding_To_A_Misissuance#Incident_Report

Comment 2

[Raúl Santisteban]

After several months working on this, we have found technical issues with disabling SHA1 when signing OCSP responses.
EDICOM decision was not to go on supporting previous Certification Authority Root since It was impossible meets all the technical requirements of the program. We will   go on with the process of including the new Root (https://bugzilla.mozilla.org/show_bug.cgi?id=1239329) which meets all the requirements.

So, since we are not issuing new server/client certificates with the old one, we suggest to start the process of removing our "ACEDICOM Root" from the trusted PKI Root.

Kathleen, please help us with this in case we have to submit some kind of request indicating the date Mozilla can remove our CA.

The main question for us is that this doesn't alter actual BUG https://bugzilla.mozilla.org/show_bug.cgi?id=1239329, because It was about including new Root.

Comment 3

[Kathleen Wilson]

(In reply to Raúl Santisteban from comment #2)
> So, since we are not issuing new server/client certificates with the old
> one, we suggest to start the process of removing our "ACEDICOM Root" from
> the trusted PKI Root.

I filed Bug #1400013 to remove the old ACEDICOM root cert.


> The main question for us is that this doesn't alter actual BUG
> https://bugzilla.mozilla.org/show_bug.cgi?id=1239329, because It was about
> including new Root.

The request for inclusion of the new root may still continue via Bug #1239329. However, that request is on hold, awaiting the CA to provide their BR Self Assessment...
https://bugzilla.mozilla.org/show_bug.cgi?id=1239329#c22

Comment 4

[Gervase Markham [:gerv]]

It seems like this bug can be resolved, as the outcome is to remove the root?

Gerv

Comment 5

[Ryan Sleevi]

Kathleen, Wayne: I think the Security Issue flag can be removed?

Comment 6

[Kathleen Wilson]

(In reply to Ryan Sleevi from comment #5)

Kathleen, Wayne: I think the Security Issue flag can be removed?

Agreed. I'll ask someone to fix that.

Comment 7

[Emma Humphries ☕️🎸🧞‍♀️✨ (she/they) [:emceeaich] (Pacific Time) use needinfo]

Making public, per Kathleen.