Re: [Trans] overview of remaining(?) DISCUSS items for draft-ietf-trans-rfc6962-bis-33

[Paul Wouters <[e-mail]>]

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