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.
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?
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
