Subject: [Trans] comments on -05 (Section 3.1)

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

*3.1 Log Entries*

The pre-certificate discussion here is much improved.

The text says that a log MAY accept a syntactically invalid or expired 
certificate or pre-certificate. This is still a rather vague description 
of log behavior with respect to certificate path validation.

Although I acknowledge that some Web PKI CAs issue defective 
certificates, I don’t believe the IETF should encourage such practices 
by making explicit accommodations for them in an RFC. Moreover, the MAY 
here means that a log also is allowed to reject a certificate if it is 
expired or syntactically defective in any way. How is a submitter, or a 
client, supposed to know how a log behaves in this regard?

I note that my proposed definition of a certificate type field for 
submissions and SCTs would provide a cleaner way to deal with this, 
i.e., logs that elect to perform syntactic checks can do so and the 
result of the checks can be expressed in the SCT. A log operator could 
describe the set of syntactic checks that it performs (if it is not the 
same as DV or EV or other, published specs), and register them using the 
IANA mechanism I described. Finally, just as a log advertises the set of 
CA certificates that it accepts as trust anchors, it could advertise the 
set of certificate types it checks in submitted certificates, thus 
making submitters aware of what will and will not be checked.

The text says that “Logs SHOULD limit the length of chain they will 
accept.” but does not describe how logs will make this limit known to 
submitters.

The text say: “Section 4 explains how clients should handle unknown 
entry types.” But client behavior is out of scope, so …

It appears that Section 3.2 has not yet been updated to reflect the 
recent design decisions for redacted certificates, so I have no comments 
on this section at this time.