Open Bug 1586125 Opened 2 months ago Updated 23 days ago

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

Categories

(NSS :: CA Certificate Compliance, task)

task
Not set

Tracking

(Not tracked)

REOPENED

People

(Reporter: kwilson, Assigned: jorik.vant.hof)

Details

(Whiteboard: [ca-compliance] - Next Update - 09-January-2020)

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

Whiteboard: [ca-compliance] - Missing BR Audits

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

  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

  1. 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.

  1. 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.

  1. 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

  1. 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

  1. 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.

  1. 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).

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

  1. 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.

Flags: needinfo?(jorik.vant.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

Flags: needinfo?(jorik.vant.hof)

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

Status: NEW → RESOLVED
Closed: 28 days ago
Resolution: --- → FIXED
Whiteboard: [ca-compliance] - Missing BR Audits → [ca-compliance]

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.

Flags: needinfo?(wthayer)

(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.

Status: RESOLVED → REOPENED
Flags: needinfo?(wthayer)
Resolution: FIXED → ---
Whiteboard: [ca-compliance] → [ca-compliance] - Next Update - 09-January-2020
You need to log in before you can comment on or make changes to this bug.