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
