1708965 - KIR S.A.: Certificates issued greater than stated in CPS

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Piotr Grabowski]

Bug report:

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. 
   

KIR became aware of the problem in parallel: as a result of CPS internal self-audit/review which was carried out in regards to the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1705904.
Additionally KIR was informed by the third-party in the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c35
As a short description we have issued certificates, which have the validity period 1 second longer than the validity period indicated in KIR Certification Practice Statement (6.3.2).
The validity period of the certificates was compliant with BR.
We failed to consider the inclusive requirement (1 second) of RFC5280 in the validity period.

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.

2020-09-01 BR update - Certificates issued SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.
2020-09-01 KIR CPS update specifying the validity period for SSL certifctaes for a maximum of 1 year. Until 01/09/2020, KIR issued certificates with a validity period of up to 2 years.
2021-04-20 08:30 am CEST CPS review was started. It was related to the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1705904
2021-04-28 11:23 PDT KIR was informed by the third-party in the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c35 about the issue.
2021-04-29 07:38 PDT New version of KIR CPS was announced to be published on the 1st of May 2021. In the new CPS the maximum validity period of SSL certificates
is 398 days from the date of certificate generation.

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. 
   

Yes. Our CA has stopped issuing certifates with the problem. It was non-compliance with our own CPS. Before CPS update it specifed the maximum validity period of 1 year. In the new CPS the maximum validity period of SSL certificates is 398 days from the date of certificate generation.

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. 
   

The Certificates with an additional second were issued from 2020-09-17 to 2021-04-28
We have identified about 300 certificates with the problem.

Examples of them.
https://crt.sh/?id=4228551709
https://crt.sh/?id=4228531866
https://crt.sh/?id=4228478515

7.  The complete certificate data for the problematic certificates. 
   

Same as above.

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

The issue started 01.09.2020 when we have published CPS v1.12 in which we have failed to consider new validity period definition:
Validity Period: Prior to 01.09.2020, the period of time measured from the date when the Certificate is issued until the Expiry Date. For Certificates issued on or after
01.09.2020, the validity period is as defined within RFC 5280, Section 4.1.2.5: the period of time from notBefore through notAfter, inclusive.

The error is due to wrong description of the validity period in the CSP. The validity period of the issued certificates falls within the validity period approved by the BR, however, it is imprecise and does not include inclusive. The non-compliance was not detected during the earlier CSP reviews and during the review of compliance with the validity period indicated in the BR because the validity period of these certificates does not exceed the period indicated in the BR. The validity period of 1 year was communicated to clients with marketing in the business offer and hence an analogous imprecise provision in the CSP.
This problem does not concern the violation of BR rules. It should be noted that the problem does not directly affect the security of the certificates used and does not generate a risk for their users.

7. List of steps CA is taking to resolve the situation and ensure it will not be repeated.

Beside the remediation steps communicated in https://bugzilla.mozilla.org/show_bug.cgi?id=1705904#c12 we are going to conduct more proactive activities related with monitoring CA incidents from other CAs.
The certificates were issued mainly for banks operating in Poland. These certificates are used in essential infrastructure of a separated banking system.
Due to the number of certificates and the importance of the systems, certificates cannot be revoked within 5 days. Revoking the certificates in such a short time could adversely affect the operation of banking systems.
The replacement of these certificates requires a lot of efforts from our clients. We estimate that the affected certificates will be replaced with the new ones as soon as possible, but no later than within 7 months. We also consult remediation plan with our Auditor.

Comment 1

[Piotr Grabowski]

the subject is not correct - we have not issued certificates greater than 398 days, but 1 year + 1 second

Comment 2

[Ryan Sleevi]

It appears KIR S.A has again failed to meet the requirements of an Incident Report.

Revocation delays are treated as separate incidents, necessitating their own but, and per-customer breakdowns are expected, along with specific steps KIR SA. Is taking. 7 months is extremely unreasonable and unsupported, so hopefully in filing the new report, KIR SA will have a more reasonable deadline, such as two weeks time.

In redoing this incident report, KIR S.A. has not yet demonstrated an awareness of root causes, nor the seriousness of this non-compliance. It is clear there is a systemic failure to consider changes, but no such examination of that failure is present. The complete dismissal of such concerns, by indicating that a failure to effectively manage and monitor changes, by suggesting it does not generate a risk for users, is deeply concerning. This is because that particular response has been repeatedly shown to be problematic, and CAs that employ it as an answer frequently end up removed from trust entirely, because of how deeply flawed their operations turn out to be.

Please make sure you’ve properly examined questions 6 and 7 to make sure you’ve actually provided an incident report as expected.

Comment 3

[Jesper Kristensen]

I cannot find the old version of KIR S.A.'s CPS that stated one year validity. The reason I want to read it is that while the BRs are very precise about what 398 days means, should we assume the same level of precision in all CPSes? I think doing so would encourage all CAs to be as vague as possible in their CPS, if a small typo in there will be treated as misissuance.

Comment 4

[Piotr Grabowski]

(In reply to Jesper Kristensen from comment #3)

I cannot find the old version of KIR S.A.'s CPS that stated one year validity. The reason I want to read it is that while the BRs are very precise about what 398 days means, should we assume the same level of precision in all CPSes? I think doing so would encourage all CAs to be as vague as possible in their CPS, if a small typo in there will be treated as misissuance.

https://www.elektronicznypodpis.pl/gfx/elektronicznypodpis/userfiles/_public/information/legal_basis/archived_versions/20200918_certification_practice_statement_kir_trusted_nq_certificates.pdf

Page 51

Comment 5

[Piotr Grabowski]

Ryan,
Thank you for your comments.

(In reply to Ryan Sleevi from comment #2)

It appears KIR S.A has again failed to meet the requirements of an Incident Report.

Revocation delays are treated as separate incidents, necessitating their own but, and per-customer breakdowns are expected, along with specific steps KIR SA. Is taking. 7 months is extremely unreasonable and unsupported, so hopefully in filing the new report, KIR SA will have a more reasonable deadline, such as two weeks time.

We will prepare a dedicated bug report for revocation delay. We examined the list of affected certificates. As we declared, we replace them ASAP. In some cases we can do it within 2 weeks, whiles in other cases some actions are required by the clients. These certificates are used in closed banking systems so revocation of these certificates without replacing them with the ne ones could cause serious problems in bank continuity. About 50 certificates will be replaced within two weeks. For the rest if the certificates (261) we will be back with the new possible date of replacement which should be sooner than 7 months.

In redoing this incident report, KIR S.A. has not yet demonstrated an awareness of root causes, nor the seriousness of this non-compliance. It is clear there is a systemic failure to consider changes, but no such examination of that failure is present. The complete dismissal of such concerns, by indicating that a failure to effectively manage and monitor changes, by suggesting it does not generate a risk for users, is deeply concerning. This is because that particular response has been repeatedly shown to be problematic, and CAs that employ it as an answer frequently end up removed from trust entirely, because of how deeply flawed their operations turn out to be.

We treat every failure very seriously. In this particular case, saying "it does not generate a risk for users" we meant that the request validation was performed accurately and this issue did not affect keys and certificates security.

Please make sure you’ve properly examined questions 6 and 7 to make sure you’ve actually provided an incident report as expected.

Comment 6

[Ben Wilson]

I believe this bug can be closed and that further tracking of this issue, if needed, can be conducted under Bugzilla Bug #1709872 (delayed revocation of leaf certificates) or Bug #1705904 (CP/CPS contains noncompliant DV method, does not specify CAA domains)--as I will be conducting a detailed review of KIR's CPS. I'll schedule to close this bug on this Friday, 11-June-2021.