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