Subject: [Trans] CT for purposes other than TLS server certificates

From: Sherif Hanna <[email-masked]>
Date: Wed, 18 Sep 2019 09:35:08 -0700

Hello,

Is the CT approach intended to be used beyond monitoring/auditing X.509 
certificates for servers? For example, for X.509 certificates used for code 
signing?

Regards,
Sherif

---

From: "Devon O'Brien" <[email-masked]>
Date: Wed, 18 Sep 2019 10:33:01 -0700

While the mechanisms behind Certificate Transparency are technically
capable of being used for X.509 certificates other than TLS server
certificates, the current ecosystem is focused exclusively on TLS server
certificates. This intent is captured in the abstracts of both RFC 6962 and
-bis as well as policies defined by existing CT-enforcing user agents [1]
[2].

Should a compelling need for non-TLS certificate transparency arise,
current CT-enforcing user agents are very likely to insist that the set of
CT Logs used for this new purpose are separate from the existing TLS CT Log
ecosystem.

There are several benefits of this:
1. Many other certificate types contain PII or other information that
various laws require a service to be able to take down upon request, which
conflicts with the append-only nature of CT.
2. Segmenting CT Log ecosystems by purpose insulates these CT Logs from
possible mis-management of CAs in PKI ecosystems that are less scrutinized
and maintained than the web PKI. While some progress is being made in
reigning in S/MIME and code signing certificate issuance practices, there
is a long way to go.
3. This segmentation also allows purpose-specific Monitoring/Auditing of CT
Logs (e.g. a Monitor like CertSpotter or FaceBook not having to sift
through the world's S/MIME or code signing certificates to notify you of a
mis-issued TLS certificate). CT Monitoring is already a non-trivial task
for the size of CT Logs that are intended to log only TLS certificates.

-Devon

[1] https://goo.gl/chrome/ct-policy
[2] https://support.apple.com/en-us/HT205280

On Wed, Sep 18, 2019 at 9:35 AM Sherif Hanna <[email-masked]> wrote:

> _______________________________________________
> Trans mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/trans
>

---

From: Taavi Eomäe <[email-masked]>
Date: Wed, 18 Sep 2019 21:39:58 +0300

Just wanted to add one thing about this benefit: I am pretty sure even
current CT logs allow appending certificates that contain PII and conflict
with the append-only nature of CT.

---

From: "Devon O'Brien" <[email-masked]>
Date: Wed, 18 Sep 2019 12:32:03 -0700

That is correct. While this is slightly drifting out of the scope of TRANS
and the RFCs and into user agent policy, there is not currently a
technical limitation on which types of leaf certificates are logged to
existing CT Logs, except that they must chain to the set of roots specified
by the Log. Chrome, for example, also allows a Log to reject a certificate
logging request if the certificate is expired, revoked, or expires outside
of a certain time period if such a period is specified by that Log.

Speaking for one user agent only, I can say Chrome is considering requiring
Logs verify that a certificate is a TLS certificate (expressed via EKUs) in
order to be logged; however, there are myriad ways in which PII or
sensitive information can be added to even TLS certificates. User agent CT
policy is evolving over time, and if embedding such information becomes a
serious issue, it will be addressed via updates to that policy.

-Devon