Telia: Qualified BR Audit Statement

ASSIGNED
Assigned to

Status

task
ASSIGNED
Last month
15 days ago

People

(Reporter: kwilson, Assigned: pekka.lahtiharju)

Tracking

trunk

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [ca-compliance] - Next Update - 1-October 2019)

Telia received a Qualified BR audit statement:
https://support.trust.telia.com/download/CA/Telia-WebTrust-For-CA-SSL-Baseline-With-Network-Security-Report-2019.pdf

The purpose of this bug is to track closure of all of the qualifications, and for the CA to provide incident reports for them.

For each qualification that was already reported in Bugzilla, it is fine to just reference that Bugzilla Bug number, and finish resolving in that bug.

Status: NEW → ASSIGNED

Telia's Incident report of BR findings. Note! Telia has provided the most important information related to all of the qualifications in its public posting since June 2019 here: https://support.trust.telia.com/download/CA/Telia-Public-Response-To-Audit-2019.pdf. Most issues are old ones so that report and fix was done a year ago. Below is the full incident report for all listed DEVIATIONs like instructed by Mozilla:

DEVIATION 1: The Key Usage extension in the root CA certificates of TeliaSonera Root CA v1 and Sonera Class 2 CA is not marked critical and TeliaSonera Root CA v1 certificate’s subject information does not include subject:countryName.

This qualification was old one and discussed already a year ago here: https://bugzilla.mozilla.org/show_bug.cgi?id=1475115. However, in that discussion there wasn't requirement to add an incident report so it is below.

1.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.
Telia became aware of the problem when Telia applied EV permission for its roots in March 2017. Mozilla commented that Telia Roots have these errors (check https://bugzilla.mozilla.org/show_bug.cgi?id=1322668). At that point it wasn't a problem. Then in June 2018 Telia got BR audit reports and this issue was mentioned as qualification. After that Telia started a process to update its roots. Issue was again in this BR audit report received in June 2019.

1.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.
In April 2001 Telia created its first root CA and the other was created In October 2007. At that time there weren’t any clear requirements for CA certificates. The first CA Browser Forum BR document appeared in 2011 (effective 2012).
In June 2018 Auditor report listed this root CA issue as qualification
In November 2018 Telia created new root CA that is fully compliant. Auditors witnessed the creation.
In January 2019 PIT Audit report proved that new root CA is compliant.
June 2019: Telia wanted to wait for the next full audit results to June 2019 so that Mozilla and others could see that Telia has improved all its processes so that browser vendors could approve the upcoming root application without concerns.
Next step in 3Q2019 is to apply the new root to be trusted in all browsers.

1.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.
All new CA certificates have been compliant and only CA root certificates created before year 2012 had these problems. Telia needs Mozilla to continue trusting the old roots until the new root is widely accepted.

1.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.
1.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=3819
https://crt.sh/?id=989582

1.6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
At the time in 2001 and 2007 when these were created there weren’t any clear requirements for CA certificates. The first CA Browser Forum BR document appeared in 2011 (effective 2012). Telia didn't understand that BR root rules may affect also older root certificates because BR Overview chapter states: "these Requirements apply only to relevant events that occur on or after the Effective Date." None of the BR Effective dates are dated before 2012. Trust anchors in browsers have special treatment which make possible to use exceptional trust rules (like accept otherwise unacceptable SHA1).

1.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.
Telia has always followed latest BR rules. New fully compliant Telia root has been created but it is not yet included in browsers. The new root applications will be provided to browser vendors in Q3/2019. Telia can't stop using its older roots before new root is widely accepted by all browsers.

DEVIATION 2: The subscriber certificates issued by Telia Domain Validation SSL CA v1 contained wrong policy identifier until 25 June 2018.
Because this problem overlapped two audit periods the same qualification is mentioned in 2018 and 2019 audit reports. This incident report was provided a year ago in thread https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/34gZxUX3EBc. Fix was verified by PIT audit Oct 2018.

DEVIATION 3: Many subscriber certificates with email address as an optional subject attribute were not adequately verified
Because this problem overlapped two audit periods the same qualification is mentioned in 2018 and 2019 audit reports. This incident report was provided a year ago in thread https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/5K7LZfIveNQ. Fix was verified by PIT audit Oct 2018.

DEVIATION 4: 13 SSL certificates with inappropriate L value were issued to three different organizations by TeliaSonera Server CA v2. According to the CPS, locality name should be a city name, but in these cases locality name consisted of a country name or organization’s postal office name.
This was already reported and discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1551372. There one additional Telia improvement is planned to be done in 3Q2019.

DEVIATION 5: Three weekly security configuration reviews were not properly implemented before Oct 2018. In addition one new weekly review failed for several months.
Because this problem overlapped two audit periods the same qualification is mentioned in 2018 and 2019 audit reports. Mostly this was already reported and discussed here: https://bugzilla.mozilla.org/show_bug.cgi?id=1475115. Fix was verified by PIT audit Oct 2018.

The failed weekly review was a new discovery and its incident report is below.

5.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.
Telia became aware of the problem when Auditors reported this related to 2019 BR audit.

5.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.
November 2018: Secondary Firewall weekly review was implemented, but its change reports were mostly lost until June 2019
May 2019: Auditors informed that this particular weekly review doesn't work properly. All other reviews were functional.
June 2019: Secondary Firewall weekly review was fixed

5.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.
This was only a minor reviewing problem and it didn't affect issuing systems or cause threat to CA. There were multiple compensative controls at all times.

5.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.
None.

5.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.
None.

5.6. Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Telia has mostly automated change review of relevant security configurations. However, there weren't previously checks to verify that all this automation is functional. A reviewing system that caused very few messages (like secondary firewall) was potentially risky to be undetected if failing. Unfortunately failure happened to our secondary firewall monitor so that its failure wasn't detected.

5.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.
The planned change in 3Q/2019 is to monitor with a new monthly human review the functionality of all implemented reviewing systems.

Thank you for the incident report. It appears that one remediation action remains to be completed:

planned change in 3Q/2019 is to monitor with a new monthly human review the functionality of all implemented reviewing systems.

Please update this bug when that change has been put into place.

Whiteboard: [ca-compliance] Qualified BR Audit → [ca-compliance] - Next Update - 1-October 2019
You need to log in before you can comment on or make changes to this bug.