Certificate transparency: should the certificate be submitted to ct-logs if the pre-certificate is already submitted

Question

If a pre-certificate is generated and submitted to certificate transparency logs, the final certificate can include SCT receipts.

So the final certificate doesn't need to be submitted to ct-logs in order to be valid in browsers were ct is mandatory.

Advantages:

• it give public confirmation that the certificate was indeed issued (and not only the pre-certificate)

Drawbacks:

• it double the size of the ct-log

My question is, is there any other advantage or drawback to submit the final certificate? Or any requirement to do so? Or advice against it?

Link: https://community.letsencrypt.org/t/sct-feature-support/58101/8

Answer 1

it gives public confirmation that the certificate was indeed issued (and not only the pre-certificate)

To quote RFC6962bis (draft-ietf-trans-rfc6962-bis-28), section 3.2:

"signature" MUST be from the same (root or intermediate) CA that will ultimately issue the certificate. This signature indicates the CA's intent to issue the certificate. This intent is considered binding (i.e., misissuance of the precertificate is considered equivalent to misissuance of the corresponding certificate).

Essentially, what that means is that if a precertificate in a CT log is present, then in any sense related to certificate transparency the final certificate was, indeed, issued.

Further operational details (e.g. was the certificate issued then, was the issued certificate then sent to the customer or not, has the customer received the certificate, have they deployed it, etc.) fall out of scope of the certificate transparency framework.

(It is also understood, I believe, that in case the certificate has been actually issued, and not only issued but has been actually obtained by the customer of the certificate authority, then the customer — usually referred to as a "server operator" in CT-related documents — may submit the final certificate theirselves if they have such a policy.)

Hence, there are no advantages left. Yet, the drawback you've mentioned still persists. So, the final score is 0:1 against submitting final certificates.

Answer 2

After more thoughts, my conclusion is:

Drawbacks:

• it double the size of the ct-log

Advantages:

• it give public confirmation that the certificate was indeed issued (and not only the pre-certificate)
• it prevent mass-submission to ct-logs, which could cause merge delay (a reason for log disqualification) Certificate Transparency Log Policy
• it allows to catch issuance bugs (such as bad SCTs encoding) Mission Accomplished? HTTPS Security after DigiNotar
• it may help to ask for revocation (if you get an alert because a ct-log have a pre-cert you didn't requests, to revoke the real certificate it's easier to have it) How to revoke a cert I did not issue

As the only drawback is for the log operator, and is largely compensated by the protection against mass-submission, it seams that the logging of both certificate should be a best-practice.

Let's Encrypt discussion: Non-logging of final certificates