Hello, We recently noticed that EncryptContent does not work properly with ECC keys. It appears to be due to how keys matching user IDs are selected. Since user IDs are usually only attached to the master key and not to any subkeys, EncryptContent is always selecting the master key. Usually, master keys are marked as signing keys and not encryption keys.
For RSA keys, while selecting a signing key isn't ideal since a subkey marked as a signing key shouldn't be used for encryption, it still works since RSA can be used for both signing and encrypting. For ECC, this doesn't work since the signing key is ECDSA which can't be used for encryption. The encryption subkey is an ECDH key, but it isn't usually the master key and therefore it doesn't have a user ID associated with it, so EncryptContent won't select it. When trying to use an ECC key, EncryptContent throws the error "Can't use ECDSA for encryption" since it selected the ECDSA master key (which is marked as a signing key) even though there is also an ECDH encryption subkey in the key. While reviewing EncryptContent's code, I also noticed that EncryptContent does not check key revocation, expiration, or ensure that the key is marked for encryption. I have created fixes for all of the above, but wanted to see how I should proceed since it risks breaking existing flows if they depend on the incorrect key selection or using expired keys. Options I can think of are: 1) Potentially break existing flows that depend on bad key selection. Do this by forcing key selection to only return the first non-expired, non-revoked subkey that is marked for encryption. One could argue that this is the proper way to do it since expired, revoked, or signing keys shouldn't be used for encryption. 2) Allow compatibility with existing flows that depend on bad key selection by creating a new property for EncryptContent called "Enforce strict key handling" that defaults to "false". Use this to determine if expired or revoked keys are allowed to proceed. Still enforce selecting only subkeys that are marked for encryption. 3) Same as #2, but only check if the key is marked as an encryption key for ECC keys. Allow RSA to continue to use signing keys for encryption. This would allow full compatibility with old RSA flows but would allow ECC keys to be used as well. Also, would it be better to separate these into two JIRAs? One to fix key selection so that the first subkey marked for encryption that matches the user ID is selected (bug) and one to add expiration and revocation checks (improvement or maybe also a bug)? Or do them all as one fix? Thanks, Paul
