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.
Section 10.1 (metadata): Is the Final STH specified as a TransItem of
type signed_tree_head_v2 or as a tree_size integer?
Section 10.2.2 (Reconstructing the TBSCertificate): It's also necessary
to remove the Transparency Information extension, but this step is
omitted.
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.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
