<div dir="ltr"><p dir="ltr">On Feb 11, 2015 11:01 AM, "Natanael" <<a href="mailto:natanael.l@gmail.com" target="_blank">natanael.l@gmail.com</a>> wrote:<br></p><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p dir="ltr">What I want is identity declarations like more advanced PGP keys. </p>
<p dir="ltr">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),</p></blockquote><div>We had a few thoughts along these lines in our initial writeup of CONIKS (<a href="http://eprint.iacr.org/2014/1004.pdf">http://eprint.iacr.org/2014/1004.pdf</a>) 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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div></div>
</div>