[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