1649942 - SK ID Solutions: Incorrect OCSP Delegated Responder Certificate

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Ryan Sleevi]

The following was originally reported to m.d.s.p. at https://www.mail-archive.com/[e-mail]/msg13493.html

SK ID Solutions has issued one or more OCSP Delegated Responders, as defined within RFC 6960, Section 2.6 and Section 4.2.2.2, without including the id-pkix-ocsp-nocheck response, as required by the Baseline Requirements, Version 1, Section 13.2.5 through Version 1.7.0, Section 4.9.9

Example certificate: https://crt.sh/?id=78288258

Kathleen: I'm assigning this bug to you, because Bug 1621159 set this CA to distrusted for TLS after 2017/09/01. However, this prevents proper OCSP functioning for any of the intermediates issued by this CA. Removing the TLS trust bit may be appropriate, but note that this also would prevent using OCSP to revoke any of the other sub-CAs (e.g. those used for e-mail), and so this issue doesn't go away.

Full Data:

 certificate_id | ca_id  | parent_ca_id |                                                                     parent_name                                                                     |  validity           | revoked
----------------+--------+--------------+-----------------------------------------------------------------------------------------------------------------------------------------------------+---------------------+---------
         862503 |    995 |          995 | C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=[e-mail]                                                       | 2030-12-17 23:59:59 | f
       12624839 |  12278 |          995 | C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=[e-mail]                                                       | 2030-12-17 23:59:59 | f
       78288258 |  39962 |          995 | C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=[e-mail]                                                       | 2030-12-17 23:59:59 | f
      163641648 |  51042 |          995 | C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=[e-mail]                                                       | 2030-12-17 23:59:59 | f
      164243751 |   6528 |          995 | C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=[e-mail]                                                       | 2024-03-18 10:14:59 | t
      164243750 |   6533 |          995 | C=EE, O=AS Sertifitseerimiskeskus, CN=EE Certification Centre Root CA, emailAddress=[e-mail]                                                       | 2024-03-18 10:11:11 | t

Comment 1

[Mihkel Tammsalu]

We inform that we have acknowledged the issue addressed and started investigation/analyze.

Comment 2

[Mihkel Tammsalu]

Date: 06.07.2020
SK Incident report according to https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

SK ID Solutions became aware of the problem reported via Bugzilla https://bugzilla.mozilla.org/show_bug.cgi?id=1649942 on Thursday, 2 July 2020 at 08:58 EEST.

• 2. July 2020 at 08:58 EEST – SK became aware of the problem reported in Bugzilla.
• 2. July 2020 at 11:30 EEST - SK's internal meeting was held, to discuss/review the possible security impact. Further plan was agreed.
• 3. July 2020 at 15:00 EEST - SK made discussion with our auditors to analayze the current situation as non-conformity/security issue in scope of requirements CAB BRG and eIDAS (ETSI). Further action plan was agreed for start of the week 28.

Regarding end-entity TLS certificates, please note that SK has terminated issuance of TLS Server Certificates as of 1. September 2017. Latest will expired on 29th of September 2020. In current situation the relevant (valid) CA hierarchy affected can be found here https://misissued.com/batch/138/

All related SK's CA certificates (can be found here https://misissued.com/batch/138/ ) have the common non-conformity, where "id-kp-OCSPSigning" EKU is present, without "id-pkix-ocsp-nocheck" extension.

Problematic CA certificates:
ROOT: https://crt.sh/?id=862503&opt=cablint
Intermediate 1: https://crt.sh/?id=12624839&opt=cablint
Intermdeiate 2: https://crt.sh/?id=78288258&opt=cablint
Intermediate 3: https://crt.sh/?id=163641648&opt=cablint

Related end-entity certificates:
PROFILE SERIAL VALIDTO

---

TLS 45CDC81C78336FA459A7FA7674BBA4B0 29-SEP-20
TLS 6946DF29C240C3AF599FCD7922B4A6BB 23-SEP-20
TLS 631999B132B8D564595F602EC5D4C311 05-AUG-20
TLS 686AE27975787BD9595F60CE7B39DB63 05-AUG-20

CA's like us, enabled the id-kp-OCSPSigning EKU in the Intermediate CA Profiles were following the Baseline Requirements to "protect relying parties". According to the BRs 7.1.2.2:
/"Generally Extended Key Usage will only appear within end entity certificates (as highlighted in RFC 5280 (4.2.1.12)), however, Subordinate CAs MAY include the extension to further protect relying parties until the use of the extension is consistent between Application Software Suppliers whose software is used by a substantial portion of Relying Parties worldwide"/

Also in our case following the ETSI is normative, and it has been not mandatory. But by our PKI ecosystem design, the same root is used, so the current situation is also consequence of different standards interpretations.

SK ID Solutions as TSP, will not carry out of revocation on listed root and intermediate CA's.
Currently SK has following action plan agreed, solving the BR compliance issue:

1. SK will revoke* the last valid end-entity TLS certificates. Contact with 4 last customers is needed.
   *NB! or let them expire, as "valid to" dates are close by. This needs discussion with Mozilla.
2. If needed, leaving the Mozilla CA program earlier as planned, might be considered (depends on point 1 outcome).
3. During week 28, SK will prepare risk assessment, to analyze it as reported security relevant issue, in a wider scope of overall TSP perspective.

SK will notice, when more detailed action plan is available. Please feel free to ask additional questions, if something is unclear.

Comment 3

[Kathleen Wilson]

(In reply to Ryan Sleevi from comment #0)

Kathleen: I'm assigning this bug to you, because Bug 1621159 set this CA to distrusted for TLS after 2017/09/01. However, this prevents proper OCSP functioning for any of the intermediates issued by this CA. Removing the TLS trust bit may be appropriate, but note that this also would prevent using OCSP to revoke any of the other sub-CAs (e.g. those used for e-mail), and so this issue doesn't go away.

Mozilla only has the Websites trust bit enabled for this root cert, so I filed Bug #1651211 to remove the root certificate in our next batch of root changes to NSS, which will probably be in September.

(In reply to Mihkel Tammsalu from comment #2)

SK ID Solutions as TSP, will not carry out of revocation on listed root and intermediate CA's.
Currently SK has following action plan agreed, solving the BR compliance issue:

1. SK will revoke* the last valid end-entity TLS certificates. Contact with 4 last customers is needed.
   *NB! or let them expire, as "valid to" dates are close by. This needs discussion with Mozilla.

Revoking those end-entity TLS certificates would have zero impact on Mozilla. So I am fine with you letting them expire. However, I do not speak on behalf of the operators of the other root stores that your CA is included in.

Comment 4

[Mihkel Tammsalu]

Mozilla only has the Websites trust bit enabled for this root cert, so I filed Bug #1651211 to remove the root certificate in our next batch of root > > changes to NSS, which will probably be in September.

Can You please clarify, the date "in September" ? Like we mentioned, our last certificate will be expired in 29-SEP-20.

Comment 5

[Ben Wilson]

The answer depends on whether the September batch of root changes gets into NSS 3.57. If the change gets into NSS 3.57, then root removal would occur in Firefox 82, which is currently scheduled to go into Beta on September 22, and release on October 20. See https://wiki.mozilla.org/NSS:Release_Versions and https://wiki.mozilla.org/Release_Management/Calendar. Otherwise, it would likely go into Firefox 83 which goes to Beta on October 20 and final release on November 17.

Comment 6

[Mihkel Tammsalu]

Regarding this opened bug and our posted incident report (06.07.2020) what indicated that SK ID Solutions as TSP, will not carry out of revocation on listed root and intermediate CA's we kindly request to close this Bug 1649942.

SK have made risk assessment, to analyze it in a wider scope of overall TSP perspective. The analysis looked into the security problem where the interim CA certificate has been issued with the X509v3 EKU id-kp-OCSPSigning and with the assumption, that the key pair of the interimediate CA has been already compromised. By large, the compromise of the ICA key pair is very unlikely event. The analysis assesses the impact of such situation to the eIDAS PKI ecosystem and identifies compensating security measures and residual risks.
The overall analysis outcome of different risk/attack vectors showed, that for most use cases (authentication, siging, signature validation etc.) the existing control measures were sufficient enough, to evaluate risk likelihood on level unlikely or even rare.

Comment 7

[Kathleen Wilson]

Since we are removing this root certificate via Bug #1651211, I'm fine with closing this bug.