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

[Natanael]

Den 11 feb 2015 07:37 skrev "Trevor Perrin" <trevp at trevp.net>:
>
> On Mon, Feb 9, 2015 at 5:13 PM, elijah <elijah at riseup.net> wrote:
> >
> > (3) We need common practices for "verified key transitions".
>
> Do you mean this:
>  - When you replace your long-term key, the old key signs the new (and
> maybe vice versa)?
>  - When someone presents their new key with correct signatures, you
> silently replace the old one in your local trust store (no key change
> warning)
>
> I wonder how useful that is.  Consider the reasons for key replacement:
>
> 1) You lost your old key
> 2) You're proactively replacing your old key
> 3) Your old key was compromised
>
> This doesn't help (1).
>
> It avoids the warning in (2), but adds complexity - a public key no
> longer matches one fingerprint, now it can be verified by any
> fingerprint that chains to it.  So your protocols have to deal with
> these chains, and users will encounter situations where they had one
> fingerprint for Alice before talking to her, and a different one
> after.
>
> (3) arguably becomes worse, because someone who steals your private
> key can silently replace the public key your correspondents have for
> you, just by messaging them.
>
> I'm not sure this is a net positive.

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), messaging policy
(always sign mail to me, encrypt with PFS if sensitive; I always sign mails
I send), updates must follow rules ABC (this can also even ban certain
future configurations, you can say "I will NEVER send unsigned email),
updates are available via sources 1, 2 and 3 (append-only, signed and using
hash chains like git and Bitcoin blocks do), etc...

But you won't need to store the full multi-megabyte raw blob of all data,
as all the fields could be separately hashed in a Merkle tree hash (or
patricia tree? Supposedly you can prove if entries are lacking or not with
them, IIRC), and a regular hash of that tree hash would be the identifier.

Not sure if a signature always should be appended or not, thoughts? Should
it still be self-signed if the hash is how you always identify it? Maybe it
is sufficient with having one of the entries in the tree hash be a
signature of the other entries that are considered mandatory to include. Or
you have two levels of tree hashes, one which is signed and which is based
on the raw data as well as another tree hash that includes all the raw data
plus the previous tree hash plus the signature. But that doesn't seem
strictly necessary for avoiding tampering if you're always careful with
verifying the hash.

With an interconnected network that propagate all public identity
declaration hashes (like a mix of PGP keyservers and DHT) and that tracks
who to ask to get the details for each key, lookups using the hash could be
fast and reliable as long as you have an Internet connection.

A scheme like certificate transparency or a blockchain like Namecoin could
be used to make sure there's no conflicting sets of appended entries or
changes that has been published, as well as for key lookups.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20150211/49eb8600/attachment.html>