Subject: [Trans] comments on -05 (Sections 3.3, 3.4 and 3.4.1)

From: Stephen Kent <[email-masked]>
Date: Fri, 06 Mar 2015 11:08:38 -0500

*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.