From nobody Thu Dec 14 02:27:25 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDD401267BB for ; Thu, 14 Dec 2017 02:27:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dw1JLNwBochM for ; Thu, 14 Dec 2017 02:27:20 -0800 (PST) Received: from mail-it0-x235.google.com (mail-it0-x235.google.com [IPv6:2607:f8b0:4001:c0b::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 816EF124217 for ; Thu, 14 Dec 2017 02:27:20 -0800 (PST) Received: by mail-it0-x235.google.com with SMTP id d137so9976172itc.2 for ; Thu, 14 Dec 2017 02:27:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=cQENcBxDj78lKprRabsGH97zwaxqf1b/XFStN2Cq7Kk=; b=nzhCjZdJkl/ezontjbAS+4YJqaspwOsZfD/1t/MqQI7bsH++7RrzdzWe700Zs8DiQf XXbv++YwYzLbVqSDbWzlPW6QdF9Tw/CEeU1MuwuK8kxEVknSs8nGs+Z//iWsYwf6Flyh O8aDuPRb2N1Xd+xvT6edkoCX3HtVe1Eg889qGDIBP+fUiXj77QZYb/kROK0iEX8KqKHf qZ1p9Dk5gCVN0rEmfTdaHApRExgDTXRd0T7tmTWdOqevst2/cqzphcL7uo6LwsZ2X46j fb/fFZwOdP0EMrsHiHltoiXcIb7ptbuGzn7wC9ibl2UsyAspz/jU0CdR7ksCuU3U7PIA obIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=cQENcBxDj78lKprRabsGH97zwaxqf1b/XFStN2Cq7Kk=; b=hFw0iQ0uoLo15A1Hya82VyfKCPqkf01uGFgWaLfjZWpptbGdFVB2n5vy4XjCZTD+wM fwNHpfL+whS+4zWs84VyUO7Smgb7BGufMfeNpRirs+KHIHQN0tpIjCrC6+5EOoOh3IMj fLu33MJOoBPFYGXuUyslHVMwc+Zw9+0k92WpJ/C8UkbKgxLjfVVclvIdw/pKCgP5nFCJ jNSZDLGkbSAzjGSAJtZyN4uLkcPX/L8auVboMggRMRHM8QVU8c+faUMcdcAj473b9BTn ILi82VGekgGWpKR/SCQYlio1Jen4cKeFBFgFqTWB/izi/lRHXa2/x9QIlmT5lykMW4nr X/fQ== X-Gm-Message-State: AKGB3mK2+zbPeAqSIr9qQV25Aet6r4+fqP6bje08/Rzt7xh3GlFCMb27 4Jpe80Vh81Zd+04EBVM5+dP28h1GVhaakWSkY0n9Xw== X-Google-Smtp-Source: ACJfBovJdL42i37fY85ucx3kNI15s0myAlM+bUErz/8A97A/eZlK5c6gah/tigoRdVQDO8rbFF7wGzN2g+MDpeczSw0= X-Received: by 10.36.39.8 with SMTP id g8mr2993801ita.42.1513247239277; Thu, 14 Dec 2017 02:27:19 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.222.3 with HTTP; Thu, 14 Dec 2017 02:26:48 -0800 (PST) In-Reply-To: References: From: Eran Messeri Date: Thu, 14 Dec 2017 10:26:48 +0000 Message-ID: To: Eric Rescorla Cc: Rob Stradling , Al Cutter , Trans Content-Type: multipart/alternative; boundary="001a1147c5ac28449c05604a544e" Archived-At: Subject: Re: [Trans] Section 4.2 follow-up X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Dec 2017 10:27:24 -0000 --001a1147c5ac28449c05604a544e Content-Type: text/plain; charset="UTF-8" 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. In PR289 , 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. 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 wrote: > > > On Wed, Nov 22, 2017 at 3:55 AM, Rob Stradling > wrote: > >> On 21/11/17 19:33, Al Cutter wrote: >> >>> >>> >>> On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri >> eranm@google.com>> 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 >> Trans@ietf.org >> https://www.ietf.org/mailman/listinfo/trans >> > > --001a1147c5ac28449c05604a544e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 o= r one of the intermediate are revoked or not temporally valid (I don't = know of any logs that do revocation checking currently).
* Non RF= C5280-compliant leaf (for example, BER-encoded instead of DER encoded) ->= ; intermediate -> TA.
*=C2=A0leaf -> intermediate1 -> in= termediate2 without the trust anchor (however when the log stores and serve= s the chain it must serve the trust anchor used to accept the submission).<= /div>

Examples of chains that are not allowed:
(1) Incomplete chain: leaf -> intermediate1 , missing intermediate2 -&g= t; 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 va= lidate.

In PR289, the sugg= estion was to change the MUST restricting chains (2), (3) from being admitt= ed at all, to a SHOULD, so such chains may be admitted under some circumsta= nces (that is, AFAIUI, the meaning of SHOULD in RFC2119).

The arguments were:
* Chrome CT policy requires CT logs t= o be RFC compliant.
* A bug in a CT log implementation could lead= to accepting a submission that doesn't chain to a trust anchor accepte= d by the root.
* Such a bug would make the CT log non RFC-complia= nt, 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 t= hese changes because:
* The Chrome CT policy can be changed to ac= commodate 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 S= tradling has found at least one). In those cases the log was not disqualifi= ed from Chrome.
* Most importantly, it further burdens monitors a= nd 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 t= hat require particularly lax parsers and some CT log clients already resort= to their own fork of DER parsers / X.509 decoders. I think perpetuating th= is situation in unhealthy in the long term.
* These MUST statemen= ts are there to guide implementation - to make it clear that no 6962-bis im= plementation should admit submissions unless it can check their validity.

While I can appreciate that the narrow view of a lo= g operator would favour as few restrictions on the log as possible, relaxin= g 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 i= s already biased towards ease of log implementation and I don't see a r= eason to tip the balance further towards log implementation (given it has a= lready been demonstrated in the workgroup that finding feasible, privacy-pr= eserving methods to audit logs or get stronger security guarantees from the= m is hard).

Eran

<= div class=3D"gmail_extra">
On Wed, Nov 22, 20= 17 at 4:58 PM, Eric Rescorla <ekr@rtfm.com> wrote:


On Wed, Nov 22, 2017 at 3:55 AM, R= ob Stradling <rob.stradling@comodo.com> wrote:
On 21/11/17 19:33, Al Cutter wrote:


On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri <eranm@google.com <mailto:eranm@google.com>> wrote:=

=C2=A0 =C2=A0 [shortening subject]

=C2=A0 =C2=A0 Two MUSTs are being discussed:
=C2=A0 =C2=A0 (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 possibl= y 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 sho= uld be SHOULDs.

I've updated the PR.=C2=A0 This discussion is now only about whether or= not that first "MUST NOT" should be changed to "SHOULD NOT&= quot;.

>From the discussion on the PR, it seems that:
=C2=A0 - Eran and Andrew strongly prefer "MUST NOT".
=C2=A0 - EKR wrote "this is a WG decision" and so I presume he= 9;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 sugg= ests that it's not because we don't know what the lax validation ex= ception covers. As long as you have clarity on that point then SHOULD NOT/M= UST NOT is totally up to the WG.

-Ekr


=C2=A0
=C2=A0 - 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
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans


--001a1147c5ac28449c05604a544e-- From nobody Fri Dec 29 06:32:52 2017 Return-Path: X-Original-To: trans@ietfa.amsl.com Delivered-To: trans@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8639F127AD4 for ; Fri, 29 Dec 2017 06:32:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rtfm-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7sCYBJK3q0Ni for ; Fri, 29 Dec 2017 06:32:48 -0800 (PST) Received: from mail-yw0-x22a.google.com (mail-yw0-x22a.google.com [IPv6:2607:f8b0:4002:c05::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C332A120046 for ; Fri, 29 Dec 2017 06:32:47 -0800 (PST) Received: by mail-yw0-x22a.google.com with SMTP id n25so9467189ywh.10 for ; Fri, 29 Dec 2017 06:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rtfm-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9vmwjr1iqHiD3KWNKaYKGQfigmoXXaSyHxZs/q/MFNg=; b=ppsxR8dtJWy6C1ffIwgKjKLVymNrYHerZeLf+Jfhd3BNZaFyX+Gn+q+OVcn2Xhpb+I iA+ZP/6/L+iNHO3y1W2NnfdZutZMcA0nFYXjiwzmvty0uej+Erx3U1GudtRb6XxsKRwG yOk4m17aJTciufHPDqjyZB1dEiSVdZRc5boaMdImL7MrhnlFhRkMNbzuWyu1611d2aLJ YCiejhhmw6/M75szUantD2DwyscQt2FKj5Zn9RbGORmfQoY9MGl9dwp5xbcTFVCXCtgy zh25OVfCWehA7hnuWsA25077T9aWVJSyQdpxOXY8+stiv4PX4SSSEhC7Dzkoq1tCQ4Nw spgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9vmwjr1iqHiD3KWNKaYKGQfigmoXXaSyHxZs/q/MFNg=; b=qrcsYLbFXpZ58Q4ZEIVnsC50wYdL0sUVXPzS3+D2alvKZn9B0OFnLbxvQBrouAZI2M eA9CZyX67b5pzpsMfhe0ymKEPGfEwcd4axzJKqbYaXQ4Ja3gSPfWc+91xvdg8mPXMAQA E2JXYo/VJZvsJ/I5gAD/ZBUo4WiD/9Hv48LBQDtpEPrfZ8rRHZZodlGhihOrqDcwr4mY 6rbD06F5L2bMnMECuroLesW5tULxo9/puEZw4/yzy3yDJVH+pRtvjP0iAg5hQbvWPbIh ffxP6ugUZXZ/Wc1IG8xxQMfKTAeaqaFAlMyURaaQh6STydKeNr9/MUVrQfo9npzkEf+E 1Qfw== X-Gm-Message-State: AKGB3mLjKruSBt6lGbdS4G422VxtBM6/Oviy7C1a4fjkfLC3vUplmRmE 9KVz+NYjlj2L86PFqiPFzj90l4gD6b7G6zCgK7XhcNRC X-Google-Smtp-Source: ACJfBotLYjMp4ILfy3Ann2F2uiDCyHMBcihAbhBfg6gNC0/mbWyUbAMYhQgRH5dZEl69ANIsTfpKwgl5tKjl/Hi22uA= X-Received: by 10.129.154.22 with SMTP id r22mr23611091ywg.296.1514557966902; Fri, 29 Dec 2017 06:32:46 -0800 (PST) MIME-Version: 1.0 Received: by 10.129.123.132 with HTTP; Fri, 29 Dec 2017 06:32:06 -0800 (PST) In-Reply-To: References: From: Eric Rescorla Date: Fri, 29 Dec 2017 06:32:06 -0800 Message-ID: To: Eran Messeri Cc: Rob Stradling , Al Cutter , Trans Content-Type: multipart/alternative; boundary="94eb2c0bb4e89bfb1d05617b8197" Archived-At: Subject: Re: [Trans] Section 4.2 follow-up X-BeenThere: trans@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Public Notary Transparency working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Dec 2017 14:32:50 -0000 --94eb2c0bb4e89bfb1d05617b8197 Content-Type: text/plain; charset="UTF-8" On Thu, Dec 14, 2017 at 2:26 AM, Eran Messeri 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 , > 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 wrote: > >> >> >> On Wed, Nov 22, 2017 at 3:55 AM, Rob Stradling >> wrote: >> >>> On 21/11/17 19:33, Al Cutter wrote: >>> >>>> >>>> >>>> On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri >>> > 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 >>> Trans@ietf.org >>> https://www.ietf.org/mailman/listinfo/trans >>> >> >> > --94eb2c0bb4e89bfb1d05617b8197 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Dec 14, 2017 at 2:26 AM, Eran Messeri <eranm@google.com>= wrote:
To follow= up on some of the points raised in the issue:

Examples of cha= ins that are allowed under the current text:
* RFC5280-compliant = leaf -> intermediate -> trust anchor.
* RFC5280-compliant l= eaf -> 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 r= evocation checking currently).
* Non RFC5280-compliant leaf (for = example, BER-encoded instead of DER encoded) -> intermediate -> TA.
*=C2=A0leaf -> intermediate1 -> intermediate2 without the tr= ust anchor (however when the log stores and serves the chain it must serve = the trust anchor used to accept the submission).

E= xamples of chains that are not allowed:
(1) Incomplete chain: lea= f -> intermediate1 , missing intermediate2 -> trust anchor.
(2) leaf -> intermediate -> trust anchor _not trusted by the log_.
(3) leaf -> intermediate -> trust anchor, where the signatur= es either by the intermediate or the TA do not validate.
<= /blockquote>

What about leaf -> non-CA cert -> tru= st anchor? That seems to conform to the requirement that it have a valid si= gnature chain.



In PR28= 9, the suggestion was to change the MUST restricting chains (2), (3) fr= om 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 req= uires CT logs to be RFC compliant.
* A bug in a CT log implementa= tion 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 b= y Chrome.

I do not think this is a strong argument= in favour of these changes because:
* The Chrome CT policy can b= e changed to accommodate some deviations from the standard (Chrome's po= licy is dynamic and may change at any time).
* There have been ca= ses where a log incorrectly accepted chains that do not terminate in an acc= epted TA (Rob Stradling has found at least one). In those cases the log was= not disqualified from Chrome.
* Most importantly, it further bur= dens 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.
* Thes= e MUST statements are there to guide implementation - to make it clear that= no 6962-bis implementation should admit submissions unless it can check th= eir validity.

As I said i= n 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 b= asic requirements). So, my purpose here is primarily to ensure non-ambiguit= y.

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 potent= ially not for security (at most for DoS, it seems?), so I'm not sure it= really belongs in this document.

-Ekr
<= br>

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 demon= strated 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 <ekr@rtfm.com> wrote:


On Wed, Nov 22, 2017 at 3:55 AM, Rob Stradling = <rob.stradling@comodo.com> wrote:
On 21/11/17 19:33, Al Cutter wrote:


On Tue, Nov 21, 2017 at 7:20 PM, Eran Messeri <eranm@google.com <mailto:eranm@google.com>> wrote:=

=C2=A0 =C2=A0 [shortening subject]

=C2=A0 =C2=A0 Two MUSTs are being discussed:
=C2=A0 =C2=A0 (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 possibl= y 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 sho= uld be SHOULDs.

I've updated the PR.=C2=A0 This discussion is now only about whether or= not that first "MUST NOT" should be changed to "SHOULD NOT&= quot;.

>From the discussion on the PR, it seems that:
=C2=A0 - Eran and Andrew strongly prefer "MUST NOT".
=C2=A0 - EKR wrote "this is a WG decision" and so I presume he= 9;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 sugg= ests that it's not because we don't know what the lax validation ex= ception covers. As long as you have clarity on that point then SHOULD NOT/M= UST NOT is totally up to the WG.

-Ekr


=C2=A0
=C2=A0 - 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
Trans@ietf.org
https://www.ietf.org/mailman/listinfo/trans



--94eb2c0bb4e89bfb1d05617b8197--