(In reply to François CHASSERY from comment #3)
First, I apologize, but I am not certain, even after translation, to understand what this sentence means :
"As a consequence, the expectation is that a response positively affirming these - and any other pre-certificates that do not comply with policy - are revoked, since there 'may' exist (in an unverifiable, to Mozilla, way) an equivalent certificate for that pre-certificate."
Basically, by logging a certificate, a CA is promising that there is or will exist an equivalent certificate. Thus, it needs to be treated as if it was issued.
If you imagine the world before CT, there was no way to know what a CA had issued, unless you had the actual certificate. CT was meant to address this, by having CAs log their certificates. For technical reasons related to issuance, pre-certificates were introduced as a way to let a CA log the certificate before they gave it to the subscriber.
From external point of view, anyone looking at a CT log should and does expect that, for any precertificate, the CA has also issued an equivalent certificate. Thus, misissuing a precertificate is just as bad as misissuing a certificate.
There's no way for anyone not at Certinomis to "prove" that, for these certificates, you didn't actually issue the equivalent certificate. You might have actually issued them, and might just be misreading the logs. With CT, because the precertificate exists, you could use the actual certificate as well, if it did exist - and clients would treat it as logged - which is also why it's important to treat it as issued.
Third, as I wanted to explain in point 7, we have undertaken since beginning of this year a stengthening of our RA software, to provide systemic domain validation in addtion to human control.
the firts step of it is now ready : we have a function implementing method n°4 of §18.104.22.168 of CAB/F BR. We still need to test it and install it on the production platform, but the soft is ready.
The second step will be to add a second automatism (method n°6) for giving a choice of method to client. Presently it has been planned for end of september.
That's not clear what methods you presently use to validate domains. The reason I'm pushing on this point is that it's possible to implement 22.214.171.124.4 and 126.96.36.199.6 with the same flawed human practices, leading to this same issue. A more comprehensive explanation about what the current process is, and what the future process will be, helps make sure that end-to-end, the systemic risks of human factors in this critical function have been addressed. It's equally as important to understand the current practice, so that it's clear how the current practice complied with the Baseline Requirements, and where that compliance "wasn't enough" to prevent misissuance, so that we can work to address that going forward.
I realize in light of the mozilla dev-security-policy discussion right now, Certinomis has its hands full. However, having a holistic, detailed, technical explanation of both the present and the future flow is a way that Certinomis could demonstrate that the systemic patterns addressed in that thread have been or are being addressed, and future incidents are less likely.