Rob,
...
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 thought I recall someone suggesting that the move to an OID (vs. key/hash)
would require that someone(?) check to make sure that a log operator didn't
re-use the same key with a new log instance. I'd call that a procedural
secruity
measure.
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.
The issue I was citing is different from what you note above, i.e., the
possibility that a log operator changes the ID but not the key.
...
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).
that strikes me as a reasonable compromise.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
