Support OpenPGP keys that use different passphrase for sub keys, and allow them to remain locked
Categories
(MailNews Core :: Security: OpenPGP, enhancement)
Tracking
(Not tracked)
People
(Reporter: mielket, Unassigned)
Details
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Steps to reproduce:
Tried to import certain keys for mailinglists, where I only have the passphrase for the decrypt key but not for the primary key. (Only the list owner is allowed to have it.)
Actual results:
When migrating using the Enigmail plugin, it just didn't work. Pressing the button simply had no effect.
When importing manually in Thunderbird 78.2.1, after entering the passphrase and pressing OK, the passphrase input dialog is simply shown again without further explanation what went wrong.
Expected results:
Depending on what I do (decryption or key management like extending the expiry date), the passphrase of the correct subkey of the resp. secret key needs to be accessed on demand. It should not be necessary to enter the the primary keys passphrase during import. Thunderbird should be able to handle secret OpenGPG keys even if the passphrases for subkeys differ from the passphrase of the primary key -- just like GPG did.
Btw.: Importing keys and storing them without a master password sould not be allowed -- at least give a warning and encourage the user to setup a master passort during migration, so the private keys won't be stored completely without protection.
|
||
Updated•4 years ago
|
|
||
Updated•4 years ago
|
|
|
||
Comment 1•4 years ago
|
||
Yes, we currently don't support this type of complex key.
|
|
||
Updated•4 years ago
|
Note: the subkey has been created using the option "--quick-addkey" (GnuPG >= 2.1.13 needed for this).
Ist there a chance that it is being supported in the near future? Or does our organization need to stick to TB68 indefinitely?
|
|
||
Comment 4•4 years ago
|
||
While it's unfortunate that we don't handle this scenario, at least the migration seems to happen gracefully.
I've created a standard key pair with one subkey.
Then I used gpg --edit-key to change the passphrase of primary and sub to separate values.
I've tested using 78.2.2 to migrate a keyring containing this secret key.
During the "export from gnupg" phase, at the prompt to enter the primary (which you said you don't have), I simply entered an incorrect value. After three wrong attempts, it prompted me for the passphrase of the subkey, which I entered. Then it prompted me to for the key ID of the subkey, and I entered it, which it accepted on first try.
After exporting was done, I was NOT prompted to enter any passphrase of the failing key. So the migrator probably detected that it failed to export that key, and didn't try to import it.
Finally, the summary told me that the secret key couldn't get imported.
While we don't support the key yet, the feedback we give seems to better as reported by Thomas.
|
|
||
Comment 5•4 years ago
|
||
I think supporting all scenarios here involves testing a lot of combinations.
(a) as reported, password for primary key is unknown. Thomas: Would you be able to use other software to delete the secret key that you don't have? After you delete the primary key, then it would be the same as scenario 1654893 right?
(b) password for subkey is unknown. Again, would it be reasonable to demand that external software is used to delete the secret key that cannot be imported, and only import the stripped key?
(c) Password for primary and subkey is different, but both are known to the user. This might be the easiest to support, because we'd simply have to prompt again, if the primary key password cannot be used to decrypt the subkey. But it's not clear how important this is. If both passwords are known to the user, and the user is willing to import both, then the user could use other software to change all passphrases to be the same, to make importing work with our current implementation.
I used gpgs --export-secret-subkeys option to separate the subkey from the primary key and tried to import it in TB 78.2.2. But it didn't make any difference. (I'm no OpenPGP expert, but I can't imagine that it's possible to frankenstein a subkey like this and everything works as before.) I also can't confirm the behavior that TB just proceeds with the subkey after three unsuccessful attempts. It just asks for the same keys passphrase indefinitely, giving no explanation why I need to enter the passphrase again.
Btw.: I noticed that contrary to 78.2.1 the 78.2.2 that updated itself on my backup computer did respond to button klicks during migration -- but that may be due to an Enigmail update that might have happend, too. Unfortunately TB 78 now seem to update automatically on other team members computers and we are beginning to lose access to our lists, which is our main means of communication and collective memory. This is a bit tragic.
i'm the person who generated the keys the reporter was mentioning. i'd like to emphasize that the keys in question do not neccessarily use different passwords for primary and subkeys. the real difference of these keys compared to ordinary default keypairs is that not all people using them have access to the primary key, but only to the secret ecryption subkey (in addition to the full public key).
as explained, we use these kinds of keys for internal mailing lists, therefore a secret key must be shared in orer for everyone to be able to decrypt messages. we have used full default keypairs for this in the past, but it turned out to be a bad idea: some used that key also for signing, some added their own mail address as an identity, and all were able to manipulate key expiration, add new subkeys or even revoke the key. none of this can happen when all you have is the secret encryption subkey.
to sum this up, thunderbird should be able to import secret subkeys while their primary key is absent. otherwise we can't use it in our organisation.
looking at the public key in conjunction with findings from bug #1665685, i would assume that features of the various subkeys may be what's causing trouble here.
the key in question has a primary key with just the PGP features S (sign) and C (certify), and a subkey with the feature E (encrypt). if thunderbird is ignoring the subkey or can't import it without the primary key, it is impossible to decrypt any messages.
Description
•