Re: [TLS] ct_compliant cached info field

+ trans

On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson <mt@lowentropy.net> wrote:

>
> On Fri, Dec 28, 2018, at 04:58, Eric Rescorla wrote:
> > Please take a look at
> > 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.
>
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>