Closed koto closed 9 years ago
From koto@google.com on September 04, 2014 04:05:37
I implemented the change. The keys to encrypt/sign will prefer keys with a certified usage. Any key capable of encryption/signing (based on cipher used) will be chosen as a fallback only.
Status: FixedInStaging
Owner: koto@google.com
From adhintz@google.com on September 04, 2014 10:29:14
Status: Fixed
From koto@google.com on September 02, 2014 17:01:03
When we choose keys to sign/encrypt in TransferableKey.getKeyTo, we ignore key preferences stored in flags in key signatures. Instead, we only consider if the key algorithm can sign/encrypt. Additionally we prefer main keys for signing and subkeys for encryption.
That may lead to encrypting to different keys that the key owner intends to.
For example, the key from https://code.google.com/p/end-to-end/issues/detail?id=60 has a main (signing) key and a revoked encryption subkey, which is removed during import:
pub 2048R/267CDC0E created: 2014-06-08 expires: never usage: SC
trust: unknown validity: unknown
This key was revoked on 2014-06-08 by RSA key 267CDC0E revoked revoked@revoked.net
sub 2048R/CFD3C86E created: 2014-06-08 revoked: 2014-06-08 usage: E
unknown. revoked revoked@revoked.net
When this key is used in the extension, all encryption happens to users' main key, because RSA is both a Signer and a Cipher.
Original issue: http://code.google.com/p/end-to-end/issues/detail?id=143