On Thu, Jul 29, 2021 at 6:06 PM Salz, Rich <[email protected]> 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 >
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
