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

[Rob Stradling <[e-mail]>]

On 19/09/2019 17:19, Paul Wouters wrote:
> On Thu, 19 Sep 2019, Rob Stradling wrote:
<snip>
>>> 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 ?

Hi Paul.  This was my thought process...

A mechanism for a log to change its base url might be "nice to have", 
but it would add complexity.  Adding complexity should be avoided unless 
it's "really necessary".  "nice to have" is not "really necessary", and 
besides, there is already a mechanism for achieving the same goal: 
retire the current log and spin up a new log.

The ecosystem needs to be agile enough to support regular log retirement 
and regular spinning up of new logs, so let's not (over)engineer an 
alternative mechanism that assumes the ecosystem lacks that agility.

-- 
Rob Stradling
Senior Research & Development Scientist
Sectigo Limited