#2 seems like an obvious "no" to me as, at that point, you're only compounding a mistake and making that mistake actually usable in the public PKI if you proceed to issue the certificate. In practice I can't imagine this scenario coming up much, but the policy shouldn't mandate doing this.
I think there's a third scenario to consider, and that is a case where the final certificate was issued but needed to be revoked prior to being put into service. This might be because of mis-issuance, but it might just as easily be for another reason. For example, after obtaining the certificate but before installing it, the requestor may discover that the private key had been exposed and thus want to get a new certificate with a different key. If we required the final certificate to be CT-logged In that scenario, a certificate that was previously only known to the CA and the requestor would now be publicly-discoverable, and now the mandatory logging policy has made it easier for that exposed private key to be exploited. So, while there are certainly advantages to indiscriminately logging all final certificates, there are downsides to weigh as well, at least for ones not (yet?) deployed on publicly-accessible web servers. On 4/5/18, 3:08 PM, "dev-security-policy on behalf of Alex Gaynor via dev-security-policy" <dev-security-policy-bounces+tshirley=trustwave....@lists.mozilla.org on behalf of [email protected]> wrote: There's two separable questions here: 1) Should CAs log final certificates after they issue a certificate with embedded SCTs: My answer, yes. 2) Should CAs issue final certificates if they discover they are misissued after logging the pre-certificate. The answers to (1) and (2) do not need to be the same. Alex On Thu, Apr 5, 2018 at 3:05 PM, Jakob Bohm via dev-security-policy < [email protected]> wrote: > On 04/04/2018 04:27, Matt Palmer wrote: > >> On Tue, Apr 03, 2018 at 01:49:58AM +0200, Jakob Bohm via >> dev-security-policy wrote: >> >>> On 02/04/2018 18:26, Tom Delmas wrote: >>> >>>> Following the discussion on >>>> https://scanmail.trustwave.com/?c=4062&d=l_TG2r42aQmbn72ySdqaNlBjW-xvJAqoIpJG1bH1_Q&s=5&u=https%3a%2f%2fcommunity%2eletsencrypt%2eorg%2ft%2fnon-logging-of-final-cer >>>> tificates/58394 >>>> >>>> What is the position of Mozilla about the submission to ct-logs of the >>>> final certificate when there is already a pre-certificate? >>>> >>>> As it helps discover bugs ( >>>> https://scanmail.trustwave.com/?c=4062&d=l_TG2r42aQmbn72ySdqaNlBjW-xvJAqoIsVD1OD1_w&s=5&u=https%3a%2f%2ftwitter%2ecom%2f%5fquirins%2fstatus%2f979788044994834434 ), it helps >>>> accountability of CAs and it's easily enforceable, I feel that it should >>>> be mandatory. >>>> >>> >>> If such a policy were to be enacted, an alternative to submitting the >>> final certificate should be to revoke the certificate in both a >>> published CRL and in OCSP. It would be counter to security to require >>> issuance in the few cases where misissuance is detected between CT >>> Pre-cert logging and actual issuance. >>> >> >> Logging the precert is considered demonstration of intent to issue, and is >> considered misissuance to the exact same degree as actually issuing the >> cert. So revoke or whatever, you still done goofed, and so you should be >> checking for misissuance *before* you log the precert, not afterwards. >> >> > Of cause, I am just saying we should not force CAs to make a misissuance > worse in the rare cases where they /actually/ spot the mistake between > precert signing and actual cert signing. > > Remember, a precert generates only the danger that the cert might be > issued with an embedded CT proof, all other dangers only materialize if > and when the cert is actually issued. > > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://scanmail.trustwave.com/?c=4062&d=l_TG2r42aQmbn72ySdqaNlBjW-xvJAqoIsMQ0OCqrA&s=5&u=https%3a%2f%2fwww%2ewisemo%2ecom > Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://scanmail.trustwave.com/?c=4062&d=l_TG2r42aQmbn72ySdqaNlBjW-xvJAqoIsAQ1rX1pw&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://scanmail.trustwave.com/?c=4062&d=l_TG2r42aQmbn72ySdqaNlBjW-xvJAqoIsAQ1rX1pw&s=5&u=https%3a%2f%2flists%2emozilla%2eorg%2flistinfo%2fdev-security-policy _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
