1605126 - PKIoverheid: Missing intermediate CA certificates in WTBR audit statements Staat der Nederlanden 2017/2018

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Jorik van 't Hof]

Attachment: management_assertion_WTBR_Logius_2018_revised.pdf

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.

During a review of audit records in CCADB on mid November, Logius noticed (due to the ALV warning) that several fingerprint were missing for our Domain CAs (level 2 CAs) which act as a high-level measure to split several certificate types. The split only happens on a policy OID level and not by use of EKUs. Because of this design choice, this means that the CAs in question are technically capable of issuing all types of certificates and as such must be audited against the relevant Webtrust or ETSI standards as required by Mozilla. For several domain CAs the audit in question (WTBR) did take place but wasn’t properly listed in the management assertion of Logius over the past years.

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.

(all dates are in the format dd/mm/yyyy)

01-03-2017: Logius issues its first management assertion in which SHA256 fingerprints are listed, as required by Mozilla. In this year, the WTBR management assertion doesn’t list CAs (by name or fingerprint) that should have been included for WTBR (as a result of Mozilla policy 2.4)

25-11-2019 Logius noticed while going through CCADB records that several of her Domain CAs were flagged by the ALV check. This triggered an action in which Logius, in cooperation with KPMG, looked into the root cause and to see if this is something that can be remedied.

13-12-2019 Based on earlier statements from Kathleen Wilson Logius has issued new management assertions and asked KPMG if they could issue a revised opinion over the period concerned.

19-12-2019 creation of this bug. Our intent is to get the facts as clear and as concise as possible and to offer the full picture including remediation actions (see below)

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.

N/A.

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.

Only CAs in scope. It concerns the following certificates:
•https://crt.sh/?id=18068196 (Staat der Nederlanden Organisatie Persoon CA - G3)
•https://crt.sh/?id=18068175 (Staat der Nederlanden Autonome Apparaten CA - G3)
•https://crt.sh/?id=18068179 (Staat der Nederlanden Burger CA - G3)
•https://crt.sh/?id=12721860 (Staat der Nederlanden Autonome Apparaten CA - G2)
•https://crt.sh/?id=12625428 (Staat der Nederlanden Burger CA - G3)

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.

See answer 4

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

The same flaw in the logic used by Logius in other cases (see bug 1586125) seems to apply here. The CAs in question weren’t (and aren't) used to issue end-user certificates and are kept offline and air gapped, and as such deemed to have “technical measures” to prevent issuance of TLS certificates. Nevertheless, the systems are shared between different Domain CAs (including the BR audited ones). This means that the CAs have been properly audited against the WTBR principles, only this didn't show up on the management assertions because of the error in logic. The reason that this hasn't been picked up earlier was partially because of this error in logic thinking, but also because the Root/Domain environement was viewed bij Logius to exist in a technically stable environment and as such, most of the attention, time and effort was put into supervision of the issuing CAs which led to this omission being overseen during several iterations of reviews over the years.

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.

Kathleen has indicated in bug 1586125 that she sees three different solutions to these kinds of issues: Revocation, addition to OneCRL or revised audit statements in which the correct fingerprints are listed. Seeing that the first two options would, in essence, mean the complete rebuilding of the trust hierarchy of PKIoverheid, we prefer to go for the third option. The missing CAs have been audited and as indicated earlier rely on the same housing and processes as the WTBR CAs. We’ve asked KPMG to issue new opinions over newly issued Management Assertions from the Director of Logius for the Webtrust audits from 2017 and 2018. Please find these attached

Regards,

Jorik

Comment 1

[Jorik van 't Hof]

Attachment: management_assertion_WTBR_Logius_2017_revised.pdf

Comment 2

[Jorik van 't Hof]

Attachment: 2017 A1300003042 RA Logius KPMG WebTrust Auditor Report BR - all Domain CAs - 20191213.pdf

Comment 3

[Jorik van 't Hof]

Attachment: 2018 A1800014656 RA Logius KPMG WebTrust Report BR - all domain CAs - 20191213.pdf

Comment 4

[Wayne Thayer]

Jorik: thank you for this incident report. Please submit a new CCADB audit case with these updated reports.

Comment 5

[Jorik van 't Hof]

Hello Wayne,

Yesterday, January 7th we submitted a new CCADB audit case with the updated reports.

Regards,

Jorik

Comment 6

[Wayne Thayer]

Waiting for CCADB case #538 and 539 to be processed.

Jorik: It appears that more information is required (CP/CPS information). Will you please confirm that these audit cases have been completed? Instructions are at https://ccadb.org/cas/updates.

Comment 7

[Jorik van 't Hof]

Hello Wayne,

Cases #538 and 539 have been updated in CCADB.

Regards,

Jorik

Comment 8

[Wayne Thayer]

Confirmed - these cases are now just awaiting verification.

Comment 9

[Kathleen Wilson]

I have finished processing these audit cases, so will close this bug.