On 10/09/15 18:19, Stephen Kent wrote: > Folks, Hi Steve.
> 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. But ISTM that 32 bytes (assuming SHA-256) is an unnecessarily bloaty scheme for uniquely identifying each log. > The former appears to be attractive only because one > could structure the OIDs to indicates that successive log instances are > related. I agree that you could structure the OIDs to indicate relationships between logs, but that's not what this ticket proposes. This ticket is about reducing unnecessary bloat. > 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. Any OID will do, as long as no two logs share the same OID. Personally I don't think this needs to be managed by IETF or ITU. > 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). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
