Request For Comment: Removing support for detached SCTs

[haydentherapper]

Background

Certificate transparency background: RFC6962 supports the distribution of SCTs (log inclusion promises) in three ways: Embedded in a certificate, distributed alongside the certificate (detached), or as part of the TLS handshake.

There are almost no real-world webPKI examples of SCTs being distributed separately or in a TLS handshake from what I understand. Embedding has become the defacto approach. The only argument in support for detached SCTs could be to keep certificate size down while still recording a certificate in a log.

Originally, Fulcio only supported returning the SCT in a response header. Later, we added support for embedding the SCT in the certificate, solving the need to separately persist the promise. This has been running in production for a couple of years now.

Sigstore usage

I am aware of only one use case for Sigstore users to support detached SCTs, which is when using GCP CA Service to issue certificates. This is a limitation in the product: Since we cannot control serial numbers and issuance time, we cannot issue a precertificate and final certificate with the same values.

Clients

As more Sigstore clients are created, the focus is on the public instance, which only embeds SCTs. Furthermore, it would be unexpected for a private instance to configure Fulcio to not embed SCTs, as the default is to embed them, unless the private instance is using GCP CA Service.

Only Cosign and sigstore-java support detached SCTs currently, and in both cases, the detached SCTs are not persisted in either the OCI image annotations or Sigstore bundle (neither supports detached SCTs), meaning certificate inclusion is not verified by clients for the detached case.

Call to Action

This is a request for comment to remove support for detached SCTs from Fulcio. This will not break the API, only mark detached SCTs as deprecated. We will also remove the code to generate detached SCTs. GCP CA Service will no longer support generating SCTs until a product feature is added to control serial numbers and timestamps on issuance.

There should be no impact to clients, besides cleaning up unneeded code paths. There may be impact to private deployments.

Any concerns from clients? @loosebazooka @woodruffw @bdehamer @kommendorkapten @steiza

[bdehamer]

This seems like a nice simplification, and I'm definitely in favor of that. This should have no impact on sigstore-js as it has never had support for detached SCTs.

One thing to note . . . we're running a private Fulcio instance w/ NO transparency log. In this mode, I noticed that the response from the create-signing-certificate API always uses the signedCertificateDetachedSct field in the response (despite the fact that there is no SCT). As the code is cleaned-up we'll want to make sure not to change this behavior so we don't break existing clients (/cc @codysoyland).

[loosebazooka]

I already removed support for detached SCTs in Java (https://github.com/sigstore/sigstore-java/pull/478) cause the logic was so annoying to deal with.

[kommendorkapten]

Agree with this! This would also mean that we should deprecate this (unused flag): https://github.com/sigstore/protobuf-specs/blob/main/protos/sigstore_verification.proto#L65

[woodruffw]

Strong support on my end! sigstore-python removed detached SCT verification a while back.

Edit: Whoops, spoke too soon -- the detached SCT handling code is still present, but I believe hasn't been exercised in a long time.

[haydentherapper]

@bdehamer Thanks for the heads up. I would not make any breaking changes to the API, so we'll still write responses to the detached SCT one-of message. I'll only mark the SCT field as deprecated.