Freezing log lists and adding mimic logs Requirements

[方一格（Ethan）]

Hi Chrome Security and Certificate Transparency Team,

I am writing on behalf of our technical teams regarding the upcoming deprecation and temporary breakage (brownout) tests for third-party libraries using Chrome’s CT Log Lists (as outlined in 3p_libraries.md).

First of all, we completely understand and respect Google’s rationale for enforcing this migration. Relying on Chrome’s ephemeral log_list.json without explicit authorization introduces fragile dependencies, and we are already actively working on removing the hardcoded third-party CT verification libraries from our legacy client applications.

However, we are facing a severe operational challenge. we already have the solution for CT verification but it takes time to complete, thus we still using the original CT verification by two SCTS.

If a full brownout occurs, it will lead to immediate, cascading connection failures for millions of legacy clients trying to access our core services. To minimize catastrophic user impact while we aggressively push the migration, Therefore, we would like to request that Google exclude our specific setup from the brownout tests. Specifically, please do not simulate outages for the following three SCT verification endpoints during the upcoming random test phases:

SCT #1 - DigiCert Log 1 

• Log ID (HEX): C2317E574519A345EE7F38DEB29041EBC7C2215A22BF7FD5B5AD769AD90E52CD

• Signature Algorithm: ecdsa-with-SHA256

• Timestamp: May 11 07:14:04.642 2026 GMT

SCT #2 - Google Transparency Log

• Log ID (HEX): D76D7D10D1A7F577C2C7E95FD700BFF982C9335A65E1D0B30173177C0C8C56977

• Signature Algorithm: ecdsa-with-SHA256

• Timestamp: May 11 07:14:04.795 2026 GMT

SCT #3 - Venafi Log

• Log ID (HEX): 944E4387FAECC1EF81F31924226A186501C7D35F380203F72677D55372E19D8

• Signature Algorithm: ecdsa-with-SHA256

• Timestamp: May 11 07:14:04.657 2026 GMT

Why we are requesting this selective exclusion:

1. Critical Business Impact: These two specific SCT verification endpoints directly handle the traffic for our most critical legacy user flows. Simulating outages on them will cause immediate, widespread connection failures for millions of active users.

2. Migration in Progress: We have already deployed an emergency app update that moves away from the legacy third-party library to native platform enforcement. We strictly need a brief buffer for the user-adoption and update curve.

If temporary selective allowlisting is technically feasible for these two endpoints during the initial test phase, it would prevent massive user disruption.

Please advise if this is possible, or if there is an alternative mitigation we can explore.

Thank you,

Best,

Ethan.

[Joe DeBlasio]

Thanks for reaching out. We cannot accommodate individual requests for delay, particularly since we have no ability to assess user impact beyond your personal assurances. However, since the logs you mention aren't valid, it is unclear what you're requesting:

• The log ID you provided for "SCT #1" is not from "DigiCert Log 1", but rather from DigiCert's Wyvern2026h2. Perhaps you meant the latter.
• The log ID you provided for "SCT #2" is not a valid hex string (it's an odd number of characters), nor does "Google Transparency Log" does not correspond to a valid log.
• The log ID you provided for "SCT #3" is similarly not a valid hex string, and Venafi operates no CT logs present in the CT log lists.

Best,

Joe

--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/6b4c2b46-c3a9-4482-bbc4-f7f97390bf3en%40chromium.org.

[Rob Stradling]

> > we already have the solution for CT verification but it takes time to complete

Hi Ethan.  I presume that means you're either (1) working to obtain a TLS certificate that contains "mimic" SCTs or (2) working towards getting your TLS server to send "mimic" SCTs via the RFC6962 signed_certificate_timestamp TLS extension ?

BTW, as promised here, Sectigo has been working towards providing a solution for embedding "mimic" SCTs in TLS certificates - this is one of the features in ctsubmit.  However, it's not yet clear if ctsubmit will be both production-ready and deployed by any CA prior to 2026-07-01 (when the brownouts begin).

> However, since the logs you mention aren't valid, it is unclear what you're requesting

Hi Joe.  SCT timestamps are accurate to the millisecond, and with a bit of detective work...

crt.sh knows of only 1 certificate that has corresponding log entries for all 3 of those timestamps:

certwatch@certwatch=> SELECT ctl.URL, ctle.CERTIFICATE_ID, ctle.ENTRY_TIMESTAMP

[more] - >   FROM ct_log_entry ctle

[more] - >          JOIN ct_log ctl ON (ctle.CT_LOG_ID = ctl.ID)

[more] - >   WHERE ctle.ENTRY_TIMESTAMP IN (

[more] ( >       'May 11 07:14:04.657 2026 GMT'::timestamp,

[more] ( >       'May 11 07:14:04.795 2026 GMT'::timestamp,

[more] ( >       'May 11 07:14:04.642 2026 GMT'::timestamp

[more] ( >     )

[more] - >   ORDER BY ctle.CERTIFICATE_ID;

┌────────────────────────────────────────────────┬────────────────┬─────────────────────────┐

│                      url                       │ certificate_id │     entry_timestamp     │

├────────────────────────────────────────────────┼────────────────┼─────────────────────────┤

│ https://ct.googleapis.com/logs/eu1/xenon2026h2 │    26248109612 │ 2026-05-11 07:14:04.642 │

│ https://wyvern.ct.digicert.com/2026h2          │    26248110103 │ 2026-05-11 07:14:04.642 │

│ https://sphinx.ct.digicert.com/2026h2          │    26248110103 │ 2026-05-11 07:14:04.657 │

│ https://ct.googleapis.com/logs/us1/argon2026h2 │    26248110103 │ 2026-05-11 07:14:04.795 │

│ https://sphinx.ct.digicert.com/2026h2          │    26248110547 │ 2026-05-11 07:14:04.642 │

│ https://ct.googleapis.com/logs/eu1/xenon2026h2 │    26248116942 │ 2026-05-11 07:14:04.642 │

│ https://ct.googleapis.com/logs/eu1/xenon2026h2 │    26248117030 │ 2026-05-11 07:14:04.795 │

└────────────────────────────────────────────────┴────────────────┴─────────────────────────┘

https://crt.sh/?id=26248110103, aka

https://crt.sh/?sha256=01E2855D7BAA10CF2D5E7018E8AA66E6C086F75C16A6A96DD822E348FF77A332

(BTW, sorry for crt.sh's poor quality of service right now!)

---

From: Joe DeBlasio <jdeb...@chromium.org>
Sent: 03 June 2026 18:10
To: 方一格（Ethan） <hiddenin...@gmail.com>
Cc: Certificate Transparency Policy <ct-p...@chromium.org>
Subject: Re: [ct-policy] Freezing log lists and adding mimic logs Requirements

 

Thanks for reaching out. We cannot accommodate individual requests for delay, particularly since we have no ability to assess user impact beyond your personal assurances. However, since the logs you mention aren't valid, it is unclear what

ZjQcmQRYFpfptBannerStart

This Message Is From an External Sender

This message came from outside your organization.

Report Suspicious

 

ZjQcmQRYFpfptBannerEnd

To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAFZs0S4qb%3DXc%2BqsBATExTc3DXXar%3DT2e871O5ZBzTpSiC46oew%40mail.gmail.com.