[Autocrypt] live discussion about historical keys tomorrow -- 2017-12-12 17:00 UTC https://meet.jit.si/Autocrypt267
holger at merlinux.eu
Wed Dec 13 14:47:42 EST 2017
On Wed, Dec 13, 2017 at 14:21 +0100, Björn Petersen wrote:
> On 13.12.2017 at 08:25, holger wrote:
> > Thanks for going through the discussion!
> > one inline comment ...
> > On Tue, Dec 12, 2017 at 17:12 -0500, Daniel Kahn Gillmor wrote:
> >> [...]
> >> 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.
> > Does this mean that we could have a 1.1 version of the spec which
> > specifies how to deal with secret keys that come after the first one.
> > 1.1 clients would then not break 1.0 ones, right?
OK, actually i think the meaning of the text before PR275 was not
really different from the one introduced by PR275.
> > However, strictly speaking, wouldn't a MUA that processes multiple
> > keys before such a 1.1 spec, break Level 1.0 compliance?
> Yes - esp. as it's not even clear _what_ will follow the first key -
> just another key, a delimiter, other options, whatever. We only say,
> whatever there is - ignore it.
ok, i am not sure how helpful this is in practise. If MUAs
start experimenting with adding "historic" keys then chances
are they will be doing this differently from one another.
I was hoping we would simply say that historic keys should come
after the first secret key blob (which consists of primary&subkey)
but don't otherwise model the historic state for MUAs in 1.0.
This would increase chances of having two MUAs have a compatible way to
exchange what they consider as historic keys -- however they determine
or store it. I think the ambiguity this could introduce is not that
bad compared to the unclarity now how to transfer multiple secret keys.
Anyway, let's see how it plays out in 2018 ...
To not further block L1 i removed the "level 1 functionality freeze"
milestone from #267.
More information about the Autocrypt