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

Eran Messeri <eranm@google.com> Tue, 13 December 2016 14:33 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 322811299DF for <trans@ietfa.amsl.com>; Tue, 13 Dec 2016 06:33:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.596
X-Spam-Level:
X-Spam-Status: No, score=-5.596 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, 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 KIKkk7DWHZ8Q for <trans@ietfa.amsl.com>; Tue, 13 Dec 2016 06:33:49 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::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 CE79F12998C for <trans@ietf.org>; Tue, 13 Dec 2016 06:32:36 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id g23so111861750wme.1 for <trans@ietf.org>; Tue, 13 Dec 2016 06:32:36 -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=Ow3989s/d3yqjCWIXGAfgXP24865X6Ojqy3HIdbJCTo=; b=OOpO0p+MpusF++sBMAEb8YkPiVkCZyvq5PiKL/SpAb8jPFO0E4vgiwCPJElzag1tWY Zo4M5VkkylRbd70IZErdgFblQzg1DtCVHP0sBucEvwwF/kU4keROATFA8V0GND2I2QTh YiG1g+IEE4eGa6G1Z/G6nm0VLedfJN6l1wgC0eCSHQ9gEROKHipYlSIgb/iFdf+u/WhS v/UBZbyZ2JC4opYOBld2P8A7p7pdMGAQPm9Kdso79Arl6hSAI4Gw3JNpemEAXA7+vD7p w79VfXkYaKHMxemMRGFpwAYe43k9IzhoCQXzg3tP7cJ653yhnIUYo3TOhWR+R+1LUalj /EKQ==
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=Ow3989s/d3yqjCWIXGAfgXP24865X6Ojqy3HIdbJCTo=; b=mrdbFlI6a7u0FohGhYqHnlnhaN2ITVrK48Xm1y9ru0bey6+5a0a29dJCD+JR1YWjBZ TVDtC0sNHT2C2POJagjYFitVblrcJx0HFb0fwDnqeWcYdYleSIOyBCo3u9+4Dd8z8nbF Nk4dxPkNxZF6ou6MAgzbW+UzZx1e9q/+NdO9lZ9ZsVFqoqQkKsXaR+xvJE9DdZ4Qv3Pz /eQ6HO3r91TGKSAOP5Q0g0v6QEX2DESB/4SEFfSMUH+L76aBoyOz60KyEp2J1u2UNLmq YgRrmRzsRYz+GBK2iS2D5nqiXohP7VH3w8WFeU5uioKHbl9ItRgnHqGYQjikUGCeZkK9 2Aag==
X-Gm-Message-State: AKaTC01nuPiK0k7IgQSUeF5DVvLEpqPixwqXf9K30rzezBPr2xwgkwGJXvkgsXffBdIZ+wUEc/oV8yeMsM2qyM5s
X-Received: by 10.28.96.4 with SMTP id u4mr3157368wmb.86.1481639555137; Tue, 13 Dec 2016 06:32:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.28.31.21 with HTTP; Tue, 13 Dec 2016 06:32:04 -0800 (PST)
In-Reply-To: <alpine.LRH.2.20.1612122034310.31017@bofh.nohats.ca>
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>
From: Eran Messeri <eranm@google.com>
Date: Tue, 13 Dec 2016 14:32:04 +0000
Message-ID: <CALzYgEdBHz5XaqXzPH5rThoJYkrfmViGOCG8soechR1HE9SJfA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Content-Type: multipart/alternative; boundary="001a1148e9985ec54105438b176c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/trans/eoIcfgxMByCFGhRqk6k1pWAtyqs>
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 14:33:52 -0000

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
>>
>>
>>