Subject: [TLS] ct_compliant cached info field

From: Eric Rescorla <[email-masked]>
Date: Thu, 27 Dec 2018 09:58:08 -0800

Hi folks

Please take a look at
https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5
which defines a new "ct_compliant" cached info extension. This sort of
overloads the cached info mechanism (one might say "abuses"), so needs
review by the TLS WG.

-Ekr

---

From: Martin Thomson <[email-masked]>
Date: Mon, 31 Dec 2018 17:06:17 +1100

> https://tools.ietf.org/html/draft-ietf-trans-rfc6962-bis-30#section-6.5

At a minimum, this would seem to update cached_info.

There's not a lot of meat on this text.  It seems to be saying that if you are providing transparency_info, then you can provide a certificate other than any of the certificates that the client believes to be CT compliant.  Also, you don't provide "x509_sct_v2" or "precert_sct_v2" in transparency_info.

How is the client then able to determine that this new certificate is CT compliant?  Using  "inclusion_proof_v2" and "signed_tree_head_v2" (or one or other)?  If so, the text doesn't point in that direction.

There's a lot of "why" missing in this document.  Why would a client choose to indicate "ct_compliant"?  Why is cached_info being extended in this way?

I might guess that the reason here is that the draft aims to avoid including information that might change over time, which would render caches invalid.  Isn't that motivation to recommend an SCT over an STH?

Separately, why does this establish a new registry for signature schemes?  It is obviously trying to keep TLS compatibility, based on the codepoints, but forking the registry is a great way to create problems.

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 31 Dec 2018 06:36:54 -0800

+ trans

On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson <[email-masked]> wrote:

> There's not a lot of meat on this text.  It seems to be saying that if you
> are providing transparency_info, then you can provide a certificate other
> than any of the certificates that the client believes to be CT compliant.
> Also, you don't provide "x509_sct_v2" or "precert_sct_v2" in
> transparency_info.
>
> How is the client then able to determine that this new certificate is CT
> compliant?  Using  "inclusion_proof_v2" and "signed_tree_head_v2" (or one
> or other)?  If so, the text doesn't point in that direction.
>
> There's a lot of "why" missing in this document.  Why would a client
> choose to indicate "ct_compliant"?  Why is cached_info being extended in
> this way?
>
> I might guess that the reason here is that the draft aims to avoid
> including information that might change over time, which would render
> caches invalid.  Isn't that motivation to recommend an SCT over an STH?
>
> Separately, why does this establish a new registry for signature schemes?
> It is obviously trying to keep TLS compatibility, based on the codepoints,
> but forking the registry is a great way to create problems.
>
> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>