I cleared my DISCUSS. Thanks! Alissa > On Sep 19, 2019, at 12:19 PM, Paul Wouters <[email protected]> wrote: > > On Thu, 19 Sep 2019, Rob Stradling wrote: > >> 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 > > Alissa, is the resolution okay with you? I thought you might also wanted > text in the paragraph itself, and not just in the table, but perhaps > this is all you wnated? > >>> = 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 > > Okay that seems clear to me now. Hopefully to Alissa as well. Alissa, > can you clear your DISCUSS if all your concerns are addressed? > >>> 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. > > So this seems to contradict itself. You give a good reason why a base > url might change, then suggest to say MUST NOT. And you cannot add a > new entry with updated base url using the same OID I guess? So one would > have to replay the existing log into a new one. If that becomes a common > practise, how is this distinguishable from a log reply that removes an > entry and urges everyone to (automatically or not) update to the new > base url ? > >> 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. > > Okay. Hopefully this can be done very soon so we can re-issue a WGLC and > then have this done before IETF 106. > > Paul
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
