1551364 - SwissSign: "Some-State" in stateOrProvinceName

Status: RESOLVED FIXED

(CA Program :: CA Certificate Compliance, task)

Description

[Wayne Thayer]

One SwissSign certificate containing a stateOrProvinceName of "Some-State" was published at https://misissued.com/batch/53/ This is apparently the default placed in OpenSSL CSRs, indicating that this field was not validated. BR section 7.1.4.2.2(f) states: If present, the subject:stateOrProvinceName field MUST contain the Subject’s state or province information as verified under Section 3.2.2.1. The EVGLs reference the BRs.

Please provide an incident report, as described at https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_Report

Comment 1

[Timo Schmitt]

Issue description:
Misissuing of one leaf certificate because of incorrect stateOrProvinceName.
For the leaf CA listed below the stateOrProvinceName = Some-State is wrong

This is an incident report for the issue above according to https://wiki.mozilla.org/CA/Responding_To_An_Incident#Incident_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.

On Monday May 13, 2019 we became aware as of the posting in mozilla.dev.security.policy (https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/NIuszkzNK7A)

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.

Timeline of incident handling
a. May 13, 2019 (11:00 AM): SwissSign InfSec & Compliance read the post https://groups.google.com/forum/#!topic/mozilla.dev.security.policy/NIuszkzNK7A

b. May 13, 2019 (11:30 AM) SwissSign InfSec started the internal incident management process. Next to other tasks this included
i. Confirming the issue
ii. Checking for additional affected certificates: no certificates with the same issue are detected
iii. Informing responsible management
iv. Informing our Auditors TÜV Trust IT (TÜV Austria)

c. May 13, 2019 (2:55 PM) Start investigation of the certificate problem report including revocation related notice to the subscriber

d. May 14, 2019 (03:00 AM) Incident Bug opened on Bugzilla by Mozilla (https://bugzilla.mozilla.org/show_bug.cgi?id=1551364)

e. May 14, 2019 (09:45 AM) Certificate revocation

f. May 14, 2019 (03:20 PM) Incident Report published by SwissSign https://bugzilla.mozilla.org/show_bug.cgi?id=1551364 and mozilla.dev.security.policy

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.

This erroneous certificate was issued on Feb 26, 2018.
No other certificate has been found with the same error.
The certificate https://crt.sh/?id=341594837&opt=cablint has been revoked within 24hours after recognition by the CA.

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.

Only 1 certificate is affected. The certificate was issued on Feb 26, 2018.

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.

Under the SwissSign Server Gold CA 2014 - G22 Issuing CA the following leaf certificate https://crt.sh/?id=341594837&opt=cablint

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

• The CSR provided by the client was created using OpenSSL with the default value for stateOrProvinceName ‘some-state’. During the check by our Registration Authority Office this was not detected which led to the linked leaf certificate
• The client sent us the CSR file including the wrong value.
Based on the data gathered we concluded that the mistake was based on a human error.

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.

a. This is a one-time human error from beginning of 2018. The RAO-checklists were already improved mid of 2018 which includes this checkpoint.
b. Additionally we will conduct an extra training session to ensure further awareness.

This bug is also linked at mozilla.dev.security.policy.

Thank you

Timo Schmitt
ICT Compliance Manager
SwissSign AG

Comment 2

[Ryan Sleevi]

Thanks for providing this.

Several follow-up questions:

1. Can you please provide specific and descriptive details about the (overall) set of changes in the RAO checklists?
   • What were there before mid-2018?
   • What are they after mid-2018?
   • What about these changes would address this?
2. What will your additional training session cover, and how will that be sufficient?
   • Will it focus on only this issue?
   • Will it focus on other issues?
   • How will it be developed and reviewed?
3. What technical controls exist or may exist in the future?
   • For example, it would seem like stateOrLocality is something that can be preprogrammed to only accept a certain set of acceptable values. I'm given to understand Switzerland has 26 cantons, which would seem reasonable?
   • Similarly, SwissSign could examine the countries it issues for / does business in, and similarly configure appropriate lists, for which the compliance team shall oversee and maintain according to any changes.
   • Exceptions might require an executive override, ensuring multi-party review.
4. What caused the human error, and how might that be systemically addressed?
   • For example, does the RA interface visually distinguish information provided by the customer (e.g. via CSR) from information provided by the RA? One can imagine that the workflow the validation agent engaged in contributed to the issue.
   • Alternatively, avoiding the inclusion of such information might also reduce the risk of future human error, by focusing on automation.

In trying to make these suggestions, I went to examine the CP/CPS. The certificate profile lists http://repository.swisssign.com/SwissSign-Gold-CP-CPS.pdf as the URL, which is version 2.7.0, published 2018-12-17. However, the applicable OID is 2.16.756.1.89.1.2.1.11 within that CP/CPS, but the certificate asserts 2.16.756.1.89.1.2.1.6. Looking through the version control history, I do not see references to the previous OID.

When I perform a Google search for that OID, I find references to https://repository.swisssign.com/SwissSign-Gold-CP-CPS-R7.pdf , which asserts that OID, at version 2.4.2. However, that version was issued 2015-04-30, while the certificate was issued 2018-02-26. This causes me some confusion, because using the CP/CPS URL referenced within the certificate, I see there were multiple CP/CPS updates (on 2017-09-13 to 2.4.3 and 2017-10-12 to 2.4.4). Using the URL scheme for R7, I can see https://repository.swisssign.com/SwissSign-Gold-CP-CPS-R8.pdf leads to version 2.4.4, asserting OID 2.16.756.1.89.1.2.1.8

I highlight all of this because it is unclear to me whether this OID represents a human error in the same category of this incident, whether it's a representation that it was issued according to 2.4.2 of the CP/CPS, rather than the then-current version 2.4.4, or whether it was a misconfiguration of the CA. My ability to make positive suggestions for other steps is limited, due to the uncertainty of the applicable CP/CPS.

That said, I truly appreciate that SwissSign is using the policy OID to bind the CP/CPS within the certificates, so I do hope this practice continues, as, when applied properly, it wholly removes ambiguities.

Comment 3

[Timo Schmitt]

Hi Ryan,

Please find below the feedback on your follow-up questions:

(In reply to Ryan Sleevi from comment #2)

Thanks for providing this.

Several follow-up questions:

1. Can you please provide specific and descriptive details about the (overall) set of changes in the RAO checklists?
   • What were there before mid-2018?
   • What are they after mid-2018?
   • What about these changes would address this?

The checkpoint “proof of organization” was improved in the new checklist after mid-2018. Especially the address check (including “stateOrProvinceName”) was pointed out in the list, which resulted in a clearer appearance and explanation what needs to be checked.
We believe that this change and the additional awareness training prevent a repeat of this single incident. After the change, there was not any mis-issuance in connection to this topic.

2. What will your additional training session cover, and how will that be sufficient?
   • Will it focus on only this issue?
   • Will it focus on other issues?
   • How will it be developed and reviewed?

We train our employees regarding every change in checklists or processes as well as a yearly repeat of the entire checklist. In this case, we decided to point out again the awareness and importance of exact checks for the field “stateOfProvinceName”.
Head RAO ensures the correct execution after those trainings.

3. What technical controls exist or may exist in the future?
   • For example, it would seem like stateOrLocality is something that can be preprogrammed to only accept a certain set of acceptable values. I'm given to understand Switzerland has 26 cantons, which would seem reasonable?
   • Similarly, SwissSign could examine the countries it issues for / does business in, and similarly configure appropriate lists, for which the compliance team shall oversee and maintain according to any changes.
   • Exceptions might require an executive override, ensuring multi-party review.

There is currently no technical control in place, as we cover those with manual controls.

4. What caused the human error, and how might that be systemically addressed?
   • For example, does the RA interface visually distinguish information provided by the customer (e.g. via CSR) from information provided by the RA? One can imagine that the workflow the validation agent engaged in contributed to the issue.

The person performed the control in 2018 was probably not aware enough of the correct value in this field. We have no indication that validation agent contributed to the mis-issuance, with the exception that he did oversee the default information provided in the customer’s CSR.

The separation of the checks within the checklist (followed by a training) lead the RAO clear and explicitly through the verification process of the content within the certificate request.

* Alternatively, avoiding the inclusion of such information might also reduce the risk of future human error, by focusing on automation.

In trying to make these suggestions, I went to examine the CP/CPS. The certificate profile lists http://repository.swisssign.com/SwissSign-Gold-CP-CPS.pdf as the URL, which is version 2.7.0, published 2018-12-17. However, the applicable OID is 2.16.756.1.89.1.2.1.11 within that CP/CPS, but the certificate asserts 2.16.756.1.89.1.2.1.6. Looking through the version control history, I do not see references to the previous OID.

The references to previous OID is found on page 4 in the current CP/CPS.

When I perform a Google search for that OID, I find references to https://repository.swisssign.com/SwissSign-Gold-CP-CPS-R7.pdf , which asserts that OID, at version 2.4.2. However, that version was issued 2015-04-30, while the certificate was issued 2018-02-26. This causes me some confusion, because using the CP/CPS URL referenced within the certificate, I see there were multiple CP/CPS updates (on 2017-09-13 to 2.4.3 and 2017-10-12 to 2.4.4). Using the URL scheme for R7, I can see https://repository.swisssign.com/SwissSign-Gold-CP-CPS-R8.pdf leads to version 2.4.4, asserting OID 2.16.756.1.89.1.2.1.8

I highlight all of this because it is unclear to me whether this OID represents a human error in the same category of this incident, whether it's a representation that it was issued according to 2.4.2 of the CP/CPS, rather than the then-current version 2.4.4, or whether it was a misconfiguration of the CA. My ability to make positive suggestions for other steps is limited, due to the uncertainty of the applicable CP/CPS.

Thank you for pointing this out. This is something we definitively need to have a closer look.
We will provide further details as soon as our analysis is finished.

That said, I truly appreciate that SwissSign is using the policy OID to bind the CP/CPS within the certificates, so I do hope this practice continues, as, when applied properly, it wholly removes ambiguities.

Comment 4

[Timo Schmitt]

The remediation has been completed. Please close this incident.

We created a new posting for the last item (new topic) identified by Ryan:
https://bugzilla.mozilla.org/show_bug.cgi?id=1558552

Comment 5

[Ryan Sleevi]

While noting other CAs have implemented technical controls to address this, it does appear consistent with the timeline that this issue has not re-appeared, and the non-technical controls appear to be functioning correctly. Technical controls, as implemented by other CAs, may provide added assurance and confidence, but I think that's for Wayne as to whether to require, in light of the information and remediation steps shared.

Comment 6

[Wayne Thayer]

(In reply to Ryan Sleevi from comment #5)

While noting other CAs have implemented technical controls to address this, it does appear consistent with the timeline that this issue has not re-appeared, and the non-technical controls appear to be functioning correctly. Technical controls, as implemented by other CAs, may provide added assurance and confidence, but I think that's for Wayne as to whether to require, in light of the information and remediation steps shared.

Technical controls on these fields certainly reduce the risk of future incidents and the resulting loss of confidence, but at this time Mozilla is not requiring them. I thank SwissSign for all of the information that has been provided, and I believe this issue has been adequately remediated.