1518560 - Asseco DS / Certum: 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]

Wojciech: Please provide an incident report.

Comment 2

[Wojciech Trapczyński]

I will provide it soon.

Comment 3

[Ryan Sleevi]

It's been nearly a week now. As per https://wiki.mozilla.org/CA/Responding_To_An_Incident#Keeping_Us_Informed , providing weekly updates is expected unless agreed otherwise.

Comment 4

[Wojciech Trapczyński]

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 in bug 1518560.

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.

Feb 28, 2017 00:00 GMT – Mozilla Root Store Policy v2.4 was released.
Nov 28, 2018 08:04 GMT – The certificate that include P-521 keys was issued.
Jan 8, 2019 18:48 GMT - The Bugzilla bug 1518560 was created.
Jan 9, 2019 05:30 GMT – We blocked issuing certificates that include P-521 keys.

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 have stopped issuing certificates that include P-521 keys.

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 is one certificate.

5. The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.

https://crt.sh/?id=983011607

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

We did not change allowed public key algorithms after Mozilla Root Store Policy change to 2.4. The team responsible for Mozilla Root Store Policy inspection did not report this change to product manager.

7. List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

In past year (in August) we extend our team (including me and Aleksandra) responsible for reviewing browsers root store policies and CABF documents. That team gathers and reports all changes to product manager. Of course, all information and changes are documented. We think that this is a sufficient step to avoid such non-compliance in the future.

Comment 5

[Ryan Sleevi]

In the spirit of both transparency and having a better understanding about the mitigations in place, can you please detail a bit more about what your processes and procedures are to ensure that there is compliance with the Baseline Requirements and Mozilla Policy going forward. Understanding what the processes and procedures are to both ensure timely awareness of these changes and compliance is very valuable.

For example, a process could exist for the team to review all changes, but relies on the team being first aware that there were changes. If there's no process for monitoring for changes, only reviewing them when detected, then it's still possible for issues like this to repeat. That's why understanding what the process flow looks like is important to preventing issues like this :)

Comment 6

[Wojciech Trapczyński]

In a nutshell, each member of the team is obligated to monitor and collect the changes related to the CA/Browser Forum, browsers and other software vendors policies. The team meets regularly every two weeks. On our meetings we analyze all changes and other topics related to Web PKI. If something requiring modification in our system, we inform about it the appropriate product manager. Then, in cooperation with the appropriate project manager we create the plan to implement the change in timely manner. After the change is implemented, we review it for compliance and the issue is closed.

The additional action we are going to take in connection with this incident is to review browsers policies once again in order to draw up a list of the technical differences between them. The task of creating and then regular updating this list should help us to avoid such non-compliance in the future.

Comment 7

[Ryan Sleevi]

Thanks for clarifying! Moving this to Wayne to review and decide.

Comment 8

[Wayne Thayer]

Wojciech: Please update this bug when the following action has been completed: review browsers policies once again in order to draw up a list of the technical differences between them. I have added a note expecting this update within 2 weeks - if that is not enough time, please tell me when to expect it to be completed.

Comment 9

[Wojciech Trapczyński]

Wayne: We have created a documentation in order to compare technical requirements coming from browsers policies, including CA/Browser Forum BR. We considered different technical things i.a. keys lengths, algorithms, CRL and OCSP services requirements. We are going to update this documentation if necessary.

We are also reviewed our operational practices and we did not find any non-conformity with reference to the policies differences.