[messaging] Verified key transitions (was: TOFU to ease PGP key discovery)

[Joseph Bonneau]

On Feb 11, 2015 11:01 AM, "Natanael" <natanael.l at gmail.com> wrote:

> What I want is identity declarations like more advanced PGP keys.
>
> They would be static (append-only mechanism for updates), identified by
> the hash. And the main difference is that they would have room for new ways
> fields like key succession policies (requiring a chosen third party to
> agree?), revocation policy (if 3 of 5 of entities out of the group XYZ
> signs the revocation, it is valid even without a signature from my own key
> - allows you to show up in person with an ID card to get your key revoked
> if you lose your computer and all backups of the key),
>
We had a few thoughts along these lines in our initial writeup of CONIKS (
http://eprint.iacr.org/2014/1004.pdf) although we only described only two
key succession policies: anything my service provider signs is a valid
transition (default) and anything my master key signs is valid (paranoid,
requires storing this as a backup key indefinitely). There's definitely
room for more types of policies and I think it's a good point to think
about different policies and a language for expressing them.

I expect though that the default policy 90-99% of users want is "I just
want to be able to go to my mail provider via password login/reset
questions/phone call/SMS reset code and change keys." Backup authentication
for big web services is still a complicated and proprietary mess. There's
been some effort to nag users into configuring a backup policy in advance
but it hasn't gone that far. I don't believe the bulk of users will accept
something more complicated for key backup.

I still think there's value in designing protocols to support more
complicated use though even if that use is rare-we want the most tech-savvy
users and the least to be on the same platform.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150211/a4b42748/attachment.html>