Closed Bug 1670458 Opened 4 years ago Closed 3 years ago

Disig: Failure to provide a preliminary report within 24 hours.

Categories

(CA Program :: CA Certificate Compliance, task)

Product:
CA Program
Component:
CA Certificate Compliance
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: fozzie, Assigned: peter.miskovic)

Details

(Whiteboard: [ca-compliance] [disclosure-failure])

Attachments

(1 file)

RE Invalid stateOrProvinceName (Slovakia).msg
54.00 KB, application/octet-stream
Details

I sent a problem report to tspnotify@disig.sk and have yet to receive a preliminary report:

Friday 9 October 22:17 UTC - I sent a report concerning the following certificates' stateOrProvinceNames as "Slovakia":

As of Sunday 11 October 08:33 UTC I have yet to receive a response.

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

Hi Ben,

a message from George <george@fozzie.dev> we received on Saturday, October 10, 2020 at 00:18 a.m. I read it that day afternoon. In terms of content, I decided not to react immediately during the weekend because I wasn't sure if there was a real violation of the Basic requirement and I evaluated it as a low security risk for the PKI ecosystem. I reacted this morning that, in our opinion, there was no violation of the Baseline requirements (version 1.7.2) stated in 7.1.4.2.2 (f). BTW George alleges a breach of 7.1.4.2.2 (g) which is about postalCode.

The response to the George <george@fozzie.dev> is in attachment.
Regards.
Peter Miskovic

It is particiularly concerning that you would ignore an incident report because you initially thought it wasn't a violation of the Baseline Requirements. CAs can and do misinterpret requirements and a reply stating that you don't believe it is a violation is useful for explaining further. This is especially concerning in this case as there has been multiple bugs opened with this exact issue on Bugzilla over the past 2 weeks (bug 1667430, bug 1667986, bug 1667842 and an even older bug 1645686). Does Disig not frequently view the incidents posted in this section?

What would have happened if someone reported an incident to Disig, Disig did not think it was a violation initially and the reporter did not report this to Bugzilla or to another trust store?

Now onto the violation itself, Matthias has provided an excellent explanation in comment 1 of bug 1667430.

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.

Answer: We were conscious about the problem for the first time when George send a message to the tsp_notify@disig.sk at 10.10.2020 at 0:18 CET and then when he filled up this bug report.

2) A timeline of the actions your CA took in response. A timeline is a date-and-time-stamped sequence of all relevant events. This may include events before the incident was reported, such as when a particular requirement became applicable, or a document changed, or a bug was introduced, or an audit was done.

Answer
October 10, 2020: When we received the notification on tsp_notify@disig.sk I read it (Peter Miskovic) and decided to respond to the George on my first working day e. g. October 12, 2020 because I was not sure if what he reported is an violation of BR. Also it was a weekend and I know that there be no possibility to issue a new TLS/SSL certificate with reporting problem, so I decided to wait until Monday morning to respond.
October 12, 2020: Study the case and respond to the George and to the ben how we see the situation
October 12, 2020: Stop issuing certificated with the affected profiles and wait until resolving if issued certificates are really not conformed with the BR requirements.

3) Whether your CA has stopped, or has not yet stopped, issuing certificates with the problem. A statement that you have will be considered a pledge to the community; a statement that you have not requires an explanation.

Answer
CA stopped issuing TLS/SSL certificates and it has not issued any from October 10, 2020 - we are not issuing certificates during the weekend (Saturday, Sunday)

4) A summary of the problematic certificates. For each problem: number of certs, and the date the first and last certs with that problem were issued.
Answer
CA Disig R2I2 Certification Service - reported by George was 81

5) The complete certificate data for the problematic certificates. The recommended way to provide this is to ensure each certificate is logged to CT and then list the fingerprints or crt.sh IDs, either in the report or as an attached spreadsheet, with one list per distinct problem.
Answer
The complete certificate data for the problematic certificates are part of this bug on the link [https://misissued.com/batch/184/]

6) Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
Answer
As I am explained in may answer to the Gorge in my previous comments, we are not aware that this practice is the violation requirement of the point 7.1.4.2.2.f) belonged to Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates.

Here is our interpretation how we see this requirement:

We see this requirement has four parts.

f. Certificate Field:
subject:stateOrProvinceName (OID: 2.5.4.8)

Required/Optional:

  1. Required if the subject:organizationName field, subject:givenName field, or subject:surname field are present and subject:localityName field is absent.

  2. Optional if the subject:localityName field and the subject:organizationName field, the subject:givenName field, or the subject:surname field are present. Prohibited if the subject:organizationName field, the subject:givenName field, or subject:surname field are absent.

  3. Contents: If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under Section 3.2.2.1.

  4. If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XXin accordance with Section 7.1.4.2.2(g), the subject:stateOrProvinceName field MAY contain the full name of the Subject’s country information as verified under Section

My comments to that parts:

At 1) In this part is stated that this field is required when subject:organizationName field, subject:givenName field, or subject:surname field are present and subject:localityName field is absent. - this is no case for assigned TLS/SSL certificate issued by our company

At 2) In this par is stated that this field can be optionally present if subject:localityName field and the subject:organizationName field are present. - This is our case. There is nothing more about what if there is in the filed countryName something else as "XX"

At 3) In this part is only requirement for verification of Subject’s state or province information

At 4) The last part is concerning situation where there is in the subject:countryName user-assigned code of XX.
This is no valid for assigned certificate issued by our company. In all of them is in countryName "SK"

According this interpretation we think that we can filled in this field "Slovakia" because from our point of view we have to be in conformance with the parts 2) and 3) of 7.1.4.2.2 (f) of BR?

7) List of steps your CA is taking to resolve the situation and ensure such issuance will not be repeated in the future, accompanied with a timeline of when your CA expects to accomplish these things.

Answer
If there is a match, the reported TLS / SSL certificates were issued incorrectly with the stateOrProvinceName field incorrectly filled in, then we must prepare a plan with our clients on how to reissue these certificates with the correct content and not damage their operation.

You are correct, with these particiular certificates there is not a requirement to have a stateOrProvinceName field. However if you include one it does need to be in conformance with the Baseline Requirements. As "Slovakia" is not a province and the certificates do not meet the exception for containing the country name in the ST field (due to Slovakia having SK as an assigned country code) this means that these certificates are misissued.

Where is stated that exception?

I see only one exception:

The one in the 7.1.4.2.2 (f) of BR:
If the subject:countryName field specifies the ISO 3166-1 user-assigned code of XX in accordance with Section 7.1.4.2.2(g), the subject:stateOrProvinceName field MAY contain the full name of the Subject’s country information as verified under Section 3.2.2.1.

BTW in the last version of BR (1.7.2) there is a typo because Section 7.1.4.2.2(g) is concerning postalCode (OID: 2.5.4.17) and has nothing to do with the stateOrProvinceName field.

In my view, there is no link between part 2) of point 7.1.4.2.2 (a). f) BR and part 4) of point 7.1.4.2.2 letter f BR. I think that the last sentence (part 4) in 7.1.4.2.2 (f) with MAY contain does not mean that there is only this possibility and excludes all others.

Part 2) only stated if there is subject:localityName field and the subject:organizationName field ĆA has an option to put the stateOrProvinceName to the TLS/SSL certificate. I see no further restriction there.

Yes that is the exception I’m referring to, which you’ve already agreed you don’t meet. Look the first part though, you have not included the verified province as “Slovakia” is not a province.

Since there seems to be some confusion, perhaps you can explain:

  1. Contents: If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under Section 3.2.2.1.

Can you help me understand how the value "Slovakia" meets those requirements?

Using your analysis from Comment #4, there are two conditions on when the field may be present (#1 and #2) and two conditions on what the field may contain (#3 and #4). I understand you're asserting that it meets the requirements of #2, and so can be present, but I'm confused how Disig sees the value as meeting the requirements in #3.

Comment #4 suggests somehow that is only has to be verified, namely:

At 3) In this part is only requirement for verification of Subject’s state or province information

But that seems to ignore the statement that it applies to the contents

Flags: needinfo?(peter.miskovic)

(In reply to Peter Miskovic from comment #2)

a message from George <george@fozzie.dev> we received on Saturday, October 10, 2020 at 00:18 a.m. I read it that day afternoon. In terms of content, I decided not to react immediately during the weekend because I wasn't sure if there was a real violation of the Basic requirement and I evaluated it as a low security risk for the PKI ecosystem. I reacted this morning that, in our opinion, there was no violation of the Baseline requirements (version 1.7.2) stated in 7.1.4.2.2 (f). BTW George alleges a breach of 7.1.4.2.2 (g) which is about postalCode.

Also, is this process described somewhere in the CP/CPS? I tried to find it in version 5.4 of the CP, but I couldn't find any description of a triage process here that described those determined to be "low security risk" or uncertainty to be dealt with on the next business day. If this is dealt with in supplemental documentation about the processes and workflow, could you please attach them?

(In reply to Ryan Sleevi from comment #8)

Since there seems to be some confusion, perhaps you can explain:

  1. Contents: If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under Section 3.2.2.1.

Can you help me understand how the value "Slovakia" meets those requirements?

The verification of the possibility to put to the subject:stateOrProvinceName is based on the two sources:

  1. First one is the BUSINESS REGISTER provided by MINISTRY OF JUSTICE OF THE SLOVAK REPUBLIC where is provided name and address of an organization together with the Identification number (IČO).
  2. The second one is the registrar of top level .SK Internet domain SK-NIC where we can see that the name and address from Business register match the name and address of the domain owner. Registrar of all SK domain has in their reference state code in form of SK and this belongs to the Slovakia.

As I wrote to the George in Comment #1 some of our clients from Slovakia are using for the generation keys and request for issuing TLS/SSL certificate MS IIS where field State/province is mandatory, so for them we accepted if they filled this with the „Slovakia“ as a „state“ name.

Due to the fact that this practice is a violation of BR requirements, we should now force them to use key generation tools, which may pose an increased security risk to many of them, only to exclude the StateOrPrrovince name value, which, if stated, itself does not pose any security risk.

Using your analysis from Comment #4, there are two conditions on when the field may be present (#1 and #2) and two conditions on what the field may contain (#3 and #4). I understand you're asserting that it meets the requirements of #2, and so can be present, but I'm confused how Disig sees the value as meeting the requirements in #3.

Comment #4 suggests somehow that is only has to be verified, namely:

At 3) In this part is only requirement for verification of Subject’s state or province information

But that seems to ignore the statement that it applies to the contents

It is not a problem for us to contact all holders of the affected TLS / SSL certificates, with the proviso that we must revoke them, as they contain the value "Slovakia", which is not allowed.

However, you can advise me on how to justify the security risk posed by the certificate issued in this way. Have any been recorded, or are we just playing with the details and keeping a close eye on them, even at a cost that will cost us all a lot of effort and the resulting security effect will be more or less zero?

I would also like to advise you on what to recommend when generating keys and requests if, for the reasons described, they can no longer use the ones offered by the purchased software.
(In reply to Ryan Sleevi from comment #9)

(In reply to Peter Miskovic from comment #2)

a message from George <george@fozzie.dev> we received on Saturday, October 10, 2020 at 00:18 a.m. I read it that day afternoon. In terms of content, I decided not to react immediately during the weekend because I wasn't sure if there was a real violation of the Basic requirement and I evaluated it as a low security risk for the PKI ecosystem. I reacted this morning that, in our opinion, there was no violation of the Baseline requirements (version 1.7.2) stated in 7.1.4.2.2 (f). BTW George alleges a breach of 7.1.4.2.2 (g) which is about postalCode.

Also, is this process described somewhere in the CP/CPS? I tried to find it in version 5.4 of the CP, but I couldn't find any description of a triage process here that described those determined to be "low security risk" or uncertainty to be dealt with on the next business day. If this is dealt with in supplemental documentation about the processes and workflow, could you please attach them?

Flags: needinfo?(peter.miskovic)

(In reply to Peter Miskovic from comment #10)

As I wrote to the George in Comment #1 some of our clients from Slovakia are using for the generation keys and request for issuing TLS/SSL certificate MS IIS where field State/province is mandatory, so for them we accepted if they filled this with the „Slovakia“ as a „state“ name.

Due to the fact that this practice is a violation of BR requirements, we should now force them to use key generation tools, which may pose an increased security risk to many of them, only to exclude the StateOrPrrovince name value, which, if stated, itself does not pose any security risk.

I don't understand this, why couldn't you just include the actual province information instead of "Slovakia"? Slovakia does have provinces/regions (https://en.wikipedia.org/wiki/ISO_3166-2:SK).

As for revocation, under the Baseline Requirements these certificates must be revoked within 5 days. So if you decide not to revoke them, you will need to publish a separate incident report on why you're violating the Baseline Requirements and your CPS by not revocing these certificates.

(In reply to Ryan Sleevi from comment #9)

(In reply to Peter Miskovic from comment #2)

a message from George <george@fozzie.dev> we received on Saturday, October 10, 2020 at 00:18 a.m. I read it that day afternoon. In terms of content, I decided not to react immediately during the weekend because I wasn't sure if there was a real violation of the Basic requirement and I evaluated it as a low security risk for the PKI ecosystem. I reacted this morning that, in our opinion, there was no violation of the Baseline requirements (version 1.7.2) stated in 7.1.4.2.2 (f). BTW George alleges a breach of 7.1.4.2.2 (g) which is about postalCode.

Also, is this process described somewhere in the CP/CPS? I tried to find it in version 5.4 of the CP, but I couldn't find any description of a triage process here that described those determined to be "low security risk" or uncertainty to be dealt with on the next business day. If this is dealt with in supplemental documentation about the processes and workflow, could you please attach them?

You are right, this was my decision without any process which is describing in the CP/CPS. What I wanted to say was that if somebody from <george@fozzie.dev> wants to revoked 81 TLS/SSL certificates issued I needed a time to see what exactly happen and at that time I didn't see any big security to do it immediately. Only what I forgot was to respond to him with the explanation what we will do with his request.
(In reply to george from comment #11)

(In reply to Peter Miskovic from comment #10)

As I wrote to the George in Comment #1 some of our clients from Slovakia are using for the generation keys and request for issuing TLS/SSL certificate MS IIS where field State/province is mandatory, so for them we accepted if they filled this with the „Slovakia“ as a „state“ name.

Due to the fact that this practice is a violation of BR requirements, we should now force them to use key generation tools, which may pose an increased security risk to many of them, only to exclude the StateOrPrrovince name value, which, if stated, itself does not pose any security risk.

I don't understand this, why couldn't you just include the actual province information instead of "Slovakia"? Slovakia does have provinces/regions (https://en.wikipedia.org/wiki/ISO_3166-2:SK).

As for revocation, under the Baseline Requirements these certificates must be revoked within 5 days. So if you decide not to revoke them, you will need to publish a separate incident report on why you're violating the Baseline Requirements and your CPS by not revocing these certificates.

(In reply to george from comment #11)

(In reply to Peter Miskovic from comment #10)

As I wrote to the George in Comment #1 some of our clients from Slovakia are using for the generation keys and request for issuing TLS/SSL certificate MS IIS where field State/province is mandatory, so for them we accepted if they filled this with the „Slovakia“ as a „state“ name.

Due to the fact that this practice is a violation of BR requirements, we should now force them to use key generation tools, which may pose an increased security risk to many of them, only to exclude the StateOrPrrovince name value, which, if stated, itself does not pose any security risk.

I don't understand this, why couldn't you just include the actual province information instead of "Slovakia"? Slovakia does have provinces/regions (https://en.wikipedia.org/wiki/ISO_3166-2:SK).

As for revocation, under the Baseline Requirements these certificates must be revoked within 5 days. So if you decide not to revoke them, you will need to publish a separate incident report on why you're violating the Baseline Requirements and your CPS by not revocing these certificates.

George, I can ask them to prepare a new request but are you sure that the ones with the province information will be more secured as the ones exists now.

As I respond to the Ryan in #8 could you explain to me how do you see the security risk of using current existing TLS/SSL certificates in comparison to the new one with the Slovakia province/regions according https://en.wikipedia.org/wiki/ISO_3166-2:SK?
BTW I can't be able to verify suggested information according to the Section 3.2.2.1. because there is no relevant source which is using it.

There is no hard defined source for provinces, most CAs will have their own listed based on sources like ISO 3166-2 (see bug 1645686 and bug 1576013). I believe the linked regions satisfy the definition of a "state or province".

As you mentioned, the certificates here have locality fields which do mitigate some of the security risk of not being able to verify a company's authenticity and as already mentioned, the Baseline Requirements do not require the stateOrProvinceName field if you have both an organizationName and locality field. However as Disig has included one it has to be valid.

The security risk is in trusting a CA that won't abide by its promises to relying parties.

(In reply to Peter Miskovic from comment #10)

Can you help me understand how the value "Slovakia" meets those requirements?

The verification of the possibility to put to the subject:stateOrProvinceName is based on the two sources:

  1. First one is the BUSINESS REGISTER provided by MINISTRY OF JUSTICE OF THE SLOVAK REPUBLIC where is provided name and address of an organization together with the Identification number (IČO).
  2. The second one is the registrar of top level .SK Internet domain SK-NIC where we can see that the name and address from Business register match the name and address of the domain owner. Registrar of all SK domain has in their reference state code in form of SK and this belongs to the Slovakia.

Can you clarify: Does the validation process use either of these, or does it require both?

As I wrote to the George in Comment #1 some of our clients from Slovakia are using for the generation keys and request for issuing TLS/SSL certificate MS IIS where field State/province is mandatory, so for them we accepted if they filled this with the „Slovakia“ as a „state“ name.

Can you help me understand this more? I’m quite familiar with IIS and it’s certificate generation process, and I’m not aware of any such requirement existing within the software. While it’s true that the CSRs it generates follow a default template (which can be further customized), it doesn’t have any such limitation, nor does it require the CSR subject exactly match the generated certificate.

Due to the fact that this practice is a violation of BR requirements, we should now force them to use key generation tools, which may pose an increased security risk to many of them, only to exclude the StateOrPrrovince name value, which, if stated, itself does not pose any security risk.

I’m deeply troubled by this response, and hoping it’s something lost in translation. I do believe Disig may be misunderstanding the tools, so I think the premise is flawed. However, even if it was correct, the entire basis for trusting Disig is on the belief and condition that they will faithfully and accurately adhere to the Root Policy. A CA that does not adhere to a root policy, no matter the nature of the divergence, is a security risk, because that CA cannot be trusted to do what they say and correctly do it. CA Security is based on trust, and failing to do what they say undermines trust and undermines user security.

Equally important, however, is that revocation does not pose security risks if the CA is designed and behaving appropriately. Every CA is required, as a condition of trust, to design their systems with revocation in mind. That’s been true since the very first version of X.509, is the basis for all CP/CPSes, and has been true of the Baseline Requirements for nearly 7 years. As such, if the argument is that revocation poses a security risk, then the only possible conclusion we can reach is that such security risk is caused by the CA themselves. Since CAs causing security risks to users is deeply troubling, I hope that isn’t the case here.

It is not a problem for us to contact all holders of the affected TLS / SSL certificates, with the proviso that we must revoke them, as they contain the value "Slovakia", which is not allowed.

However, you can advise me on how to justify the security risk posed by the certificate issued in this way. Have any been recorded, or are we just playing with the details and keeping a close eye on them, even at a cost that will cost us all a lot of effort and the resulting security effect will be more or less zero?

I think statements like this are concerning, because they highlight a fundamental misunderstanding of risk, compliance, and security. As a CA, Disig has committed to following the required Root Policy. Disig has not done this, and appears to not view this fact as significant. Further, any “cost” is not a result of the community actions here, but because of how Disig designed and operates its CA. Similar CAs do not have the same cost, so if our goal is to avoid any cost, the best solution is to only trust the CAs that designed their systems to avoid that, which would mean not trusting Disig.

Compliance incidents like this are incredibly valuable to the community, because they highlight CAs that are not designed to operate in a trustworthy fashion, or which see compliance as difficult.

If it helps better understand this perspective, imagine a company that was hired to sell tickets for a concert. They agree to sell 100 tickets, at $10, and will pay the venue $1000. However, instead of selling 100 tickets, they sell 150, and keep the extra $500 for themselves. When this is pointed out, they argue the venue can hold 200 people, so what’s the problem?

A CA is entrusted by browsers to ensure all of their certificates are made according to a specification. If the CA does not follow the specification, then those certificates should not be trusted. One way is for the CA to publish that they made a mistake, letting the world know the certificates were not issued correctly. Another is to remove trust in the CA, if they cannot be trusted to follow the specification.

I would also like to advise you on what to recommend when generating keys and requests if, for the reasons described, they can no longer use the ones offered by the purchased software.

The answer is simple: if the certificate does not conform to the requirements, do not issue it. However, as I’ve stated, Disig has yet to demonstrate that this is the case here. This is why transparency is so important: it helps identify facts from confusion, and helps find workable solutions. CAs are not permitted to unilaterally make decisions to ignore requirements, as that is not trustworthy nor in the interests of users.

(In reply to Peter Miskovic from comment #12)

(In reply to Ryan Sleevi from comment #9)

(In reply to Peter Miskovic from comment #2)

a message from George <george@fozzie.dev> we received on Saturday, October 10, 2020 at 00:18 a.m. I read it that day afternoon. In terms of content, I decided not to react immediately during the weekend because I wasn't sure if there was a real violation of the Basic requirement and I evaluated it as a low security risk for the PKI ecosystem. I reacted this morning that, in our opinion, there was no violation of the Baseline requirements (version 1.7.2) stated in 7.1.4.2.2 (f). BTW George alleges a breach of 7.1.4.2.2 (g) which is about postalCode.

Also, is this process described somewhere in the CP/CPS? I tried to find it in version 5.4 of the CP, but I couldn't find any description of a triage process here that described those determined to be "low security risk" or uncertainty to be dealt with on the next business day. If this is dealt with in supplemental documentation about the processes and workflow, could you please attach them?

You are right, this was my decision without any process which is describing in the CP/CPS. What I wanted to say was that if somebody from <george@fozzie.dev> wants to revoked 81 TLS/SSL certificates issued I needed a time to see what exactly happen and at that time I didn't see any big security to do it immediately. Only what I forgot was to respond to him with the explanation what we will do with his request.

I hope it’s clear that this is a critical failure by a trusted CA to perform the actions it promised to within its CP/CPS. The stated policies for Disig state in no uncertain terms that this is not the process Disig uses. Minimally, this needs to be noted within the next audit report, but more practically, this incident report needs to evaluate why it was possible for this to happen, and the steps being taken to prevent it from ever happening again.

This isn’t about trying to blame you from making a completely inappropriate choice. It’s about making sure that Disig has the processes and tools in place to ensure this cannot happen. If Disig is following CA incidents, as required by Mozilla policy, then they should have been aware of past CA incidents, understand how unacceptable this is, and been working to ensure controls are in place to prevent this. Please include these incidents from other CAs as part of your timeline for the incident report, so that we can understand how Disig’s controls and practices learned from them and were designed to prevent the same from occurring.

Flags: needinfo?(peter.miskovic)

(In reply to Peter Miskovic from comment #10)

Due to the fact that this practice is a violation of BR requirements, we should now force them to use key generation tools, which may pose an increased security risk to many of them, only to exclude the StateOrPrrovince name value, which, if stated, itself does not pose any security risk.

There seems to be a misunderstanding of the BR. The BR only force you to revoke the certificates, they do not force you to reissue them. You seem to describe that there is some nebulous security issue with reissuing them, so it would seem advisable that you do, in fact, not reissue them or, if you still do, describe why this does not pose a security risk anymore. A CA forcing customers or relying parties to take an "increased security risk" would be poor.

UPDATION OF TIMELINE

  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.

Answer
October 10, 2020: When we received the notification on tsp_notify@disig.sk I read it (Peter Miskovic) and decided to respond to the George on my first working day e. g. October 12, 2020 because I was not sure if what he reported is an violation of BR. Also it was a weekend and I know that there be no possibility to issue a new TLS/SSL certificate with reporting problem, so I decided to wait until Monday morning to respond.
October 12, 2020: Study the case and respond to the George and to the ben how we see the situation
October 12, 2020: Stop issuing certificated with the affected profiles and wait until resolving if issued certificates are really not conformed with the BR requirements.
October 12, 2020: Sending an e-mail to all customers whose certificates contain the item subject:stateOrProvinceName = Slovakia with an explanation and requesting the earliest possible delivery of applications for issuing a new certificates without subject:stateOrProvinceName, as we as their provider are obliged within 5 days from the obtained notification i.e. no later than 15.10. 0:18 CET to revoke all misissued certificates.
October 13, 2020: We changed all profiles for TLS/SSL certificate such way that profiles will not contain "subject:stateOrProvinceName"
October 13, 2020 During the day, we issued 72 new TLS / SSL certificates out of 77 ([https://misissued.com/batch/184/]) that were incorrectly issued based on new requests from individual holders, where the new certificates no longer contain subject: stateOrProvinceName.

Flags: needinfo?(peter.miskovic)

TIMELINE UPDATE:

October 13, 2020: I have carefully looked at these similar incidents that have occurred in the past and are related to the problem:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1648997] Actalis: inaccurate value in stateOrProvinceName
[https://bugzilla.mozilla.org/show_bug.cgi?id=1670894] SwissSign: Invalid stateOrProvinceName field
[https://bugzilla.mozilla.org/show_bug.cgi?id=1551364] SwissSign: "Some-State" in stateOrProvinceName
[https://bugzilla.mozilla.org/show_bug.cgi?id=1667842 ] SecureTrust: Inaccurate value in stateOrProvinceName
[https://bugzilla.mozilla.org/show_bug.cgi?id=1667986] Asseco DS / Certum: Invalid stateOrProvinceName field
[https://bugzilla.mozilla.org/show_bug.cgi?id=1667684] Asseco DS / Certum: Failure to provide a preliminary report within 24 hours.
[https://bugzilla.mozilla.org/show_bug.cgi?id=1668523] Asseco DS/Certum: Failure to revoke within 5 days
[https://bugzilla.mozilla.org/show_bug.cgi?id=1645686] Camerfirma: Invalid stateOrProvinceName field
[https://bugzilla.mozilla.org/show_bug.cgi?id=1668007] GlobalSign: Invalid stateOrProvinceName value
[https://bugzilla.mozilla.org/show_bug.cgi?id=1653284] Izenpe: incorrect value in stateOrProvinceName
[https://bugzilla.mozilla.org/show_bug.cgi?id=1645686] Sectigo: Lack of input validation in stateOrProvinceName

UPDATED Timeline from comment #4

  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.

Answer
October 10, 2020: When we received the notification on tsp_notify@disig.sk I read it (Peter Miskovic) and decided to respond to the George on my first working day e. g. October 12, 2020 because I was not sure if what he reported is an violation of BR. Also it was a weekend and I know that there be no possibility to issue a new TLS/SSL certificate with reporting problem, so I decided to wait until Monday morning to respond.

October 12, 2020: Study the case and respond to the George and to the ben how we see the situation

October 12, 2020: Stop issuing certificated with the affected profiles and wait until resolving if issued certificates are really not conformed with the BR requirements.

October 12, 2020: Sending an e-mail to all customers whose certificates contain the item subject:stateOrProvinceName = Slovakia with an explanation and requesting the earliest possible delivery of applications for issuing a new certificates without subject:stateOrProvinceName, as we as their provider are obliged within 5 days from the obtained notification i.e. no later than 15.10. 0:18 CET to revoke all misissued certificates.

October 13, 2020: We changed all profiles for TLS/SSL certificate such way that profiles will not contain "subject:stateOrProvinceName"

October 13, 2020 During the day, we issued 72 new TLS / SSL certificates out of 77 ([https://misissued.com/batch/184/]) that were incorrectly issued based on new requests from individual holders, where the new certificates no longer contain subject: stateOrProvinceName.

October 13, 2020 I have carefully looked at these similar incidents that have occurred in the past and are related to the problem:
[https://bugzilla.mozilla.org/show_bug.cgi?id=1648997] Actalis: inaccurate value in stateOrProvinceName
[https://bugzilla.mozilla.org/show_bug.cgi?id=1670894] SwissSign: Invalid stateOrProvinceName field
[https://bugzilla.mozilla.org/show_bug.cgi?id=1551364] SwissSign: "Some-State" in stateOrProvinceName
[https://bugzilla.mozilla.org/show_bug.cgi?id=1667842 ] SecureTrust: Inaccurate value in stateOrProvinceName
[https://bugzilla.mozilla.org/show_bug.cgi?id=1667986] Asseco DS / Certum: Invalid stateOrProvinceName field
[https://bugzilla.mozilla.org/show_bug.cgi?id=1667684] Asseco DS / Certum: Failure to provide a preliminary report within 24 hours.
[https://bugzilla.mozilla.org/show_bug.cgi?id=1668523] Asseco DS/Certum: Failure to revoke within 5 days
[https://bugzilla.mozilla.org/show_bug.cgi?id=1645686] Camerfirma: Invalid stateOrProvinceName field
[https://bugzilla.mozilla.org/show_bug.cgi?id=1668007] GlobalSign: Invalid stateOrProvinceName value
[https://bugzilla.mozilla.org/show_bug.cgi?id=1653284] Izenpe: incorrect value in stateOrProvinceName
[https://bugzilla.mozilla.org/show_bug.cgi?id=1645686] Sectigo: Lack of input validation in stateOrProvinceName

October 14, 2020 During the day we re-issued two more certificates from the list. For the rest there was no interest to re-issue.

October 14,2020 Preparation of process for revoking all the 77 certificates on the list [https://misissued.com/batch/184/]

October 14, 2020 Revocation of all 77 certificates on the list [https://misissued.com/batch/184/] started at 20:00 CET and ended at 20:30 CET.

October 14, 2020 All 77 certificates on the list [https://misissued.com/batch/184/] are revoked.

UPDATED Timeline from comment #4

October 16, 2020
Based on similar bugs [https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c4], I performed an analysis of all valid TLS / SSL certificates, whether they contain subject: stateORProvinceName and how they are filled.
I found 24 more certificates that have this item filled in with content other than "Slovakia".

  1. Six of them have the term "Slovensko ", which is a Slovak translation of the English "Slovakia."
    [https://crt.sh/?id=638515373]
    [https://crt.sh/?id=638515374]
    [https://crt.sh/?id=2697117708]
    [https://crt.sh/?id=3028271831]
    [https://crt.sh/?id=3254939480]
    [https://crt.sh/?id=2383029901]

  2. Six has the abbreviation "SK", which is according to ISO 3166-1 alpha-2 code for Slovakia.
    [https://crt.sh/?id=606389217]
    [https://crt.sh/?id=2070648382]
    [https://crt.sh/?id=3335964848]
    [https://crt.sh/?id=3001594862]
    [https://crt.sh/?id=3257828086]
    [https://crt.sh/?id=1770662207]

  3. One certificate has the official name in English in the form "Slovak Republic.
    [https://crt.sh/?id=2210014935]

  4. The two certificates have the same name as the L (locality) item name
    [https://crt.sh/?id=2385752502]
    [https://crt.sh/?id=3335964848]

  5. Three have the given name from ISO 3166-2 subdivison name (sk) in incomplete form "Banskobystricky" resp. "Bratislavsky".
    [https://crt.sh/?id=2440653538]
    [https://crt.sh/?id=633490685]
    [https://crt.sh/?id=998683558]

  6. Six has the given name from ISO 3166-2 subdivison name (sk) in the correct form.
    [https://crt.sh/?id=2303073896]
    [https://crt.sh/?id=2359882488]
    [https://crt.sh/?id=3324984962]
    [https://crt.sh/?id=3325011530]
    [https://crt.sh/?id=2672981426]
    [https://crt.sh/?id=3314898936]

Based on the previous discussion in this case, it was decided that all certificates listed in points 1) to 5) must be revoked no later than 5 days after their inclusion in this record on the grounds that they have an incorrect item name stateOrProvinceName.

At certificates listed in point 6), I am not sure whether this is an incorrect listing of the item stateOrProvinceName also with regard to the recommendation from [https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c11]. Here I would need a recommendation from QA Contact.

Expected other activities:
October 16, 2020: Contact all holders of the certificates in question and inform them of the need to revoke the issued certificates (at the latest until October 21, 2020) due to incorrectly filled in stateOrProvinceName.

October 16, 2020: Send an email to all customers whose certificates contain the wrong subject: stateOrProvinceName, and requesting that a new certificate request be delivered as soon as possible without subject: stateOrProvinceName.

Flags: needinfo?(bwilson)

UPDATED Timeline from comment #4

October 16, 2020 - October 20, 2020 During this time we re-issued all the certificates listed at point 1) to 5) [https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c22] except of [https://crt.sh/?id=633490685 ]. The new issued certificates no longer contain subject: stateOrProvinceName.

October 19, 2020 Revocation of [https://crt.sh/?id=3257828086] certificate based on domain owner request.

October 20, 2020 Certificate [https://crt.sh/?id=606389217] expired.

October 20, 2020 Preparation of process for revoking rest of certificates (16) listed at point 1) to 5) [https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c22]

October 21, 2020 Revocation of 16 certificates listed at point 1) to 5) [https://misissued.com/batch/184/] except [https://crt.sh/?id=3257828086] and [https://crt.sh/?id=606389217] started at 09:33 AM CET and ended at 09:34 AM CET.

October 21, 2020 17 certificates listed at point 1) to 5) [https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c22] are revoked. One certificate [https://crt.sh/?id=606389217] expired in meantime, so this one could not be revoked.

(In reply to Peter Miskovic from comment #22)

  1. Six has the given name from ISO 3166-2 subdivison name (sk) in the correct form.
    [https://crt.sh/?id=2303073896]
    [https://crt.sh/?id=2359882488]
    [https://crt.sh/?id=3324984962]
    [https://crt.sh/?id=3325011530]
    [https://crt.sh/?id=2672981426]
    [https://crt.sh/?id=3314898936]

Based on the previous discussion in this case, it was decided that all certificates listed in points 1) to 5) must be revoked no later than 5 days after their inclusion in this record on the grounds that they have an incorrect item name stateOrProvinceName.

At certificates listed in point 6), I am not sure whether this is an incorrect listing of the item stateOrProvinceName also with regard to the recommendation from [https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c11]. Here I would need a recommendation from QA Contact.

I looked up Kosicky kraj on sk.wikipedia.org and Google Translate provides the following: "The Košice Region is an organization of state administration in the south of Eastern Slovakia . It has an area of ​​6,753 km2 and has a population of over 800,000. It was established by the public administration reform in 1996 . Since 2007, it has been administered by the District Office based in Košice , which has replaced the former Regional Office ." I would see that subdivision as the equivalent of a province. Wikipedia also provides the following information for "kraj" - "A kraj is the highest-level administrative unit in the Czech Republic and the Slovak Republic. For lack of other English expressions, the Slavic term is often translated as "province", "region", or "territory", although it approximately means " country", or " countryside". "
Similarly, "Bratislavsky kraj" means "Bratislava Region" which is "one of the administrative regions of Slovakia. Its capital is Bratislava" according to Wikipedia. Similar results came back for "Nitriansky kraj".
So I think these fit into definition of stateorprovince and that certificates with these names would not have to be revoked.

Can this bug be closed now? Are there unresolved tasks that still need to be performed?

This bug seems to have stumbled onto the actual misissuance itself. I don't believe Peter has given us a proper remedation / explanation for the failure to provide a preliminary report other than him deciding to delay the reply.

Flags: needinfo?(peter.miskovic)

George,
as I explained in the https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c2
"...a message from George <george@fozzie.dev> we received on Saturday, October 10, 2020 at 00:18 a.m."

In Slovakia it was 18 minutes after midnight and I was out of my office and weekend was starting. I believe it was just a coincidence to send it at such date and time.

I discovered a new e-mail that day afternoon. In terms of content and sender anonymity, I decided not to react immediately during the weekend because I wasn't sure if there was a real violation of the Basic requirement and I evaluated it as a low security risk for the PKI ecosystem.

My mistake was that I did not realize at the time that, in accordance with CAB requirements, it was my duty to respond within 24 hours.

My remedy is that I'm now careful to monitor my emails every weekend morning, as soon as I get up to see if anyone else has been waiting for an early weekend morning to report a serious violation of basic CAB requirements so that I can respond in a timely manner.

There was nothing more than my personal decision, not very well chosen, as Director of Operations of CA Disig.

What else you are expect?
Peter

Flags: needinfo?(peter.miskovic)

I intend to close this bug as having adequately explained the delay in responding. I will close this on or about 23-November-2020.

I find comment 27 worrying, if it means compliance is reliant on a single person checking their email every single day, and never being unavailable or otherwise unable to do so.

(In reply to Julien Cristau [:jcristau] from comment #29)

I find comment 27 worrying, if it means compliance is reliant on a single person checking their email every single day, and never being unavailable or otherwise unable to do so.

Julian, your interpretation is misleading.

The comment https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c27 was only a response to <george@fozzie.dev> and was related to
the situation why we did not respond to his announcement Julian, your interpretation is misleading.

The comment [https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c27] was only a response to <george@fozzie.dev> and was related to
the situation why we did not respond to his announcement [https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c0] within
the 24-hour limit, especially if someone reports an incident late Friday night after business hours, or better on Saturday early morning
local time, so to we had as little time to react as possible and to have possibility to open incident concerning not react in timely manner.

In my reply, I wanted to emphasize that I now personally pay special attention to such warnings, which appear to be announced
over the weekend on Friday late at night or on Saturday or early Sunday morning, where our response may be slower,
given that that all participants are out of their workplace and there is risk we are not responding within the mandatory 24 hours,
whether is it just a statement that the content of the TLS / SSL certificate seems to someone anonymous to be in conflict with the requirements .

Normally, our e-mail address for reporting incidents tspnotify@disig.sk is monitored by four people, so not only me, but also three
other colleagues see a possible incident report and can respond adequately.

(In reply to Julien Cristau [:jcristau] from comment #29)

I find comment 27 worrying, if it means compliance is reliant on a single person checking their email every single day, and never being unavailable or otherwise unable to do so.

Julian, your interpretation is misleading.

The comment https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c27 was only a response to <george@fozzie.dev> and was related to
the situation why we did not respond to his announcement [https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c0] within
the 24-hour limit, especially if someone reports an incident late Friday night after business hours, or better on Saturday early morning
local time, so to we had as little time to react as possible and to have possibility to open incident concerning not react in timely manner.

In my reply, I wanted to emphasize that I now personally pay special attention to such warnings, which appear to be announced
over the weekend on Friday late at night or on Saturday or early Sunday morning, where our response may be slower,
given that that all participants are out of their workplace and there is risk we are not responding within the mandatory 24 hours,
whether is it just a statement that the content of the TLS / SSL certificate seems to someone anonymous to be in conflict with the requirements .

Normally, our e-mail address for reporting incidents tspnotify@disig.sk is monitored by four people, so not only me, but also three
other colleagues see a possible incident report and can respond adequately.

I don't quite understand what you are saying. If four people are monitoring the email then why did no one reply within 24 hours? Are you saying that only you can respond during the weekends? If so then I think that makes Julien's concerns valid.

(In reply to george from comment #32)

I don't quite understand what you are saying. If four people are monitoring the email then why did no one reply within 24 hours? Are you saying that only you can respond during the weekends? If so then I think that makes Julien's concerns valid.

No, I'm not saying I'm just a person who can answer over the weekend. I'm just saying that I focus more on the weekends than my colleagues because of someone who really likes to open new cases at that time.

The reason why we didn't respond within 24 hour on your [https://bugzilla.mozilla.org/show_bug.cgi?id=1670458#c0] I explained at minimum twice comment#2 and comment#27.

In comment 27 you explained why you didn't reply, which I understand. What I don't understand is why no one else replied when 3 other people are monitoring the email, did you tell them not to?

Yes, you are right, I told them I would answer on Monday.

I did not realize at that time that we had to respond to you with a preliminary report within 24 hours.
It was our first notification case on the tspnotify@disig.sk address.
That was my fault.

But on the other hand, if we answered in time, we would not answer anything other than "We will start an investigation after the weekend (Monday)", because at that time I was not sure, that it was a violation of the basic requirements of the CAB.

Well the requirement is to provide a preliminary report, not just to reply with "We will start an investigation". If Disig now received any reports during the weekend would they now be prepared to investigate and provide a preliminary report within 24 hours?

Yes, based on this discussion and experience

I believe this matter has been adequately discussed and addressed, and I intend to close it on or about Friday 22-Jan-2021.

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Flags: needinfo?(bwilson)
Resolution: --- → FIXED
Product: NSS → CA Program
Whiteboard: [ca-compliance] → [ca-compliance] [disclosure-failure]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: