Security considerations: Interactions with Certificate Transparency

[thomwiggers]

The implicit method of proof-of-possession, for encryption key- and KEM-based certificates, relies on the end-entity not obtaining the issued certificate if they do not posses the private key to decrypt the certificate.

This means that a certificate is created and, if CMP is used to issue WebPKI certificates, recorded to the certificate transparency logs: after all, we need to include the SCT statements in the certificate. Most submitters will likely submit precertificates instead of full certificates (which, in CT 1.0, include the poison precertificate extension, or in CT 2.0, use CMS syntax). But normal certificates can be submitted, and if they are submitted before the PoP is completed, the certificate can be obtained from the CT logs: see for example this cert (which does have the poison extension https://crt.sh/?id=8512435380)

[thomwiggers]

This comment is an extension of the discussion we had on the mailing list https://mailarchive.ietf.org/arch/msg/tls/McnWDK1UQ_hSNRwGg8mjHD0tWEY/

[HBrock]

You are right, using CT logs is a special case.

Currently Section 3.1.2 writes Note that policy may dictate that the CA must not publish or otherwise distribute the certificate until the requesting entity has reviewed and accepted the newly-created certificate (typically through use of the certConf message). I would propose extending the sentence to Note that policy may dictate that the CA must not publish or otherwise distribute the certificate until the requesting entity has reviewed and accepted the newly-created certificate or the indirect POP is completed (typically through use of the certConf message). In case of publication of the certificate or a precertificate in a Certificate Transparency log [RFC9162], the certificate must be revoked if it was not accepted or the indirect POP could not be completed.

Also Section 4.2.2.2 states (Where verification of the cert confirmation message fails, the RA/CA MUST revoke the newly issued certificate if it has been published or otherwise made available.)

But I would also add a security consideration: 8.9 Usage of Certificate Transparency Logs If a certificate or its precertificate was published in a Certificate Transparency log [RFC9162] it must be revoked, if a required certConf message could not be verified, especially when the implicit POP was used.

[ounsworth]

I suggest we add an additional sentence to this security consideration:

CAs that support indirect PoP MUST NOT also publish final certificates to CT logs. The risk is that a malicious actor could fetch the final certificate from the CT log and use that to spoof a response to the implicit PoP challenge via a certConf response. This risk does not apply to CT precertificates, so those are ok to publish.

[HBrock]

Extended the security considerations as proposed by Mike