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

[Ryan Sleevi <[e-mail]>]

On Thu, Jul 29, 2021 at 6:06 PM Salz, Rich <[e-mail]> wrote:

>
>
>    - 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?
>
>
>
> The registry is only for those organization that don’t have an OID arc of
> their own.
>

A correction here: The registry defined by CT for anyone - including those
who hold their own PEN.

That is,
https://www.ietf.org/archive/id/draft-ietf-trans-rfc6962-bis-40.html#name-log-ids-registry
exists as a size optimization.

CT today (6962) currently uses the SHA-256 hash of the log key - so takes
32 bytes.
Using Google's PEN as an example (since every new PEN will be longer),
Google's PEN is 1.3.6.1.4.1.11129, which takes 9 bytes. Plus the usual
byte-per-arc for organization.
Using the LogID registry, the first 8K logs (since it's FCFS, same as PEN)
can get away with just 4 bytes.
The next 128 can also get away with 4 bytes, while those remaining get
increasingly longer, starting at 5 bytes.

This saves a few bytes per SCT, which saves several bytes per certificate
(with embedded SCT). The IETF security areas have a history of allocating
short OIDs to allow for efficient encoding, e.g. through the donation of
organizations who, for historic purposes, have shorter OIDs than otherwise
obtainable today through PENs.

That's the case here: Thawte ( http://oid-info.com/get/1.3.101 ) - or more
aptly, DigiCert, who acquired Thawte by way of acquiring Symantec by way of
acquiring VeriSign... and so forth - has graciously donated the use of
their OID space to promote shorter encodings, effectively using a portion
of their namespace as "PENs, but for Log IDs". To ensure that's managed
without conflict, IANA is asked to manage it - the same as they manage
PENs. Unlike PENs, requesters only get a single OID for the Log - although
they can request many at once - since the whole point is "fewer arcs, more
efficient encoding"

Hopefully this explains a bit more the context?

You're absolutely right that no one has to use this, they can always use a
PEN if they want to not have to coordinate new logs with IANA action - but
the benefit of that small IANA overhead is a (relatively) substantial
savings in encoding overhead for the log ID, over the certificate hash.

Hopefully this captures for Martin the context as to why it's a valuable
thing, and how the IANA action is hopefully not too heavyweight for the log
operator.

That said, if the concern is IANA's management overhead, that's good to
make explicit. I think it's still likely that we'd see the same clever
scheme above, but if the current text needed to get pulled, I think it'd
just end up that the spec just says "use an OID", and DigiCert runs the
list and allocates OIDs themselves. However, if they decide that's too much
hassle, we may all lose out on the efficient encoding, so it'd be a shame.

I do agree with your PR, but in terms of expectations, I think we'll see
the majority of log operators explicitly preferring the Log ID approach
because of the efficient encoding

>