Rob,
Thus re-use of an old key by that log operator, for a new log instance,
wouldbe detected easily if the log ID were derived from the public key.
That seems like a non sequitur to me.
Since a monitor has a copy of every log's public key,
a Monitor has a copy of every public key for every log that _it
watches_, and perhaps
only since it began watching the log.
it can compare these public keys to ensure that each one is used by
only 1 log.
only for the logs it watches.
Or, since it knows each public_key, the monitor could calculate
HASH(public_key) all by itself and then check the uniqueness of each.
It makes no difference whether LogID is defined as HASH(public_key),
an OID, or something else.
I expect that the most common way that a "new" log would fail to switch
to a new
key pair is by reusing the same pair it had been using most recently,
i.e., an error, not
a malicious action. if so then using a key hash as an ID should make it
very obvious
when this sort of error occurs.
Anyway, I don't think we need to continue to debate this. If you and other
developers are happy with the OID approach, so be it.
Steve
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
