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:
- 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.
- 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.
- 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.
- 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.7126.96.36.199.2.1.11 within that CP/CPS, but the certificate asserts
2.16.7188.8.131.52.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
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.