That works for me -Ekr
On Fri, Feb 22, 2019 at 6:41 AM Rob Stradling <[email protected]> wrote: > EKR, Martin, > > Hi, and sorry for the long delay in replying. > > This originated in [1] and was added to 6962-bis in [2]. The motivation > was to provide a mechanism to permit a TLS server to avoid sending CT > artifacts (SCTs, STHs, inclusion proofs) that it knows the TLS client > already has or doesn't need, thereby reducing bytes on the wire for > constrained and high-volume environments. > > The approach envisaged by RFC7924 seems to be: "here's a list of TLS > message fingerprints I've received previously; please don't send these > exact messages to me again". This works for stand-alone messages that > contain one item, such as the server's Certificate message (which > contains 1 server certificate chain). > > However, in 6962-bis's case, SCTs and inclusion proofs are not > stand-alone items; instead, they correspond to particular certificates. > Each relevant TLS message will contain a TransItemList, which will > probably contain at least a set of several SCTs; and whilst each SCT is > static, the set (and the order within the set) is not. Therefore, the > approach of caching TLS messages by fingerprint didn't look like it > would work for us. > > We concluded that it would make more sense for the client to make a more > high-level statement: "here's a list of certificate fingerprints that > I've received previously and that I already regard as being CT-compliant". > > This isn't an essential part of 6962-bis. Other than Ben L's "Sounds > like a good idea" comment in [1], I don't recall anyone commenting on it > until EKR started this thread. > > I propose to remove this cached-info mechanism from 6962-bis, if nobody > objects. (It could of course be revisited in some future document, if > there's interest). > > > [1] https://trac.ietf.org/trac/trans/ticket/111 > > [2] https://github.com/google/certificate-transparency-rfcs/pull/186 > > On 31/12/2018 14:36, Eric Rescorla wrote: > > + trans > > > > On Sun, Dec 30, 2018 at 10:06 PM Martin Thomson <[email protected] > > <mailto:[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. > > -- > Rob Stradling > Senior Research & Development Scientist > Email: [email protected] > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
