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

On 12/12/16 15:54, Eran Messeri wrote:
> Some background as to why I propose each of the policies:
> * Expert Review for Hash algorithm and Signature algorithm: The
> algorithm selection does not affect the behaviour of the protocol.
> However, an expect should make sure proposed additions are suitable (for
> example, that a proposed hash algorithm does not suffer from known
> preimage attacks).

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

Separately, should we reserve some values in either or both of these 
registries for Private Use or for Experimental Use?

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

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

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