Asseco DS / Certum: CPS does not refer to BR domain validation methods
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: fozzie, Assigned: aleksandra.kurosz)
Details
(Whiteboard: [ca-compliance] [policy-failure])
Certum's 7.0 CPS (dated 31/05/2021) does not refer to the subsections of 3.2.2.4 in the BRs. This is contrary to MRSP 2.2.3:
The CA's CP/CPS must clearly specify the procedure(s) that the CA employs, and each documented procedure should state which subsection of 3.2.2.4 it is complying with.
It is unclear if "Agreed-Upon Change to Website" under section 3.2.2.1 relates to the forbidden 3.2.2.4.6 method or the new 3.2.2.4.18 method.
Updated•3 years ago
|
Assignee | ||
Comment 1•3 years ago
|
||
Thank you for reporting that, we will analyze that point in our CPS again and will back with the answer. Of course this point is related to new 3.2.2.4.18 method.
Comment 2•3 years ago
|
||
Setting N-I for the incident report that Comment #1 commits to provide.
Assignee | ||
Comment 3•3 years ago
|
||
- How your CA first became aware of the problem.
We were notified on June 17, 2021 that this bug has been opened in Bugzilla. - A timeline of the actions your CA took in response.
Time in UTC.
2021-05-31 CPS version 7.0 are published
2021-06-17 This bug is created
2021-06-18 We analyzed the part of the CPS in question and found that section 3.2.2.1, and found that the provisions in this section are not sufficient - Confirmation that your CA has stopped issuing TLS/SSL certificates with the problem.
Not applicable - 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.
Not applicable - 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.
Not applicable - Explanation about how and why the mistakes were made, or bugs introduced, and how they avoided detection until now.
As it turns out, we identified the provisions of our CPS as sufficient in the light of the regulations. We identified individual methods by method name, not by numbers of chapters describing these methods. Already in versions 6.8 and 6.9 we introduced changes in chapter 3.2.2.1, describing the ways in which Certum verifies domains. But we have not added information with which BR Sections the verification methods used comply with. - List of steps your CA is taking to resolve the situation.
The section will be updated with references to the relevant subchapters of BR. The CPS update will be performed and published 2021-06-30.
Reporter | ||
Comment 4•3 years ago
|
||
Stating the subsection name may meet the requirements of MRSP
each documented procedure should state which subsection of 3.2.2.4 it is complying with.
Although Ben may want to comment whether it does.
However, the issue here is that the subsection name of "Agreed-Upon Change to Website" matches subsection 3.2.2.4.6 of the BRs and not "Agreed‑Upon Change to Website v2" for 3.2.2.4.18. How would a third party know what domain validation method Certum was using?
Has Certum reviewed other parts of its CPS which may have the same issue of being ambiguous?
Assignee | ||
Comment 5•3 years ago
|
||
We did not think that the name Agreed Website Change could be confusing. Especially since subsection 3.2.2.4.6 has not been used for a long time. We regularly check our CPS and bring it up to date with current standards, but we didn't think this was a problem.
For clarity, we have updated our CPS by adding links to BR points.
https://files.certum.eu/documents/repsitory/3-cert-pract-state/CCP-DK02-ZK02-CPS-Cert-7.1.pdf
Assignee | ||
Comment 6•3 years ago
|
||
No updates. Are there any other questions or comments on this bug?
Updated•3 years ago
|
Assignee | ||
Comment 7•3 years ago
|
||
No updates here.
Assignee | ||
Comment 8•3 years ago
|
||
No updates. If there are no additional questions, can this bug be closed?
Comment 9•3 years ago
|
||
I'll anticipate closing this on Friday, 30-July-2021, unless I hear otherwise.
Updated•3 years ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Description
•