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 <[email protected]
<mailto:[email protected]>> 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
[email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/trans
