*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.
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
