[Autocrypt] live discussion about historical keys tomorrow -- 2017-12-12 17:00 UTC https://meet.jit.si/Autocrypt267
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Dec 12 17:12:01 EST 2017
On Mon 2017-12-11 15:33:40 -0500, Daniel Kahn Gillmor wrote:
> Please join us if you're interested! I'll try to make sure that a
> summary of the discussion makes it into the ticket.
After a bit of delay, Vincent, Bjoern, and i had a good discussion about
several issues related to multiple secret keys, and came up with the
following minimalist approach for level 1:
0) we will not say anything specific about what to do with multiple
secret keys for a given account in level 1. there's a lot of
potential complexity there, and we don't think level 1 clients need
to engage with it if they don't want to.
1) we will leave space in the Autocrypt setup message for shipping
(arbitrary) additional optional information, while avoiding too much
additional complexity in the setup message spec. Level 1 clients
will ignore that information, but at least there's still room for
experimentation. This is encapsulated in the minimalist PR
https://github.com/autocrypt/autocrypt/pull/275 which makes clear
that additional information after the *first* openpgp-armored blob
in the cleartext of the encrypted payload will be ignored by level 1
clients.
2) when discussing the autocrypt setup message (ASM), we realized that
muas are likely to encounter things that look a lot like an ASM, but
don't match exactly (e.g. future version 2 ASM). We realized that
the spec needs some guidance on what to do with non-matching ASM
messages, because if there is standard guidance widely adopted, then
future clients will know how their updated non-matching ASMs are
likely to be handled by older deployed clients. This doesn't need a
lot of text:
https://github.com/autocrypt/autocrypt/issues/276
3) We noticed that implementors are going to need to deal with the
case where they find an ASM for an account that they *already* have
a secret key for. we should have stable, simple guidance for this.
Vincent and i seemed to reach agreement that for Level 1, where we
have mandated that there must always be human interaction on
importing an ASM, a MUA can just explain to the user that this will
override their existing Autocrypt setup. So we leave the process
up to the human user to decide which direction to publish the ASM,
and whether to to accept it or not. But still, it needs a bit of
documentation:
https://github.com/autocrypt/autocrypt/issues/277
So we've opened two tickets while providing a PR that should close one
-- progress? :P Any PRs that provide text to close 276 or 277 would be
welcome.
We're really close, let's push it across the finish line!
--dkg
More information about the Autocrypt
mailing list