Re: [Trans] Policy for adding to IANA registries requested in 6962-bis

Eran Messeri <eranm@google.com> Tue, 13 December 2016 15:46 UTC

Return-Path: <eranm@google.com>
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 CE03D129411 for <trans@ietfa.amsl.com>; Tue, 13 Dec 2016 07:46:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.896
X-Spam-Level:
X-Spam-Status: No, score=-4.896 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_NONE=-0.0001, RP_MATCHES_RCVD=-2.896, SPF_PASS=-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 JX55P3KX0pnb for <trans@ietfa.amsl.com>; Tue, 13 Dec 2016 07:46:14 -0800 (PST)
Received: from mail-wj0-x22e.google.com (mail-wj0-x22e.google.com [IPv6:2a00:1450:400c:c01::22e]) (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 6A299129404 for <trans@ietf.org>; Tue, 13 Dec 2016 07:46:14 -0800 (PST)
Received: by mail-wj0-x22e.google.com with SMTP id tg4so104312561wjb.1 for <trans@ietf.org>; Tue, 13 Dec 2016 07:46:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=D2d8b82/dEMLr8iiO6pOwK5d+NDEw+2zyv+gvFbcYvc=; b=deP4n6s/3cukwYTZuqW4skLr4Kn2D971XdpvbRX4TENb/Y0sa8u1gTn0hpaTfAIld/ /zRCzCTwrCopuR45R0Zvl0f5vgMz05mpNiddrXxLFz7q9rRD9CKJ21KuCR0JI/GquHkW OHf78FbFfV2aIUcGgI1IFKD1StgeIRRPj+m+ii0O+EYJvnlN6sFLQAsz1jlWkXgFZ/oT GFZqPCjMVPIj7JAKIvjwllDFUMQMdrVRjnoh3IDksZnogqRpJjjhumFarR4yZs3djL1F SbBvAkh7BtLQqfPQOrwUnNOnRZWmw0lRiF1bijwTh5JWfs2GSwG2pP+VMZE47N+j+49T JQzQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=D2d8b82/dEMLr8iiO6pOwK5d+NDEw+2zyv+gvFbcYvc=; b=B1X8Qsf5JjZvhGXo8W59eMYBivDgzdTrWQz7uJMnu/ckU6Ga47GVmMq5iIgr9I0Ma6 Zh7fuNwlEZve+/ehdjmPCebll06aBRfMF/1+6ZeHIRJtmz5Okxjr3Q2IEI06VxHoEpcm JWRO/LlH+2nob1P6m+9RlySdsU2kMDwXwlnabSFGtERNEITwgG5W/LsubJXySAA0XUXf tLDDTQIqS/kSYJzF0sdp46p/JOxypxJbLXA1EGIkSc7IllM4vd61SmJn+2yJz49KWFbn wsVScZgRkQFc1qfE55H+Q8UObxJzo3aOiRkCsJ+mfijdpEW/r7DmgD9MnGzk3CURTvlz VNjQ==
X-Gm-Message-State: AKaTC02N9oRTQ3nTq9rGLG6vuLNLLrPMnYP10qpRPRnsz1BqQps9PHvBm8Zm9aZD1zw2SEm7G3AcFTgU+lCPpS2n
X-Received: by 10.194.149.143 with SMTP id ua15mr101307972wjb.48.1481643972602; Tue, 13 Dec 2016 07:46:12 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.31.21 with HTTP; Tue, 13 Dec 2016 07:45:41 -0800 (PST)
In-Reply-To: <CALzYgEdBHz5XaqXzPH5rThoJYkrfmViGOCG8soechR1HE9SJfA@mail.gmail.com>
References: <CALzYgEce25Z7tSz6T+kmFQCA+xbgO0ECknV6nE1m55-pey3vrQ@mail.gmail.com> <CALzYgEf74uLn00GWDt0ccHVuPRdJOpBNfGBKGcB2BWML23s3YQ@mail.gmail.com> <06cb8a34-7067-95af-708d-b2c2be261a1d@comodo.com> <alpine.LRH.2.20.1612122034310.31017@bofh.nohats.ca> <CALzYgEdBHz5XaqXzPH5rThoJYkrfmViGOCG8soechR1HE9SJfA@mail.gmail.com>
From: Eran Messeri <eranm@google.com>
Date: Tue, 13 Dec 2016 15:45:41 +0000
Message-ID: <CALzYgEeh8om5dEDzy6abG4f7d140sA+z+J=yWReVA4M7p3PTVw@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="089e0122897cac374405438c1eb9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/j4HjoGCpI8MfXsWfStvg8i8GV8E>
Cc: Rob Stradling <rob.stradling@comodo.com>, "trans@ietf.org" <trans@ietf.org>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Subject: Re: [Trans] Policy for adding to IANA registries requested in 6962-bis
X-BeenThere: trans@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 13 Dec 2016 15:46:18 -0000

Text to describe the policies and expert reviews was added in:
https://github.com/google/certificate-transparency-rfcs/commit/615a8c3be0acfc6461f6d3043d19ecc863f3888b


On Tue, Dec 13, 2016 at 2:32 PM, Eran Messeri <eranm@google.com> wrote:

> Rob and I had a chat, we have the following proposals (which Rob may
> correct in case I got something wrong):
>
> * For Hash Algorithm repository, specify "Expert Review" guiding the
> Expert to make sure the proposed hash algorithm has public specification
> and does not suffer from known preimage attacks.
>
> * For the Signature Algorithm repository, specify "Expert Review" guiding
> the Expert to make sure the proposed signature algorithm has public
> specification and can generate signatures deterministically.
>
> * For the STH extensions, SCT extensions and VersionedTransType: Require a
> public specification that accompanies the proposed additional values and an
> expert review of the public specification, to ensure the public
> specification is detailed enough for interoperable implementations.
>
> * For the Log ID 2 repository: First-Come-First-Served, only requirement
> is to fill in a template that contains the log metadata.
>
> * For the Log ID 1 repository: Require Expert Review, guiding the Expert
> to make sure the requester is requesting the OID in good faith with the
> intention of running a CT log (since that's a limited resource). The log
> metadata is still required.
>
>
> On Tue, Dec 13, 2016 at 1:39 AM, Paul Wouters <paul@nohats.ca> wrote:
>
>> On Tue, 13 Dec 2016, Rob Stradling wrote:
>>
>> https://tools.ietf.org/html/rfc5226 section 4.1 says (emphasis mine):
>>>   "Expert Review (or Designated Expert) - approval by a Designated
>>>          Expert is required.  The *required documentation* and review
>>>          criteria for use by the Designated Expert should be provided
>>>          when defining the registry."
>>>
>>> So I think we should specify both Expert Review and Specification
>>> Required, just as (for example) https://tools.ietf.org/html/rfc6844
>>> section 7.2 does:
>>>   "Addition of tag identifiers requires a public specification and
>>>    Expert Review as set out in..."
>>>
>>
>> Sounds good.
>>
>> Separately, should we reserve some values in either or both of these
>>> registries for Private Use or for Experimental Use?
>>>
>>
>> Yes please.
>>
>>  * Specification requirement for SCT & STH extensions: new values for
>>>>  these extensions are meaningless without specifying what they do - how
>>>>  should clients behave when encountering them.
>>>>
>>>
>>> +1 (and for the VersionedTransType registry we just added too)
>>>
>>> Separately, should we reserve some values in any of these registries for
>>> Private Use or for Experimental Use?
>>>
>>
>> Yes.
>>
>>  * First-come-first-served for Log IDs: I can't see how an expect review
>>>>  could be meaningful, given log operators requesting those IDs can't
>>>>  really prove competence to "own" log IDs, so requiring a "minimal
>>>> amount
>>>>  of clerical information" seems enough.
>>>>
>>>
>>> +1
>>>
>>
>> It would be nice to have some kind of rules or documentation, and at
>> least have an Expert around to block strange or excessive requests?
>>
>> Stephen: how would you see this happening?
>>
>> Paul
>>
>>
>>  Eran
>>>>
>>>>  On Mon, Dec 12, 2016 at 3:44 PM, Eran Messeri <eranm@google.com
>>>>  <mailto:eranm@google.com>> wrote:
>>>>
>>>>      No policy has been specified in 6962-bis for adding values to the
>>>>      IANA registries requested.
>>>>
>>>>      In https://github.com/google/certificate-transparency-rfcs/pull
>>>> /215
>>>>      <https://github.com/google/certificate-transparency-rfcs/pull/215>
>>>> I
>>>>      propose the following policies, all based on definitions in
>>>> RFC5226:
>>>>      * Hash algorithms and Signature algorithms: Expert Review
>>>>      * SCT extensions and STH extensions: Specification Required
>>>>      * Log ID 1, Log ID 2: First Come First Served.
>>>>
>>>>      Feedback welcome, since, as far as I recall, this topic was not
>>>>      discussed on the list previously.
>>>>
>>>>      Eran
>>>>
>>>>
>>>>
>>>>
>>>>  _______________________________________________
>>>>  Trans mailing list
>>>>  Trans@ietf.org
>>>>  https://www.ietf.org/mailman/listinfo/trans
>>>>
>>>>
>>> --
>>> Rob Stradling
>>> Senior Research & Development Scientist
>>> COMODO - Creating Trust Online
>>> Office Tel: +44.(0)1274.730505
>>> Office Fax: +44.(0)1274.730909
>>> www.comodo.com
>>>
>>> COMODO CA Limited, Registered in England No. 04058690
>>> Registered Office:
>>>   3rd Floor, 26 Office Village, Exchange Quay,
>>>   Trafford Road, Salford, Manchester M5 3EQ
>>>
>>> This e-mail and any files transmitted with it are confidential and
>>> intended solely for the use of the individual or entity to whom they are
>>> addressed. If you have received this email in error please notify the
>>> sender by replying to the e-mail containing this attachment. Replies to
>>> this email may be monitored by COMODO for operational or business reasons.
>>> Whilst every endeavour is taken to ensure that e-mails are free from
>>> viruses, no liability can be accepted and the recipient is requested to use
>>> their own virus checking software.
>>>
>>> _______________________________________________
>>> Trans mailing list
>>> Trans@ietf.org
>>> https://www.ietf.org/mailman/listinfo/trans
>>>
>>>
>>>
>