Allow the user to configure a strategy for encryption subkey selection
Categories
(MailNews Core :: Security: OpenPGP, enhancement)
Tracking
(Not tracked)
People
(Reporter: KaiE, Unassigned)
References
Details
Initially, TB 78 used the first encryption subkey it found, regardless of other properties.
In bug 1665281 we'll change it to select the newest encryption subkey for compatibility reason.
Neal suggest that we should always encrypt to all good encryption subkeys, and Nickolay thinks we should make it configurable. Both these options would require additional changes, so let's keep this as an enhancement request for now, and decide later what to do.
You say "for compatibility reason", but as I lay out in my email on this subject, there are several different approaches in practice.
As I describe in that mail, Sequoia would encrypt to all encryption keys intended for protecting data in transit, and I still think this is the best option.
I don't think it should be configurable at the TB level. TB should choose a reasonable policy.
The relevant content of the email:
Unfortunately, RFC 4880 doesn't provide any guidance on what
implementations should do when an OpenPGP certificate includes
multiple encryption-capable subkeys. As you have observed, this has
led to divergent behavior.
rnp uses the first encryption-capable subkey that it finds:
https://github.com/rnpgp/rnp/blob/6a5fb890eb30a59f7aa46b3e915a236d4bbe4176/src/lib/pgp-key.cpp#L1876
As far as I know, rnp doesn't sort the packets in the OpenPGP
Certificate in anyway. So what is first depends on how the
certificate is received. On the one hand, this means that you can try
and influence the behavior by reordering the packets so that the
strong key is first (use gpgsplit and then recombine the key). On
the other hand, this means that an attacker can do the same thing and
ensure that the weakest key is first.
GnuPG uses the "best" encryption-capable subkeys:
I'll let the comment there speak for itself:
/* Set LATEST_KEY to the latest (the one with the most recent
- timestamp) good (valid, not revoked, not expired, etc.) subkey.
- Don't bother if we are only looking for a primary key or we need
- an exact match and the exact match is not a subkey. */
Open Keychain encrypts to all encryption-capable subkeys. A
Sequoia-using application will normally do the same thing, but Sequoia
is a bit more nuanced than the other OpenPGP implementations that I
know about: the application needs to choose between those keys that
are for protecting data in transit and those that are for protecting
data at rest (or both).
https://tools.ietf.org/html/rfc4880#section-5.2.3.21
AIUI, GnuPG doesn't encrypt to all subkeys, because of the history of
the ADK extension:
https://www.rossde.com/PGP/pgp-adk.html
Basically, using ADK, a company could include a special subkey in all
of its employees keys, which the company controls, and therefore
allows them to read all of their employees' mail. That extension was
not included in 4880, but encrypting to all encryption-capable subkeys
is the moral equivalent.
There are good operational reasons to allow a company to read their
employees' email. For instance, employees are sometimes
unreachable---they are on vacation, are sick, or have left the
company---and they have the only copy of some important document.
Also, today, most big companies force employees to use their own CA.
This would allow them to silently do a MitM attack, and decrypt
everything. Given this policy, it's not clear to me that not
encrypting to all subkeys will stop this. Instead, it will just
ensure that companies don't use OpenPGP.
That said, there are good reasons to encrypt to all encryption-capable
subkeys. The most important one is that it facilitates multi-device
support. Say you have a TPM on your desktop computer and use it to
generate an OpenPGP key. Because you can't extract the key, you can't
transfer it to your phone. But if OpenPGP implementations encrypted
to all encryption-capable subkeys, then both the desktop and the phone
could use a key generated and stored in their own TPMs, and both could
encrypt all messages.
|
Reporter | |
Comment 3•5 years ago
|
||
(In reply to neal from comment #1)
You say "for compatibility reason", but as I lay out in my email on this subject, there are several different approaches in practice.
For compatibility with GnuPG, which users have complained about in bug 1665281. I don't see a problem with using the same "use newest subkey" as the immediate hotfix, and it was the easiest to do.
As I describe in that mail, Sequoia would encrypt to all encryption keys intended for protecting data in transit, and I still think this is the best option.
Do you define "in transit" as key flag 0x04 ?
I don't think it should be configurable at the TB level. TB should choose a reasonable policy.
That might be fine. Let's see if other opinions and arguments will be raised in this bug.
For compatibility with GnuPG, which users have complained about in bug 1665281. I don't see a problem with using the same "use newest subkey" as the immediate hotfix, and it was the easiest to do.
If this doesn't preclude discussion, then I agree.
Do you define "in transit" as key flag 0x04 ?
Yes.
Description
•