The standard, as it stands right now, says nothing about dealing with
multiple encryption subkeys. I think, this is something that affects
interoperability and thus merits a few sentences in the standard.
GPG assumes that the one with the latest valid subkey binding signature is
the one that should be used when encrypting to the given primary key. I
think, this is wrong, because it makes multiple subkeys useless and
confusing, while there would be better and more useful ways of interpreting
multiple encryption subkeys.
IMHO, the best way would be to encrypt with ALL the valid subkeys, because
it allows for havind different decryption subkeys on different machines
(just like with signature subkeys) that can be revoked/expired separately.
Also, it would make it possible to create encrypted mailing lists with
minimum effort: the list administrator has access to the main key of the
mailing list and can add/revoke the encryption subkeys of the subscribers as
they sign up and off. Those who wish to post to the list will only need to
encrypt with to the list key, which is what their client will do
automagically, if they turn encryption on. It is the users' responsibility
to refresh the list key frequently, though the list itself is a good medium
for distributing updates to the key as they happen.
Just my €0.02 ...
Cheers,
--
Daniel
signature.asc
Description: Digital signature