On 28/09/15 20:32, Stephen Kent wrote: > Rob, > > >> 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. > I agree that one can design smaller IDs, but they lack the nice security > property > that comes from using the public key (or a hash thereof?). >> >>> 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. > I appreciate the desire to avoid unnecessary bloat, but if that causes > us to have > to rely on procedural security measures instead of algorithmic ones, I'm > not > convinced that the tradeoff is a good one.
Procedural security measures? I don't see how any security measure is needed. The only purpose of the LogID field is, AFAICT, to give clients a hint about which log public key should be used to verify an SCT. We could ditch the LogID field if we thought clients would be prepared to loop through all known log public keys until verification succeeds or all keys have been tried. >>> 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. > > Again, I agree that one could manage OIDs for this separate from existing > systems, but that just means that some new party is responsible. Why not > make use of existing OID management entities? I proposed using OIDs from any OID arcs because I think making use of existing management entities would be overkill for allocating LogIDs. (If we had to involve IANA in allocating LogIDs, then I would not propose to use OIDs at all. Instead, I would propose "uint32 LogID", with unique integers allocated from a new dedicated IANA registry). -- Rob Stradling Senior Research & Development Scientist COMODO - Creating Trust Online _______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
