Asseco DS / Certum: Failure to provide a preliminary report within 24 hours.
Categories
(CA Program :: CA Certificate Compliance, task)
Tracking
(Not tracked)
People
(Reporter: fozzie, Assigned: wtrapczynski)
References
Details
(Whiteboard: [ca-compliance] [disclosure-failure])
Attachments
(1 file)
64.45 KB,
text/plain
|
Details |
I sent a problem report to revoke@certum.pl and have yet to receive a response:
Saturday 26 September 17:44 UTC - I sent a report concerning the attached leaf fingerprints regarding the stateOrProvinceName field of "Russian Federation" being invalid.
Saturday 26 September 18:08 UTC - While re-reading the email I sent I realised I had sent the wrong link to the certificates, so I replied and uploaded them as an attachment instead.
It is currently 25 hours and 38 minutes since my last email to them and I have yet to receive a response.
Updated•4 years ago
|
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Thank you very much for this incident report. We are analyse it now and we will respond with an incident report.
Can you please provide more details why those certificates do not match requirements?
As I can see - those certficates do contain County is ISO format.
If present, the subject:stateOrProvinceNamefield MUST contain the Subject’s state or province information as verified under Section 3.2.2.1.
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:stateOrProvinceNamefield MAY contain the full name of the Subject’s country information as verified under Section 3.2.2.1.
Reporter | ||
Comment 3•4 years ago
|
||
That exception is for user-assigned country codes. Matthias has provided a great explanation of this in comment 1 of bug 1667430.
Well, it is very unclear in documentation. But if the documentation is not good enough to understand is it ok to force reissue of thousands of the certificates? Why don't fix the documentation and then restrict the issuance of the new certificates?
Comment 5•4 years ago
|
||
(In reply to kyprizel from comment #4)
Well, it is very unclear in documentation.
No. It isn't. This is as unambiguous as you can get: "If (condition), then (result)" is as basic as you can get within the statement of requirements, is heavily practiced throughout the requirements, and there's no factual basis for stating they are unclear.
CAs are trusted based upon their ability to understand and execute the requirements, which they themselves state in their CP/CPS. If CAs have trouble doing so, this undermines their trustworthiness of the entire CA.
But if the documentation is not good enough to understand is it ok to force reissue of thousands of the certificates? Why don't fix the documentation and then restrict the issuance of the new certificates?
Revocation is one of the methods that the CA can use to publicly demonstrate that any violations of the requirements were not intentional, and that the CA is taking corrective steps to ensure that every certificate trusted can be counted on to follow the requirements. If there are certificates out there which do not follow the requirements, this undermines the trustworthiness of the CA.
CAs are expected to design their systems precisely to ensure that they follow the requirements, as well as design and prepare for the possibility of mistakes. That's a risk management process the CA takes, and if the CA chooses poorly, that's ultimately the CA's problem. Relying parties rely on the CA's CP/CPS to mitigate their risk, and when the CA commits to doing something, and then fails to do so, the failure exposes relying parties to untold risks that are best mitigated by removing trust in the CA. Since that's not ideal, for anyone, revocation is one of the ways the CA can demonstrate they're capable of doing what they committed to anyone who uses their certificates to do.
What's the risk of having stateOrProvinceName field filled by country name specified as ISO code in the Country field?
What is the root cause of such a requirement? Talking about Russian Federation - Moscow is the city of Federal subordination.
Reporter | ||
Comment 7•4 years ago
|
||
If you have a locality in localityName and an organization in organizationName then you do not need to include a stateOrProvinceName. For example, DigiCert just includes "Moscow" in the localityName and does not have a stateOrProvinceName. The purpose of stateOrProvinceName is to be able to verify the company in a state or province, generally you can do this with a locality hence why stateOrProvinceName is not required if you have specified a localityName and an organizationName. However as you have included stateOrProvinceName it needs to be valid under the terms in the Baseline Requirements, as "Russian Federation" is not, these certificates are misissued.
Reporter | ||
Comment 8•4 years ago
|
||
Due to the scale of this issue, can you also check for other certificates issued with "Russian Federation" in the stateOrProvinceName? Will Certum also be revoking these certificates within the 5 day timeline outlined in the Baseline Requirements? If not then a separate bug should be opened here before the deadline is reached, following the recommended incident template.
FYI: I'm not from Certum, I'm one of customers working on revocation/reissue from client side.
Comment 10•4 years ago
|
||
Additional guidance can be found here - https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation
Reporter | ||
Comment 11•4 years ago
|
||
I think we should leave this bug for the failure to provide a preliminary report, keep bug 1667986 for the invalid stateOrProvinceName incident itself and open another one for the delayed revocation.
Comment 12•4 years ago
|
||
- How your CA first became aware of the problem
On Saturday, September 26th 2020, Certum received the report from third party about incorrect issues of certificates. - A timeline of the actions your CA took in response
26th of September, 7pm UTC +2: notification came in via the email address: revoke@certum.pl,
26th of September, 8pm UTC +2 : The employee operating the mailbox accepted the request,
26th of September, 9pm UTC +2: The employee analyzed the request and found that the request does not concern a security issue or compromise of the key. An employee requested for further analysis
27th of September, 8am UTC +2 : The second analyze was started. Due the misunderstanding, the response to the third party wasn’t send.
28th of September, we realized that we didn’t send a response to a third party, this bug was created. - 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.
Information about incorrect issue of certificates will be described in bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1667986 - Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
The person who received the request qualified the request as non-safety related and submitted it for a second analysis. Due to misunderstanding between the first and second person who analyzed the problem, the reply was not sent to the third party within the required time - List of steps your CA is taking to resolve the situation
- We updated our procedures, add information about that the person who did first analyze must send a response to requester
- We instructed the employees that a response to each requests should be provided in 24h.
Assignee | ||
Updated•4 years ago
|
Reporter | ||
Comment 13•4 years ago
|
||
I'm a bit confused about this response. If the first person sent it to a secondary person for review then why would the secondary person not provide the preliminary report? Surely if the first person didn't have a definitive answer (hence the review) they wouldn't have been able to provide a preliminary report anyway.
It seems like you've added procedures to reply to the email within 24 hours but the Baseline Requirements state that a preliminary report should be provided with the results of the investigation, not just a confirmation reply:
Within 24 hours after receiving a Certificate Problem Report, the CA SHALL investigate the facts and circumstances related to a Certificate Problem Report and provide a preliminary report on its findings to both the Subscriber and the entity who filed the Certificate Problem Report.
Can you provide more details regarding the change in procedures? What were the procedures before? What did you change specifically?
Assignee | ||
Updated•4 years ago
|
Comment 14•4 years ago
|
||
We are aware that within 24 hours we need to provide a preliminary report, not just a response about acceptance of the request and our procedure includes that.
The procedure included that the preliminary report from the notification must be send to the third party and the client in 24 hours from report, but it was not clearly stated who is responsible for doing it, only that it should be done by person handling the notification.
The First Line found that by forwarding the notification to the Second Line, it made the Second Line is responsible for handling notification and response to the third party. The First Line expected that the Second Line will take over all further actions.
The second line was focused on analyzing the problem, confirming it and estimating the scale, and additionally coordinating contact with the client. The Second Line had all data necessary to provide the third party with a preliminary report, but assumed that the First Line was responsible for response the third party. The Second Line expected that after confirming the problem and communicating it to the First Line, the requester would be provided with the results of the preliminary analysis(preliminary report).
We introduced to the procedure the First and Second Line nomenclature, because previously the procedure was imprecise.
Comment 15•4 years ago
|
||
If there are no more questions, please close this bug
Comment 16•4 years ago
|
||
I will close this bug on or about 18-Nov-2020 unless there are more questions or issues raised.
Updated•4 years ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Description
•