On Thu, Dec 14, 2017 at 2:26 AM, Eran Messeri <[email protected]> wrote:
> To follow up on some of the points raised in the issue: > > Examples of chains that are allowed under the current text: > * RFC5280-compliant leaf -> intermediate -> trust anchor. > * RFC5280-compliant leaf -> intermediate -> TA, where the leaf or one of > the intermediate are revoked or not temporally valid (I don't know of any > logs that do revocation checking currently). > * Non RFC5280-compliant leaf (for example, BER-encoded instead of DER > encoded) -> intermediate -> TA. > * leaf -> intermediate1 -> intermediate2 without the trust anchor (however > when the log stores and serves the chain it must serve the trust anchor > used to accept the submission). > > Examples of chains that are not allowed: > (1) Incomplete chain: leaf -> intermediate1 , missing intermediate2 -> > trust anchor. > (2) leaf -> intermediate -> trust anchor _not trusted by the log_. > (3) leaf -> intermediate -> trust anchor, where the signatures either by > the intermediate or the TA do not validate. > What about leaf -> non-CA cert -> trust anchor? That seems to conform to the requirement that it have a valid signature chain. In PR289 <https://github.com/google/certificate-transparency-rfcs/pull/289>, > the suggestion was to change the MUST restricting chains (2), (3) from > being admitted at all, to a SHOULD, so such chains may be admitted under > some circumstances (that is, AFAIUI, the meaning of SHOULD in RFC2119). > > The arguments were: > * Chrome CT policy requires CT logs to be RFC compliant. > * A bug in a CT log implementation could lead to accepting a submission > that doesn't chain to a trust anchor accepted by the root. > * Such a bug would make the CT log non RFC-compliant, and so subject to > removal from the set of logs trusted by Chrome. > > I do not think this is a strong argument in favour of these changes > because: > * The Chrome CT policy can be changed to accommodate some deviations from > the standard (Chrome's policy is dynamic and may change at any time). > * There have been cases where a log incorrectly accepted chains that do > not terminate in an accepted TA (Rob Stradling has found at least one). In > those cases the log was not disqualified from Chrome. > * Most importantly, it further burdens monitors and log clients - which > will have to investigate, and be able to cope with, corrupted chains. There > are already quite a few certificates in 6962 logs that require particularly > lax parsers and some CT log clients already resort to their own fork of DER > parsers / X.509 decoders. I think perpetuating this situation in unhealthy > in the long term. > * These MUST statements are there to guide implementation - to make it > clear that no 6962-bis implementation should admit submissions unless it > can check their validity. > As I said in my comment, I think it's ultimately a wg decision what to do here, as long as the MUST is unambiguous (otherwise it doesn't conform to our basic requirements). So, my purpose here is primarily to ensure non-ambiguity. With that said, these aren't the arguments I was offering. Rather, I was saying that the MUST is guidance to how a log should operate, but it's not required for interoperability, and potentially not for security (at most for DoS, it seems?), so I'm not sure it really belongs in this document. -Ekr > While I can appreciate that the narrow view of a log operator would favour > as few restrictions on the log as possible, relaxing the requirement that > each chain is signed correctly and terminates at an accepted TA does not > make sense for the overall protocol. The CT protocol is already biased > towards ease of log implementation and I don't see a reason to tip the > balance further towards log implementation (given it has already been > demonstrated in the workgroup that finding feasible, privacy-preserving > methods to audit logs or get stronger security guarantees from them is > hard). > > Eran > > > On Wed, Nov 22, 2017 at 4:58 PM, Eric Rescorla <[email protected]> wrote: > >> >> >> On Wed, Nov 22, 2017 at 3:55 AM, Rob Stradling <[email protected]> >> wrote: >> >>> On 21/11/17 19:33, Al Cutter wrote: >>> >>>> >>>> >>>> On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri <[email protected] >>>> <mailto:[email protected]>> wrote: >>>> >>>> [shortening subject] >>>> >>>> Two MUSTs are being discussed: >>>> (1) "the log MUST NOT accept any submission until it has verified >>>> ..." >>>> >>>> >>>> Actually it's just this one, I think the one below was included >>>> possibly by mistake (I mentioned to that to Rob when I spotted it on the >>>> PR). >>>> >>> >>> Yeah, I misunderstood which MUSTs (in section 4.2) EKR (and Al) thought >>> should be SHOULDs. >>> >>> I've updated the PR. This discussion is now only about whether or not >>> that first "MUST NOT" should be changed to "SHOULD NOT". >>> >>> From the discussion on the PR, it seems that: >>> - Eran and Andrew strongly prefer "MUST NOT". >>> - EKR wrote "this is a WG decision" and so I presume he'll accept >>> either "MUST NOT" or "SHOULD NOT". >>> >> >> I'll accept MUST NOT as long as the MUST NOT is unambiguous. I thought it >> was but the discussion in the PR suggests that it's not because we don't >> know what the lax validation exception covers. As long as you have clarity >> on that point then SHOULD NOT/MUST NOT is totally up to the WG. >> >> -Ekr >> >> >> >> >> >>> - Al is the sole proponent of changing it to "SHOULD NOT". >>> >>> Al, can you live with "MUST NOT"? >>> >>> -- >>> Rob Stradling >>> Senior Research & Development Scientist >>> COMODO - Creating Trust Online >>> >>> >>> _______________________________________________ >>> Trans mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/trans >>> >> >> >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
