On Feb 11, 2015 11:01 AM, "Natanael" <[email protected]> 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.
_______________________________________________ Messaging mailing list [email protected] https://moderncrypto.org/mailman/listinfo/messaging
