Closed Bug 1705657 Opened 8 months ago Closed 4 months ago

KIR S.A.: Many certificates with OCSP Unknown

Categories

(NSS :: CA Certificate Compliance, task)

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: michel, Assigned: piotr.grabowski)

Details

(Whiteboard: [ca-compliance])

Attachments

(4 files)

Attached file 4364227155_ocsp.txt

Hello,
I found many certificates with OCSP Unknown:

CRL Not Revoked, issues recently:
https://crt.sh/?id=4364227155&opt=ocsp
https://crt.sh/?id=4364230681&opt=ocsp

CRL Revoked:
https://crt.sh/?id=2886005219&opt=ocsp
https://crt.sh/?id=2886013550&opt=ocsp
https://crt.sh/?id=2886124820&opt=ocsp
https://crt.sh/?id=2688712040&opt=ocsp
https://crt.sh/?id=2688725947&opt=ocsp
https://crt.sh/?id=2688961161&opt=ocsp
https://crt.sh/?id=2688657539&opt=ocsp
https://crt.sh/?id=2688662261&opt=ocsp
https://crt.sh/?id=2688673395&opt=ocsp
https://crt.sh/?id=2688697359&opt=ocsp
https://crt.sh/?id=2527478648&opt=ocsp
https://crt.sh/?id=2527165585&opt=ocsp
There can be more.

That makes me think that it's possible that the practice explained in https://bugzilla.mozilla.org/show_bug.cgi?id=1523186#c10 has not stopped even tho at no point it was found to be acceptable. The CPS at https://www.elektronicznypodpis.pl/gfx/elektronicznypodpis/userfiles/_public/information/legal_basis/20200918_certification_practice_statement_kir_trusted_nq_certificates.pdf (listed in https://ccadb-public.secure.force.com/mozilla/IncludedCACertificateReport) states:

1)Good –means that the certificate has been issued by KIR and is not in CRL issued by KIR.
2)Revoke –means that a specific certificate has been issued by KIR and is in CRL,i.e. it has been revoked
3)Unknown –means  that  a  certificate  has  not  been  issued  by KIR and  the  status  of  such certificate is not known.

My understanding is that a certificate that has been issued by KIR can't have the Unknown status.

Assignee: bwilson → piotr.grabowski
Status: NEW → ASSIGNED
Whiteboard: [ca-compliance]

For a quick explanation we made a big effort to apply procedural controls to stop this practice bacause technical change was too big challage for us at the time, but it looks like there is no other way and we have to implement it finally. I think I will report incident here in order you have a full overview about the progress.

I queried OCSP about all certificates that are in CRL. 123 are revoked, 446 unknown. Also, most of the certificates listed there are not on crt.sh, so I can't inspect them and check what was wrong. Did KIR send all issued certificates to CT? It might just be a crt.sh issue...

Attached file ocsp_crl.txt

The CA is issuing not only SSL/TLS
certificates but for end user for Digital Signature as well, which are not sent to crt.sh, so it is normal that you can't find them there.

(In reply to Piotr Grabowski from comment #1)

For a quick explanation we made a big effort to apply procedural controls to stop this practice bacause technical change was too big challage for us at the time, but it looks like there is no other way and we have to implement it finally. I think I will report incident here in order you have a full overview about the progress.

This is an unacceptable response, and completely inappropriate for a trusted CA to even consider. "We thought about compliance, but gave up, because it was hard, but I guess we have to do it" is not the sign of a trustworthy CA in the slightest, especially in light of Bug 1523186.

I cannot help but think that in light of the complete failure on that issue (including actively deceiving the Mozilla community in Bug 1523186), and then failing to implement the necessary mitigations, as shown by this issue, and combined with issues like Bug 1705832 and Bug 1705187, that the both necessary and appropriate step is to begin discussions about removing this CA, because it cannot be trusted to have implemented the necessary security controls, nor management to understand and communicate when issues occur. This bug is yet another example of a critical security failure that should see all issuance halted, at a minimum, but realistically can only be remediated by complete removal of trust.

Flags: needinfo?(bwilson)

Ryan,
Sorry, but I was completely misunderstood or I expressed myself in wrong way. The procedural controls were the only one that can be implemented then, we started the process of analysis of technical mitigation but it is hard - we didn't give up.

From the management point of view we keep on constant improving both: our procedures and used software. Although the overall number of errors has decreased significantly we still are very concerned about new incidents that comes from KIR CA.
Last year we initiated the project of automating the process of generating certificates. The project is complexed and it covers all steps of certificates pre-validation and certificates generation. After it will be finished it eliminates all human mistakes. The project is now in implementing faze and it is planned to be finished this year.

Bearing in mind the 3 last issues/incidents (Bug 1705657, Bug 1705832, Bug 1705187, - after management review we decided to do immediately as follows.

As a emergency measures:

For Bug 1705657 :

  • to scan all certificates and put even unissued ones in OCSP.
  • to implement automatic mechanism for placing unissued certificates in OCSP
  • both changes will be carried out in the highest priority max till the end of next week with the supervision of the management.
    Please bear in mind that this issue concerns the certificates that were generated but not issued to the clients. This mechanism was recommended but eIDAS auditor. But as it generates inconsistences we change it.

For Bug Bug 1705832:

  • the dedicated patch was implemented in August 2020 and the problem has not repeated since that time. The patch completely eliminated operators mistakes.

For Bug Bug 1705187:

  • patch request was sent to the vendor, the certificate was revoked ASAP after generating and incorrect verification result. The certificate was not delivered to the client.

The possibility of any mistakes will be completely eliminated after implementing the changes mentioned at the beginning. Till the project will be finished we have already started additionally a deep analysis and specific tasks have been delegated to right resources:

  • to review all current business processes and procedures related to issuing certificates.
  • with a cooperation with software vendor perform weak point analysis and show all places for improvement and potential flaws.

placing unissued certificates in OCSP

Should I understand unissued as signed by the CA, but not delivered to the client yet?

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

placing unissued certificates in OCSP

Should I understand unissued as signed by the CA, but not delivered to the client yet?

Yes, exactly. We don't send automatically certificates to the clients. Certificates were added to OCSP as they are delivered. Only if they were delivered to the clients, responses could be GOOD or REVOKED. A response for a certificate which was generated by CA, but not delivered to a client was UNKNOWN. Now we are changing it as it was describe in my earlier comment.

We have confirmation that a technical change will be implemented in this week.

The technical change implementation started today.

Why is this certificate https://crt.sh/?id=4409119791&opt=ocsp issued very recently also OCSP Unknown?

Attached file 4409119791_ocsp.txt

yes, we started implementing technical change yesterday for similar cases. So for now there can be some latency between the timestamps of its issuance and the timestamp of its delivery to the end-user which triggers good status. The procedural change was not enough in some cases.
The technical change should be ready by the end this week I hope.

While I appreciate the piece-meal updates here, my hope is that KIR S.A. is aware that it has not yet provided an Incident Response, as required by https://wiki.mozilla.org/CA/Responding_To_An_Incident , and so the first steps are still missing.

As part of any incident response for this, it's going to be absolutely essential for KIR S.A. to address why it failed to make this change for two years, in light of comments like https://bugzilla.mozilla.org/show_bug.cgi?id=1523186#c9 that communicated this was and is not acceptable.

This needs to be viewed as both a technical failure - and I appreciate that all of KIR S.A.'s explanations, to date, have been focused on that - as well as a systemic procedural failure by the CA. Our desire for the incident report is to understand both: in particular, how the procedural failures lead to the technical failure, and how the procedural failures are being addressed as well. This is because procedural failures can continue to cause new technical failures, even after specific technical failures are fixed, and this is not acceptable.

I encourage KIR S.A. to take several days to focus on examining other CA incident reports, such as those closed in the past two years, particularly those called out as "good" incident reports, before filing the incident report, because KIR S.A. needs to be aware it is in serious jeopardy of being removed. The risk of removal is not just because of the technical incident, but the failure to understand and recognize the procedural failures, and the failure to reassure the community that KIR S.A. fully understands and is addressing them (through clear and comprehensive communication). Understanding past incident reports - those that have been seen as problematic and those that have been seen as exemplary - seems necessary to do that, since it does not appear KIR S.A. has done so to date.

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=1705657. The issue is related to "unknown" OCSP responses for certificates which were generated but not issued to the users.

  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. 
    

2019-02-01 09:10 KIR statement about current (2019) practice was communicated https://bugzilla.mozilla.org/show_bug.cgi?id=1523186#c10 The the exemption was based on principle that it was not even intentional practice but eIDAS auditor recommendation to mark certificates "not received" by the customer as "unknown".
2019-04-05 08:00 am CEST Procedural steps were taken and reconfiguration of existing software were done.
2019-04-12 08:00 am CEST Analysis of technical change started to measure the cost and the impact on other systems.
2020-02-19 10:00 am CEST The decision was made that the new, initiated in 2020 and still ongoing project should technically solve the issue.
2021-04-16 08:09 PTD KIR was assigned to a new bug 'Many certificates with OCSP Unknown' https://bugzilla.mozilla.org/show_bug.cgi?id=1705657 which is a continuation of the one started in 2018.
2021-04-17 11:00 am CEST The investigation about re-opened issue has begun.
2021-04-18 11:00 am CEST The technical change was designed and requested for deployment.
2021-04-20 11:00 am CEST The implementation of the technical change began.
2021-04-22 11:00 am CEST The technical change is tested.

  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. 
    

Certificates are correct. The issue concerns status presented by OCSP and on CRLs in some business cases.
For the moment, just before deploying the technical change to our production system we can still face temporary inconsistence between OCSP and CRL statuses in some business cases.

  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. 
    

https://crt.sh/?id=2886005219&opt=ocsp
https://crt.sh/?id=2886013550&opt=ocsp
https://crt.sh/?id=2886124820&opt=ocsp
https://crt.sh/?id=2688712040&opt=ocsp
https://crt.sh/?id=2688725947&opt=ocsp
https://crt.sh/?id=2688961161&opt=ocsp
https://crt.sh/?id=2688657539&opt=ocsp
https://crt.sh/?id=2688662261&opt=ocsp
https://crt.sh/?id=2688673395&opt=ocsp
https://crt.sh/?id=2688697359&opt=ocsp
https://crt.sh/?id=2527478648&opt=ocsp
https://crt.sh/?id=2527165585&opt=ocsp
There can be more.

We will provide the full list after production deployment is completed.

  1.  The complete certificate data for the problematic certificates. 
    

Same as above.

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

eIDAS recommendations

Following eIDAS auditor recommendation given in 2017 certificates which were generated but not handed over to end users had “unknown” status in OCPS. The certificates are not automatically send to the users after they are generated. We hand the certificate over to the end user after as we confirm user’s identity. If a certificate is delivered personally it requires face to face user’s identity validation based on ID card or passport check by RA operator. In such a case there is a time gap between certificate generation and issuance. There are two cases where the certificates status presented by OCSP is inconsistent with the status presented on CRLs. The certificates generated but not handed to the users and not revoked have status “unknown” on OCSP. In this case the status changes into “good” in OCSP as soon as the certificate is delivered to the user and the validity period begins. The certificates which were generated and revoked but were not handed to the users have status “unknown” in OCSP and “revoked” on CRLs. Such certificates are never issued (handed out) to the end users. The status “issued (delivered)” or “not issued (not delivered)” is marked in our internal CRM by RA operator. We examine the statuses from CA DB and CRM DB and only for certificates with “issued (delivered)” status in our CRM OCSP was fed with certificate. For a certificate which was generated and revoked but not issued to the user to have the same status on CRL and in OCPS RA operator should change the certificate status to “issued” what was forbidden by our internal procedure.
Despite inconsistence between OCSP and CRL, status for such certificates prevents them from acceptance by the relying parties.

Procedural change

Then we deployed procedural change which made RA operator obliged to upload generated, revoked but not handed over certificate to our CRM system just to align CRL and OCSP statuses. On the one hand it tried to fix disconnection from OCSP and CRL and from the other it was breaking some logic in our CRM system where the operator had to set status 'handed over to the customer' on the certificate which was not handed over at all. The procedure was not intuitive and that’s why sometimes it was not executed by the operators. We have not also deployed full validation mechanism to check if the procedure was run for every certificate. Only random checks were executes but it turned out it was not enough.
For freshly issued and valid certificates that were generated, valid but not yet picked up by the user all we could do was to shorten a time gap between certificate generation and issuance.
The procedural change, as shown by the results of the analysis carried out on 2021-04-17, was insufficient to prevent inconsistencies between the OCSP and CRL statuses in one morefor some cases. The analysis revealed an error which manifested in sending issued and “ocsp ready” certificate to OCSP only if validFrom date was greater or equal today so the error was blocking the certificate if its validFrom was in the future. It didn't cover all possible cases of inconsistencies. It focused on revoked but not received by the end user certificates. On the one hand it tried to fix disconnection from OCSP and CRL and from the other it was breaking some logic in our CRM system where the operator had to set status 'handed over to the customer' on the certificate which was not handed over at all.
Besides it turned out that the issue is also related to the freshly issued and valid certificates that were generated, valid but not yet picked up by the user. So within the time the certificate was awaiting for being picked up (sometimes it was minutes, sometimes hours and sometimes even days) CRL and OCSP statuses were disconnected as well.

Technical change

All these issues will be gone when the technical change is deployed.

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

When the new issue was raised at 2021-04-16 we decided to reschedule planned changes in our system. We are using shared environment for OCSP coming from different CA's so any change in this environment has impact (re-reaudit) on other CAs including eIDAS compliant CA. The technical changes related to separation of OCSP components will technically revert the changes made at the beginning of our OCSP service (requested by our eIDAS auditor). So every generated certificates, doesn’t matter handed over to the end user or not, will have good or revoke status compliant with CRL status. The publication in OCPSP will omit checking status in our internal CRM. The certificate status will be based directly only on CA BD and will be not correlated with certificates status “issued/ not issued” in our CRM. This also will be also immune to operators errors.
The issue will be fixed by the technical change deployed in a few days. For the time being the solution is tested now in the integration environment.
The code of the OCSP service was reviewed and patched. After deployment, the revision process will bBegin. All previous certificates will be scanned and their status will be aligned between OCSP and CRL. We will perform also cyclic OCSP/CRL disconnection scans to be sure we are not facing this issue again. Results of these scans will documented.

Flags: needinfo?(piotr.grabowski)

The certificates are not automatically send to the users after they are generated. We hand the certificate over to the end user after as we confirm user’s identity.

Why are you doing this? Are you also generating the private key for the client?

Flags: needinfo?(piotr.grabowski)

(In reply to Piotr Grabowski from comment #16)

2019-04-12 08:00 am CEST Analysis of technical change started to measure the cost and the impact on other systems.
2020-02-19 10:00 am CEST The decision was made that the new, initiated in 2020 and still ongoing project should technically solve the issue.
2021-04-16 08:09 PTD KIR was assigned to a new bug 'Many certificates with OCSP Unknown' https://bugzilla.mozilla.org/show_bug.cgi?id=1705657 which is a continuation of the one started in 2018.

Could you extend on this very long delay between updates? 8 months between 'analysis of issue' and 'decision to start project that could fix this' is in my opinion too long for what is effectively a known consistent violation of your disclosed procedures and the RFCs.

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

eIDAS recommendations

[snip]
The certificates are not automatically send to the users after they are generated. We hand the certificate over to the end user after as we confirm user’s identity. If a certificate is delivered personally it requires face to face user’s identity validation based on ID card or passport check by RA operator.

You make it sound like you issue certificates before doing the validation (as described in BR s3.2), which would be an outragious violation of the BR (and by extension the MRSP). If I misunderstand this, could you clarify what validation you mean instead?

[snip]
The analysis revealed an error which manifested in sending issued and “ocsp ready” certificate to OCSP only if validFrom date was greater or equal today so the error was blocking the certificate if its validFrom was in the future.

Could you explain why you issue certificates into the future? I do indeed not see a direct mention as to why notBefore may not be set to a future moment, but I didn't expect a CA to actually issue certificates that are not valid at the moment of issuance / that the CA doesn't know to be valid at any point in the validity period (barring validation result reuse).

Could you explain why you issue certificates into the future? I do indeed not see a direct mention as to why notBefore may not be set to a future moment, but I didn't expect a CA to actually issue certificates that are not valid at the moment of issuance / that the CA doesn't know to be valid at any point in the validity period (barring validation result reuse).

They issued such certificates, but I'm not aware of it being a BR violation:
https://crt.sh/?id=4384411658
https://crt.sh/?id=4384418428
https://crt.sh/?id=4409119791

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

Could you explain why you issue certificates into the future? I do indeed not see a direct mention as to why notBefore may not be set to a future moment, but I didn't expect a CA to actually issue certificates that are not valid at the moment of issuance / that the CA doesn't know to be valid at any point in the validity period (barring validation result reuse).

They issued such certificates, but I'm not aware of it being a BR violation:

It is also my understanding that it is not a BR violation, nor could I find guidance in the relevant RFCs. The BRs do not require CAs to only issue certificates that are Valid as per RFC 5280 s6.1 (and more specifically, s6.1.3(a)(2)).

But, as future-dating certificates is not ruled out, it allows for certificates being issued many years in advance, which effectively circumvents the limitation on certificate duration by issuing not one three-year certificate but three one-year certificates. As such, I'd like to know the reasoning behind issuing future-dated certificates to understand why a CA would do that.

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

The certificates are not automatically send to the users after they are generated. We hand the certificate over to the end user after as we confirm user’s identity.

Why are you doing this? Are you also generating the private key for the client?

We are not generating private keys for TLS certificates. Users generate them themselves and have to deliver certificates request to KIR. It can be done personally by the entitled person.
Certification request can be deliver to KIR personally by client to one of our branches. During such a visit we verify his/her identity based on ID. Certificate is generated only after positive domain validation. After certificate is generated we hand it over to the user during the first or sometimes next visit.
Bear in mind that the certificates are order by different clients with different level of IT support. Sometimes it easier for them to do some activities in person, not online. That’s way we still practice delivery of the certificates during visits in our branches with face to face users identity validation.

Flags: needinfo?(piotr.grabowski)

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

Could you explain why you issue certificates into the future? I do indeed not see a direct mention as to why notBefore may not be set to a future moment, but I didn't expect a CA to actually issue certificates that are not valid at the moment of issuance / that the CA doesn't know to be valid at any point in the validity period (barring validation result reuse).

They issued such certificates, but I'm not aware of it being a BR violation:
https://crt.sh/?id=4384411658
https://crt.sh/?id=4384418428
https://crt.sh/?id=4409119791

In the order user can specify the beginning of validity period. Generally the validity period should not start later than 30 days after certificate is generated. It is usually the day when the certificate will be installed on a server or the date correlated with the expiration date of a previously used certificate. Then we generate a certificate and hand it over before the validity period starts.

(In reply to Matthias from comment #18)

(In reply to Piotr Grabowski from comment #16)

2019-04-12 08:00 am CEST Analysis of technical change started to measure the cost and the impact on other systems.
2020-02-19 10:00 am CEST The decision was made that the new, initiated in 2020 and still ongoing project should technically solve the issue.
2021-04-16 08:09 PTD KIR was assigned to a new bug 'Many certificates with OCSP Unknown' https://bugzilla.mozilla.org/show_bug.cgi?id=1705657 which is a continuation of the one started in 2018.

Could you extend on this very long delay between updates? 8 months between 'analysis of issue' and 'decision to start project that could fix this' is in my opinion too long for what is effectively a known consistent violation of your disclosed procedures and the RFCs.

It's becuase the nature of the project initiated. It is really very complex and it covers all steps of certificate lifecycle nad integrates many systems. After it will be finished it eliminates all human mistakes.

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

eIDAS recommendations

[snip]
The certificates are not automatically send to the users after they are generated. We hand the certificate over to the end user after as we confirm user’s identity. If a certificate is delivered personally it requires face to face user’s identity validation based on ID card or passport check by RA operator.

You make it sound like you issue certificates before doing the validation (as described in BR s3.2), which would be an outragious violation of the BR (and by extension the MRSP). If I misunderstand this, could you clarify what validation you mean instead?

Please take a look at my comments https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c21 and https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c22

[snip]
The analysis revealed an error which manifested in sending issued and “ocsp ready” certificate to OCSP only if validFrom date was greater or equal today so the error was blocking the certificate if its validFrom was in the future.

Could you explain why you issue certificates into the future? I do indeed not see a direct mention as to why notBefore may not be set to a future moment, but I didn't expect a CA to actually issue certificates that are not valid at the moment of issuance / that the CA doesn't know to be valid at any point in the validity period (barring validation result reuse).

Please take a look at my comments https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c21 and https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c22

(In reply to Piotr Grabowski from comment #23)

(In reply to Matthias from comment #18)

You make it sound like you issue certificates before doing the validation (as described in BR s3.2), which would be an outragious violation of the BR (and by extension the MRSP). If I misunderstand this, could you clarify what validation you mean instead?

Please take a look at my comments https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c21 and https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c22

(In reply to Piotr Grabowski from comment #21)

Certification request can be deliver to KIR personally by client to one of our branches. During such a visit we verify his/her identity based on ID. Certificate is generated only after positive domain validation. After certificate is generated we hand it over to the user during the first or sometimes next visit.

Your answer seems to limit your pre-issuance† validation to domain validation, even though there are more fields subject to validation other than the DNS in CN and SAN (e.g. localityName, stateOrProvenceName, countryName, organizationName). Do you validate all these fields before generating and signing the certificate, or after generating / signing the certificate?

(In reply to Piotr Grabowski from comment #23)

(In reply to Matthias from comment #18)

Could you explain why you issue certificates into the future? I do indeed not see a direct mention as to why notBefore may not be set to a future moment, but I didn't expect a CA to actually issue certificates that are not valid at the moment of issuance / that the CA doesn't know to be valid at any point in the validity period (barring validation result reuse).

Please take a look at my comments https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c21 and https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c22

(In reply to Piotr Grabowski from comment #22)

In the order user can specify the beginning of validity period. Generally the validity period should not start later than 30 days after certificate is generated. It is usually the day when the certificate will be installed on a server or the date correlated with the expiration date of a previously used certificate. Then we generate a certificate and hand it over before the validity period starts.

This is less information than I had hoped. "We offer the option" is not really an answer to the question why you offer that option. Could you further explain why this future-dating this is offered to the customer? More specifically, why don't you generate certificates that are valid from the moment they're generated / issued instead?

In a related note, this apparently also came up on the CA/B Forum validation list recently, at https://lists.cabforum.org/pipermail/validation/2021-April/001652.html, with https://github.com/cabforum/servercert/issues/266 as a tracking issue. If this future-dating of certificates is expected and required behaviour, I would suggest to discuss your reasoning on that list as well, before the BR are updated with requirements you cannot meet.

† Note that with Issuance I mean "when the certificate is signed", not "when the certificate is delivered to the customer".

Flags: needinfo?(piotr.grabowski)

(In reply to Piotr Grabowski from comment #16)

2019-02-01 09:10 KIR statement about current (2019) practice was communicated https://bugzilla.mozilla.org/show_bug.cgi?id=1523186#c10 The the exemption was based on principle that it was not even intentional practice but eIDAS auditor recommendation to mark certificates "not received" by the customer as "unknown".

On 2019-02-04 11:19am PST, https://bugzilla.mozilla.org/show_bug.cgi?id=1523186#c13 was made by Mozilla that concluded such practice is not compliant with, and does not comply with, the Baseline Requirements.

Could you help us understand why KIR S.A. ignored that comment? Did it feel it only applied to the certificate in question? Was it seen as ambiguous?

Certificates are correct. The issue concerns status presented by OCSP and on CRLs in some business cases.
For the moment, just before deploying the technical change to our production system we can still face temporary inconsistence between OCSP and CRL statuses in some business cases.

It seems like KIR S.A. should halt all issuance, then, until it can be sure it will not be issuing new certificates that subsequently fail to be delivered.

Could you explain why this hasn't been done?

Following eIDAS auditor recommendation given in 2017 certificates which were generated but not handed over to end users had “unknown” status in OCPS.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1525082#c4 , on 2020-05-06, KIR S.A. stated "For TLS (non-qualified) certificates we are now aligned with WebTrust and we are counting "non-delivered" certificates as issued, but opinion of our eIDAS auditor on this matter is completely different." This was further clarified in https://bugzilla.mozilla.org/show_bug.cgi?id=1525082#c9 on 2020-05-07, which stated "Wayne, qualified eIDAS certificates are out of scope of Mozilla's root store policy, they come from completely different, technicallly separarated subCA and ROOT which is not listed in Mozilla but in the european TSL lists."

From the example certificates provided, we see they are TLS (non-qualified) certificates, for example, https://crt.sh/?id=2886124820&opt=ocsp This seems to suggest that the comment on Bug 1525082 was factually incorrect. Could you explain why there's a disconnect?

We hand the certificate over to the end user after as we confirm user’s identity. If a certificate is delivered personally it requires face to face user’s identity validation based on ID card or passport check by RA operator.

I couldn't find this documented in your CP/CPS. Did I overlook something? CAs that do this are actively harmful to the goals of a more secure Internet, and so it's useful to understand why this may be done and how it's disclosed. If this is not disclosed within your CP/CPS, is there any public documentation about this process and workflow?

The procedure was not intuitive and that’s why sometimes it was not executed by the operators. We have not also deployed full validation mechanism to check if the procedure was run for every certificate. Only random checks were executes but it turned out it was not enough.

To make sure we understand, is the statement on Bug 1525082 one that KIR S.A. did not fix its systems, but instead instituted manual procedures, and then failed to supervise those manual procedures to ensure compliance with KIR S.A.'s publicly stated policies? If so, what assurance should we, the community, have that KIR S.A. follows any of its other stated procedures?

If this is not a correct understanding, please provide further detail to understand the decision making process here.

(In reply to Piotr Grabowski from comment #22)

In the order user can specify the beginning of validity period. Generally the validity period should not start later than 30 days after certificate is generated. It is usually the day when the certificate will be installed on a server or the date correlated with the expiration date of a previously used certificate. Then we generate a certificate and hand it over before the validity period starts.

Within the Baseline Requirements, Section 9.6.1, the CA is required to give warranty that, at the time of issuance, the CA:

i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate (with the exception of the subject:organizationalUnitName attribute);
ii. followed the procedure when issuing the Certificate; and
iii. accurately described the procedure in the CA’s Certificate Policy and/or Certification Practice Statement;

As Comment #24 points out, this practice seems directly at odds with the Baseline Requirements. Could you share KIR S.A.'s analysis of how such forward dating reasonably complies with the requirement that the information is accurate, given that KIR S.A. is stating it for the future?

Further, I do not see this language incorporated into KIR S.A.'s CP/CPS. Could you detail where this warranty is provided?

Similarly, Section 9.6.3 of the BRs places certain obligations on a CA with respect to their Subscriber Agreement and Terms of Use. Similar to the above issue with Section 9.6.1, I can find no such reference in the KIR S.A. repository. If this is correct, please file a new issue, as this is another area of non-compliance.

(In reply to Piotr Grabowski from comment #21)

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

The certificates are not automatically send to the users after they are generated. We hand the certificate over to the end user after as we confirm user’s identity.

Why are you doing this? Are you also generating the private key for the client?

We are not generating private keys for TLS certificates. Users generate them themselves and have to deliver certificates request to KIR. It can be done personally by the entitled person.
Certification request can be deliver to KIR personally by client to one of our branches. During such a visit we verify his/her identity based on ID. Certificate is generated only after positive domain validation. After certificate is generated we hand it over to the user during the first or sometimes next visit.
Bear in mind that the certificates are order by different clients with different level of IT support. Sometimes it easier for them to do some activities in person, not online. That’s way we still practice delivery of the certificates during visits in our branches with face to face users identity validation.

Thanks for the explanation. I was asking because your https://www.elektronicznypodpis.pl/gfx/elektronicznypodpis/userfiles/_public/information/legal_basis/20200918_certification_practice_statement_kir_trusted_nq_certificates.pdf states:

3.2.1. Method To Prove Possession of Private Key

A certificate may be issued with a pair of keys generated by KIR or to a public key from a pair generated by the subscriber.

If a pair of keys is generated by KIR, a document confirming issuance of the certificate signedby the subscriber or a person authorised to collect the certificate shall be confirmation of provision of private key to the subscriber.

Could you please clarify when generation of keys by KIR is allowed and when it is not allowed?

(In reply to Matthias from comment #24)

(In reply to Piotr Grabowski from comment #23)

(In reply to Matthias from comment #18)

You make it sound like you issue certificates before doing the validation (as described in BR s3.2), which would be an outragious violation of the BR (and by extension the MRSP). If I misunderstand this, could you clarify what validation you mean instead?

Please take a look at my comments https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c21 and https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c22

(In reply to Piotr Grabowski from comment #21)

Certification request can be deliver to KIR personally by client to one of our branches. During such a visit we verify his/her identity based on ID. Certificate is generated only after positive domain validation. After certificate is generated we hand it over to the user during the first or sometimes next visit.

Your answer seems to limit your pre-issuance† validation to domain validation, even though there are more fields subject to validation other than the DNS in CN and SAN (e.g. localityName, stateOrProvenceName, countryName, organizationName). Do you validate all these fields before generating and signing the certificate, or after generating / signing the certificate?

Of course we validate allt these before signing the request. You took my post out of the context as the original question was about private key.
We desrcibe it in our CPS. Here is a snippet

3.2.2. Identification and Authentication of Entities Other Than Natural Person
If a certificate is to contain data on a contracting authority other than a natural person, such as a name of the organisation and its address, KIR prior to issuance of a certificate, on the basis of information obtained from legal and reliable, publicly available sources, including available registers maintained by public authorities, shall check if such entity exists if data indicated by a contracting authority is compliant
with that presented in the register used and if persons acting on behalf of the contracting authority are authorised to that...

(In reply to Piotr Grabowski from comment #23)

(In reply to Matthias from comment #18)

Could you explain why you issue certificates into the future? I do indeed not see a direct mention as to why notBefore may not be set to a future moment, but I didn't expect a CA to actually issue certificates that are not valid at the moment of issuance / that the CA doesn't know to be valid at any point in the validity period (barring validation result reuse).

Please take a look at my comments https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c21 and https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c22

(In reply to Piotr Grabowski from comment #22)

In the order user can specify the beginning of validity period. Generally the validity period should not start later than 30 days after certificate is generated. It is usually the day when the certificate will be installed on a server or the date correlated with the expiration date of a previously used certificate. Then we generate a certificate and hand it over before the validity period starts.

This is less information than I had hoped. "We offer the option" is not really an answer to the question why you offer that option. Could you further explain why this future-dating this is offered to the customer? More specifically, why don't you generate certificates that are valid from the moment they're generated / issued instead?

Actually it is our customer's need. It is usually the day when the certificate will be installed on a server or the date correlated with the expiration date of a previously used certificate.

In a related note, this apparently also came up on the CA/B Forum validation list recently, at https://lists.cabforum.org/pipermail/validation/2021-April/001652.html, with https://github.com/cabforum/servercert/issues/266 as a tracking issue. If this future-dating of certificates is expected and required behaviour, I would suggest to discuss your reasoning on that list as well, before the BR are updated with requirements you cannot meet.

† Note that with Issuance I mean "when the certificate is signed", not "when the certificate is delivered to the customer".

Flags: needinfo?(piotr.grabowski)

(In reply to Piotr Grabowski from comment #28)

Actually it is our customer's need. It is usually the day when the certificate will be installed on a server or the date correlated with the expiration date of a previously used certificate.

As a continued trend with KIR S.A., this surface answer doesn't really demonstrate an awareness or understanding of what's being asked.

The conversation can best be summarized:

  • Q: Why does KIR S.A. do this?
  • A: Because that's what we do
  • Q: But why do you do this?
  • A: Because our customer asked us
  • Q: But why did you decide to do what your customer asked?
  • A: Because our customer asked us

Matthias' question in Comment #24 is seemingly clear and unambiguous to this point: The question was:

Could you further explain why this future-dating this is offered to the customer? More specifically, why don't you generate certificates that are valid from the moment they're generated / issued instead?

And the answer here completely ignores that latter question, and simply answers the former question with "Because they asked us to".

The obvious goal here is to understand how KIR S.A. makes its policy decisions, since fundamentally, that's what is being called into question, both with this original issue, in which KIR S.A. made a decision to actively mislead the public by stating they had stopped something, but not actually stopped doing it, and because the presumptive answer for why they didn't stop it was because it was hard because they were doing something else problematic, and it made that hard.

At no point do we have a clear answer about why a customer would need a certificate to be dated as to when it's installed on the server, or correlated with the previous expiration date, with one exception: That KIR S.A. did this to work around browser restrictions, including Mozilla's, on the validity period of certificates, which can be grounds for complete distrust and is explicitly forbidden in policy. As a community, the only reason we can see for putting the notBefore in the future, given that there is no provided nor known technical reason, is so that the notAfter can be the full period from that (as Validity Period is defined as notAfter - notBefore), as a way of issuing a certificate greater than the permitted time in the BRs.

I had hoped that KIR S.A. would have considered their answer in light of the further clarifications by Comment #26, but the selective responses, both to individual comments (i.e. the half-answered Comment #24) and to the overall pattern is, unquestionably, deeply concerning.

(In reply to Piotr Grabowski from comment #28)

Of course we validate allt these before signing the request. You took my post out of the context as the original question was about private key.

I do not believe that I took your post out of context:

Based on your statement ("The certificates are not automatically send to the users after they are generated. We hand the certificate over to the end user after as we confirm user’s identity", Comment #16) I asked if my understanding that you only validated user identies after the certificate was issued was correct (Comment #18). To that, you responded that (paraphrased) the answer could be found in Comment 21 and Comment 22. The only relevant portion of those two posts that mentions user identity validation was the quoted portion ("Certification request can be deliver to KIR personally by client to one of our branches. During such a visit we verify his/her identity based on ID. Certificate is generated only after positive domain validation. After certificate is generated we hand it over to the user during the first or sometimes next visit.", Comment #21 ), which does not answer the question asked as it only mentions domain validation.

We desrcibe it in our CPS. Here is a snippet

3.2.2. Identification and Authentication of Entities Other Than Natural Person
If a certificate is to contain data on a contracting authority other than a natural person, such as a name of the organisation and its address, KIR prior to issuance of a certificate, on the basis of information obtained from legal and reliable, publicly available sources, including available registers maintained by public authorities, shall check if such entity exists if data indicated by a contracting authority is compliant
with that presented in the register used and if persons acting on behalf of the contracting authority are authorised to that...

As established in the other issue (Bug 1705904) , your CPS does not accurately reflect your current pratice. Therefore, seeing you mention that you validate identities after the certificate is issued raised red flags, to which I was expecting a simple, short and decisive answer. I did not expect "don't take my words out of context" and "look in our CPS".

(In reply to Matthias from comment #30)

(In reply to Piotr Grabowski from comment #28)

Of course we validate allt these before signing the request. You took my post out of the context as the original question was about private key.

I do not believe that I took your post out of context:

Based on your statement ("The certificates are not automatically send to the users after they are generated. We hand the certificate over to the end user after as we confirm user’s identity", Comment #16) I asked if my understanding that you only validated user identies after the certificate was issued was correct (Comment #18). To that, you responded that (paraphrased) the answer could be found in Comment 21 and Comment 22. The only relevant portion of those two posts that mentions user identity validation was the quoted portion ("Certification request can be deliver to KIR personally by client to one of our branches. During such a visit we verify his/her identity based on ID. Certificate is generated only after positive domain validation. After certificate is generated we hand it over to the user during the first or sometimes next visit.", Comment #21 ), which does not answer the question asked as it only mentions domain validation.

We desrcibe it in our CPS. Here is a snippet

3.2.2. Identification and Authentication of Entities Other Than Natural Person
If a certificate is to contain data on a contracting authority other than a natural person, such as a name of the organisation and its address, KIR prior to issuance of a certificate, on the basis of information obtained from legal and reliable, publicly available sources, including available registers maintained by public authorities, shall check if such entity exists if data indicated by a contracting authority is compliant
with that presented in the register used and if persons acting on behalf of the contracting authority are authorised to that...

As established in the other issue (Bug 1705904) , your CPS does not accurately reflect your current pratice. Therefore, seeing you mention that you validate identities after the certificate is issued raised red flags, to which I was expecting a simple, short and decisive answer. I did not expect "don't take my words out of context" and "look in our CPS".

I still can not see the fragment which can suggest that we validate identities after the certificate is issued.
So this time my ansewer will short. We always do all necessary validation before certificate issuance.

(In reply to Ryan Sleevi from comment #29)

Let me explain the issue concerning a certificate validity period later then the certificate issuance. It was in our answers but maybe not cleat enough, so let me summarise it:

  1. Validity period for TLS certificate (notBefore – notAfter) cannot be longer that 1 year.
  2. A client can pointed out in the order the beginning of a certificate.
  3. A certificate can be generated by KIR max 30 days before the validity period starts.
  4. A certificate request validation (including validating data in the request, domain validation) is made before a certificate is generated.

The reasons by clients want their certificates to be generated with the given date are as follow:

  • A current certificate expires and they want to get a new certificate in advance to have a time to install it. For example a certificate expires on 1 July, and a client wants to get a certificate with the validity period since 15 May, but can visit our branch 10 May to collect the certificate. Then we generate certificate on 10 May with notBefore – 15 May.
  • A new client orders certificate with a given date indicated in the order, but want to collect a certificate earlier – just to have enough time to install it on a server.
  • Sometimes clients order certificates for the given services and they know that their service will be available since the given date. They order certificate with a given date.
    Generally, our clients pay for certificates and want to use them within the full validity period – 1 year. That’s why we sometimes generate certificate with the notBefore date not equal to the date that are generated.

The mentioned certificates (e.g., https://crt.sh/?id=4384411658) have a validity period of 1 year (365 days in this case) and 1 second.

I don't understand how you calculated the 1 year and one second. Where is the additional second from? Is it the leap second? I see:

Validity
    Not Before: Apr 28 06:00:00 2021 GMT
    Not After : Apr 28 06:00:00 2022 GMT

Do you dematerialize your customers to hand over a digital certificate personally? Wouldn't it be easier for your customers to dematerialize themselves at home at send themselves to your one of your branches via email? Sorry, but this is exactly how ridiculous you process sounds to me.

https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Flags: needinfo?(paul.leo.steinberg)

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

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

  1. Validity period for TLS certificate (notBefore – notAfter) cannot be longer that 1 year.

The mentioned certificates (e.g., https://crt.sh/?id=4384411658) have a validity period of 1 year (365 days in this case) and 1 second. If you specify a validity period of 1 year in your CP(S), please revoke all of these certificates within 5 days. If you do not specify a validity period of 1 year in your CP(S), your statement is obviously just made up and not backed by your own policy documents.

Oh, I am sorry. Indeed, your CPS DOES specify a maximum validity period of 1 year (https://www.elektronicznypodpis.pl/gfx/elektronicznypodpis/userfiles/_public/information/legal_basis/20200918_certification_practice_statement_kir_trusted_nq_certificates.pdf#page=51). Via BR 4.9.1.1., you are made aware that all of these certificates (probably all of your certificates) were not issued in accordance with the "CA’s Certificate Policy or Certification Practice Statement" and you MUST revoke them within 5 days.

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

The mentioned certificates (e.g., https://crt.sh/?id=4384411658) have a validity period of 1 year (365 days in this case) and 1 second.

I don't understand how you calculated the 1 year and one second. Where is the additional second from? Is it the leap second? I see:

Validity
    Not Before: Apr 28 06:00:00 2021 GMT
    Not After : Apr 28 06:00:00 2022 GMT

RFC 5280 4.1.2.5 (https://www.rfc-editor.org/rfc/rfc5280.html#section-4.1.2.5) specifies: "The validity period for a certificate is the period of time from notBefore through notAfter, inclusive."

Flags: needinfo?(paul.leo.steinberg) → needinfo?(piotr.grabowski)

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

Let me explain the issue concerning a certificate validity period later then the certificate issuance. It was in our answers but maybe not cleat enough, so let me summarise it:

  1. Validity period for TLS certificate (notBefore – notAfter) cannot be longer that 1 year.

If I request a certificate on 2021-01-01, and request its notBefore be 2021-01-30, what will the notAfter date be?

The answers seem to make it clear that a notAfter date of 2022-01-30 is valid, creating a certificate that is valid for more than a year from the validation period. Is this correct?

Now, let's further consider the possibility of reused data according to 4.2.1 of the BRs:

  • At T=0, KIR S.A. performs the domain validation and issues a certificate, with a validity period of [0, 398 days]
  • At T=398 days - 1 second (the maximum reuse following SC42), the customer requests another certificate. Normally, with a notBefore set to when the data was valid and certificate issued, this would be a validity period of [398 days - 1 second, 796 days - 1 second]. This sets the "upper bound" for domain data at 796 days.
  • However, if the customer requests a 'forward dated' certificate, it seems that KIR S.A. will issue a certificate with a validity period of [428 - 1 second, 824 days].

Given the poor quality of responses so far, I want to highlight that saying "But we don't reuse data" would not be a reassuring response here. The issue here is that the effective period for domain validation data use seems to be significantly greater than intended.

The reasons by clients want their certificates to be generated with the given date are as follow:

  • A current certificate expires and they want to get a new certificate in advance to have a time to install it. For example a certificate expires on 1 July, and a client wants to get a certificate with the validity period since 15 May, but can visit our branch 10 May to collect the certificate. Then we generate certificate on 10 May with notBefore – 15 May.

Why, though? Why would you not generate the certificate with a notBefore of 10 May?

The answer I referred to in my previous comment seems to be "So that their new certificate can also expire on 1 July", which gets to the point of evading requirements and restrictions.

  • A new client orders certificate with a given date indicated in the order, but want to collect a certificate earlier – just to have enough time to install it on a server.

Same response as previous.

  • Sometimes clients order certificates for the given services and they know that their service will be available since the given date. They order certificate with a given date.

And the problem with dating the certificate at issuance is?

Generally, our clients pay for certificates and want to use them within the full validity period – 1 year. That’s why we sometimes generate certificate with the notBefore date not equal to the date that are generated.

Right. This seems to actively confirm the problematic practice's justification, which is fundamentally troubling.

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

RFC 5280 4.1.2.5 (https://www.rfc-editor.org/rfc/rfc5280.html#section-4.1.2.5) specifies: "The validity period for a certificate is the period of time from notBefore through notAfter, inclusive."

From the BRs:

Validity Period: Prior to 2020‐09‐01, the period of time measured from the date when the Certificate is issued until the Expiry Date. For Certificates issued on or after 2020‐09‐01, the validity period is as defined within RFC 5280, Section 4.1.2.5: the period of time from notBefore through notAfter, inclusive.

The issue here is that under the BRs, for all certificates issued prior to 2020-09-01, the validity period is measured from the time at issuance, which means forward dated certificates that also increased the notAfter, if the date of notAfter was greater than the maximum validity period, it was misissued (i.e. if notAfter was more than 825 days from issuance, it was a BR violation; if the CPS at the time specified 398 days, and it was greater than 398 days from issuance, than its a CPS violation and thus also a BR violation)

Following 2020-09-01, the BRs are clear and unambiguous that "Validity Period" means what RFC 5280 says, and Paul's answer is correct.

I think, at this point, we've identified three separate BR violations that bear dealing with as their own (separate) bugs and incident reports:

  • Failing to consider the inclusive requirement of the validity period
  • Validity period exceeding beyond the CPS/BR permitted periods when interacting with forward dating for those certificates prior to 2020-09-01.
    • This is particularly concerning given Comment #22, which suggests "30 days" is only generally the max. I have not yet found documentation of policies or practices here that would be satisfactory.
  • Failing to include the required portions in the Subscriber Agreement (Comment #26)

Further, we've identified issues that should probably be tracked as incidents, as they're clearly problematic practices:

  • Forward dating in general
  • There may still need to be an incident related to validation practices. The answers here have not yet clarified to an acceptable degree that there's not a BR issue here.

Finally, there are still questions that KIR S.A. has not yet answered, inevitably due to there being so many questions at play here:

  • It's questionable whether Comment #23 was a suitable answer to Comment #18 ("Could you extend ...")
  • Comment #25 remains thus far unaddressed, which builds on Comment #18 ("Could you help us ...", "Could you explain ...", "Could you explain ...", "Is there any ...", "Is the statement")
  • Comment #26 remains thus far unaddressed ("Could you detail ...")
  • Comment #27 remains thus far unaddressed ("Could you please clarify ...")

(In reply to Ryan Sleevi from comment #39)
To clear up all issues concerning our practice with the validity period we decided to make update of our CSP and change maximum validity period for TLS certificates from “1 year” into “398 days since a certificate is generated” (not in the future). So the ‘notBefore’ will be equal to the current date.
This change is in process of formal acknowledgment at KIR.
Bearing this in mind we decided to stop certificate TLS issuance till the CSP update will go in force.
As many questions have been raised please let as prepare answers for all of them.

(In reply to Ryan Sleevi from comment #29)

(In reply to Piotr Grabowski from comment #28)

Actually it is our customer's need. It is usually the day when the certificate will be installed on a server or the date correlated with the expiration date of a previously used certificate.

As a continued trend with KIR S.A., this surface answer doesn't really demonstrate an awareness or understanding of what's being asked.

The conversation can best be summarized:

  • Q: Why does KIR S.A. do this?
  • A: Because that's what we do
  • Q: But why do you do this?
  • A: Because our customer asked us
  • Q: But why did you decide to do what your customer asked?
  • A: Because our customer asked us

Matthias' question in Comment #24 is seemingly clear and unambiguous to this point: The question was:

Could you further explain why this future-dating this is offered to the customer? More specifically, why don't you generate certificates that are valid from the moment they're generated / issued instead?

I though my exaplantions was clear. I was wrong.
It is a very common practice of our customers, that they order "new" certificate for their server some time before

And the answer here completely ignores that latter question, and simply answers the former question with "Because they asked us to".

The obvious goal here is to understand how KIR S.A. makes its policy decisions, since fundamentally, that's what is being called into question, both with this original issue, in which KIR S.A. made a decision to actively mislead the public by stating they had stopped something, but not actually stopped doing it, and because the presumptive answer for why they didn't stop it was because it was hard because they were doing something else problematic, and it made that hard.

At no point do we have a clear answer about why a customer would need a certificate to be dated as to when it's installed on the server, or correlated with the previous expiration date, with one exception: That KIR S.A. did this to work around browser restrictions, including Mozilla's, on the validity period of certificates, which can be grounds for complete distrust and is explicitly forbidden in policy. As a community, the only reason we can see for putting the notBefore in the future, given that there is no provided nor known technical reason, is so that the notAfter can be the full period from that (as Validity Period is defined as notAfter - notBefore), as a way of issuing a certificate greater than the permitted time in the BRs.

I had hoped that KIR S.A. would have considered their answer in light of the further clarifications by Comment #26, but the selective responses, both to individual comments (i.e. the half-answered Comment #24) and to the overall pattern is, unquestionably, deeply concerning.

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

(In reply to Piotr Grabowski from comment #21)

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

The certificates are not automatically send to the users after they are generated. We hand the certificate over to the end user after as we confirm user’s identity.

Why are you doing this? Are you also generating the private key for the client?

We are not generating private keys for TLS certificates. Users generate them themselves and have to deliver certificates request to KIR. It can be done personally by the entitled person.
Certification request can be deliver to KIR personally by client to one of our branches. During such a visit we verify his/her identity based on ID. Certificate is generated only after positive domain validation. After certificate is generated we hand it over to the user during the first or sometimes next visit.
Bear in mind that the certificates are order by different clients with different level of IT support. Sometimes it easier for them to do some activities in person, not online. That’s way we still practice delivery of the certificates during visits in our branches with face to face users identity validation.

Thanks for the explanation. I was asking because your https://www.elektronicznypodpis.pl/gfx/elektronicznypodpis/userfiles/_public/information/legal_basis/20200918_certification_practice_statement_kir_trusted_nq_certificates.pdf states:

3.2.1. Method To Prove Possession of Private Key

A certificate may be issued with a pair of keys generated by KIR or to a public key from a pair generated by the subscriber.

If a pair of keys is generated by KIR, a document confirming issuance of the certificate signedby the subscriber or a person authorised to collect the certificate shall be confirmation of provision of private key to the subscriber.

Could you please clarify when generation of keys by KIR is allowed and when it is not allowed?

In case of SSL/TLS the keys are generated always by the end-user and we certify P#10 requests. But in KIR we issue different types of certificates for end-users (not only SSL/TLS), for example for digital signature. In this case keys are generated in KIR in secure device like smartcard.

Flags: needinfo?(piotr.grabowski)

(In reply to Elżbieta Włodarczyk from comment #40)
Update.
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 section 6.3.2 "1 year" valitidty period has been replaced with "398 days from the date of certificate generation". Update CSP is going to be valid since 1 May 2021.

The testing phase of a technical change was successfully carried out. We have registered request for production deployment.
Tomorrow we will report the incident related to the inclusive requirement of the validity period.

We have registered new bug related to inclusive requirement of the validity period: https://bugzilla.mozilla.org/show_bug.cgi?id=1708965

Hello,
Do you have any ETA for when OCSP and CRL will be in sync? Were you able to identify all affected certificates?

Flags: needinfo?(piotr.grabowski)

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

Hello,
Do you have any ETA for when OCSP and CRL will be in sync? Were you able to identify all affected certificates?

CR for production deployment is already registered.
We had to add some additional tests and all went fine.
I think we will be in sync within a week. Just before the deployment we will provide a list of affected certificates.
It should be rather short.

Flags: needinfo?(piotr.grabowski)

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

Hello,
Do you have any ETA for when OCSP and CRL will be in sync? Were you able to identify all affected certificates?

CRL and OCSP sync is planned for tomorrow.
We identified 38 certificates (list of SN HEX numbers).

The technical change OCSP/CRL sync was deployed on the production. Full scan was executed. No certificate with OCSP unknown was found.

(In reply to Piotr Grabowski from comment #47)

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

Hello,
Do you have any ETA for when OCSP and CRL will be in sync? Were you able to identify all affected certificates?

CRL and OCSP sync is planned for tomorrow.
We identified 38 certificates (list of SN HEX numbers).

I think this attachment failed to upload, or at least I cannot find it. Could you please share this list with us for reference?

Attached file OCSP-unknown-SSL.txt

(In reply to Matthias from comment #49)

(In reply to Piotr Grabowski from comment #47)

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

Hello,
Do you have any ETA for when OCSP and CRL will be in sync? Were you able to identify all affected certificates?

CRL and OCSP sync is planned for tomorrow.
We identified 38 certificates (list of SN HEX numbers).

I think this attachment failed to upload, or at least I cannot find it. Could you please share this list with us for reference?

here you go

(In reply to Ryan Sleevi from comment #39)

I think, at this point, we've identified three separate BR violations that bear dealing with as their own (separate) bugs and incident reports:

  • Failing to consider the inclusive requirement of the validity period

We reported a bug https://bugzilla.mozilla.org/show_bug.cgi?id=1708965

  • Validity period exceeding beyond the CPS/BR permitted periods when interacting with forward dating for those certificates prior to 2020-09-01.
    • This is particularly concerning given Comment #22, which suggests "30 days" is only generally the max. I have not yet found documentation of policies or practices here that would be satisfactory.

We no longer issue forward dated certificates.

  • Failing to include the required portions in the Subscriber Agreement (Comment #26)

An order signed by a client contains the following statement. The order is signed by entitled representatives of the client.
In the case of an SSL certificate, the Ordering Party undertakes to:

  1. provide KIR with true and accurate information regarding the data of the certificate subject (subscriber) throughout the certificate validity period, in the form of both data contained in the order and data contained in the certificate request containing the public key for which the certificate is to be prepared;
  2. protect the private key associated with the public key for which KIR will issue a certificate by controlling the use of the private key, ensuring the confidentiality of the private key, ensuring the protection of all information related thereto;
  3. verification of data contained in the issued certificate;
  4. installation of the certificate only on the server that supports the domain name or domain names listed in the certificate issued by KIR;
  5. use the certificate in accordance with the law and the Agreement;
  6. immediate cessation of the use of the certificate and the related private key and notification to KIR of a request for certificate revocation in the following cases:
    a) incorrect or untrue data contained in the certificate,
    b) there is a suspicion of misuse of the certificate,
    c) compromising the private key,
    d) cease to use the private key associated with the public key included in the certificate upon expiry of the certificate or its revocation,
    e) other provisions provided for in the Certification Practice Statement of KIR for Trusted Non-Qualified Certificates;
  7. follow the instructions provided by KIR in the event of compromising the private key or misused the certificate.
    The Ordering Party accepts the right of KIR to revoke the certificate immediately if the Ordering Party does not comply with the obligations imposed on it or the revocation results from the Certification Practice Statement of KIR for Trusted Non-Qualified Certificates, Certification Policy of KIR for Trusted Non-qualified Certificates and Baseline Requests for the Issuance and Management of Publicly-Trusted Certificates.

Further, we've identified issues that should probably be tracked as incidents, as they're clearly problematic practices:

  • Forward dating in general
  • There may still need to be an incident related to validation practices. The answers here have not yet clarified to an acceptable degree that there's not a BR issue here.

Finally, there are still questions that KIR S.A. has not yet answered, inevitably due to there being so many questions at play here:

The project initiated in 2020 has very larger scope and the technical change in OCSP was only one of them. The project is really very complex and it covers all steps of certificate lifecycle and integrates many systems. Once it is finished it will hopefully eliminate all human mistakes. Our goal was to fix the issue with procedural change and in the next phase replace the procedure with the technical change. The project initiated in 02-2020 was the first opportunity to include the technical change for implementation.

  • Comment #25 remains thus far unaddressed, which builds on Comment #18 ("Could you help us ...", "Could you explain ...", "Could you explain ...", "Is there any ...", "Is the statement")

I will answer directly to the comment #25

  • Comment #26 remains thus far unaddressed ("Could you detail ...")

I will answer directly to the comment #26

  • Comment #27 remains thus far unaddressed ("Could you please clarify ...")

The answer is here https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c41
In case of SSL/TLS the keys are generated always by the end-user and we certify P#10 requests. But in KIR we issue different types of certificates for end-users (not only SSL/TLS), for example for digital signature. In this case keys are generated in KIR in secure device like smartcards.

(In reply to Ryan Sleevi from comment #25)

(In reply to Piotr Grabowski from comment #16)

2019-02-01 09:10 KIR statement about current (2019) practice was communicated https://bugzilla.mozilla.org/show_bug.cgi?id=1523186#c10 The the exemption was based on principle that it was not even intentional practice but eIDAS auditor recommendation to mark certificates "not received" by the customer as "unknown".

On 2019-02-04 11:19am PST, https://bugzilla.mozilla.org/show_bug.cgi?id=1523186#c13 was made by Mozilla that concluded such practice is not compliant with, and does not comply with, the Baseline Requirements.

Could you help us understand why KIR S.A. ignored that comment? Did it feel it only applied to the certificate in question? Was it seen as ambiguous?

As stated in https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c16 we have not ignored this comment:
2019-04-05 08:00 am CEST Procedural steps were taken and reconfiguration of existing software were done. In another comment https://bugzilla.mozilla.org/show_bug.cgi?id=1523186#c18 I said that we have also procedural controls in place that should protect us for similar misissuance to happen again. I agree that two years ago our communication left much to be desired but it was not for sure our intension to leave this comment without an answer.

Certificates are correct. The issue concerns status presented by OCSP and on CRLs in some business cases.
For the moment, just before deploying the technical change to our production system we can still face temporary inconsistence between OCSP and CRL statuses in some business cases.

It seems like KIR S.A. should halt all issuance, then, until it can be sure it will not be issuing new certificates that subsequently fail to be delivered.

Could you explain why this hasn't been done?

We almost stopped all issuance, we left the the access to the registration policies only most trained 2 out of 100 operators https://bugzilla.mozilla.org/show_bug.cgi?id=1523186#c18. When I said 'temporary inconsistence' I meant very short periods of time in minutes.
It is a time that was needed by the operator to manually set proper status of the order which in turn triggered proper OCSP status. Now it is of course history.

Following eIDAS auditor recommendation given in 2017 certificates which were generated but not handed over to end users had “unknown” status in OCPS.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1525082#c4 , on 2020-05-06, KIR S.A. stated "For TLS (non-qualified) certificates we are now aligned with WebTrust and we are counting "non-delivered" certificates as issued, but opinion of our eIDAS auditor on this matter is completely different." This was further clarified in https://bugzilla.mozilla.org/show_bug.cgi?id=1525082#c9 on 2020-05-07, which stated "Wayne, qualified eIDAS certificates are out of scope of Mozilla's root store policy, they come from completely different, technicallly separarated subCA and ROOT which is not listed in Mozilla but in the european TSL lists."

From the example certificates provided, we see they are TLS (non-qualified) certificates, for example, https://crt.sh/?id=2886124820&opt=ocsp This seems to suggest that the comment on Bug 1525082 was factually incorrect. Could you explain why there's a disconnect?

I think we explained this issue serveral times. We are issuing qualified and non-qualified certificates.
Qualified services undergo an eIDAS audit, non-qualified WebTrust audit. In the first case our auditor is T-Systems, in the second case EY Poland. https://bugzilla.mozilla.org/show_bug.cgi?id=1525082#c4
Saying European TSL lists I meant Trusted Services List https://webgate.ec.europa.eu/tl-browser/#/tl/PL/3 The CA's listed there are out of the WebTrust audit scope.

We hand the certificate over to the end user after as we confirm user’s identity. If a certificate is delivered personally it requires face to face user’s identity validation based on ID card or passport check by RA operator.

I couldn't find this documented in your CP/CPS. Did I overlook something? CAs that do this are actively harmful to the goals of a more secure Internet, and so it's useful to understand why this may be done and how it's disclosed. If this is not disclosed within your CP/CPS, is there any public documentation about this process and workflow?

The procedure was not intuitive and that’s why sometimes it was not executed by the operators. We have not also deployed full validation mechanism to check if the procedure was run for every certificate. Only random checks were executes but it turned out it was not enough.

To make sure we understand, is the statement on Bug 1525082 one that KIR S.A. did not fix its systems, but instead instituted manual procedures, and then failed to supervise those manual procedures to ensure compliance with KIR S.A.'s publicly stated policies? If so, what assurance should we, the community, have that KIR S.A. follows any of its other stated procedures?

If this is not a correct understanding, please provide further detail to understand the decision making process here.

When implementing the procedure, we were convinced that it would fix this error. In retrospect, it seems that the decision to implement procedural change was not thoroughly analyzed. Solution risk analysis did not cover all its aspects. I mean the lack of full supervisory and the inconsistency of this process with other processes. These two factors made a basically simple procedural change not working
always as expected. We have drawn conclusions from this matter and we can assure you that each similar case will be thoroughly and cross-sectionally analyzed before implementation. Deep analysis of the risk and effectiveness of the chosen solution will be performed. The implemented solution itself will be always closely monitored in fixed time intervals. We have already developed several scan and parsing tools which seems to be very useful. Another thing that we want to do is to execute review of all our business processes to be sure they are effective, transparent and fully understandable.

(In reply to Ryan Sleevi from comment #26)

(In reply to Piotr Grabowski from comment #22)

In the order user can specify the beginning of validity period. Generally the validity period should not start later than 30 days after certificate is generated. It is usually the day when the certificate will be installed on a server or the date correlated with the expiration date of a previously used certificate. Then we generate a certificate and hand it over before the validity period starts.

Within the Baseline Requirements, Section 9.6.1, the CA is required to give warranty that, at the time of issuance, the CA:

i. implemented a procedure for verifying the accuracy of all of the information contained in the Certificate (with the exception of the subject:organizationalUnitName attribute);
ii. followed the procedure when issuing the Certificate; and
iii. accurately described the procedure in the CA’s Certificate Policy and/or Certification Practice Statement;

As Comment #24 points out, this practice seems directly at odds with the Baseline Requirements. Could you share KIR S.A.'s analysis of how such forward dating reasonably complies with the requirement that the information is accurate, given that KIR S.A. is stating it for the future?

Further, I do not see this language incorporated into KIR S.A.'s CP/CPS. Could you detail where this warranty is provided?

Similarly, Section 9.6.3 of the BRs places certain obligations on a CA with respect to their Subscriber Agreement and Terms of Use. Similar to the above issue with Section 9.6.1, I can find no such reference in the KIR S.A. repository. If this is correct, please file a new issue, as this is another area of non-compliance.

https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c40 We no longer issue forward dated certificates.

(In reply to Piotr Grabowski from comment #52)

  • Failing to include the required portions in the Subscriber Agreement (Comment #26)

An order signed by a client contains the following statement. The order is signed by entitled representatives of the client.
In the case of an SSL certificate, the Ordering Party undertakes to:

  1. provide KIR with true and accurate information regarding the data of the certificate subject (subscriber) throughout the certificate validity period, in the form of both data contained in the order and data contained in the certificate request containing the public key for which the certificate is to be prepared;
  2. protect the private key associated with the public key for which KIR will issue a certificate by controlling the use of the private key, ensuring the confidentiality of the private key, ensuring the protection of all information related thereto;
  3. verification of data contained in the issued certificate;
  4. installation of the certificate only on the server that supports the domain name or domain names listed in the certificate issued by KIR;
  5. use the certificate in accordance with the law and the Agreement;
  6. immediate cessation of the use of the certificate and the related private key and notification to KIR of a request for certificate revocation in the following cases:
    a) incorrect or untrue data contained in the certificate,
    b) there is a suspicion of misuse of the certificate,
    c) compromising the private key,
    d) cease to use the private key associated with the public key included in the certificate upon expiry of the certificate or its revocation,
    e) other provisions provided for in the Certification Practice Statement of KIR for Trusted Non-Qualified Certificates;
  7. follow the instructions provided by KIR in the event of compromising the private key or misused the certificate.
    The Ordering Party accepts the right of KIR to revoke the certificate immediately if the Ordering Party does not comply with the obligations imposed on it or the revocation results from the Certification Practice Statement of KIR for Trusted Non-Qualified Certificates, Certification Policy of KIR for Trusted Non-qualified Certificates and Baseline Requests for the Issuance and Management of Publicly-Trusted Certificates.

Is the view that this contains all the necessary provisions of 9.6.3? It seems there are some elements missing. Perhaps you could provide a comparison of the BR provisions to KIR S.A.'s provisions, to see how they map up?

Flags: needinfo?(piotr.grabowski)

(In reply to Piotr Grabowski from comment #53)

As stated in https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c16 we have not ignored this comment:

I'm not sure I understand this reply. This bug appears to be indication that you ignored the comment and failed to make the changes that would have prevented this issue.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1525082#c4 , on 2020-05-06, KIR S.A. stated "For TLS (non-qualified) certificates we are now aligned with WebTrust and we are counting "non-delivered" certificates as issued, but opinion of our eIDAS auditor on this matter is completely different." This was further clarified in https://bugzilla.mozilla.org/show_bug.cgi?id=1525082#c9 on 2020-05-07, which stated "Wayne, qualified eIDAS certificates are out of scope of Mozilla's root store policy, they come from completely different, technicallly separarated subCA and ROOT which is not listed in Mozilla but in the european TSL lists."

From the example certificates provided, we see they are TLS (non-qualified) certificates, for example, https://crt.sh/?id=2886124820&opt=ocsp This seems to suggest that the comment on Bug 1525082 was factually incorrect. Could you explain why there's a disconnect?

I think we explained this issue serveral times. We are issuing qualified and non-qualified certificates.

I believe you have attempted to do what you believe is an explanation, but the reason this question has been asked is because the answer here is not sufficient, nor consistent with the statements that KIR S.A. has made. The issue here is that, independent of Qualified or Non-Qualified, the expectation is that all TLS certificates will comply with policy. Further, the question raised is an example of how a non-qualified certificate, which KIR S.A. stated it had taken steps to remediate, was not, in fact, remediated.

It's this lack of remediation that is concern, along with KIR S.A.'s attempts to make a distinction between qualified and non-qualified, which is not relevant for purposes of TLS.

I couldn't find this documented in your CP/CPS. Did I overlook something? CAs that do this are actively harmful to the goals of a more secure Internet, and so it's useful to understand why this may be done and how it's disclosed. If this is not disclosed within your CP/CPS, is there any public documentation about this process and workflow?

It appears you overlooked this question.

(In reply to Ryan Sleevi from comment #55)

Is the view that this contains all the necessary provisions of 9.6.3? It seems there are some elements missing. Perhaps you could provide a comparison of the BR provisions to KIR S.A.'s provisions, to see how they map up?

Ryan,
here is a comparion of the BR provisions to KIR's provions. All this provisions are included in an order signed by a client (Ordering Party). The order is signed by entitled representatives of the client (Ordering Party) and must be deliverd to KIR.

BR:
The Subscriber Agreement or Terms of Use MUST contain provisions imposing on the Applicant itself (or made by the Applicant on behalf of its principal or agent under a subcontractor or hosting service relationship) the following obligations and warranties:
Accuracy of Information: An obligation and warranty to provide accurate and complete information at all times to the CA, both in the certificate request and as otherwise requested by the CA in connection with the issuance of the Certificate(s) to be supplied by the CA;

KIR S.A.'s provisions:
In the case of an SSL certificate, the Ordering Party undertakes to:

  1. provide KIR with true and accurate information regarding the data of the certificate subject (subscriber) throughout the certificate validity period, in the form of both data contained in the order and data contained in the certificate request containing the public key for which the certificate is to be prepared;

BR:
2. Protection of Private Key: An obligation and warranty by the Applicant to take all reasonable measures to assure control of, keep confidential, and properly protect at all times the Private Key that corresponds to the Public Key to be included in the requested Certificate(s) (and any associated activation data or device, e.g. password or token);

KIR S.A.'s provisions:
2. protect the private key associated with the public key for which KIR will issue a certificate by controlling the use of the private key, ensuring the confidentiality of the private key, ensuring the protection of all information related thereto;

BR:
3. Acceptance of Certificate: An obligation and warranty that the Subscriber will review and verify the Certificate contents for accuracy;

KIR’s provisions:
3. verification of data contained in the issued certificate;

BR:
4. Use of Certificate: An obligation and warranty to install the Certificate only on servers that are accessible at the subjectAltName(s) listed in the Certificate, and to use the Certificate solely in compliance with all applicable laws and solely in accordance with the Subscriber Agreement or Terms of Use;

KIR’s provisions:
4. installation of the certificate only on the server that supports the domain name or domain names listed in the certificate issued by KIR;
5. use the certificate in accordance with the law and the Agreement;

BR:
5. Reporting and Revocation: An obligation and warranty to: (a) promptly request revocation of the Certificate, and cease using it and its associated Private Key, if there is any actual or suspected misuse or compromise of the Subscriber’s Private Key associated with the Public Key included in the Certificate, and (b) promptly request revocation of the Certificate, and cease using it, if any information in the Certificate is or becomes incorrect or inaccurate;
6. Termination of Use of Certificate: An obligation and warranty to promptly cease all use of the Private Key corresponding to the Public Key included in the Certificate upon revocation of that Certificate for reasons of Key Compromise.

KIR’s provisions:
6. immediate cessation of the use of the certificate and the related private key and notification to KIR of a request for certificate revocation in the following cases:
a) incorrect or untrue data contained in the certificate,
b) there is a suspicion of misuse of the certificate,
c) compromising the private key,
d) cease to use the private key associated with the public key included in the certificate upon expiry of the certificate or its revocation,
e) other provisions provided for in the Certification Practice Statement of KIR for Trusted Non-Qualified Certificates;

BR:
7. Responsiveness: An obligation to respond to the CA’s instructions concerning Key Compromise or Certificate misuse within a specified time period.

KIR’s provisions:
7. follow the instructions provided by KIR in the event of compromising the private key or misused the certificate.

BR:
8. Acknowledgment and Acceptance: An acknowledgment and acceptance that the CA is entitled to revoke the certificate immediately if the Applicant were to violate the terms of the Subscriber Agreement or Terms of Use or revocation is required by the CA’s CP, CPS, or these Baseline Requirements.

KIR’s provisions (this is a part missed in Piotr's comment): The Ordering Party accepts the right of KIR to revoke the certificate immediately if the Ordering Party does not comply with the obligations imposed on it or the revocation results from the Certification Practice Statement of KIR for Trusted Non-Qualified Certificates, Certification Policy of KIR for Trusted Non-qualified Certificates and Baseline Requests for the Issuance and Management of Publicly-Trusted Certificates.

I couldn't find this documented in your CP/CPS. Did I overlook something? CAs that do this are actively harmful to the goals of a more secure Internet, and so it's useful to understand why this may be done and how it's disclosed. If this is not disclosed within your CP/CPS, is there any public documentation about this process and workflow?

It appears you overlooked this question.

You can find the description of this process here https://www.elektronicznypodpis.pl/en/offer/non-qualified-certificates/

Flags: needinfo?(piotr.grabowski)

(In reply to Ryan Sleevi from comment #56)

(In reply to Piotr Grabowski from comment #53)

As stated in https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c16 we have not ignored this comment:

I'm not sure I understand this reply. This bug appears to be indication that you ignored the comment and failed to make the changes that would have prevented this issue.

In https://bugzilla.mozilla.org/show_bug.cgi?id=1525082#c4 , on 2020-05-06, KIR S.A. stated "For TLS (non-qualified) certificates we are now aligned with WebTrust and we are counting "non-delivered" certificates as issued, but opinion of our eIDAS auditor on this matter is completely different." This was further clarified in https://bugzilla.mozilla.org/show_bug.cgi?id=1525082#c9 on 2020-05-07, which stated "Wayne, qualified eIDAS certificates are out of scope of Mozilla's root store policy, they come from completely different, technicallly separarated subCA and ROOT which is not listed in Mozilla but in the european TSL lists."

From the example certificates provided, we see they are TLS (non-qualified) certificates, for example, https://crt.sh/?id=2886124820&opt=ocsp This seems to suggest that the comment on Bug 1525082 was factually incorrect. Could you explain why there's a disconnect?

I think we explained this issue serveral times. We are issuing qualified and non-qualified certificates.

I believe you have attempted to do what you believe is an explanation, but the reason this question has been asked is because the answer here is not sufficient, nor consistent with the statements that KIR S.A. has made. The issue here is that, independent of Qualified or Non-Qualified, the expectation is that all TLS certificates will comply with policy. Further, the question raised is an example of how a non-qualified certificate, which KIR S.A. stated it had taken steps to remediate, was not, in fact, remediated.

It's this lack of remediation that is concern, along with KIR S.A.'s attempts to make a distinction between qualified and non-qualified, which is not relevant for purposes of TLS.

This bug report and the timeline provided in point 2 of the comment https://bugzilla.mozilla.org/show_bug.cgi?id=1705657#c1, especially this one:
2019-04-05 08:00 am CEST Procedural steps were taken and reconfiguration of existing software were done
shows that we did not ignored the Wayne's comment. This is just one of the examples that we then tried to fix the inconsistency by, in our opinion, the best means at the time. In retrospect, however, we all know that the selected countermeasures and their controls were not optimal. That was also very concerning for us.
We used the distinction between qualified and non-qualified certificates only to show the source of the problem, which may be valueable to other CAs and the community to avoid similar issues.
We think that lessons learned with this issue will improve our processes in many areas. Clear separation of duties for main components, detailed risk analysis and impact assessment and multi-layer supervisory just to name a few. Once again, we admit that we are fully aware that the first attempt to eliminate the problem was not 100% effective, but we have our lesson learnt from this that will certainly
improve our business processes.
However, it should also be clearly emphasized that the technical change that we have implemented solves the matter comprehensively and, hopefully, ultimately.

So this issue is quite long, and obviously untangled a set of dependent/related issues, and has a lot of quoted text that can further make it difficult to follow on.

Trying to make sure I can summarize this issue adequately:

Date Source Statement
2019-01-28 Bug 1523186, Comment #2 it's pointed out that KIR S.A.'s procedural controls have regularly been insufficient, and recommends halting all issuance until technical controls are in place (in this case, linting).
2019-01-31 Bug 1523186, Comment #5 it's pointed out that KIR S.A. is responding "unknown" to issued certificates.
2019-02-04 Bug 1523186, Comment #13 it's pointed out that the resolution of discussion affirmatively concludes that this is prohibited.
2019-04-05 Comment #16 KIR S.A. states they have begun implementing technical controls.
2019-07-04 Bug 1523186, Comment #17 KIR S.A. is one of three CAs that has to be contacted due to their lack of progress updates.
2020-05-06 Bug 1525082, Comment #4 KIR S.A. states that for TLS certificates, they have addressed the issue by changing their procedures.
2021-04-07 Comment #1 KIR S.A. states that their solution to this problem was procedural controls, because technical controls were too difficult ("was too big a technical challenge for us").
2021-04-17 Comment #7 KIR S.A. states they have implemented technical controls.
2021-04-19 Comment #10 KIR S.A. states they are beginning to implement technical controls.
2021-04-20 Comment #16 KIR S.A. states the technical changes did not begin until this date.
2021-04-21 Comment #12 A new incident of this issue is observed. In Comment #14, KIR S.A. states they've not completed implementing the technical controls.
2021-04-22 Comment #16 KIR S.A. states the technical changes are complete.
2021-05-02 Comment #46 KIR S.A. states that the technical changes are not yet complete.
2021-05-05 Comment #48 KIR S.A. states the technical changes are complete.

Throughout this incident, it's been revealed that there are a host of systemic communication issues, which is something that was previously captured in Bug 1523186, Comment #25 and Bug 1523186, Comment #26. These issues appear to still be present, as evidenced by the ample discussion on this bug and the related incidents it has spawned. As https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/jOq6_ijw-9g/m/FdtIjvypAgAJ captures, this appears to be a systemic trend.

While I think more discussion about how to address the issues here is necessary, considering overall the quality of these incident responses, I think with the above captured, there's nothing further for this bug if that path is taken.

Here is our small update to the summary based on previously selected comments/sources and dates.

Date Source Statement
2019-01-28 Bug 1523186, Comment #2 it's pointed out that KIR S.A.'s procedural controls have regularly been insufficient, and recommends halting all issuance until technical controls are in place (in this case, linting).
2019-01-31 Bug 1523186, Comment #5 it's pointed out that KIR S.A. is responding "unknown" to issued certificates.
2019-02-04 Bug 1523186, Comment #13 it's pointed out that the resolution of discussion affirmatively concludes that this is prohibited.
2019-04-05 Bug 1705657, Comment #16 KIR S.A. states they that procedural steps were taken and reconfiguration of existing software were done. /procedural control has been deployed/
2019-07-04 Bug 1523186, Comment #17 KIR S.A. is one of three CAs that has to be contacted due to their lack of progress updates.
2020-05-06 Bug 1525082, Comment #4 KIR S.A. states that for TLS certificates, they have addressed the issue by changing their procedures.
2021-04-07 Bug 1705657, Comment #1 KIR S.A. states that their solution to this problem was procedural controls, because technical controls were too difficult ("was too big a technical challenge for us"). /
2021-04-17 Bug 1705657, Comment #7 KIR S.A. states that will implement automatic mechanism for placing unissued certificates in OCSP /technical change/
2021-04-19 Bug 1705657, Comment #10 KIR S.A. states that technical change will be implemented in this week /estimation of the workload/.
2021-04-20 Bug 1705657, Comment #16 KIR S.A. states the implementation of the technical change began /development environment/.
2021-04-21 Bug 1705657, Comment #12 A new incident of this issue is observed. In Comment #14, KIR S.A. states they've not completed implementing the technical controls /the technical change is not deployed in the production yet/.
2021-04-22 Bug 1705657, Comment #16 KIR S.A. states the technical technical change is tested /development and integration environment/.
2021-05-02 Bug 1705657, Comment #46 KIR S.A. states that the the change is production ready /some more test cases were added/.
2021-05-05 Bug 1705657, Comment #48 KIR S.A. states the technical changes are complete /was deployed on the production/.

As a short summary - the issue no longer exists, but in case of any further questions, doubts or explanations we are open for discussion.

No update here. Are there any additional questions?

No update here . Are there any additional questions?

I will close this bug on or about Wed. 14-July-2021 unless there are additional questions.

(In reply to Ben Wilson from comment #64)

I will close this bug on or about Wed. 14-July-2021 unless there are additional questions.

Based on this comment, can we close this bug?

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