Encryption to key with multiple subkeys

[Joke de Buhr]

On Wednesday 12 May 2010 02:08:27 Daniel Kahn Gillmor wrote:
> yup, i think this is a good argument for your proposed behavior.  what i
> haven't seen yet (haven't thought through yet) is what the
> counter-arguments might be.

One possible argument against it could be the increased size of the encrypted 
message. But the size of an email isn't that important nowadays and if size 
matters the user should set a compression (bzip2) algorithm within the key 
settings.

> For example, consider the introduction of a new encryption-capable
> asymmetric algorithm X that has "better" properties than RSA (pretend
> for a moment that some flaw is found in RSA).  I might want to have an
> RSA encryption-capable subkey for all the deployed RSA-only
> implementations to use, since using RSA is better than nothing.  But i
> might want tools that *do* support X to use my encryption-capable X
> subkey, and not the RSA key.

The current implementation (always choose last) will use a RSA subkey if it's 
the last even if the user has a better NEW-subkey capable algorithm.

A gnupg commandline option like --realy-use-insecure-rsa could be added to new 
gnupg versions which support the NEW-subkey algorithm. Old gnupg versions 
would always use the old RSA subkey because they don't recognize NEW-subkeys.

New gnupg versions would always consider RSA keys as insecure and never choose 
them if there is a NEW-subkey present or the user forces gnupg by specifying
--realy-use-insecure-rsa.

> (the same argument can be made for old, small keys and newer larger
> keys, if the larger key sizes do not have wide adoption, i think)

Again the current implementation will use a smaller encryption subkeys if it's 
the last one.

If a user has 2048 encryption subkeys and newer 4096 encryption subkeys he can 
always revoke the 2048 encryption keys. This way a encrypt-to-all-capable-not-
revoked-encryption-subkeys setting wouldn't consider encrypting to these keys 
anymore. But someone could always encrypt to a revoked 2048 subkey by 
specifying that particular one.

If a user has low sized keys which are not revoked he knows someone could use 
them since they are not revoked. If it wasn't his attention gnupg will output 
that the message was encrypted to multiple subkeys if he's using the command 
line interface and gnupg starts to do encrypt-to-all-... .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 706 bytes
Desc: This is a digitally signed message part.
URL: </pipermail/attachments/20100512/8caa7320/attachment-0001.pgp>