Closed Bug 1705904 Opened 4 months ago Closed 20 days ago

KIR S.A.: CP/CPS contains noncompliant DV method, does not specify CAA domains

Categories

(NSS :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: agwa-bugs, Assigned: piotr.grabowski)

Details

(Whiteboard: [ca-compliance])

KIR S.A. has disclosed the following CP/CPS:

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

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

for the CA https://crt.sh/?sha256=E22E6B25908E1107A607AF060E0B24E50C6D9562FF04F455BE0F8DF41A5032C0

Neither document specifies the recognized CAA domains as required by BR 2.2.

Neither document clearly specifies the subsections of BR 3.2.2.4 which SECOM uses to validate domain control, as required by MRSP 2.2 (3).

Section 3.2.2 describes the following domain validation method:

checking in publicly available WHOIS services or directly with entities registering domains, if a contracting authority is registered as a domain owner or has the right to use the domain name;

That sounds like the forbidden method 3.2.2.4.1.

which SECOM uses to validate domain control

Why SECOM?

(In reply to Michel Le Bihan from comment #1)

which SECOM uses to validate domain control

Why SECOM?

My apologies, that's a typo and should say "KIR S.A."

I looked at CAA records of domains in certificates issued by them and it looks like they are using elektronicznypodpis.pl:

michel@debian:~$ dig +short CAA wssd.olsztyn.pl
0 issue "certum.pl"
0 issue "letsencrypt.org"
0 issuewild "elektronicznypodpis.pl"
0 issuewild "letsencrypt.org"
0 issuewild "certum.pl"
0 issue "elektronicznypodpis.pl"

So there is a high chance that, at least wssd.olsztyn.pl (probably more domains), had only CAA records which did not allow KIR S.A. to issue certificates at the time of issuance (as there were no Issuer Domain Names that would have allowed them to issue at the time of issuance).

@KIR S.A.: This is a BR violation and an incident in itself. You have to revoke all certificates, for which you cannot prove that they had no CAA records at time of issuance within 5 days.

(In reply to paul.leo.steinberg from comment #5)

So there is a high chance that, at least wssd.olsztyn.pl (probably more domains), had only CAA records which did not allow KIR S.A. to issue certificates at the time of issuance (as there were no Issuer Domain Names that would have allowed them to issue at the time of issuance).

@KIR S.A.: This is a BR violation and an incident in itself. You have to revoke all certificates, for which you cannot prove that they had no CAA records at time of issuance within 5 days.

I don't believe the issuances were necessarily a BR violation. BR 2.2 imposes requirements on the publication of information, not on the validation of certificates. BR 3.2.2.8, which specifies the processing of CAA records, refers to RFC 8659, which states that the issue property grants "authorization to issue certificates containing that FQDN to the holder of the issuer-domain-name or a party acting under the explicit authority of the holder of the issuer-domain-name." That was presumably satisfied with an issue property containing "elektronicznypodpis.pl".

Assignee: bwilson → piotr.grabowski
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Whiteboard: [ca-compliance]

(In reply to Andrew Ayer from comment #6)

(In reply to paul.leo.steinberg from comment #5)

So there is a high chance that, at least wssd.olsztyn.pl (probably more domains), had only CAA records which did not allow KIR S.A. to issue certificates at the time of issuance (as there were no Issuer Domain Names that would have allowed them to issue at the time of issuance).

@KIR S.A.: This is a BR violation and an incident in itself. You have to revoke all certificates, for which you cannot prove that they had no CAA records at time of issuance within 5 days.

I don't believe the issuances were necessarily a BR violation. BR 2.2 imposes requirements on the publication of information, not on the validation of certificates. BR 3.2.2.8, which specifies the processing of CAA records, refers to RFC 8659, which states that the issue property grants "authorization to issue certificates containing that FQDN to the holder of the issuer-domain-name or a party acting under the explicit authority of the holder of the issuer-domain-name." That was presumably satisfied with an issue property containing "elektronicznypodpis.pl".

We will update CP/CPS to (In reply to Andrew Ayer from comment #0)

KIR S.A. has disclosed the following CP/CPS:

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

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

for the CA https://crt.sh/?sha256=E22E6B25908E1107A607AF060E0B24E50C6D9562FF04F455BE0F8DF41A5032C0

Neither document specifies the recognized CAA domains as required by BR 2.2.

Neither document clearly specifies the subsections of BR 3.2.2.4 which SECOM uses to validate domain control, as required by MRSP 2.2 (3).

Section 3.2.2 describes the following domain validation method:

checking in publicly available WHOIS services or directly with entities registering domains, if a contracting authority is registered as a domain owner or has the right to use the domain name;

That sounds like the forbidden method 3.2.2.4.1.

We use only 2 methods:
3.2.2.4.6 Agreed-Upon Change to Website
3.2.2.4.7 DNS Change

(In reply to Piotr Grabowski from comment #7)

We will update CP/CPS to (In reply to Andrew Ayer from comment #0)

After doing so, please file a full incident report.

Please note, the incident report MUST consider why KIR S.A. failed to detect this non-compliance, what KIR S.A.'s current policies are for compliance, and how they're being addressed and changed.

Please pay special attention to the following language from https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

The purpose of these incident reports is to provide transparency about the steps the CA is taking to address the immediate issue and prevent future issues, both the issue that originally lead to the report, and other potential issues that might share a similar root cause. Additionally, they exist to help the CA community as a whole learn from potential incidents, and adopt and improve practices and controls, to better protect all CAs. Mozilla expects that the incident reports provide sufficient detail about the root cause, and the remediation, that would allow other CAs or members of the public to implement an equivalent solution.

For example, it’s not sufficient to say that “human error” of “lack of training” was a root cause for the incident, nor that “training has been improved” as a solution. While a lack of training may have contributed to the issue, it’s also possible that error-prone tools or practices were required, and making those tools less reliant on training is the correct solution. When training or a process is improved, the CA is expected to provide specific details about the original and corrected material, and specifically detail the changes that were made, and how they tie to the issue. Training alone should not be seen as a sufficient mitigation, and focus should be made on removing error-prone manual steps from the system entirely.

Flags: needinfo?(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 was informed by the third-party in the bug https://bugzilla.mozilla.org/show_bug.cgi?id=1705904 that KIR’s CP/CPS is not clearly specifying the set of Issuer Domain Names that the CA recognizes in CAA “issue” or “issuewild” records as permitting it to issue. By the the way the examples were given of the usage value 'elektronicznypodpis.pl' as KIR's CAA “issue” or “issuewild” record.

  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.

2021-04-19 09:10 PDT KIR was assigned to this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1705904
2021-04-19 07:00 pm CEST The investigation the root cause began.
2021-04-19 07:30 pm CEST The CP/CPS were reviewed if the issue exists.
2021-04-19 07:38 pm CEST The confirmation of the issue was communicated on the forum and the update was declared. Although practice on processing CAA Records for Fully Qualified Domain Names has been disclosed, the value of the Issuer Domain Names that the CA recognizes in CAA “issue” or “issuewild” records as permitting it to issue was not clearly specified.
2021-04-20 08:30 am CEST Full CP/CPS review was started.

  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. 
    

BR non-compliant issue - missing clear specification the set of Issuer Domain Names that the CA recognizes in CAA “issue” or “issuewild” records as permitting it to issue.
Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.
The value 'elektronicznypodpis.pl' was not disclosed in CP/CPS. KIR is a holder of the issuer-domain-name elektronicznypodpis.pl and the domain is KIR's public repository.

  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. 
    

The issue in not related to misissuance.

  1.       The complete certificate data for the problematic certificates. 
    

The issue in not related to misissuance.

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

Annual updates of CP/CSP were made based on changes introduced in BR and MRSP. During these updates this requirement concerning Issuer Domain Names was overlooked.
The team responsible for CP/ CSP updates will be enlarged by additional KIR’ specialist.
The revision of KIR CP/CSP and compatibility with BR and MRSP will be included as a part of Audit.

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

The issue was immediately identified. CP/CPS will be updated till the 1st of May.

Flags: needinfo?(piotr.grabowski)

(In reply to Piotr Grabowski from comment #9)

  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.

2021-04-19 09:10 PDT KIR was assigned to this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1705904
2021-04-19 07:00 pm CEST The investigation the root cause began.
2021-04-19 07:30 pm CEST The CP/CPS were reviewed if the issue exists.
2021-04-19 07:38 pm CEST The confirmation of the issue was communicated on the forum and the update was declared. Although practice on processing CAA Records for Fully Qualified Domain Names has been disclosed, the value of the Issuer Domain Names that the CA recognizes in CAA “issue” or “issuewild” records as permitting it to issue was not clearly specified.
2021-04-20 08:30 am CEST Full CP/CPS review was started.

So I've emphasized a part of text that KIR S.A. seems to have ignored or misunderstood with respect to this bug, and which in general demonstrates a continuation of the pattern of KIR S.A. to fail to provide meaningful incident reports. This is particularly disappointing given Comment #8, which encouraged KIR S.A. to closely review the requirements.

The value 'elektronicznypodpis.pl' was not disclosed in CP/CPS. KIR is a holder of the issuer-domain-name elektronicznypodpis.pl and the domain is KIR's public repository.

My understanding of this statement is KIR S.A. is stating this was already documented, but has provided no evidence of this fact.

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

Annual updates of CP/CSP were made based on changes introduced in BR and MRSP. During these updates this requirement concerning Issuer Domain Names was overlooked.

As with above, I've emphasized a particular portion of the expectation, which KIR S.A. has also failed to meet. This is a description of "what" the mistake was, but does not address in the least the how and why, nor does it meaningfully address how they avoided detection until now.

A suitable answer would have included an in-depth discussion about the process and controls at KIR S.A. for compliance. That is, not just "We have a compliance team", but exactly how it's structured, what duties it performs, what controls exist to ensure the correct outputs are generated, how and why those controls were insufficient for this particular case, and what's being done to address.

The team responsible for CP/ CSP updates will be enlarged by additional KIR’ specialist.

Comment #8 specifically addressed this level of detail, highlighting it was and is not acceptable. It is profoundly troubling that KIR S.A. would ignore that comment, and the long-standing expectation, as well as communication on related bugs, to this effect.

The revision of KIR CP/CSP and compatibility with BR and MRSP will be included as a part of Audit.

This is already required of the Baseline Requirements, and so this provides no reassurance whatsoever of KIR S.A.'s ability or competence to operate as a CA. A proper response would have examined and detailed, at length, the existing process for auditing, how that process failed to consider changes to the BRs in which changes to CP/CPSes were expected, and looked at steps to improve this, such as replacing the auditor with one proven to be capable and competent in performing this, if the auditor failed to do so, or why the auditor allowed KIR S.A. to contract in such a way that it would fail to provide the necessary assurance.

The concern here is that because such a "basic" expectation was not included as part of the audit, a natural conclusion should be to reject KIR S.A.'s audits, and to disqualify the auditor from being considered for future CA audits. It's KIR S.A.'s response here, and the level of detail provided (or omitted) that could materially change that conclusion.

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

The issue was immediately identified. CP/CPS will be updated till the 1st of May.

As with the previous examples, KIR S.A. has failed to provide a meaningful response to the details provided, which points to a consistent pattern of failing to consider https://wiki.mozilla.org/CA/Responding_To_An_Incident . There is zero reassurance whatsoever, based on KIR S.A.'s report, that KIR S.A. is capable of complying with, or is in compliance with, the Baseline Requirements, nor that it has the processes and understanding in place to prevent a similar reoccurrence.

Comment #8 specifically highlighted language relevant to trying to avoid this conclusion ("The purpose of these incident reports"), and it's thus quite troubling that it was ignored.

Flags: needinfo?(piotr.grabowski)

The concern here is that because such a "basic" expectation was not included as part of the audit, a natural conclusion should be to reject KIR S.A.'s audits, and to disqualify the auditor from being considered for future CA audits.

It seems that https://bugzilla.mozilla.org/show_bug.cgi?id=1598577 has the same auditor.

Let me add some information to bug report reported by Piotr Grabowski.
The requirement concerning adding CA CAA Records for Fully Qualified Domain Names to CPS has been since the 8th of September 2017. This required information wasn’t add do CPS: It shall clearly specify the set of Issuer Domain Names that the CA recognises in CAA "issue" or "issuewild" records as permitting it to issue.
So the corrected timeline of actions is as follow:
2017–09-08 Requirement in BR 1.4.3
2017-07-10 CPS update concerning domain validation without adding statement about CAA Records
2018-04-12 CPS update without adding statement about CAA Records
2019-01-22 CPS update without adding statement about CAA Records
2020-03-30 CPS update without adding statement about CAA Records
2020-08-26 CPS update without adding statement about CAA Records
2021-04-19 09:10 PDT KIR was assigned to this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1705904
2021-04-19 07:00 pm CEST The investigation the root cause began.
2021-04-19 07:30 pm CEST The CP/CPS were reviewed if the issue exists.
2021-04-19 07:38 pm CEST The confirmation of the issue was communicated on the forum and the update was declared. Although practice on processing CAA Records for Fully Qualified Domain Names has been disclosed, the value of the Issuer Domain Names that the CA recognizes in CAA “issue” or “issuewild” records as permitting it to issue was not clearly specified.
2021-04-20 08:30 am CEST Full CP/CPS review was started.

A group consisting of KIR specialists from various areas is responsible for updating CPS/CP. One person in the team was responsible for the verification of compliance of CSP/ CP with BR/ MRSP. This person changed at the turn of 2017 and 2018. A new person verified the changes that had been introduced and overlooked the lack of previously required CPS entry. The rest members of the team are responsible for the verification of compliance with the provisions of law and internal regulations as well as procedures in force at KIR. At the same time, internal procedures for operators required checking if in CAA Records there is “electronicznypodpis.pl".
As part of corrective actions and preventing from further such non-compliance, the team responsible for CPS revisions is supplemented with an additional person (double-checking for four eyes) responsible for checking compliance of CPS/CP with BR and MRSP. The procedure for CPS/ CP revisions will be supplemented with the obligation to four eyes checking to verify of all requirements were fulfilled and correctly describe in CSP/ CP. In our opinion, adding additional person (double checking) and changing the procedure obliging the verification of all requirements will prevent such mistakes.
Additionally, to exclude any inconsistences in CSP/CP, annually KIR will order an additional checking of CSP/CP made by external auditor.

Hello,
Could you please tell me what were the CAA records for ezd.wsse.krakow.pl and wsse.krakow.pl when https://crt.sh/?id=4433476269&opt=ocsp was issued? I only see:

michel@debian:~$ dig +short CAA ezd.wsse.krakow.pl
michel@debian:~$ dig +short CAA wsse.krakow.pl
0 issue "letsencrypt.org"
0 issuewild "certum.pl"
0 issuewild "letsencrypt.org"
0 issue "certum.pl"

It's possible that a record was removed shortly after issuance and I missed it.

(In reply to Michel Le Bihan from comment #13)

Hello,
Could you please tell me what were the CAA records for ezd.wsse.krakow.pl and wsse.krakow.pl when https://crt.sh/?id=4433476269&opt=ocsp was issued? I only see:

michel@debian:~$ dig +short CAA ezd.wsse.krakow.pl
michel@debian:~$ dig +short CAA wsse.krakow.pl
0 issue "letsencrypt.org"
0 issuewild "certum.pl"
0 issuewild "letsencrypt.org"
0 issue "certum.pl"

It's possible that a record was removed shortly after issuance and I missed it.

CAA record for ezd.wsse.krakow.pl was empty, just like now.

CAA record for wsse.krakow.pl had entries eletronicznypodpis.pl for issue and issuewild.
The entries were removed, as the certificate was generated. We asked the domain owner to add this record ,eletronicznypodpis.pl' once again and keep it for at least week to confirm for you that KIR was acknowledged to issue this certificate .

Flags: needinfo?(piotr.grabowski)

(In reply to Elżbieta Włodarczyk from comment #12)

As part of corrective actions and preventing from further such non-compliance, the team responsible for CPS revisions is supplemented with an additional person (double-checking for four eyes) responsible for checking compliance of CPS/CP with BR and MRSP. The procedure for CPS/ CP revisions will be supplemented with the obligation to four eyes checking to verify of all requirements were fulfilled and correctly describe in CSP/ CP. In our opinion, adding additional person (double checking) and changing the procedure obliging the verification of all requirements will prevent such mistakes.

In general, we've seen a number of issues in which "Person X failed to detect", and the CA takes some action as "We have added Person Y" or "Person X is no longer with the company, Person Y is now in charge". Then, when either Person Y or Persons X+Y make a mistake, we repeat the process, so now we have either Person Y+Z or Person X+Y+Z and the cycle repeats.

These solutions tend to focus on addressing the problem "reactively", but can easily lead to issues that are preventable with proactive engagement. For example, "Person X + Y will review. For each change, they will produce a report summarizing the nature of the change, the impact, and the steps to be taken, even if they determine there is no impact. This will then be cross-checked by persons A + B quarterly, as part of our internal review." which is about trying to recognize that while having a second person can be a useful stop-gap, the risk exists that X misinterprets, and convinces Y that their (mis)interpretation is correct.

Similarly, there's an opportunity here to be proactive with respect to monitoring CA incidents from other CAs, such as by subscribing to the Bugzilla component or via a saved query, to identify when there is the risk of misinterpretation and the steps to take. For example, had KIR S.A. been monitoring such bugs, they could have spotted Bug 1596949 , which is near identical to this explanation here, nearly two years ago. Similarly, bugs like Bug 1705480, Bug 1693932, or Bug 1688215 could have highlighted the expectations here around domain validation documentation.

This is particularly concerning, given that for Bug 1688215, this was discussed on m.d.s.p. as part of the Camerfirma discussions, and given that all CAs are required to be aware of m.d.s.p. discussions, this exact issue could and should have been recognized by KIR S.A.

This is what is meant by carefully examining the root cause: there have been a number of related and relevant incidents, filed against other CAs, that if KIR S.A. was following these incidents, could and should have lead KIR S.A. to recognize this error itself.

Additionally, to exclude any inconsistences in CSP/CP, annually KIR will order an additional checking of CSP/CP made by external auditor.

As mentioned, this was and is already expected of audits. Literally the existence of CA audits began with the premise of checking a CP/CPS or set of requirements against how a CA operates, and that the CP/CPS accurately reflects how the CA audits. This is concerning that this sort of consistency check was not already party of things.

I'm assigning this to Ben for consideration of closing. While I'm encouraged to see a more detailed answer in Comment #12, it's concerning it took Comment #10 to get there, and as captured above, still suggests there's ample room for improvement. I think it would be quite concerning if KIR S.A. didn't implement the above suggestions and encountered more issues, but I also don't think we need to block closing this issue for KIR S.A. to do so, since they failed to identify these proactive measures.

Flags: needinfo?(bwilson)

Updated CSP has been published on our website https://www.elektronicznypodpis.pl/gfx/elektronicznypodpis/userfiles/_public/information/legal_basis/20210501_certification_practice_statement_kir_trusted_nq_certificates.pdf. In contains new section 4.2.4."Certificate Authority Authorization Records Processing".
Updated CSP is going to be valid since 1 May 2021.

(In reply to Ryan Sleevi from comment #15)

These solutions tend to focus on addressing the problem "reactively", but can easily lead to issues that are preventable with proactive engagement. For example, "Person X + Y will review. For each change, they will produce a report summarizing the nature of the change, the impact, and the steps to be taken, even if they determine there is no impact. This will then be cross-checked by persons A + B quarterly, as part of our internal review." which is about trying to recognize that while having a second person can be a useful stop-gap, the risk exists that X misinterprets, and convinces Y that their (mis)interpretation is correct.

Similarly, there's an opportunity here to be proactive with respect to monitoring CA incidents from other CAs, such as by subscribing to the Bugzilla component or via a saved query, to identify when there is the risk of misinterpretation and the steps to take.

Thank you for your comments and suggestions. Regarding the root cause concering CPS/ CP we define a new procedure consisting on:

  1. Additional person will be added to the team responsible for CPS updates (annual internal review updates and updates resulted by BR/ MRSP changes). The team consist on specialists from different departments (Security, Law, IT).
  2. Each member of the team will make his own CSP and BR &MRSP review and present it to other members in a form of report describing: nature of the change, the original source of the requirement, why it is necessary, the impact, and the steps to be taken, even if they determine there is no impact.
  3. The reports will be discussed by the team members during the dedicated meetings.
  4. The list of reconciled changes and the impacts they generated (together will implementation plan) will be presented to Management Board for acceptance.
  5. If MB accepts changes, the updated document will be published and requited changes will be implemented.

Additionally, we will implement more proactive activities related with monitoring incidents from other CAs. The revision of all incidents from other CAs will be made at least once a week by two dedicated specialists.

No update here.

I will be reviewing the CPS in close detail and get back here with my findings.

Here are my findings after a brief review of the KIR CPS.

Review of v. 1.14 of the Certification Practice Statement of KIR for Trusted Non-Qualified Certificates (“CPS”), dated April 30, 2021.

General notes: “Foreward” should be replaced with “Foreword”. Also, KIR should start replacing references to “SSL” with the more modern term, “TLS”.


CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)

Needs to be fixed – The CPS does not follow RFC 3647 throughout. This is especially true for CPS section numbers 1.3.3, 1.5.1, 1.5.2, 4.9.12, and sections 7.1.1 through 7.1.6. See comments below regarding section 1.3.3 (Registration authorities should be section 1.3.2), 1.5.2 (should be Contact person where KIR needs to state a means for third parties to submit certificate problem reports and revocation requests), 4.9.12 (should be revocation for key compromise) and section 7.1.4 (should be Name forms).


CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)

“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”

Adequate – Section 9.5 of the CPS states, “Copyright to this document is held by Krajowa Izba Rozliczeniowa It may be used solely for the purposes of using certificates. Any other uses, including the entire or part of the document shall require a written consent of Krajowa Izba Rozliczeniowa, provided that KIR expresses its consent to copying and publishing this document in its entirety.” Nothing appears to contradict the license required by Mozilla, but a more permissive license for the use of the CPS would be better.


Statement of adherence to BRs/EVGs and their precedence (MRSP § 2.3) (BR § 2.2 / EVG 8.3)

“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”

Section 8.3 of the EV Guidelines contains a similar provision – “In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document.”

Should be fixed – Section 1.1 of the CPS states, “KIR provides trust services in compliance with the requirements of the current version of the Baseline Requirements Certification Policy for the Issuance and Management of Publicly- Trusted Certificates published at www.cabforum.org. In the event of any discrepancies between the CSP and the said document, the document shall prevail over the CSP.” “CSP” is a typo. The last sentence would be better worded, “In the event of any discrepancies between the CPS and the Baseline Requirements, said document shall prevail over the CPS.”


Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.)

Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.

Should be clarified – Section 7.1 lists the types of EKUs and what they are for: “clientAuthentication – verification of the customer’s certificate, serverAuthentication – verification of the server’s certificate, codeSigning – for signing the application code, emailProtection – for electronic mail protection”, but I did not see separate certificate profiles for EKUs for issuing CAs. Section 7.1 does say, “In case of SSL certificates extension extendedKeyUsage includes the following values: serverAuthentication and clientAuthentication.” However, this requirement only applies to intermediate CAs created after January 1, 2019. A review of the SZAFIR Trusted CA2 created in 2015 shows that these EKUs are not in the Issuing CA that is currently in use.


Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6)

“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”

OK – Sections 1 and 2 of the CPS mention the Szafir Root CA and the Szafir Root CA2 and subordinate CAs.


Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)

“CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, a version history table provides evidence of compliance and good change management practices.

Should be fixed – Section 9.12.1 of the CPS should be revised to state something to the effect that “KIR updates the CPS on at least an annual basis, even if there are no other changes, and implements the latest version of the CA/Browser Forum Baseline Requirements.”


Statement of Non-Delegation for Domain Validation (BR § 1.3.2)

“With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”

Should be fixed – Section 1.3.3 of the CPS (this should be section 1.3.2, according to RFC 3647), should explicitly say that KIR does not delegate domain validation to any third parties, e.g. “Tasks of registration authorities are carried out only by organisational units of KIR, and no third parties are delegated responsibility to perform domain validation.” (Because the email trust bit is enabled for KIR, this applies to the domain part of an email address (see below), too, in the event that KIR is deploying email certificates through an enterprise RA.)


Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3)

“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”

Needs to be fixed – Section 1.5.2 of the CPS needs to tell subscribers and third parties where and how they can report “suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.”


Naming compliant with X.500, RFC5280, and Baseline Requirements

The structure and use of names in certificates must comply with the Baseline Requirements, and other standards such as X.500 and RFC 5280.

Should be fixed – Sections 3.1, 3.2.2, 7.1.2 and 7.1.3 of the CPS adequately discuss naming for end entity certificates but do not reference KIR’s compliance with X.500, RFC 5280 and the Baseline Requirements. Section 3.1 or 7.1.4. of the CPS should contain KIR’s commitment to comply with naming schemes required by X.500, RFC 5280 and the Baseline Requirements.


No internal names or reserved IP addresses (BR § 7.1.4.2.1)

“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”

Good – Section 7.1.3 of the CPS says, “SSL certificates may not contain IP addresses in the subject and subjectAltName fields. Additionally, certificates in the subject and subjectAltName fields may not contain domain names that are not registered in the DNS system.” So Reserved IP Addresses and internal host names in certificates should not be a problem. The CPS also contains several other instances where Fully Qualified Domain Names are specified. E.g. CPS Section 3.1 says, “Name of the internet domain interested in the internet DNS system for which the certificate has been issued”. Section 3.1.1. says, “In particular, the subscriber's distinguished name for an SSL certificate should contain a Fully Qualified Domain Name (FQDN).” And section 1.4.1 says, “Certificates of that type may be issued only for servers that operate in public networks and have a non-ambiguous domain name defining location of a specific node in the DNS system (FQDN - Fully Qualified Domain Name)”


ALL certificates must meet Mozilla/BR validation requirements

CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)

CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.

[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used by a man-in-the-middle to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]

Needs to be fixed – Please make reference to the specific subsections in section 3.2.2.4 of the CA/Brower Forum’s Baseline Requirements for validation steps taken to verify an FQDN. CPS Section 3.2.2 states:

• confirming control over the requested Domain Name by placing indicated by KIR random data in file kirdv.txt under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation. The file with random data has to be accessible by KIR via HTTP or HTTPS over an Authorized Port. Random data in file is unique for every certificate request, does not appear in the request and data is not older than 30 days.;

• the alternative way of checking the control over the requested Domain Name is placing the random data given by KIR in DNS record TXT, CAA or CNAME type. Random data sent by KIR are unique for each validation and they are not older than 30 days, and CAA record checked not earlier than 8 hours before certificate generation;

In other words, the CPS should additionally state that KIR complies with BR section 3.2.2.4.18 Agreed-Upon Change to Website v2 and 3.2.2.4.7 DNS Change.


CA validates domain part of all e-mail addresses (MRSP § 2.2.2)

“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”

Needs to be fixed – The CPS needs to say that KIR performs a challenge-response verification for email addresses included in SMIME certificates (or at least it will validate the domain part for email addresses included in SMIME certificates issued in the context of an enterprise RA). See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control


Data sources need to be accurate (BR § 3.2.2.7)

“[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”

Needs to be fixed – CPS sections 3.1.4, 3.2, and 3.2.2 discuss reliable information sources. However, KIR needs to disclose its process for determining that a third-party data source is reliable. Section 3.2.2.7 of the Baseline Requirements says, “The CA SHOULD consider the following during its evaluation:

\1. The age of the information provided,

\2. The frequency of updates to the information source,

\3. The data provider and purpose of the data collection,

\4. The public accessibility of the data availability, and

\5. The relative difficulty in falsifying or altering the data.”


All information in a certificate must be verified (MRSP § 2.2.1)

“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”

Needs to be fixed – Section 3.2.4 of the CPS should state, “All information in the certificate is verified.”


Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)

CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”, and “for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated in accordance with section 3.2.2 of the CA/Browser Forum's Baseline Requirements within the prior 398 days.”

Needs clarification – CPS section 6.3.2 states, “The maximum validity period of SSL certificates is 398 days from the date of certificate generation.” However, it is unclear whether KIR uses any information collected from previous certificate requests. Section 3.3 of the CPS says, “Verification of the agreement validity and data included in the agreement and in the order shall be done in accordance with Clause 3.2.” This implies that all information is collected and verification is re-performed for every single renewed certificate. KIR needs to state more clearly whether it reuses any data.


CAA record checking and recognized domain names in section 4.2 (BR § 2.2)

“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”

Good – Section 4.2.4 of the CPS says, “Before generating the certificate, KIR checks Certification Authorities Authorization (CAA) records, authorizing certificate authorities to issue certificates for given domains. If the CAA record is present, then KIR generates the certificate only if the CAA records include the following name: elektronicznypodpis.pl.”


Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3)

CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.

Needs to be fixed – I could not find the phrase “multi-factor authentication” in conjunction with “accounts capable of causing certificate issuance”.


Pre-issuance linting (Recommended Practices)

“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences.”

Should be fixed – Pre-issuance linting does not appear to be mentioned in the CPS.


Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)

24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

Needs to be fixed – Please refer to sections 4.9.1.1 and 4.9.1.2 of the Baseline Requirements. There are two parts to BR section 4.9.1.1, including mandatory 24-hour revocation for the five reasons set forth therein. E.g., “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys”. KIR should carefully review both section 4.9.1.1 and section 4.9.1.2 of the Baseline Requirements and ensure that it has adequately addressed the revocation reasons and timeframes from the BRs.


SMIME Reasons for Revocation (MRSP § 6.2)

“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events … [e.g. MRSP § 6.2, ”5. the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted;”]

Needs to be fixed – KIR should review MRSP section 6.2 and make sure it has covered the revocation reasons for SMIME certificates.


CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)

Adequate –Section 4.9.7 of the CPS says, “CRLs for certificates issued by the operational certification authority Szafir Trusted CA shall be published always after certificate suspension or revocation, however, not less frequently than every 24 hours.” (KIR should ensure that the nextUpdate for CRLs is less than 10 days.)


Clearly specify methods to demonstrate private key compromise (MRSP § 6)

Needs to be fixed - Mozilla now requires that Section 4.9.12 of the CP/CPS describes the method by which any party can demonstrate private key compromise to KIR. KIR needs to renumber this section so that section 4.9.13 is suspension. See next.


CA must not allow certificate suspension (BR § 4.9.13)

Needs to be fixed. Section 4.9.12 of the CPS appears to allow certificate suspension. This is prohibited for TLS server certificates.


OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)

Needs to be fixed – Section 4.9.9 does not disclose how often KIR updates OCSP responses and their validity period.


Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)

“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”

Needs to be fixed – KIR needs to ensure that its disaster recovery and key compromise plans require that someone immediately notify Mozilla and other root stores that have trusted the KIR PKI hierarchy. This requirement on KIR should be made clear in the CPS.


CA must not generate Subscriber key pairs (MRSP § 5.2)

“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”

Needs to be fixed – Section 6.1.1 of the CPS says “Keys for subscribers may also be generated by the Szafir Trusted CA both in the cryptographic cards or in the form of files. Keys generated in files are password protected.” However, it should say that KIR never generates key pairs for server certificates.


Must meet RSA key requirements (MRSP § 5.1)

Could be improved – CPS section 6.1.5 says, “SSL Certificates shall be issued for RSA keys having the length at least of 2048 bits and SHA-256 hash functions.” However, sections 6.1.5 and 6.1.6 could be improved after a review of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#511-rsa, etc. and corresponding sections of the Baseline Requirements. Pre-issuance linting may also provide KIR with additional safeguards that protect KIR from mis-issuing server certificates.


Must meet ECC key requirements (MRSP § 5.1)

Could be improved – It appears from section 7.1.1 of the CPS that ECC is not supported, however, the quality of any submitted ECC key needs to be ensured. Sections 6.1.5 and 6.1.6 could be improved with reference to

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#512-ecdsa

and corresponding sections of the Baseline Requirements. Pre-issuance linting may also provide KIR with additional safeguards that protect KIR from mis-issuing server certificates.


Certificate lifetimes limited to 398 days (BR § 6.3.2)

“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”

Good – CPS section 6.3.2 states, “The maximum validity period of SSL certificates is 398 days from the date of certificate generation.”


Network Security (MRSP § 2.1.2)

CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.

Needs to be fixed – Section 6.7 of the CPS states, “Access to the communication and IT system in which trust services are provided shall be protected at the level specified in the law for qualified trust services. Supervision over security of the computer networks of KIR is exercised by qualified staff.” Compliance with the CA/Browser Forum’s Network and Certificate System Security Requirements should be ensured with incorporation of it, in its entirety, by reference. See https://cabforum.org/network-security-requirements/ .


Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)

“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”

Needs to be fixed – Section 7.1 of the CPS concerning serial numbers does not recite this specification.


EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)

Good – The EKUs of end entity server certificates can contain both serverAuth and clientAuth but the anyExtendedKeyUsage EKU cannot be present. Section 7.1 says, “In case of SSL certificates extension extendedKeyUsage includes the following values: serverAuthentication and clientAuthentication.”


Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1)

Good – Section 7.1.1 of the CPS states, “SSL Certificates shall be issued for RSA keys having the length at least of 2048 bits and SHA-256 hash functions.”


Any CN must also be in a SAN (BR § 7.1.4.2.2.a)

Needs to be fixed – The CPS should state that any commonName field in the certificate Subject DN has to be one of the FQDN SANs that has been validated pursuant to one of the allowed methods in BR section 3.2.2.4.

Ben, Thank you very much for reviewing our CPS and your comments. As we currenly are in process of our internal review we will take all your remarks into account. According to the survey, the new version of the CPS will be released by the end of June.

No specific update here. New version of the CPS will be released by the end of June as scheduled.

(In reply to Piotr Grabowski from comment #7)

We use only 2 methods:
3.2.2.4.6 Agreed-Upon Change to Website
3.2.2.4.7 DNS Change

In re-reviewing this incident, I can't find discussion of this statement here. The closest is Ben's fantastic deep review (Comment #20), but it would appear by all evidence that KIR S.A. has disclosed that they have fundamentally misissued certificates here.

Piotr: Please carefully review Bug 1715455 and Bug 1706967 as two example incidents, which KIR S.A. should have been aware of, in addition to the thread by Corey Bonnell. 3.2.2.4.6 has been forbidden by the BRs since 2020-06-03. It would appear that 100% of the certificates you've issued using this method, based on your disclosure, would be in violation of the BRs and your CP/CPS, and thus need revocation.

I apologize for overlooking so serious a disclosure, but this is a rather significant failing.

Flags: needinfo?(piotr.grabowski)

Ben, Thank you once again for the review. I have added inline comments to your analysis.

(In reply to Ben Wilson from comment #20)

Here are my findings after a brief review of the KIR CPS.

Review of v. 1.14 of the Certification Practice Statement of KIR for Trusted Non-Qualified Certificates (“CPS”), dated April 30, 2021.

General notes: “Foreward” should be replaced with “Foreword”. Also, KIR should start replacing references to “SSL” with the more modern term, “TLS”.

Typo corrected. SSL replaced with TLS.


CP/CPS structured in accordance with RFC 3647 with no blank sections (MRSP § 3.3.5) (BR § 2.2)

Needs to be fixed – The CPS does not follow RFC 3647 throughout. This is especially true for CPS section numbers 1.3.3, 1.5.1, 1.5.2, 4.9.12, and sections 7.1.1 through 7.1.6. See comments below regarding section 1.3.3 (Registration authorities should be section 1.3.2), 1.5.2 (should be Contact person where KIR needs to state a means for third parties to submit certificate problem reports and revocation requests), 4.9.12 (should be revocation for key compromise) and section 7.1.4 (should be Name forms).

We mostly adjusted these sections to be fully structured in accordance with RFC 3647. Final improvement will be made in the next CPS revision.


CP/CPS made available under a Creative Commons License (MRSP § 3.3.3)

“CPs and CPSes are made available to Mozilla under one of the following Creative Commons licenses (or later versions)”

Adequate – Section 9.5 of the CPS states, “Copyright to this document is held by Krajowa Izba Rozliczeniowa It may be used solely for the purposes of using certificates. Any other uses, including the entire or part of the document shall require a written consent of Krajowa Izba Rozliczeniowa, provided that KIR expresses its consent to copying and publishing this document in its entirety.” Nothing appears to contradict the license required by Mozilla, but a more permissive license for the use of the CPS would be better.

No changes here.


Statement of adherence to BRs/EVGs and their precedence (MRSP § 2.3) (BR § 2.2 / EVG 8.3)

“The CA SHALL publicly give effect to these Requirements and represent that it will adhere to the latest published version”, including a statement such as “in the event of any inconsistency between this CP/CPS and those Requirements, those Requirements take precedence.”

Section 8.3 of the EV Guidelines contains a similar provision – “In the event of any inconsistency between this document and those Guidelines, those Guidelines take precedence over this document.”

Should be fixed – Section 1.1 of the CPS states, “KIR provides trust services in compliance with the requirements of the current version of the Baseline Requirements Certification Policy for the Issuance and Management of Publicly- Trusted Certificates published at www.cabforum.org. In the event of any discrepancies between the CSP and the said document, the document shall prevail over the CSP.” “CSP” is a typo. The last sentence would be better worded, “In the event of any discrepancies between the CPS and the Baseline Requirements, said document shall prevail over the CPS.”

Section 1.1 adjusted. Typo corrected.


Separate, EKU-constrained issuing CAs (MRSP § 5.3) (BR § 7.1.2.2.g.)

Intermediate CAs must have an EKU, not the anyEKU EKU, and not both serverAuth and an emailProtection, codesigning, or timeStamping EKU.

Should be clarified – Section 7.1 lists the types of EKUs and what they are for: “clientAuthentication – verification of the customer’s certificate, serverAuthentication – verification of the server’s certificate, codeSigning – for signing the application code, emailProtection – for electronic mail protection”, but I did not see separate certificate profiles for EKUs for issuing CAs. Section 7.1 does say, “In case of SSL certificates extension extendedKeyUsage includes the following values: serverAuthentication and clientAuthentication.” However, this requirement only applies to intermediate CAs created after January 1, 2019. A review of the SZAFIR Trusted CA2 created in 2015 shows that these EKUs are not in the Issuing CA that is currently in use.

We placed extensions and EKU for current ROOT i subCA in 7.1.2. Certificate Extensions (7.1.2.1. KIR root certificate, 7.1.2.2. KIR subordinate Certificate)


Clear identification of CAs covered by CP/CPS (MRSP § 3.3.6)

“CAs must provide a way to clearly determine which CP and CPS applies to each of its root and intermediate certificates.”

OK – Sections 1 and 2 of the CPS mention the Szafir Root CA and the Szafir Root CA2 and subordinate CAs.

No changes here.


Explicit annual revision of CP/CPS w/ table of changes (MRSP § 3.3.4) (BR § 2.3)

“CPs and CPSes MUST be reviewed and updated as necessary at least once every year, as required by the Baseline Requirements. CAs MUST indicate that this has happened by incrementing the version number and adding a dated changelog entry, even if no other changes are made to the document.” Also, a version history table provides evidence of compliance and good change management practices.

Should be fixed – Section 9.12.1 of the CPS should be revised to state something to the effect that “KIR updates the CPS on at least an annual basis, even if there are no other changes, and implements the latest version of the CA/Browser Forum Baseline Requirements.”

Section 9.12.1 adjusted.


Statement of Non-Delegation for Domain Validation (BR § 1.3.2)

“With the exception of sections 3.2.2.4 and 3.2.2.5, the CA MAY delegate the performance of all, or any part, of Section 3.2 requirements to a Delegated Third Party, provided that the process as a whole fulfills all of the requirements of Section 3.2.”

Should be fixed – Section 1.3.3 of the CPS (this should be section 1.3.2, according to RFC 3647), should explicitly say that KIR does not delegate domain validation to any third parties, e.g. “Tasks of registration authorities are carried out only by organisational units of KIR, and no third parties are delegated responsibility to perform domain validation.” (Because the email trust bit is enabled for KIR, this applies to the domain part of an email address (see below), too, in the event that KIR is deploying email certificates through an enterprise RA.)

Section 1.3.2 adjusted.


Clear problem reporting instructions in section 1.5.2 (BR § 4.9.3)

“The CA SHALL provide Subscribers, Relying Parties, Application Software Suppliers, and other third parties with clear instructions for reporting suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates. The CA SHALL publicly disclose the instructions through a readily accessible online means and in section 1.5.2 of their CPS.”

Needs to be fixed – Section 1.5.2 of the CPS needs to tell subscribers and third parties where and how they can report “suspected Private Key Compromise, Certificate misuse, or other types of fraud, compromise, misuse, inappropriate conduct, or any other matter related to Certificates.”

Section 1.5.2 adjusted.


Naming compliant with X.500, RFC5280, and Baseline Requirements

The structure and use of names in certificates must comply with the Baseline Requirements, and other standards such as X.500 and RFC 5280.

Should be fixed – Sections 3.1, 3.2.2, 7.1.2 and 7.1.3 of the CPS adequately discuss naming for end entity certificates but do not reference KIR’s compliance with X.500, RFC 5280 and the Baseline Requirements. Section 3.1 or 7.1.4. of the CPS should contain KIR’s commitment to comply with naming schemes required by X.500, RFC 5280 and the Baseline Requirements.

Section 3.1 adjusted.


No internal names or reserved IP addresses (BR § 7.1.4.2.1)

“CAs SHALL NOT issue certificates with a subjectAltName extension or subject:commonName field containing a Reserved IP Address or Internal Name.”

Good – Section 7.1.3 of the CPS says, “SSL certificates may not contain IP addresses in the subject and subjectAltName fields. Additionally, certificates in the subject and subjectAltName fields may not contain domain names that are not registered in the DNS system.” So Reserved IP Addresses and internal host names in certificates should not be a problem. The CPS also contains several other instances where Fully Qualified Domain Names are specified. E.g. CPS Section 3.1 says, “Name of the internet domain interested in the internet DNS system for which the certificate has been issued”. Section 3.1.1. says, “In particular, the subscriber's distinguished name for an SSL certificate should contain a Fully Qualified Domain Name (FQDN).” And section 1.4.1 says, “Certificates of that type may be issued only for servers that operate in public networks and have a non-ambiguous domain name defining location of a specific node in the DNS system (FQDN - Fully Qualified Domain Name)”

No changes here.


ALL certificates must meet Mozilla/BR validation requirements

CPS must specifically explain validation methods and validation steps taken to verify certificate requests in accordance with BR §§ 3.2.2.4 and 3.2.2.5 (MRSP § 2.2.3 and MRSP § 3.3.1)

CP/CPS must be sufficient “for Mozilla to determine whether and how the CA complies with this policy, including a description of the steps taken by the CA to verify certificate requests”.

[Note: It is also recommended that CAs ensure that the domain name registrant has approved or authorized a certificate request such that the certificate cannot be used by a man-in-the-middle to facilitate surreptitious interception by third parties (except with the domain registrant's permission).]

Needs to be fixed – Please make reference to the specific subsections in section 3.2.2.4 of the CA/Brower Forum’s Baseline Requirements for validation steps taken to verify an FQDN. CPS Section 3.2.2 states:

• confirming control over the requested Domain Name by placing indicated by KIR random data in file kirdv.txt under the "/.well-known/pki-validation" directory, or another path registered with IANA for the purpose of Domain Validation. The file with random data has to be accessible by KIR via HTTP or HTTPS over an Authorized Port. Random data in file is unique for every certificate request, does not appear in the request and data is not older than 30 days.;

• the alternative way of checking the control over the requested Domain Name is placing the random data given by KIR in DNS record TXT, CAA or CNAME type. Random data sent by KIR are unique for each validation and they are not older than 30 days, and CAA record checked not earlier than 8 hours before certificate generation;

In other words, the CPS should additionally state that KIR complies with BR section 3.2.2.4.18 Agreed-Upon Change to Website v2 and 3.2.2.4.7 DNS Change.

We have made clear references to compliance with BR section 3.2.2.4.18 Agreed-Upon Change to Website v2 and 3.2.2.4.7 DNS Change.
Until now, the statement has been ambiguous indeed. Regarding my comment in this bug saying that we are using forbidden method 3.2.2.4.6 Agreed-Upon Change to Website: it was of course a typo. I am very sorry for the confusion I have made.


CA validates domain part of all e-mail addresses (MRSP § 2.2.2)

“For a certificate capable of being used for digitally signing or encrypting email messages, the CA takes reasonable measures to verify that the entity submitting the request controls the email account associated with the email address referenced in the certificate or has been authorized by the email account holder to act on the account holder’s behalf. The CA SHALL NOT delegate validation of the domain portion of an email address.”

Needs to be fixed – The CPS needs to say that KIR performs a challenge-response verification for email addresses included in SMIME certificates (or at least it will validate the domain part for email addresses included in SMIME certificates issued in the context of an enterprise RA). See https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Email_Challenge-Response and https://wiki.mozilla.org/CA/Required_or_Recommended_Practices#Verifying_Email_Address_Control

Section 3.2.2 adjusted


Data sources need to be accurate (BR § 3.2.2.7)

“[For a] Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification.”

Needs to be fixed – CPS sections 3.1.4, 3.2, and 3.2.2 discuss reliable information sources. However, KIR needs to disclose its process for determining that a third-party data source is reliable. Section 3.2.2.7 of the Baseline Requirements says, “The CA SHOULD consider the following during its evaluation:

\1. The age of the information provided,

\2. The frequency of updates to the information source,

\3. The data provider and purpose of the data collection,

\4. The public accessibility of the data availability, and

\5. The relative difficulty in falsifying or altering the data.”

Section 3.2.2 adjusted. Trusted sources link added.


All information in a certificate must be verified (MRSP § 2.2.1)

“All information that is supplied by the certificate subscriber MUST be verified by using an independent source of information or an alternative communication channel before it is included in the certificate.”

Needs to be fixed – Section 3.2.4 of the CPS should state, “All information in the certificate is verified.”

Section 3.2.4 adjusted.


Data reuse (certificate renewal) limited to 398 and 825 days (MRSP § 2.1.5) (BR § 4.2.1)

CAs must “verify that all of the information that is included in SSL certificates remains current and correct at time intervals of 825 days or less”, and “for server certificates issued on or after October 1, 2021, each dNSName or IPAddress in a SAN or commonName MUST have been validated in accordance with section 3.2.2 of the CA/Browser Forum's Baseline Requirements within the prior 398 days.”

Needs clarification – CPS section 6.3.2 states, “The maximum validity period of SSL certificates is 398 days from the date of certificate generation.” However, it is unclear whether KIR uses any information collected from previous certificate requests. Section 3.3 of the CPS says, “Verification of the agreement validity and data included in the agreement and in the order shall be done in accordance with Clause 3.2.” This implies that all information is collected and verification is re-performed for every single renewed certificate. KIR needs to state more clearly whether it reuses any data.

Section 4.2.1 adjusted.
For TLS certificates KIR may reuse the previous domain validations provided if they were successfully
performed not later than 12 months before issuance of a new certificate.


CAA record checking and recognized domain names in section 4.2 (BR § 2.2)

“Section 4.2 of a CA’s Certificate Policy and/or Certification Practice Statement SHALL state the CA’s policy or practice on processing CAA Records for Fully Qualified Domain Names; that policy shall be consistent with these Requirements.”

Good – Section 4.2.4 of the CPS says, “Before generating the certificate, KIR checks Certification Authorities Authorization (CAA) records, authorizing certificate authorities to issue certificates for given domains. If the CAA record is present, then KIR generates the certificate only if the CAA records include the following name: elektronicznypodpis.pl.”

No changes here.


Accounts capable of certificate issuance must have multi-factor authentication (MRSP § 2.1.3)

CAs must “enforce multi-factor authentication for all accounts capable of causing certificate issuance or performing Registration Authority or Delegated Third Party functions, or implement technical controls operated by the CA to restrict certificate issuance through the account to a limited set of pre-approved domains or email addresses”.

Needs to be fixed – I could not find the phrase “multi-factor authentication” in conjunction with “accounts capable of causing certificate issuance”.

Section 6.5.1 adjusted. We had phrase multi-level so far, but we added multi-factor in separate sentence.


Pre-issuance linting (Recommended Practices)

“It is strongly recommended that CAs integrate such tools …. Because BR or RFC violations are generally considered by Mozilla to be misissuance, such integration will reduce the number of misissuance events a CA experiences.”

Should be fixed – Pre-issuance linting does not appear to be mentioned in the CPS.

Section 4.3 adjusted. Last sentence in the section.


Revocation in accordance with BR section 4.9.1 (MRSP § 6.1) (BR §§ 4.9.1.1 and 4.9.1.2)

24-hour revocation for reasons (1)-(5); 5 days for reasons (1)-(11) and 7 days for Intermediate CAs reasons (1) – (9)

Needs to be fixed – Please refer to sections 4.9.1.1 and 4.9.1.2 of the Baseline Requirements. There are two parts to BR section 4.9.1.1, including mandatory 24-hour revocation for the five reasons set forth therein. E.g., “The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys”. KIR should carefully review both section 4.9.1.1 and section 4.9.1.2 of the Baseline Requirements and ensure that it has adequately addressed the revocation reasons and timeframes from the BRs.

Sections 4.9.1.1 and 4.9.1.2 appllied.


SMIME Reasons for Revocation (MRSP § 6.2)

“For any certificate in a hierarchy capable of being used for S/MIME, CAs MUST revoke certificates upon the occurrence of any of the following events … [e.g. MRSP § 6.2, ”5. the CA receives notice or otherwise becomes aware of any circumstance indicating that use of the email address in the certificate is no longer legally permitted;”]

Needs to be fixed – KIR should review MRSP section 6.2 and make sure it has covered the revocation reasons for SMIME certificates.

We covered the revocation reasons for SMIME certificates in sestion 4.9..1


CRLs at least every 7 days w/ nextUpdate not more than 10 days (MRSP § 6)

Adequate –Section 4.9.7 of the CPS says, “CRLs for certificates issued by the operational certification authority Szafir Trusted CA shall be published always after certificate suspension or revocation, however, not less frequently than every 24 hours.” (KIR should ensure that the nextUpdate for CRLs is less than 10 days.)

No changes here.


Clearly specify methods to demonstrate private key compromise (MRSP § 6)

Needs to be fixed - Mozilla now requires that Section 4.9.12 of the CP/CPS describes the method by which any party can demonstrate private key compromise to KIR. KIR needs to renumber this section so that section 4.9.13 is suspension. See next.

4.9.11. Special Responsibilities When a Key Has Been Compromised
4.9.12. Terms and Conditions of Certificate Suspension
4.9.13. Who May Request Certificate Suspension?


CA must not allow certificate suspension (BR § 4.9.13)

Needs to be fixed. Section 4.9.12 of the CPS appears to allow certificate suspension. This is prohibited for TLS server certificates.

We don't suspend TLS certificates. We have an exception in 4.9..12: With the exception of TLS and test certificates, KIR may suspend a certificate ..


OCSP updates every 4 days w/ max. expiration of 10 days (MRSP § 6)

Needs to be fixed – Section 4.9.9 does not disclose how often KIR updates OCSP responses and their validity period.

Section 4.9.10 discloses the validity period of OCSP response.


Provide Mozilla notice immediately upon private CA key compromise (MRSP § 7)

“Changes that are motivated by a security concern such as certificate misissuance or a root or intermediate compromise MUST be treated as a security-sensitive, and a secure bug filed in Bugzilla.”

Needs to be fixed – KIR needs to ensure that its disaster recovery and key compromise plans require that someone immediately notify Mozilla and other root stores that have trusted the KIR PKI hierarchy. This requirement on KIR should be made clear in the CPS.

Section 5.7.3 p. 2


CA must not generate Subscriber key pairs (MRSP § 5.2)

“CAs MUST NOT generate the key pairs for end-entity certificates that have an EKU extension containing the KeyPurposeIds id-kp-serverAuth or anyExtendedKeyUsage.”

Needs to be fixed – Section 6.1.1 of the CPS says “Keys for subscribers may also be generated by the Szafir Trusted CA both in the cryptographic cards or in the form of files. Keys generated in files are password protected.” However, it should say that KIR never generates key pairs for server certificates.

Section 6.1.1
For TLS certificates KIR does not generate private keys on behalf of subscribers, but it may do so for other types of certificates. It was stated in section 4.3. previously, but to clarify it we have added also to section 6.1.1


Must meet RSA key requirements (MRSP § 5.1)

Could be improved – CPS section 6.1.5 says, “SSL Certificates shall be issued for RSA keys having the length at least of 2048 bits and SHA-256 hash functions.” However, sections 6.1.5 and 6.1.6 could be improved after a review of https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#511-rsa, etc. and corresponding sections of the Baseline Requirements. Pre-issuance linting may also provide KIR with additional safeguards that protect KIR from mis-issuing server certificates.

To be improved with next CPS revision.


Must meet ECC key requirements (MRSP § 5.1)

Could be improved – It appears from section 7.1.1 of the CPS that ECC is not supported, however, the quality of any submitted ECC key needs to be ensured. Sections 6.1.5 and 6.1.6 could be improved with reference to

https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/#512-ecdsa

and corresponding sections of the Baseline Requirements. Pre-issuance linting may also provide KIR with additional safeguards that protect KIR from mis-issuing server certificates.

To be improved with next CPS revision.


Certificate lifetimes limited to 398 days (BR § 6.3.2)

“Subscriber Certificates … SHOULD NOT have a Validity Period greater than 397 days and MUST NOT have a Validity Period greater than 398 days.”

Good – CPS section 6.3.2 states, “The maximum validity period of SSL certificates is 398 days from the date of certificate generation.”

No changes here.


Network Security (MRSP § 2.1.2)

CAs must “follow industry best practice for securing their networks, for example by conforming to the CAB Forum Network Security Guidelines or a successor document”.

Needs to be fixed – Section 6.7 of the CPS states, “Access to the communication and IT system in which trust services are provided shall be protected at the level specified in the law for qualified trust services. Supervision over security of the computer networks of KIR is exercised by qualified staff.” Compliance with the CA/Browser Forum’s Network and Certificate System Security Requirements should be ensured with incorporation of it, in its entirety, by reference. See https://cabforum.org/network-security-requirements/ .

Section 6.7 adjusted.


Serial numbers greater than 64 bits generated by a CSPRNG (MRSP § 5.2)

“all new certificates MUST have a serial number greater than zero, containing at least 64 bits of output from a CSPRNG.”

Needs to be fixed – Section 7.1 of the CPS concerning serial numbers does not recite this specification.

serialNumber description in table in section 7.1 extended.


EKUs required in certificates issued after 7-1-2020 (MRSP § 5.2) (BR § 7.1.2.3.f)

Good – The EKUs of end entity server certificates can contain both serverAuth and clientAuth but the anyExtendedKeyUsage EKU cannot be present. Section 7.1 says, “In case of SSL certificates extension extendedKeyUsage includes the following values: serverAuthentication and clientAuthentication.”

No changes here.


Use of SHA-1 prohibited (MRSP § 5.1.3) (BR § 7.1.3.2.1)

Good – Section 7.1.1 of the CPS states, “SSL Certificates shall be issued for RSA keys having the length at least of 2048 bits and SHA-256 hash functions.”

No changes here.


Any CN must also be in a SAN (BR § 7.1.4.2.2.a)

Needs to be fixed – The CPS should state that any commonName field in the certificate Subject DN has to be one of the FQDN SANs that has been validated pursuant to one of the allowed methods in BR section 3.2.2.4.

Description of CommonName in table in section 3.1 extended.

(In reply to Ryan Sleevi from comment #23)

(In reply to Piotr Grabowski from comment #7)

We use only 2 methods:
3.2.2.4.6 Agreed-Upon Change to Website
3.2.2.4.7 DNS Change

In re-reviewing this incident, I can't find discussion of this statement here. The closest is Ben's fantastic deep review (Comment #20), but it would appear by all evidence that KIR S.A. has disclosed that they have fundamentally misissued certificates here.

Piotr: Please carefully review Bug 1715455 and Bug 1706967 as two example incidents, which KIR S.A. should have been aware of, in addition to the thread by Corey Bonnell. 3.2.2.4.6 has been forbidden by the BRs since 2020-06-03. It would appear that 100% of the certificates you've issued using this method, based on your disclosure, would be in violation of the BRs and your CP/CPS, and thus need revocation.

I apologize for overlooking so serious a disclosure, but this is a rather significant failing.

Ryan, Ben, I apologize again for the confusion I created with my comment. I can't believe I was able to make such a mistake myself. I guess in my haste I copied the wrong http validation method number into my comment. I can't find any other reasonable explanation. In the case of http at the time of writing https://bugzilla.mozilla.org/show_bug.cgi?id=1705904#c7 of course we used and continue to use only the allowed validation method 3.2.2.4.18 Agreed-Upon Change to Website v2. We additionally have a clear reference in the new CPS v1.15 to this method. Thank you very much in advance for your understanding.

No update here . Are there any additional questions?

I intend to close this bug on or about Wed. 14-July-2021.

Status: ASSIGNED → RESOLVED
Closed: 20 days ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.