*3.3 Structure of a Signed Certificate Timestamp*
There are several references to hash computations based on SHA-256. You
should ask whether the IESG will be comfortable with specifying this
hash, or whether they will require algorithm agility for hash algorithms
used in this context.
*3.4 Including the Signed Certificate Timestamp in the TLS handshake*
My views on the appropriateness of embedding an SCT as an OCTET string
in X.509 certificates and OCSP responses have already been posted, so
I'll not repeat them here.
The text states “At least one SCT MUST be included.Server operators MAY
include more than one SCT.” This specification of mandatory behavior for
a TLS server, and the later mandate that “Servers MUST implement at
least one of the three mechanisms”, seem at odds with the notion of
deferring specification of all CT clients to other documents.
Specifically, since there is no mandate for TLS client to do anything
with an SCT, it’s hard to justify mandating that a TLS server transmit
one.**
The text still says “TLS clients MUST implement all three
mechanisms.“contrary to the notion of deferring all specification of
client behavior to other documents.
*3.4.1 TLS Extension*
The text states: “Clients that support the extension SHOULD send a
ClientHello extension with the appropriate type and empty
"extension_data". This is a statement of client behavior.
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
