Bugzilla

(In reply to Piotr Grabowski from comment #9)
> > 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. 
>   
> 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.

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

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

(In reply to Piotr Grabowski from comment #9)
> > 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. 
>   
> 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.

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

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