+ trans On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/tls >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
