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