1586125 - PKIoverheid: No BR Audit for subCAs technically capable of issuing TLS certs

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Kathleen Wilson]

There is no BR audit for the following subordinate CAs of PKIoverheid, but the subordinate CAs are technically capable of issuing TLS certificates. This is a violation of section 8 of the CA/Browser Forum Baseline Requirements and of Mozilla's Root Store Policy.

Subject: CN=Ministerie van Defensie Certificatie Autoriteit - G2; O=Ministerie van Defensie; C=NL
Issuer: CN=Staat der Nederlanden Organisatie CA - G2; O=Staat der Nederlanden; C=NL
SHA-256 Fingerprint: 35FE6E6BA2005B9EAAAEAB9CEC07B6A6B6BD936F3EADC5C37B5B8ADC59760BFD

Subject: CN=Ministerie van Defensie Certificatie Autoriteit Defensiepas - G2; O=Ministerie van Defensie; C=NL
Issuer: CN=Ministerie van Defensie Certificatie Autoriteit - G2; O=Ministerie van Defensie; C=NL
SHA-256 Fingerprint: F50CE647CFE32AC2D323539B35F073E74706ADCAAD1C85E12E2AAF041474B71D

Subject: CN=MinIenM Autonome Apparaten CA - G2; O=Ministerie van Infrastructuur en Milieu; C=NL
Issuer: CN=Staat der Nederlanden Autonome Apparaten CA - G2; O=Staat der Nederlanden; C=NL
SHA-256 Fingerprint: 3B011284D8EBE902841CEC48F9D7F18BEF71BA404835717D5D2BEF5655710793

Subject: CN=MinIenM Taxi CA Systeemkaarten - G2; O=Ministerie van Infrastructuur en Milieu; C=NL
Issuer: CN=MinIenM Autonome Apparaten CA - G2; O=Ministerie van Infrastructuur en Milieu; C=NL
SHA-256 Fingerprint: 7415FC604086B4E9A7DBCF8B44AB9A478D337F506477E3D48880D4432810DD6B

Subject: CN=MinIenM Organisatie CA - G2; O=Ministerie van Infrastructuur en Milieu; C=NL
Issuer: CN=Staat der Nederlanden Organisatie CA - G2; O=Staat der Nederlanden; C=NL
SHA-256 Fingerprint: BDD191FD3B4AC34B4D2F62EFAFBD07CEAB6581BCFE6C129F5916F1892FBD5394

Subject: CN=MinIenM Taxi CA Boordcomputerkaarten - G2; O=Ministerie van Infrastructuur en Milieu; C=NL
Issuer: CN=MinIenM Organisatie CA - G2; O=Ministerie van Infrastructuur en Milieu; C=NL
SHA-256 Fingerprint: C0E1A932482E0720AF1719770533382BB724413CD076BF8A56B5CAF45F297E2A

Per similar situations (e.g. Bug #1575125) the CA needs to provide an incident report about why there are non-constrained subCAs without the required audits.

I will indicate in CCADB that these certs should be added to OneCRL. Note that while this is currently considered sufficient for Mozilla, other root store operators may require actual revocation of these certs.

Reference:
https://cabforum.org/baseline-requirements-documents/
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#31-audits

Comment 1

[Jorik van 't Hof]

Hello Kathleen,

Thank you for your report.

We are investigating the reported subordinate CAs of PKIoverheid with the mentioned TSPs and are following the discussion about this issue.

We expect to provide an update next week with an incident report.

Regards,

Jorik

Comment 2

[Jorik van 't Hof]

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.

Logius PKIoverheid was made aware of this issue due to the creation (and assignment) of bug #1586125 by Kathleen Wilson of Mozilla on October 3, 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.

(date format in DD/MM/YYYY)
10/11/2010 Creation of subCA “Ministerie van Defensie Certificatie Authoriteit – G2”’
16/11/2010 Creation of issuing CA “Ministerie van Defensie Certificatie Autoriteit Defensiepas – G2” (child CA of “Ministerie van Defensie Certificatie Autoriteit – G2”)
08/03/2012 creation of subCAs “MinIenM Autonome Apparaten CA – G2” and “MinIenM Organisatie CA – G2”
09/03/2012 creation of issuing CAs “MinIenM Taxi CA Systeemkaarten – G2” and “MinIenM Taxi CA Boordcomputerkaarten – G2 (Child CAs of “MinIenM Autonome Apparaten CA – G2” and “MinIenM Organisatie CA – G2”
04/07/2017 Mozilla CA Certificate Policy 2.4.1 is published and comes into effect. In this policy clarifications were made around (sub)CA audits and requirements were added for intermediates technically capable of issuing TLS certificates.
03/10/2019 Creation of this bug.

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.

The CA in questions have never issued TLS certificates, only S/MIME certificates.

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.

N/A

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.

N/A

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

The CAs in question were signed before the BRs came into effect. At the time, technically constraining the CAs wasn’t a common practice, and as such all PKIoverheid G2 TSP CAs were signed without any EKU or nameConstraints. When Mozilla sent a CA communication after publication of policy 2.4.1, Logius answered that they were compliant with version 2.4.1 of the Mozilla CA Certificate Policy (minus an extension for translation of the PKIoverheid CPS).
The implementation for the CAs in question is such that they only issue certificates for authentication and the use for qualified signatures. Because of our CP, certificates issued by IenM/Ministry of Defence are only issued on SSCD’s/QSCD’s.
Because of this it seems that Logius interpreted the sentence “technically capable of issuing TLS certificates” differently than Mozilla intended and as such, didn’t follow up with the TSPs involved to make sure that a BR audit would take place in the next annual audit.

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.

Both TSPs have migrated to our third generation root CA (G3). In the G3 hierarchy, all issuing CAs have constraints in the form of an (or multiple) Extended Key Usage(s) in the certificates. The new issuing (G3) CAs don’t have the EKU ServerAuth included in the certificate anymore, so issuance of (working) TLS certificates off of these CAs is technically impossible. The CAs listed (and the whole G2 hierarchy, for that matter) will expire in March 2020.
The inclusion of both intermediates on oneCRL as indicated by Kathleen is, in our opinion, the best (and quickest) solution. Our interpretation of that is inclusion on oneCRL will only be the case for TLS, and not S/MIME (seeing that the CAs in question do have valid ETSI EN 319 411-1 audits for issuance of non-TLS certificates).

Comment 3

[Ryan Sleevi]

(In reply to Jorik van 't Hof from comment #2)

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

The CAs in question were signed before the BRs came into effect. At the time, technically constraining the CAs wasn’t a common practice, and as such all PKIoverheid G2 TSP CAs were signed without any EKU or nameConstraints. When Mozilla sent a CA communication after publication of policy 2.4.1, Logius answered that they were compliant with version 2.4.1 of the Mozilla CA Certificate Policy (minus an extension for translation of the PKIoverheid CPS).
The implementation for the CAs in question is such that they only issue certificates for authentication and the use for qualified signatures. Because of our CP, certificates issued by IenM/Ministry of Defence are only issued on SSCD’s/QSCD’s.
Because of this it seems that Logius interpreted the sentence “technically capable of issuing TLS certificates” differently than Mozilla intended and as such, didn’t follow up with the TSPs involved to make sure that a BR audit would take place in the next annual audit.

I guess I'm trying to understand. The announcement by Mozilla included a link to the diff between the then-current 2.3 policy and the 2.4 policy specifically to address this potential confusion. The wording introduced in 2.4 enumerated explicitly the scope, with the statement "Such technical constraints could consist of either ..."

Is my understanding correct that PKI Overheid read the "could" as being a non-exhaustive enumeration of potential interpretations, rather than a normative list?

The inclusion of both intermediates on oneCRL as indicated by Kathleen is, in our opinion, the best (and quickest) solution. Our interpretation of that is inclusion on oneCRL will only be the case for TLS, and not S/MIME (seeing that the CAs in question do have valid ETSI EN 319 411-1 audits for issuance of non-TLS certificates).

While that's an option for Mozilla as part of its risk remediation, it does not resolve the underlying compliance issue with respect to the BRs, nor does it address other Root Programs' expectations. Other Root Programs have been clear an expectation of revocation as the only means to resolve the compliance concern.

Is there any plan to revoke these certificates prior to their natural expiration? The BRs require revocation within 7 days, although one would expect that if a CA makes a determination to delay that revocation, they will provide additional information about the decision making process. While that does not grant exceptions, it does provide transparency as to the non-compliance for revocation.

Comment 4

[Jorik van 't Hof]

Hello Ryan,

There was an internal discussion while reading the changes for 2.4.1. To shed some more light on decision making process at that time I would like to offer a short recap of the facts and considerations regarding this issue:

1. As it seems, the consensus at that time was that the specific passage was indeed seen as non-exhaustive
2. The intermediate CAs “Ministerie van Defensie Certificatie Autoriteit - G2”, “MinIenM Organisatie CA - G2” and “MinIenM Autonome Apparaten CA - G2” are kept offline and require a key ceremony (and multi-person control) to be brought online to issue an certificate.
3. The child CAs (issued by these CAs) only signs certificates which are put on a SUD or an SSCD/QCSD (token/smartcard) according to ETSI EN 319 411-1 policy NCP+ or ETSI EN 319-411-2 qcp-n-qscd. The technical setup used makes it quite difficult to issue TLS certificates, because even if the certificate profile was changed they would still be issued on a SUD or QSCD. Changing that would require, again, significant changes on the system which would involve multiple roles to be present.

At the time, the interpretation of section 1.1 combined with lines 2 and 3 led to the mistaken belief that the CAs in question were compliant.

Going forward, the following actions are being proposed by Logius PKIoverheid for remediation and to prevent future occurrence of this matter

1. Because the root for this CA’s (Staat der Nederlanden Root CA – G2) is expiring per March 18th 2020 the TSPs involved already had the following replacement schedules in place:
   a. The certificates issued by “MinIenM Taxi CA Systeemkaarten – G2” and “MinIenM Taxi CA Boordcomputerkaarten – G2” are currently being replaced. This is scheduled to be finished before the end of the year (Q4 2019). The issuing CAs (and their parent, intermediate CAs) and will be revoked before January 9nd 2020. The IenM CAs can be placed on oneCRL immediately.
   b. For the issuing CA “Ministerie van Defensie Certificatie Autoriteit Defensiepas – G2” (and its parent CA) the replacement of end-user certificates is scheduled for Q1 2020. However, the CA in question can be placed on oneCRL immediately.
2. The issuing CAs for these TSPs under the “Staat der Nederlanden Root CA – G3” have EKUs included to separate issuance of TLS and S/MIME certificates, per MS requirements. The IenM/IenW G3 TSP CAs have been further constrained by excluding the emailProtection EKU in the TSP CAs.

As #1 shows above, both TSPs are currently in a migration situation. Unfortunately that can’t be sped up. To revoke now would disrupt the process of replacement and cause outages across relying parties, including worldwide operations of the Dutch Military.

Regards,

Jorik

Comment 5

[Wayne Thayer]

These CA certificates are now in OneCRL, and all questions appear to have been answered.

Comment 6

[Ryan Sleevi]

Wayne: Historically, these bugs have been kept open until the required revocation is completed, since that also represents a distinct BR violation. It seems like this should be kept open with a Next-Update of 2020-01-09, per comment #4.

Comment 7

[Wayne Thayer]

(In reply to Ryan Sleevi from comment #6)

Wayne: Historically, these bugs have been kept open until the required revocation is completed, since that also represents a distinct BR violation. It seems like this should be kept open with a Next-Update of 2020-01-09, per comment #4.

Per the message posted to m.d.s.p. by Kathleen, no action beyond adding these certificates to OneCRL is required by Mozilla. However, since the CA has included revocation in the remediation plan that they defined, I have reopened this bug.

Jorik: please update this bug as the remaining steps of your remediation plan are completed.

Comment 8

[Jorik van 't Hof]

Hello Wayne,

Concerning the certificates issued by “MinIenM Taxi CA Systeemkaarten – G2” and “MinIenM Taxi CA Boordcomputerkaarten – G2”.

After the bugpost Nov 1st the issuance of the new G3 certificates has been started according to plan with highest priority starting with personal QSCD cards. New insights have forced the TSP to change the remediation plan as follows:

• All personal QSCD cards with SMIME certificates (~60.000) will be revoked per December 31st, 2019. Batch-wise revocation has already been started (~20.000 revoked per December 16th, 2019).
• All non personal cards (65.000) and system cards (35.000) as well as the CA certificates will expire regularly per Mar 21 23:59:59 2020 GMT.

Revoking the CA’s in January 2020 could have severe consequences:

• it could disrupt the process of replacement due to the specific infrastructure that relies on the MinIenM certificates. The certificates are used in onBoard Computers in over 35.000 Taxi vehicles. All onBoard Computers require a software update to trust the new G3 certificates and more than 10.000 vehicles need to visit a certified workshop to update the software of the onBoard Computer to trust the new certificates. Revoking the CA's before expiration per March 21st, 2020 could disrupt the possibility to install the required software updates as this requires G2 cards. Failing to update an onBoard Computer before March 21st, 2020 will effectively brick the devices.
• it could cause outages across relying parties including the Dutch Human Environment and Transport Inspectorate responsible to supervise the Taxi market for safe driving behavior and the Dutch Tax Office.

Regards,

Jorik

Comment 9

[Ryan Sleevi]

Jorik: Thanks for providing the additional details regarding the challenges with the BR-required revocation timeline.

Previously, PKIoverheid shared in https://bugzilla.mozilla.org/show_bug.cgi?id=1578809#c2 a plan to transition non-publicly-trusted issuance onto private PKI. Is it correct to understand that similar efforts are being done here? That is, that the work being done is to split the public and private hierarchies, such that only the public hierarchy can be trusted by Mozilla?

Comment 10

[Jorik van 't Hof]

Hello Ryan,

To avoid any confusion about terminology here: I assume you’re referring to the issuance of certificates under a publicly trusted root which are used in a closed off (private) system?

In that case, yes, the current measures are similar to the ones taken in bug 1578809 and are indeed in line with our intention to reduce our presence in the “public” PKI ecosystem.

Logius PKIoverheid has defined measures besides the shift to a full private PKI. In certain use cases where a switch to a full private PKI is not possible, due to external dependencies, PKIoverheid has decided to implement technical constraints in the issuing CAs. With this we reduce the impact in case of non-compliancy issues or security incidents for the general public.

An example of the above can be found in the following implementations: IenW is currently moving to issuance under the G3 Root, but their issuing CAs have been technically constrained by not including the emailProtection EKU or ServerAuth EKU, which would place them out of scope of the Mozilla Root Store Policy (per section 1.1) where CIBG moved to a fully Private CA for issuance of TLS certificates.

Where possible a shift to a private hierarchy is preferred. If a shift to a private hierarchy is not possible, we will restrict CA certificates as much as possible.

Regards,

Jorik

Comment 11

[Ryan Sleevi]

Thanks. Can you also confirm the following was implemented successfully:

All personal QSCD cards with SMIME certificates (~60.000) will be revoked per December 31st, 2019. Batch-wise revocation has already been started (~20.000 revoked per December 16th, 2019).

Comment 12

[Jorik van 't Hof]

Hello Ryan,

We can indeed confirm that the before mentioned QSCD cards with SMIME certificates have been revoked per December 31st.

Regards,

Jorik

Comment 13

[David Weissenberg]

Hello Ryan,

We can confirm that the Root CA is expired (03/25/2020) and with it all underlying CA’s and certificates have expired as well.

Regards,

David

Comment 14

[Ryan Sleevi]

Wayne: Looks like this is all done.

Comment 15

[Wayne Thayer]

Resolving per comment #7.