MMD exceeded at Cloudflare Nimbus 2023

[Nikita Korzhitskii]

On June 15th, 2021 18:36 UTC we submitted a certificate (SHA-256 hash C563A774B06CBBB21FB7C0D045C1B7DFB40D1CFF0392CB6BCD19AD3FF19B41D4) to Cloudflare Nimbus 2023 and obtained the following Signed Certificate Timestamp:

• {"sct_version":0,"id":"ejKMVNi3LbYg6jjgUh7phBZwMhOFTTvSK8E6V6NS61I=","timestamp":1623782184953,"extensions":"","signature":"BAMARzBFAiEAitK56cw3jVTgORsaMSDWj/8nabnAfmdIH4jBgyVZC4gCIDnmIha1hn2ywlFGNzVKy4W5SEyszbor7JpGqb1uLU6g"}

Our monitor has detected that the certificate (entry ID in the log 16110) was incorporated ~63 hours later (June 18th, 2021 09:48 UTC), which looks like a violation of Maximum Merge Delay.

--

Nikita Korzhitskii

Security and Networks group

Division for Database and Information Techniques

Department of Computer and Information Science

Linköping University

[Nick Sullivan]

Hi Nikita,

As listed in the crt.sh result you linked to, the certificate entry associated with the SCT you were returned is in the log at entry 15010, not 16110.

Best,

Nick

[Andrew Ayer]

Hi Nikita,

I think there might be a misunderstanding about what the timestamp
in the entry returned by get-entries means. It's the time that the
certificate was submitted (the same as the SCT timestamp), rather than
the time that the certificate was incorporated. Since the timestamp in
entry 16110 is June 18, 2021 09:48 UTC, it's for an SCT that was issued
at that time, not the SCT that you received. As Nick pointed out, your
SCT's entry is at index 15010.

Regards,
Andrew

On Mon, 19 Jul 2021 11:04:51 -0700 (PDT)
Nikita Korzhitskii <petergr...@gmail.com> wrote:

> On June 15th, 2021 18:36 UTC we submitted a certificate (SHA-256 hash
> C563A774B06CBBB21FB7C0D045C1B7DFB40D1CFF0392CB6BCD19AD3FF19B41D4

> <https://crt.sh/?q=C563A774B06CBBB21FB7C0D045C1B7DFB40D1CFF0392CB6BCD19AD3FF19B41D4>)

> to Cloudflare Nimbus 2023 and obtained the following Signed
> Certificate Timestamp:
>

> -

> {"sct_version":
> 0,"id":"ejKMVNi3LbYg6jjgUh7phBZwMhOFTTvSK8E6V6NS61I=","timestamp":
> 1623782184953,"extensions":"","signature":"BAMARzBFAiEAitK56cw3jVTgORsaMSDWj/8nabnAfmdIH4jBgyVZC4gCIDnmIha1hn2ywlFGNzVKy4W5SEyszbor7JpGqb1uLU6g"}
>
> Our monitor has detected that the certificate (entry ID in the log
> 16110

> <https://ct.cloudflare.com/logs/nimbus2023/ct/v1/get-entries?start=16110&end=16110>)

[Nikita Korzhitskii]

Hi Nick, Andrew, 

You are right, but the same certificate chain is present in both entries (15010 and 16110) and looks like we've calculated the submission-to-publication delay between the SCT above and the one submitted later on.

The RFC says:  "If the log has previously seen the certificate, it MAY return the same SCT as it returned before". 

Does it mean that logs could include the same certificate chain any number of times?

Best regards,

Nikita

понедельник, 19 июля 2021 г. в 21:16:51 UTC+2, Andrew Ayer:

[Devon O'Brien]

Hi Nikita,

A CT Log is free to include a given certificate + chain multiple times, with only minor caveats. The text you link from Section 3 of RFC 6962 permits two different behaviors in the face of a re-submitted logging request: The CT Log may decide to check whether an entry already exists for that certificate and return the previous SCT OR the CT Log can decide to create a new SCT for the new logging request. Importantly, if a new SCT is created, then the corresponding new entry must be incorporated into the CT Log within the MMD, measured from the new SCT's timestamp.

In case it's helpful, here's the section from the Chrome CT Log Policy that covers this behavior:

• "When Logs receive a logging submission for an already-incorporated certificate, Logs must either return an existing SCT or, if creating a new one, add another certificate entry within the MMD such that the new SCT can be verified using the APIs specified in RFC 6962."

-Devon

[Nikita Korzhitskii]

Hi Devon,

Thanks. We'll fix the monitor to account for that.

понедельник, 19 июля 2021 г. в 23:21:54 UTC+2, Devon O'Brien: