On 18/09/2019 20:07, Paul Wouters wrote: > On Wed, 18 Sep 2019, Rob Stradling wrote: > >> No comments received after a week, so I'm going to merge PR 312 now and >> publish -33. > > Looking at the DISCUSS items, I see some minor items that seems to > require some small edits. Can the authors answers these DISCUSS > questions cited below and let us know if they will do another revision > or whether they consider all DISCUSS items below resolved? > > Paul
Hi Paul. > Alissa Cooper: > > = Section 10.3 = > > This section needs to state what the registry policy is for the code > points not already registered (presumably Expert Review given 10.3.1, > but it needs to be explicit). This was addressed by PR 309, in this commit: https://github.com/robstradling/certificate-transparency-rfcs/commit/7cd3471548c903fd891a99227bf081ca51939470 > = Section 10.6.1 = > > FCFS registries by definition can require additional information to be > provided in order to get something registered. For avoidance of > confusion I think the assignment policy should be listed as First Come > First Served and the requirement that parameters be included in the > application can use a normative MUST in the last paragraph if there is > concern that the parameters won't be supplied. > > However, I also wonder what will be done with the parameters that are > supplied. Is IANA expected to just maintain them privately, or to > publish them? > > What is expected to appear in the 'Log' column in the registry? This was addressed by PR 309, in this commit: https://github.com/robstradling/certificate-transparency-rfcs/commit/704a71a18457b4558ce26fe4be519d6ea06a729a > And let me add my own question regarding 10.6.1. Should we expect these > registry entries can change over time? If so, is it definied anywhere what > consumers are supposed to do or how they are supposed to find out, that a > log base url has changed? Shouldn't such a change be done using a new OID? Since the OID (the Log ID) appears in each of the signed log artifacts (SCTs, STHs), I think trying to change the OID of an existing log would be pretty disastrous. However, I agree that there could be legitimate reasons for wanting to change a log's base URL. For example, in the currently deployed CT v1 ecosystem, it would be really nice if Sectigo could update the base URLs of our Mammoth and Sabre logs. ({mammoth,sabre}.ct.comodo.com made sense when we set up these logs, but then Sectigo (formerly Comodo CA) was carved out of Comodo). Having said that though, I think the best approach would be to add a sentence to the document that says that log base URLs MUST NOT change. Nice and simple. > Benjamin Kaduk: > > Sections 4.11 and 4.12 have arrays of NodeHash to carry consistency > and > inclusion proofs, respectively, with minimum array size of 1.. > However, > Sections 2.1.4.1 and 2.1.3.1 (respectively) seem to admit the > possibility of zero-length proofs in degenerate cases > > Mirja Kühlewind: > > There was a presentation at maprg IETF 103 about the question if CT > helps attackers to find new domains. I think this risk should at least > be mentioned in the security considerations section. > > To answer Mirja, the work to discuss these were going to appear in the > threat model draft. Unfortunately, this document got stuck due to > unworkable differences between the author and the WG. While I don't > object to adding a sentence covering your DISCUSS, I do not believe the > WG should try to cherry-pick content of the threat document at this > stage. So I think we should limit the Security Considerations to the > specific bis document specification, and not include issues that cover > the whole the CT ecosystem. > > Alexey Melnikov: > > I think you need to register [log client message type URN] in > <https://www.iana.org/assignments/params/params.xhtml#params-1> > > Also, can you clarify whether error need an IANA registry? We have not yet made any attempt to respond to the DISCUSS/COMMENT items from Benjamin Kaduk, Mirja Kühlewind, and Alexey Melnikov. Now that the lengthy debate about BCP190 is over, I do intend to look at these remaining items soon. I will be looking for help to address Benjamin's COMMENTs on section 2; I am not a cryptographer, and I want to ensure that these comments are satisfactorily addressed. -- Rob Stradling Senior Research & Development Scientist Sectigo Limited _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
