1518555 - DigiCert: Use of forbidden subjectPublicKeyInfo algorithm

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ryan Sleevi]

The following problems have been found in certificates issued by your CA, and reported in the mozilla.dev.security.policy forum. Direct links to those discussions are provided for your convenience.

Please provide an incident report, as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

The problems reported for your CA in the mozilla.dev.security.policy forum are as follows:
P-521 in certificates: https://groups.google.com/d/msg/mozilla.dev.security.policy/4gs5pKqTeK8/9XyMgrW8BgAJ

Comment 1

[Ryan Sleevi]

Jeremy: Please provide an incident report on behalf of DigiCert

Comment 2

[Jeremy Rowley]

These are the three certs issued after the effective date of 2.4:

https://crt.sh/?id=146656935, 2017-05-31, 2019-06-05, DigiCert ECC Secure Server CA
https://crt.sh/?id=307593001, 2017-06-01, 2019-01-15, DigiCert SHA2 Secure Server CA
https://crt.sh/?id=308273560, 2017-06-27, 2020-07-01, DigiCert SHA2 Secure Server CA

Looking into why they were issued after Feb 28, 2017.

Comment 3

[Jeremy Rowley]

Oh boy. This will be a good one.

Steps to reproduce:

1. How your CA first became aware of the problem (e.g. via a problem report submitted to your Problem Reporting Mechanism, a discussion in mozilla.dev.security.policy, a Bugzilla bug, or internal self-audit), and the time and date.

• Reported by Ryan filing this bug on Jan 8, 2019.

2. A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

• Reported by Ryan filing this bug on Jan 8, 2019.
• Looked at the history of the change on Jan 8, 2019.
• We blocked all issuance of the certificates in August.
• Not sure why we didn't report and revoke the one issued after Jun 23 (the effective date of 2.5). We should have blocked all three before that.

3. Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

We blocked issuance early August 2017. We didn't notice the policy changed from 521 until 2.5 was released. We added the change to the next sprint.

4. A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.

There are three certificates issued after policy 2.4 was released. The dates range from may 2017 to June 2017. The problem is the exact same - the certs use P-521.

5. The complete certificate data for the problematic certificates.
   https://crt.sh/?id=146656935, 2017-05-31, 2019-06-05, DigiCert ECC Secure Server CA
   https://crt.sh/?id=307593001, 2017-06-01, 2019-01-15, DigiCert SHA2 Secure Server CA
   https://crt.sh/?id=308273560, 2017-06-27, 2020-07-01, DigiCert SHA2 Secure Server CA

6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.

This is the embarrassing part. Back then we didn't have any one specifically assigned to watch revisions to the Mozilla list. Ben and I monitored and participated in industry standards, but we really didn't have someone formally reviewing our processes to ensure changes. We actually didn't know this was a change from 2.4 until this post and thought the change was in 2.5. Now, we have a team (including me) in place to monitor Mozilla policy events and CAB Forum changes. These people are dedicated to compliance and ensuring that the product is kosher with any root store changes.

7. List of steps CA is taking to resolve the situation and ensure it will not be repeated.

We have a department focused specifically on compliance now rather than just having me or Ben report it. That team reports all changes needed to the product team directly and is part of the product org. That org change happened Dec 2017.

Comment 4

[Jeremy Rowley]

The fix was pretty easy - we patched the CA to prevent p-521 certs for any publicly trusted certs

Comment 5

[Ryan Sleevi]

Jeremy: Regarding this remark:

Not sure why we didn't report and revoke the one issued after Jun 23 (the effective date of 2.5). We should have blocked all three before that.

Could you help understand what processes or controls have changed to ensure timely retroactive review and revocation?

Comment 6

[Jeremy Rowley]

Revocation in this one is interesting. We are revoking, of course, but the debate is the required timeline. Technically, these are compliant with the CAB Forum requirements, just not the Mozilla policy. This means the revocation timeline from 4.9.1 of the BRs doesn't apply as the policy states "CAs MUST revoke Certificates that they have issued upon the occurrence of any event listed in the appropriate subsection of section 4.9.1 of the Baseline Requirements, according to the timeline defined therein." Is the expectation from Mozilla that Mozilla CA policy violations will be treated as BR violations?

As far as controls, we changed a lot of process to ensure strict governance with the policies. However, the current processes only ensure that future changes are captured and made. We're still working on ensuring that any past changes to the guidelines were covered.

For future changes, we have Tim and Dean who are collecting the changes, timelines, and expectations related to browser and CAB Forum policies. The product and compliance teams meet with them weekly to ensure we know the coming changes and impact. When a new ballot is finally proposed, the compliance team breaks the requirements down to steps required for implementation which are compared to the product team's interpretation of how the systems actually work. From there we build out the plan to implement the change in the next sprint. We dedicate a portion of each sprint to compliance work (whether changes in the BRs, better reporting, or increased controls) to ensure compliance remains an ongoing concern.

Once the product team implements the change, the compliance team reviews for compliance and signs off. This way, we have three different teams of people watching the guidelines from three different perspectives, which means changes are captured (hopefully) before they impact the CA.

For past changes, we're working on a complete internal review of all current requirements that we can audit on. We regularly audit ourselves for compliance, but generally only against the BRs. Given that Mozilla, Microsoft, Adobe, and Apple all have slightly different root policies and requirements, we are building a master checklist to ensure all policies are met, root or otherwise.

From the technical perspective, we implemented zlint on our backend a while ago. We have (or will shortly) be contributing to that project to help remove some of the false positives. Going forward, I'd like us to contribute to the code changes to capture new changes in requirements, including changes in Mozilla policy.

Comment 7

[Ryan Sleevi]

(In reply to Jeremy Rowley from comment #6)

Revocation in this one is interesting. We are revoking, of course, but the debate is the required timeline. Technically, these are compliant with the CAB Forum requirements, just not the Mozilla policy. This means the revocation timeline from 4.9.1 of the BRs doesn't apply as the policy states "CAs MUST revoke Certificates that they have issued upon the occurrence of any event listed in the appropriate subsection of section 4.9.1 of the Baseline Requirements, according to the timeline defined therein." Is the expectation from Mozilla that Mozilla CA policy violations will be treated as BR violations?

Flagging this question for Wayne to answer on behalf of Mozilla. I think you raise an interesting point - which is the reforms to 4.9.1.1 by Ballot SC6 removed the requirement on revocation regarding "The technical content or format" (4.9.1.1 p15 in BR 1.6.0), and thus create a situation where it's ambiguous as to whether a CA is expected to revoke a certificate for violating Mozilla policy.

There are ways to resolve this; such as requiring, for example, positive affirmation in the CA's CP/CPS that they'll adhere to a given Root Program's policies. Alternatively, Mozilla could explicitly clarify this in policy, that they may request and/or expect revocation for any reason (or no reason).

Thanks for sharing the level of detail regarding the steps being taken to monitor for compliance changes going forward. I think that sounds like a very robust plan.

Comment 8

[Wayne Thayer]

(In reply to Ryan Sleevi from comment #7)

Flagging this question for Wayne to answer on behalf of Mozilla. I think you raise an interesting point - which is the reforms to 4.9.1.1 by Ballot SC6 removed the requirement on revocation regarding "The technical content or format" (4.9.1.1 p15 in BR 1.6.0), and thus create a situation where it's ambiguous as to whether a CA is expected to revoke a certificate for violating Mozilla policy.

As I stated on m.d.s.p., my interpretation is that Mozilla policy doesn't set any revocation requirements for these certificates.

There are ways to resolve this; such as requiring, for example, positive affirmation in the CA's CP/CPS that they'll adhere to a given Root Program's policies. Alternatively, Mozilla could explicitly clarify this in policy, that they may request and/or expect revocation for any reason (or no reason).

I think this would need to be a change to section 6 of the Mozilla policy.

Comment 9

[Ryan Sleevi]

Thanks Wayne; for future context, that message is https://groups.google.com/d/msg/mozilla.dev.security.policy/4gs5pKqTeK8/_eJvekr1BgAJ

I think Comment #6 gives a good overview of the remediation steps being taken, so it sounds like this can be resolved.