[messaging] key validation rules for today

[Daniel Thomas]

On 08/09/14 14:38, Daniel Kahn Gillmor wrote:
> On 09/08/2014 06:22 AM, Daniel Thomas wrote:
>> I think for key validation it is important to ensure that it says 'keys'
>> in all the appropriate places as in general users will likely have one
>> key per device (so that they fail independently) and several devices.
>> Does that seem sensible? 
> 
> With OpenPGP, you'd want to do this with subkeys -- so they're all part
> of the same OpenPGP certificate.

But then there is one primary key the failure of which breaks the lot? I
also wouldn't know how to go about doing that an while I could probably
work it out, I wouldn't want to have to teach my users how to do it, it
is hard enough already.

> However, it's only sensible for
> signing keys.  for encryption keys, you really do need to share the key
> across all of your devices.

But then you have to transmit private key material between various
systems which is finicky and hard to get right[0]. I much prefer systems
built by transmitting only public information and never moving private
information off the host it was generated on (modulo backups).

> This is because when someone encrypts a
> message to you, they need to know which key to encrypt to (and they'll
> generally only pick one).

I think this is the problem. They should encrypt to all valid ones.

>> The interaction between that and key transition is subtle. 
> 
> A subkey key transition is easy -- you add a new subkey, revoke the old
> one, and publish the updated certificate to the keyservers.
> Transitioning primary keys is more nuanced.
> 
>> Is it useful to distinguish between 'this is a new key,
>> signed by my old key which is now deprecated' and 'this is a new key,
>> signed by my old key which will keep on being used'?
> 
> The current way (in OpenPGP, when considering key transitions between
> primary keys) to distinguish between these cases is to revoke the old
> key.  There is even space in the key revocation packet to contain an
> arbitrary message, in which you could put "superseded by key
> 0xDEADBEEFDEADBEEFDEADBEEFDEADBEEFDEADBEEF".  I don't think there's a
> way (or that there should be a way) to indicate from the new primary key
> itself that the old primary key should be deprecated.

Yes but that is a human readable arbitrary message which is mostly
useless as users are not going to spend time reading such things, it
would have to be machine readable if the client is to do the right thing.

Daniel

[0]: And in my experience liable to land you in some outer darkness with
no implemented way of doing what you need to do because gpg's authors
(reasonably) don't trust you to get it right. Obviously in this case it
must work because you know gpg et. al. far better than me.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://moderncrypto.org/mail-archive/messaging/attachments/20140908/f4d1538c/attachment.sig>