[shortening subject] Two MUSTs are being discussed: (1) "the log MUST NOT accept any submission until it has verified ..." (2) "The log MUST NOT use other sources of intermediate CA certificates"
These MUSTs are to do with security (as Andrew Ayer pointed out <https://github.com/google/certificate-transparency-rfcs/pull/289#issuecomment-344668837>) as well as protocol correctness and determinism of the logs, not in order to restrict what logs should accept. A consensus has already been established in the group that logs need to be allowed to accept certificates that are not fully compliant with RFC5280 validation rules (hence the SHOULD in the second paragraph of said section and MAY on the third paragraph). Another consensus was established that logs should be allowed to drop valid submissions under load (to protect against DoS attacks) - which again is allowed by the SHOULD on the 2nd paragraph. The MUSTs that have remained, have remained there to guarantee that a submission has made it into the log if, and only if, it has been validated according to the log's implementation (which, again, may deviate from RFC5280). These MUSTs are in place to guide the implementation, even if there's no technical way to validate, from an external POV, that a log adhered to them at all times. To present from a different angle, if the MUSTs are changed to SHOULDs then (according to my understanding of RFC2119) logs will be able to claim that any accepted submission was not validated because the it wasn't checked. That would make monitoring difficult and submission non-deterministic (because a log would then be allowed to use other sources of intermediate CA certificates to complete a partially-submitted chain). RFC2119 says about SHOULD that "there may exist valid reasons in particular circumstances to ignore a particular item [...]" but I do not see a valid reason to ignore validation for some entries or allow acceptance of partial chains, where the 6962-bis goes to great length to ensure the submitted, valid chain is always presented to monitors. >From what I can tell, the arguments in the GitHub PR mentioned below either fall into the "non-RFC5280-compliant submission" (which is already covered) or involve the implications of a particular log not being 6962-bis compliant, which fall into the Client Behaviour category (implications of the protocol on clients and servers' behaviour, not the protocol specification itself). This part of section 4.2. has been discussed on the list a year ago ( https://www.ietf.org/mail-archive/web/trans/current/msg02484.html) and earlier (https://trac.ietf.org/trac/trans/ticket/73, https://trac.ietf.org/trac/trans/ticket/21). On Mon, Nov 20, 2017 at 7:22 PM, Al Cutter <[email protected]> wrote: > Hi all, > > I was trying to help (honest!) Rob Stradling with the outstanding AD > comments from ekr on -bis27, and so we took an easy starter for 10: > [ekr] *"Why is this a 2119 MUST? It seems wise, but not necessarily a > conformance requirement"* > in regards to Section 4.2: > >> "To avoid being overloaded by invalid submissions, the log MUST NOT >> accept any submission until it has verified that the certificate or >> precertificate was submitted with a valid signature chain to an accepted >> trust anchor. > > > FWIW I agree with ekr on this (it's a policy statement, and, I believe, a > potentially dangerous one to encode as an RFC MUST) and managed to persuade > Rob of the same (at least that's what he said at the time), so he kindly > put together a PR to change that MUST NOT to a SHOULD NOT: > https://github.com/google/certificate-transparency-rfcs/pull/289 > > Apparently not everyone sees it quite so clearly, and there's been a bit > of a discussion on the PR, so in the interests of Transparency I wanted to > call it out here too in case there's anybody who was not already aware of > the PR and wants to get involved, again, on this well worn and comfy topic. > > Cheers, > Al. > > > > _______________________________________________ > Trans mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/trans > >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
