"at least one SCT from non-Retired log" requirement

[Aaron Gable]

Hi CT folks,

The recent email regarding Sectigo's Mammoth CT log moving to the Retired state reminded me of one of Chrome's CT requirements: that "at least one SCT must come from a non-Retired CT Log in order to successfully validate in Chrome".

Suppose that a CA gets SCTs essentially at random from 8 different CT logs, run by 8 different log operators. Then there are 28 (8 choose 2) different combinations of logs that any given cert's two SCTs could be from.

Suppose further that two of those logs transition into the Retired state, such as Mammoth recently has. This transition is completely outside the control of the CA, and can happen at any time due to hardware or software failures.

Then 1/28th, or 3.5%, of that CA's certificates will no longer be trusted in Chrome. For Let's Encrypt, for example, that would be over 8.5 Million certificates that have to be replaced at short notice. And often there is no way to notify the subscriber of the fact that they need to download (or even request, if their validation data has expired) a new certificate, as many clients do not provide a contact address.

Can someone speak to the purpose that this requirement serves, and what security properties/guarantees would be removed if it were no longer required?

Thanks!

Aaron

[Aaron Gable]

Thanks for the reply!

But one clarification -- I don't follow how that argument applies to certificates that were incorporated into non-Retired logs when they were issued, but then those logs became Retired after issuance. The user-agent knows when the SCTs were issued, and it knows when the log was Retired.

Is the argument that the log may have been Retired because we now believe it wasn't behaving faithfully before?

Thanks again,

Aaron

On Thu, Jan 19, 2023 at 10:52 AM Andrew Ayer <ag...@andrewayer.name> wrote:

Hi Aaron,

On Thu, 19 Jan 2023 10:34:23 -0800
"'Aaron Gable' via Certificate Transparency Policy"

The purpose of the requirement is to ensure that certificates are logged
in CT.  There is no guarantee that retired logs are operating
faithfully - their private keys could literally be on Pastebin.  So if
you remove the requirement that certificates contain SCTs from at least
one non-retired log, then there is effectively no longer a requirement
that certificates be logged in CT, since the SCTs could all be from
misbehaving logs that don't incorporate certificates.

You are correct that certificates could stop working in browsers if
all the SCTs go bad.  This is why Apple and Chrome policy mandate
redundancy by requiring at least 2-3 (depending on certificate lifetime)
SCTs from logs that were qualified at time of certificate issuance.
This is only a baseline, and CAs are free to go above the redundancy
requirement, or always include an SCT from a log that they operate, if
they aren't comfortable with the risks.

And as I'm sure you know, there are reasons besides SCT failure why
certificates may need to be replaced on short notice, and the best
answer is more automation and standards like ACME Renewal Info.

Regards,
Andrew

[Bas Westerbaan]

What about we split retired into retired and compromised and change the requirement to at least one SCT from an uncompromised log?

Best,

 Bas

--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CAEmnErcLES1CjdmtqD8xrouGERuwRw%3DCAkxi09UHUOt%2BE6aepw%40mail.gmail.com.

[Joe DeBlasio]

Hi Aaron!

That's right -- once a log transitions to the Retired state, Chrome makes no assumptions about the integrity of the log, including before the Retirement date. For instance, the exact time of a key exposure may not be known, so Retirement needs to be able to lag behind any incident.

We do try to mitigate the risk that certificates might end up untrusted in Chrome by a log Retirement. Before making any log state changes, we analyze certificates known to us to estimate breakage, and balance that breakage against other risks to the ecosystem.

In Mammoth's case, we do not expect any immediate breakage because of the Retirement, though certificates logged to Mammoth are at a greater risk of breakage from future log state changes. Our future breakage analyses partially mitigate that risk, but we do still think that when possible, CAs should consider proactive reissuance.

Shorter-lived certificates and automated re-issuance are also a substantial mitigation, since at-risk certificates quickly turn over on their own. CAs or other logging parties can further mitigate the risk by not logging to the minimum number of logs Chrome requires -- Chrome does not enforce an upper limit on the number of SCTs provided.

Best,

Joe

--

[Aaron Gable]

Thanks for the clarification! This stance makes sense, even though it can theoretically lead to unfortunate situations in an ACME world where all issuance is driven by the client, and (until ARI gets widespread adoption) there's no mechanism to notify subscribers that they may want to renew early.

Aaron

[Matt Palmer]

On Thu, Jan 19, 2023 at 11:49:19AM -0800, 'Aaron Gable' via Certificate Transparency Policy wrote:
> But one clarification -- I don't follow how that argument applies to

> certificates that *were incorporated into non-Retired logs when they were
> issued*, but then those logs became Retired after issuance. The user-agent

> knows when the SCTs were issued, and it knows when the log was Retired.

What information can the user agent rely on, as to when the SCTs were
issued, that does not come from the now-Retired log? Anything signed by the
Retired log's key cannot be relied upon, because as Andrew said "[the log's]
private keys could literally be on pastebin".

Of course, *any* log's key could be on pastebin; there are no requirements
for a particular key management regime for CT logs. However, for active
logs, misbehaviour can be detected through analysis of the Merkle tree.
This safeguard does not exist for Retired logs.

The only security property that exists is essentially one of association: an
SCT from a Retired log, in a certificate that also has an SCT from an active
(and hence auditable) log, is circumstantial evidence that the SCT from the
Retired log is *probably* OK. If you only have SCTs from two Retired logs,
you don't even have that proof-by-association.

> Is the argument that the log may have been Retired because we now
> believe it wasn't behaving faithfully before?

I can't speak to Andrew's argument, but my argument doesn't require
pre-retirement suspicion of malfeasance, merely no ability to trust a log's
operation post-retirement.

- Matt

[Matt Palmer]

On Thu, Jan 19, 2023 at 09:44:42PM +0100, 'Bas Westerbaan' via Certificate Transparency Policy wrote:
> What about we split *retired* into *retired* and *compromised* and change

> the requirement to at least one SCT from an uncompromised log?

Can you define the requirements for each of those statuses, and describe how
the on-going requirements for those logs would be different?

- Matt

[Andrew Ayer]

Hi Aaron,

On Thu, 19 Jan 2023 10:34:23 -0800

"'Aaron Gable' via Certificate Transparency Policy"

[Andrew Ayer]

On Thu, 19 Jan 2023 11:49:19 -0800

"'Aaron Gable' via Certificate Transparency Policy"
<ct-p...@chromium.org> wrote:

> But one clarification -- I don't follow how that argument applies to

> certificates that *were incorporated into non-Retired logs when they
> were issued*, but then those logs became Retired after issuance. The

> user-agent knows when the SCTs were issued, and it knows when the log
> was Retired.

How does the UA know when the SCTs were issued? If the log isn't
operating faithfully, then the SCT timestamp can't be trusted. And
the reason for CT is CAs can't be trusted, so the notBefore timestamp
isn't usable either.

A certificate that was faithfully incorporated before the logs were all
retired would be safe to accept, but there is no way for a UA to
distinguish between that and a non-incorporated certificate whose
timestamps have all been backdated to be prior to the retirement dates.
So the only safe option is to reject certificates without any SCTs from
non-retired logs.

Regards,
Andrew