Folks,
I'm puzzled by the decision to use OIDs here, instead of a public key hash.
The latter seems to offer nice security properties and doesn't have to
rely on a log operator to follow a requirement to change public keys for
each log instance. The former appears to be attractive only because one
could structure the OIDs to indicates that successive log instances are
related.
But, if one uses OIDs that are not part of an allocation that is not managed
by an org like the IETF or ITU, then the assurances that the OID structure
follows the suggested approach are vague.
Steve
#105: Shrink LogID
Comment (by [email protected]):
Replying to [comment:8 carl.mehner@…]:
> Hi Adam, it really depends on the OID that the log operator is able to
allocate for their log. The smallest would be around 3 bytes without the
ASN.1 tag.
I'm optimistic that we'll be able to find an organization that owns a
1.3.<X> OID arc (where X<=127) and that will be willing to either:
1. delegate a single 1.3.<X>.<Y> subordinate arc (where Y<=127) so that
any log will be able to request a 1.3.<X>.<Y>.<Z> OID. (Without the ASN.1
tag and length, that would be 4 bytes for the first 128 logs, then 5 bytes
thereafter).
or
2. delegate a portion of the OID range 1.3.<X>.<0..16383>. (Without the
ASN.1 tag and length, that would be 4 bytes for many more than just the
first 128 logs, and maybe even 3 bytes for the first few logs).
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
