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

[Rob Stradling <[e-mail]>]

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