Re: [Trans] Martin Duke's No Objection on draft-ietf-trans-rfc6962-bis-39: (with COMMENT)

[Martin Duke <[e-mail]>]

So returning to my previous point, it seems rather heavyweight to update
the IANA registry every time this happens, and it would arguably be
efficient to assign a given operator a range so that these need not be
deconflicted in perpetuity?

On Thu, Jul 29, 2021 at 2:36 PM Ryan Sleevi <[e-mail]> wrote:

>
> On Thu, Jul 29, 2021 at 5:15 PM Salz, Rich <[e-mail]> wrote:
>
>>
>>    - I'm not sure this is correct, Rich? Logs regularly rotate IDs;
>>    presently annually, but it's reasonable to anticipate more frequently as
>>    the size/performance tradeoffs, precisely as the way of pruning the storage.
>>
>>
>>
>> Thanks for the correction!
>>
>>
>>
>> So how do replying parties know the log ID changed?
>>
>
> To be clear, the log ID doesn't change (and refer to the same log). Each
> Log ID uniquely identifies a log. For example, if a log changes a key, it's
> functionally a new log - this is true in 6962 as it is in 6962-bis. The
> only thing that changed in -bis is from identifying logs by key hashes to
> identifying by OIDs, which was meant to make for smaller encoding.
>
> The draft flags that the communication of LogIDs is fundamentally
> something that is done out-of-band -
> https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-40.html#name-log-id
> - i.e. up to client policy. For example, for two widespread 6962
> implementations (Apple's {mac, i, tv}OS and Google's Chrome), the list of
> recognized logs is governed by user agent/vendor policy, and those logs are
> communicated by the vendor (aka "Trusted Log Lists", although trust is a
> bit of a stretch)
>
>
>> And do we need to give Log’s not an ID but rather an arc?
>>
>
> No. As with 6962, the idea here is not that "This log was ID X, and is now
> ID Y" - but rather "I know of a log with ID X, and I now know of a log with
> ID Y, and these are logically distinct, even if their contents are
> identical"
>