(In reply to Oscar Garcia from comment #1)
Email received from bugzilla, yesterday (Sunday 21th) at 22:00. We first received an email from George last Saturday 20 at 1:45, reporting a misissuance of two certificates. This email was sent to the contact of the CPS, but the contact email is really a list that is also used for some other subjects, that was incorrectly configured, and it didn't arrive to the correct people.
This is what Izenpe has disclosed in CCADB as the problem reporting address, as per https://ccadb-public.secure.force.com/mozilla/CAInformationReport
Could you highlight which CPS you believe is relevant? When I look at Website CPS, v1.6, which also discloses the same e-mail address, I can see a number of violations of the Baseline Requirements and Mozilla Root Policy requirements, and so I'm hoping I'm just looking at the wrong document. This was accessed from http://www.izenpe.com/s15-content/en/contenidos/informacion/doc_especifica/en_def/index.shtml .
In the event it's this document, from http://www.izenpe.com/s15-content/en/contenidos/informacion/descarga_certificados/es_url/index.shtml , then I see that same email address disclosed in Section 1.5.2, which is where Relying Parties should look, according to Section 4.9.3 of the Baseline Requirements.
So this doesn't feel like a very reassuring statement, and more root cause analysis is needed.
- 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 application we use now creates a new CSR from the information in the request form, filled by the applicant.
On the other side, we finished issuing certificates to entities outside Spain more than one year ago.
It seems like this should be included in the timeline, which per Responding to An Incident, 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.
- Explanation about how and why the mistakes were made or bugs introduced, and how they avoided detection until now.
In both cases the request form included "Île-de-France" as the region of Paris (L), and we reduced the stateOrProvinceName to "France" . At that time we didn't have an application to request SSL certificates, as we have now. This application creates a new CSR from the information in the request form, filled by the applicant.
I'm having trouble seeing how this relates to or answers the question. It seems there are important details missing to understanding how that was reduced to the stateOrProvinceName, what the validation policies were at the time, why that reduction happened, why multiple approvers allowed that reduction, why that's been mitigated since the issuance, and why Spain wouldn't be similarly affected by a reduction.
- 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.
For the problem of the contact email:
- We've already asked the creation of a new contact email account, just for security incidences. We'll update the CPS with this email contact. It'll be created by the end of this week. Meanwhile we've already fixed the list of contacts in that list. The CPS must be approved by the Security Committee, but we expect to have published the new version by next week.
This is seeking to fix an issue that Izenpe should have fixed some time ago. It doesn't, however, address why it wasn't fixed, or how similar issues like this are being prevented in the future.
The opportunity of incident reports isn't just to correct mistakes, but to learn from them, in order to prevent them. It's not clear that there's been a thoughtful examination about how this happened, why it was overlooked (especially given the broad attention to this matter has received from other CAs), and what controls exist going forward to prevent future mistakes.
For the problem with the certificates:
- We've done today (June 22th) a training to all operators doing the validations
- We've developed a script that sends an email to validation operators for each certificate issued. The operator will manually review that the issued certificate is the same he validated
This doesn't meet the standard of these incident reports. Saying "We've done more training" provides no new information to the community, nor helps any CA learn from this. What was the old training? What was the new training? Why would the new training address this issue? What steps are there to make sure the training is correct and sufficient? What steps are there to prevent future training failures?
The goal would be to allow any other CA within the Mozilla Program to independently evaluate this report and adopt similar solutions. A solution of "Don't make the same mistake" doesn't really mitigate the systemic issues at play here, and that's the goal.