Certificate Transparency versions and status of CTv2

Issuance Policy
1

I have been learning certificate transparency recently, but I am not very clear about the differences and relationship between v1, v2 and Sunlight logs.

What I currently learnt is:

CTv1 is described in RFC6962 which is published in June 2013, the implementation is often referred to as 'Trillian' logs, perhaps it's because most log operators are using trillian to run the log?

CTv2 is described in RFC9162 which is published in December 2021, and it obsoletes CTv1 (RFC6962). AFAIK, CTv2 is not just a minor upgrade of CTv1, as its data structure has changed and the pre-certificate format has been changed to CMS signed data, both of which are really different from CTv1.

Sunlight log is introduced by Let's Encrypt in March this year, in partnership with Filippo Valsorda. What I learnt is that Sunlight logs have CTv1-compatible write path API endpoints, and only read path API endpoints differ from CTv1. The data structure it used can be seen as another representation of the same data that CTv1 uses, so it is possible to use some proxy servers to turn a Sunlight log into a fully CTv1-compatible log.

I'm not sure whether I understood these logs correctly, and please correct me if possible. :smiling_face_with_three_hearts:

What I felt confusing is, it seems to me that CTv2 (RFC9162) have not been adopted at all.

When I search for Certificate Transparency, most pages, including CAs (e.g. Digicert) and Certificate Consumers (e.g. Mozilla), are referencing RFC9162 as the standard that defined CT.

However, All CT logs I could find only has <Base URL>/ct/v1/get-sth endpoint, none of them has the <Base URL>/ct/v2/get-sth endpoint. (Indeed, I understand it is impossible for a log to be both CTv1 and CTv2)

Another clue is that, not a single CTv2 LogID (oid) has been assigned by IANA - LogIDs, so I think no one has actually operated a CTv2-compatiable log at all, and I'm not possible to find one.

So have a few questions about these CT logs:

  1. What is the current adoption status of RFC9162 CTv2 logs? Has anyone actually operated a CTv2 log?

  2. Both RFC6962 and RFC9162 are Experimental RFCs, so I think they are of the same level of formality. So why don't the industry upgrade to the newer standard? It is so weird that it is even difficult to find discussions about CTv2 online.

  3. Is it unreasonable for RFC9162 to obsolete RFC6962? CTv1 and CTv2 can be two different standards, and it can be extremely misleading for beginners to learn the widely adopted CTv1 internals.

  4. Why even newly developed CT logs like Sunlight is still based on CTv1? Is it just to ensure compatibility with existing CTv1 ecosystem CAs and auditors?

I have searched extensively but have been unable to find answers to these questions. I would greatly appreciate any insights or answers the community can provide. :kissing_heart:

2 Likes
2

you may want to ask on https://groups.google.com/a/chromium.org/g/ct-policy too

4 Likes
3

Updates of protocols, even if major/incompatible ones, always obsolete their older versions in RFC-speak. For example, TLS 1.3 (RFC8846) also obsoletes TLS 1.2 (RFC 5246), despite the newer version being incompatible with the older one. In practice, one typically supports both the older and the newer standards (up until the old one is no longer widely used). A newer version of CT is by definition "more up-to-date than the older document" and hence mandates the obsolete attribute. It doesn't say anything about what the industry uses (or should use) - that's what "RFC - Best Current Practice" do.

Note that the IANA registry is explicitly mentioned as being optional, so this is not a good indicator of CTv2 deployment.

AFAIK, there are currently two root programs that are actively involved in CT: Google and Apple. Both of them currently require their logs to support RFC6962 (Apple's Certificate Transparency log program - Apple Support, Certificate Transparency Log Policy | CertificateTransparency). Both apparently do not support CTv2 in their monitors, and only RFC6962 logs are accepted. I don't know if there are plans for them to move to CTv2. I also don't know of any practical CT implementation that speaks CTv2 (as you've already figured, the de-facto standard trillian speaks CTv1).

I'm guessing that the documentation folks who write these pages aren't that deep involved with the actual deployment and just choose the most recent RFC they could find. The RFC is technically better if you're just looking for CT information in general (it's more descriptive compared to its predecessor) as long as you're not looking for protocol internals.

I'm also not aware of any practical CT log that speaks v2.

4 Likes
4

I don’t believe there are any implementations of ct v2, and nobody runs any logs. Let’s Encrypt has no plans to run ctv2 logs. Sunlight is an evolution based on v1.

It does seem like ctv2 is DOA.

5 Likes
5

Oh, I understand what obsolete means here, thank you.

Yes, I also think that's the reason.

I have never heard of it either :rofl:

No wonder few relevant information about CTv2 can be found, and no one discusses it at all.

Thank you all for the reply :smiling_face_with_three_hearts: I have a better understanding of the status of CTv2 now.

4 Likes
6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.