On Wed, Apr 1, 2015 at 4:04 PM, Daniel Kahn Gillmor
<dkg(_at_)fifthhorseman(_dot_)net> wrote:
On Wed 2015-04-01 14:56:16 -0400, Phillip Hallam-Baker wrote:
The property we want to get from enrolling the endorsement in a log is
to fix it in time. So we enroll the hash in the log rather than the
endorsement itself.
It sounds to me like what you're aiming for with the log to make a
first-come, first-served arrangement, maybe as a way to distinguish the
"correct" original key from some latecomer spoof that tries to usurp it.
Is that correct? (this is quite different from the goals of CT, as far
as i understand it)
If FCFS is your goal, how does a user of this scheme considering
multiple keys for e-mail address alice(_at_)example(_dot_)com distinguish the
inevitable legitimate transitions from the would-be usurper?
Some examples of legitimate transitions:
* Alice loses her personal root key due to fire/theft/flood/whatever
* Example Corp. closes down, the example.com domain name goes up for
sale, and the new owner is a different Alice.
(this is getting pretty far afield of openpgp at this point, i think, so
i'm happy to take this discusion someplace else (therightkey?) if you
prefer).
Yeah we could go to RightKey.
But I am not arguing for first com first served. I am arguing that the
age of an endorsement is significant. An attacker can easily set up an
endorsement cartel with 100 people signing each other's keys. But they
can't backdate the endorsements to ten years before they decided they
needed them.
_______________________________________________
openpgp mailing list
openpgp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/openpgp