Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33
Alissa Cooper <alissa@cooperw.in> Fri, 27 September 2019 17:45 UTC
Return-Path: <alissa@cooperw.in>
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 4E0501209E3 for <trans@ietfa.amsl.com>; Fri, 27 Sep 2019 10:45:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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=cooperw.in header.b=VGorBNZq; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ueqN6MDg
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 Aaa0qbcertZC for <trans@ietfa.amsl.com>; Fri, 27 Sep 2019 10:45:00 -0700 (PDT)
Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A0071209BF for <trans@ietf.org>; Fri, 27 Sep 2019 10:45:00 -0700 (PDT)
Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id 9A73B53F; Fri, 27 Sep 2019 13:44:59 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 27 Sep 2019 13:44:59 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cooperw.in; h= content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; s=fm1; bh=Z r7vVxmZ8vOvW82cJSnzesgYJQ8AWZKrK2504+ub+NI=; b=VGorBNZq7/TsD6xCS 2prUukL6VcXCabQxXSiLzD3ylA3mIHpWMHGHaoEBplGKqfvrRlzCxdzN6b8jvhyO cWCria7MEGu/EIYVK2Friufaz6cWqGf0ypggETX3DBojJaqSAsAUBhBAwCipN3cC U9p8NwDNVuxp1NsETNRBl5g7uo8kZ9YpgMeUee9Q8viAabs7/05Vil6Ac1zgjmWm hmrRt6dNLLE3psOgEFkZWpTrgBUaD+eGCLBqOAZNpMgQUQWup+PDsYnc0kXisP6R cNnNZxCBxBgcr2TGVaRtCqVbZmB3199xsZqJXL380nCThkzJ2U3sUIP8GYGTYYkg SlXgA==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=Zr7vVxmZ8vOvW82cJSnzesgYJQ8AWZKrK2504+ub+ NI=; b=ueqN6MDggBk3k9jHNq+ewoKsw1qYxtC11KvDUEQ8HAHq0BIeGKc+8dM9v IMAcTVxq72rpdaAEzjCm4dYWa5ZdCMqkP7tuU2mXVn1NZ0+ULPFecwAA5ofHAwI3 J4fcWplOqJzm/vYKPmn6ZmtK3yPIX4y6besLXHuTrG+6F8dSv3hir2bf3MohlkR9 kH9kULHWOjLvPaMO134lwsMrsJRCB7/R0nNcjHU/UmPu5PWgfTrf6ZxBwPsTzJWS CXkkD3IJsYA4xC/b+YAo9Kks4yXTWyOFeVtbslUFOrj2/3sBu9VY+gnGhpq9j7CW Ma1y48fz2q1jjD01zTxgiTIELtO6g==
X-ME-Sender: <xms:mkqOXcWiN8vAkwlFeHzd01HGk3ozmYgSthOGdkrFk28YQkprcLgCAw>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrfeeigdduudegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptggguffhjgffgffkfhfvofesthhqmhdthhdtjeenucfhrhhomheptehlihhs shgrucevohhophgvrhcuoegrlhhishhsrgestghoohhpvghrfidrihhnqeenucffohhmrg hinheptghomhhoughordgtohhmpdhgihhthhhusgdrtghomhenucfkphepfeekrdelkedr feejrddufeegnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhishhsrgestghoohhpvg hrfidrihhnnecuvehluhhsthgvrhfuihiivgeptd
X-ME-Proxy: <xmx:mkqOXaCByhMT6ixegdLJtPlmUHvth9_z7zVw0bS5P9y9LB-g_ei_cA> <xmx:mkqOXf8-xetIPeBZUxJFfvKD0sp8QnpIAD_QtIzUEYxUQ4DUCb5w7A> <xmx:mkqOXREAlFaZReOF1sKr_pF9NWk07JjFyWow43vu-XN7iYD5zW-esw> <xmx:m0qOXeOEcM7vPzoeUmVfjNoKyKzTZBit41qmXybP00S7-JlWwYjakg>
Received: from [172.19.249.225] (unknown [38.98.37.134]) by mail.messagingengine.com (Postfix) with ESMTPA id 50C87D60057; Fri, 27 Sep 2019 13:44:54 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
From: Alissa Cooper <alissa@cooperw.in>
In-Reply-To: <alpine.LRH.2.21.1909191211080.29314@bofh.nohats.ca>
Date: Fri, 27 Sep 2019 13:44:48 -0400
Cc: Rob Stradling <rob@sectigo.com>, Trans <trans@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <629B4343-4ECE-4C56-B17F-BAA25DBF06E4@cooperw.in>
References: <alpine.LRH.2.21.1909181506160.11898@bofh.nohats.ca> <b6ec6a38-a4c2-64b4-0584-d13deead2605@sectigo.com> <alpine.LRH.2.21.1909191211080.29314@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.3445.9.1)
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/MXXompajF4xU6CP3O3VRtatfzdY>
Subject: Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Public Notary Transparency working group discussion list <trans.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/trans>, <mailto:trans-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/trans/>
List-Post: <mailto:trans@ietf.org>
List-Help: <mailto:trans-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/trans>, <mailto:trans-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 27 Sep 2019 17:45:03 -0000
I cleared my DISCUSS. Thanks! Alissa > On Sep 19, 2019, at 12:19 PM, Paul Wouters <paul@nohats.ca> wrote: > > On Thu, 19 Sep 2019, Rob Stradling wrote: > >> Hi Paul. >> >>> Alissa Cooper: >>> >>> = Section 10.3 = >>> >>> This section needs to state what the registry policy is for the code >>> points not already registered (presumably Expert Review given 10.3.1, >>> but it needs to be explicit). >> >> This was addressed by PR 309, in this commit: >> https://github.com/robstradling/certificate-transparency-rfcs/commit/7cd3471548c903fd891a99227bf081ca51939470 > > Alissa, is the resolution okay with you? I thought you might also wanted > text in the paragraph itself, and not just in the table, but perhaps > this is all you wnated? > >>> = Section 10.6.1 = >>> >>> FCFS registries by definition can require additional information to be >>> provided in order to get something registered. For avoidance of >>> confusion I think the assignment policy should be listed as First Come >>> First Served and the requirement that parameters be included in the >>> application can use a normative MUST in the last paragraph if there is >>> concern that the parameters won't be supplied. >>> >>> However, I also wonder what will be done with the parameters that are >>> supplied. Is IANA expected to just maintain them privately, or to >>> publish them? >>> >>> What is expected to appear in the 'Log' column in the registry? >> >> This was addressed by PR 309, in this commit: >> https://github.com/robstradling/certificate-transparency-rfcs/commit/704a71a18457b4558ce26fe4be519d6ea06a729a > > Okay that seems clear to me now. Hopefully to Alissa as well. Alissa, > can you clear your DISCUSS if all your concerns are addressed? > >>> And let me add my own question regarding 10.6.1. Should we expect these >>> registry entries can change over time? If so, is it definied anywhere what >>> consumers are supposed to do or how they are supposed to find out, that a >>> log base url has changed? Shouldn't such a change be done using a new OID? >> >> Since the OID (the Log ID) appears in each of the signed log artifacts >> (SCTs, STHs), I think trying to change the OID of an existing log would >> be pretty disastrous. >> >> However, I agree that there could be legitimate reasons for wanting to >> change a log's base URL. For example, in the currently deployed CT v1 >> ecosystem, it would be really nice if Sectigo could update the base URLs >> of our Mammoth and Sabre logs. ({mammoth,sabre}.ct.comodo.com made >> sense when we set up these logs, but then Sectigo (formerly Comodo CA) >> was carved out of Comodo). >> >> Having said that though, I think the best approach would be to add a >> sentence to the document that says that log base URLs MUST NOT change. >> Nice and simple. > > So this seems to contradict itself. You give a good reason why a base > url might change, then suggest to say MUST NOT. And you cannot add a > new entry with updated base url using the same OID I guess? So one would > have to replay the existing log into a new one. If that becomes a common > practise, how is this distinguishable from a log reply that removes an > entry and urges everyone to (automatically or not) update to the new > base url ? > >> We have not yet made any attempt to respond to the DISCUSS/COMMENT items >> from Benjamin Kaduk, Mirja Kühlewind, and Alexey Melnikov. >> >> Now that the lengthy debate about BCP190 is over, I do intend to look at >> these remaining items soon. I will be looking for help to address >> Benjamin's COMMENTs on section 2; I am not a cryptographer, and I want >> to ensure that these comments are satisfactorily addressed. > > Okay. Hopefully this can be done very soon so we can re-issue a WGLC and > then have this done before IETF 106. > > Paul
- [Trans] overview of remaining(?) DISCUSS items fo… Paul Wouters
- Re: [Trans] overview of remaining(?) DISCUSS item… Rob Stradling
- Re: [Trans] overview of remaining(?) DISCUSS item… Paul Wouters
- Re: [Trans] overview of remaining(?) DISCUSS item… Rob Stradling
- Re: [Trans] overview of remaining(?) DISCUSS item… Paul Wouters
- Re: [Trans] overview of remaining(?) DISCUSS item… Ryan Sleevi
- Re: [Trans] overview of remaining(?) DISCUSS item… Rob Stradling
- Re: [Trans] overview of remaining(?) DISCUSS item… Andrew Ayer
- Re: [Trans] overview of remaining(?) DISCUSS item… Paul Wouters
- Re: [Trans] overview of remaining(?) DISCUSS item… Rob Stradling
- Re: [Trans] overview of remaining(?) DISCUSS item… Eran Messeri
- Re: [Trans] overview of remaining(?) DISCUSS item… Alissa Cooper
- Re: [Trans] overview of remaining(?) DISCUSS item… Rob Stradling
- Re: [Trans] overview of remaining(?) DISCUSS item… Rob Stradling
- Re: [Trans] overview of remaining(?) DISCUSS item… Paul Wouters