On Sat, Jun 4, 2016 at 3:17 PM, Ben Laurie <[email protected]> wrote: > > > On 4 June 2016 at 20:01, Peter Bowen <[email protected]> wrote: >> >> Section 5.1 has a requirement that a log MUST only accept certificates >> (or precertificates) that include a full valid chain to a trusted root >> in the submission. This appears to exclude any option for a log to >> have a priori knowledge of intermediate CAs and accept submissions >> with incomplete chains. It also means that the log cannot decide to >> accept certificates that are incorrectly constructed by the CA. >> >> I would suggest the following alternative for the first paragraph of 5.1: >> >> Logs SHOULD verify that each submitted certificate or precertificate >> has a valid signature chain to an accepted trust anchor, using the >> chain of intermediate CA certificates provided by the submitter. Logs >> MUST accept certificates and precertificates that are fully valid >> according to <xref target="RFC5280">RFC 5280</xref> verification rules >> and are submitted with such a chain. Logs MAY accept certificates and >> precertificates that have expired, are not yet valid, have been >> revoked, or are otherwise not fully valid according to RFC 5280 >> verification rules in order to accommodate quirks of CA >> certificate-issuing software. However, logs MUST reject submissions >> without a known valid signature chain to an accepted trust anchor. >> Logs SHOULD also reject precertificates that do not conform to the >> requirements in <xref target="Precertificates"/>. Logs MAY accept >> objects other than certificates and precertificates that have a known >> valid signature chain to an accepted trust anchor. > > > I think this is all getting too complicated and in the wrong direction. > > The intent of this section was that logs should have some mechanism to > control spam. We (the authors) had decided that the mechanism was going to > be "issued by a trusted CA" for some value of "trusted", which is fine, but > should not have been enshrined. > > The intent is that logs should contain information that may or may not be of > interest to you. They are not arbiters of truth or correctness (other than > their own honesty). Spam makes logs difficult to use, so they need a spam > control mechanism. But we should not mandate what that mechanism is. > > Yes, I am saying my own I-D is wrong. :-) > > I think the fix is to say that logs should take measures to limit their > size, e.g. "chains up to a trusted CA", but not mandate what that mechanism > is. > > Browsers, monitors, etc, can make up their own minds what a reasonable size > for a log is. Presumably something not wildly different from the size of the > set of certs they are interested in.
Ah, good. My preference is that the I-D/RFC only discuss the technical details and leave policy to the log operator. Given that the doc is in last call, I was trying to take a compromise approach by leaving in most of the existing text. What about just removing the whole first paragraph? Thanks, Peter _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
