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

[Eran Messeri <[e-mail]>]

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

Eran

On Mon, Dec 12, 2016 at 3:44 PM, Eran Messeri <[e-mail]> 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 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
>