On Wed, 15 Jun 2016 15:56:59 +0100 Eran Messeri <[email protected]> wrote:
> On Wed, Jun 15, 2016 at 4:31 AM, Andrew Ayer <[email protected]> > wrote: > > > Section 6.6 (get-all-by-hash): It's not clear whether the inclusion > > proof is to the requested STH or to the returned STH. I'm pretty > > sure it's supposed to be the returned STH, but this wording > > suggests it's the requested STH: > > > > tree_size: The tree_size of the tree on which to base the > > proofs, in decimal > > > > In this wording, it's unclear what "selected STH" refers to: > > > > inclusion: A base64 encoded "TransItem" of type > > "inclusion_proof_v2" whose "inclusion_path" array of Merkle > > Tree nodes proves the inclusion of the chosen certificate in > > the selected STH. > > > I've changed the description to say 'returned STH' rather than > 'selected STH' for more clarity. I didn't change the tree_size > description as it seems obvious to me this is what the client > requests, but text to clarify that this may not be what the client > gets is welcome. I'll think about it. Changing "Selected STH" to "Returned STH" is probably good enough. > > Sections 10.2.5 - 10.2.7 (compliance): It's unclear what role the > > TLS Feature extension plays. > > > > > 10.2.5 says that compliance means "accompanied by at least one valid > > SCT." > > > > 10.2.6 says that if transparency_info is present in the TLS > > Feature extension, then "CT compliance ... is required" and that > > "TLS clients MUST treat certificates which fail this requirement as > > non-compliant." In other words, non-compliance must be treated as > > non-compliant, which isn't saying anything. > > > > 10.2.7 says that if the certificate chain is non-compliant, the "TLS > > client MUST refuse the connection," which renders the TLS feature > > extension unnecessary. > > > > I assume the intent is that if transparency_info is in the TLS > > Feature extension, then TLS clients MUST refuse connections using > > non-compliant chains. Otherwise, they MAY refuse connections using > > non-compliant chains, depending on the client's policy. > > > What changes do you suggest here? That section 10.2.6 explicitly > state that a TLS client must refuse the connection in case of > non-compliance? I've opened a pull request on GitHub for my suggested changes: https://github.com/google/certificate-transparency-rfcs/pull/173 Regards, Andrew _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
