Only one recipient shown in decryption feedback for files S/MIME encrypted for multiple recipients
Closed, InvalidPublic

Assigned To
None
Authored By
timegrid
Tue, Jul 7, 5:07 PM

Description

On decryption of a file S/MIME encrypted for multiple recipients in Kleopatra, the decryption feedback displays only one recipient.

Note: Using gpgsm directly seems to have additional issues, see gpgsm output below.

To reproduce:

  • S/MIME encrypt a file for multiple recipients (e.g. Ted and Edward)

  • Decrypt that file in Kleopatra => only Edward is listed

Logs

CLI gpgsm

  • on entry of passphrase for first cert (edward):
Z:\testdata\verification-feedback\8273-refactor-firstpart>gpgsm -vv --status-fd 2 --decrypt smime.encrypted-only.multiple.txt.p7m
gpgsm: enabled compatibility flags:
gpgsm: no running keyboxd - starting 'C:\\Program Files\\Gpg4win\\..\\GnuPG\\bin\\keyboxd.exe'
gpgsm: waiting for the keyboxd to come up ... (8s)
gpgsm: connection to the keyboxd established
gpgsm: recp 0 - issuer: 'CN=Root-CA 2020,OU=GnuPG.com,O=g10 Code GmbH,C=DE'
gpgsm: recp 0 - serial: 281B974B684B7934
[GNUPG:] ENC_TO C7FD4C0193216FA6 0 0
gpgsm: encrypted to brainpoolP256r1 key FF810B9281A43C394AA138E9C7FD4C0193216FA6
gpgsm: no running gpg-agent - starting 'C:\\Program Files\\Gpg4win\\..\\GnuPG\\bin\\gpg-agent.exe'
[GNUPG:] PROGRESS starting_agent ? 0 0
gpgsm: waiting for the agent to come up ... (8s)
gpgsm: connection to the agent established
gpgsm: AES256.CBC encrypted data
gpgsm: looking up issuer from the Dirmngr cache
gpgsm: no running dirmngr - starting 'C:\\Program Files\\Gpg4win\\..\\GnuPG\\bin\\dirmngr.exe'
[GNUPG:] PROGRESS starting_dirmngr ? 0 0
gpgsm: waiting for the dirmngr to come up ... (8s)
gpgsm: connection to the dirmngr established
gpgsm: number of matching certificates: 0
gpgsm: dirmngr cache-only key lookup failed: No data
gpgsm: issuer certificate {04A0A7E932B29D43A9B6673139AF52C0A5FC467BF5A64D044D1AC33613ABBB73CA532569F5779999114C0118CD66FDF6E92B1B0EEE2A4D5A815DA7FD892DDDE9C1} not found using authorityKeyIdentifier
gpgsm: looking up issuer from the Dirmngr cache
gpgsm: number of matching certificates: 0
gpgsm: dirmngr cache-only key lookup failed: No data
gpgsm: certificate is good
gpgsm: validation model used: shell
[GNUPG:] DECRYPTION_OKAY
12345
  • on entry of passphrase for second cert (ted; edward cancelled)
Z:\testdata\verification-feedback\8273-refactor-firstpart>gpgsm -vv --status-fd 2 --decrypt smime.encrypted-only.multiple.txt.p7m
gpgsm: enabled compatibility flags:
gpgsm: no running keyboxd - starting 'C:\\Program Files\\Gpg4win\\..\\GnuPG\\bin\\keyboxd.exe'
gpgsm: waiting for the keyboxd to come up ... (8s)
gpgsm: connection to the keyboxd established
gpgsm: recp 0 - issuer: 'CN=Root-CA 2020,OU=GnuPG.com,O=g10 Code GmbH,C=DE'
gpgsm: recp 0 - serial: 281B974B684B7934
[GNUPG:] ENC_TO C7FD4C0193216FA6 0 0
gpgsm: encrypted to brainpoolP256r1 key FF810B9281A43C394AA138E9C7FD4C0193216FA6
gpgsm: no running gpg-agent - starting 'C:\\Program Files\\Gpg4win\\..\\GnuPG\\bin\\gpg-agent.exe'
[GNUPG:] PROGRESS starting_agent ? 0 0
gpgsm: waiting for the agent to come up ... (8s)
gpgsm: connection to the agent established
gpgsm: error decrypting session key: Operation cancelled
gpgsm: decrypting session key failed: Operation cancelled
gpgsm: recp 1 - issuer: 'CN=Root-CA 2020,OU=GnuPG.com,O=g10 Code GmbH,C=DE'
gpgsm: recp 1 - serial: 4D9528785EE3E701
[GNUPG:] ENC_TO F7ED85B98C7DDFC5 0 0
gpgsm: encrypted to rsa3072 key 54DCF69AD0C25D777CB4B73EF7ED85B98C7DDFC5
gpgsm: AES256.CBC encrypted data
gpgsm: certificate is good
gpgsm: validation model used: shell
[GNUPG:] DECRYPTION_OKAY
12345[GNUPG:] FAILURE gpgsm-exit 50331649

That second case (first pinentry cancelled) has additional issues:

  • Note that FAILURE at the end of the second command
  • The first time this is executed (without background processes), dirmngr is not started. The second time it is (is this expected?):
Z:\issues\gpgsm-smime-multiple-recipients-list>gpgsm -vv --status-fd 2 --decrypt smime.encrypted-only.multiple.txt.p7m
gpgsm: enabled compatibility flags:
gpgsm: recp 0 - issuer: 'CN=Root-CA 2020,OU=GnuPG.com,O=g10 Code GmbH,C=DE'
gpgsm: recp 0 - serial: 281B974B684B7934
[GNUPG:] ENC_TO C7FD4C0193216FA6 0 0
gpgsm: encrypted to brainpoolP256r1 key FF810B9281A43C394AA138E9C7FD4C0193216FA6
gpgsm: AES256.CBC encrypted data
gpgsm: looking up issuer from the Dirmngr cache
gpgsm: no running dirmngr - starting 'C:\\Program Files\\Gpg4win\\..\\GnuPG\\bin\\dirmngr.exe'
[GNUPG:] PROGRESS starting_dirmngr ? 0 0
gpgsm: waiting for the dirmngr to come up ... (8s)
gpgsm: connection to the dirmngr established
gpgsm: number of matching certificates: 0
gpgsm: dirmngr cache-only key lookup failed: No data
gpgsm: issuer certificate {04A0A7E932B29D43A9B6673139AF52C0A5FC467BF5A64D044D1AC33613ABBB73CA532569F5779999114C0118CD66FDF6E92B1B0EEE2A4D5A815DA7FD892DDDE9C1} not found using authorityKeyIdentifier
gpgsm: looking up issuer from the Dirmngr cache
gpgsm: number of matching certificates: 0
gpgsm: dirmngr cache-only key lookup failed: No data
gpgsm: certificate is good
gpgsm: validation model used: shell
[GNUPG:] DECRYPTION_OKAY
12345

gpg version

>gpg --version
gpg (GnuPG) 2.5.21
libgcrypt 1.12.2

Details

Version
gpg4win-5.1.0-beta646 @ win11

Event Timeline

As you can see in the output of gpgsm it only prints ENC_TO status lines until the decryption succeeded. Hence, neither gpgme nor Kleopatra can know that there are more recipients. Interestingly, the audit log seems to have more information. I have no idea what black magic the audit log uses.

ebo renamed this task from Kleopatra: Only one recipient shown in decryption feedback for files S/MIME encrypted for multiple recipients to Only one recipient shown in decryption feedback for files S/MIME encrypted for multiple recipients.Wed, Jul 8, 8:52 AM
ebo updated the task description. (Show Details)
werner triaged this task as Normal priority.Wed, Jul 8, 9:56 AM

It looks like the audit log is requested with the command GETAUDITLOG --data --html which prints the details (including information about all recipients) as HTML. So, obviously, gpgsm has the necessary information. It just needs to emit ENC_TO status lines for the additional recipients.

A comment in gpgsm shows the problem:

/* Print the ENC_TO status line.  Note that we can
   do so only if we have the certificate.  This is
   in contrast to gpg where the keyID is commonly
   included in the encrypted messages. It is too
   cumbersome to retrieve the used algorithm, thus
   we don't print it for now.  We also record the
   keyid for later use.  */

In fact it is quite common that we don't have all the certificates to which a message is encrypted. Thus the only information we could get from the message are the issuer and s/n of each recipient. This is mostly useless for a user because no user name is available.

I would suggest that Kleopatra does not show the other recipients at all - just the own private key/certificate which was used for decryption and point the user to the audit log which will show the other issuers and S/N.

I would suggest that Kleopatra does not show the other recipients at all - just the own private key/certificate which was used for decryption and point the user to the audit log which will show the other issuers and S/N.

Then it's probably fine, as it is, just the additional hint could be added.

Are those other issues something to look into?

  • FAILURE at the end of the second gpgsm cli command output (pinentry dialog for the first recipient is cancelled, second one is entered correctly)
  • The first time the gpgsm cli command is executed (without background processes), dirmngr is not started. The second time it is

Are those other issues something to look into?

  • FAILURE at the end of the second gpgsm cli command output (pinentry dialog for the first recipient is cancelled, second one is entered correctly)

The error comes from this log error message. Cancelling the pin entry leads to Operation cancelled. gpgsm exits with an error if an error was printed with the log_error function.

  • The first time the gpgsm cli command is executed (without background processes), dirmngr is not started. The second time it is

This is related to T8333: Kleopatra: S/MIME decryption fails for certs with crl check problems.
In de-vs mode we have to check the certificate chain which is done after we successfully decrypted the session key. Checking the certificate chain includes a CRL check (which is done by the dirmngr).
With 4a8f177f390b270df9a86ea47d8eced85420d7d4, this should only happen if we are actually in de-vs mode.

  • The first time the gpgsm cli command is executed (without background processes), dirmngr is not started. The second time it is

In de-vs mode we have to check the certificate chain which is done after we successfully decrypted the session key. Checking the certificate chain includes a CRL check (which is done by the dirmngr).

Shouldn't the check then be executed on the first gpgsm cli command, too?
It looks like dirmngr is not started in this case (pinentry dialog for the first recipient is cancelled, second one is entered correctly). It will be started, if the command is repeated.

The test certificates do not have a crlDP, so there is no crl check done and no dirmngr is called for this. (see here)
After repeating the command the issuer is looked up from the dirmngr cache. In this test case the dirmngr is not called for a crl check but for a lookup.

First call (same as above):

$ gpgconf -K all
$ gpgsm -vv --debug cache,x509,lookup --status-fd 2 -d smime.encrypted-only.multiple.txt.p7m

For the repeated call:

$ gpgsm -vv --debug cache,x509,lookup --status-fd 2 -d smime.encrypted-only.multiple.txt.p7m 
[...]
gpgsm: DBG: keydb_search:   0: SUBJECT: 'CN=Root-CA 2020,OU=GnuPG.com,O=g10 Code GmbH,C=DE'
gpgsm: DBG: keydb_search: searched keybox (resource 0 of 1) => End of file
gpgsm: looking up issuer from the Dirmngr cache
gpgsm: no running dirmngr - starting '/usr/local/bin/dirmngr'
[GNUPG:] PROGRESS starting_dirmngr ? 0 0
gpgsm: waiting for the dirmngr to come up ... (8s)
gpgsm: connection to the dirmngr established
gpgsm: DBG: keydb_search: 1 search description(s):
gpgsm: DBG: keydb_search:   0: FPR20: 'D4:EC:A6:B4:69:AB:B5:44:08:27:CB:3F:C7:D7:91:08:3C:10:27:DB'
gpgsm: DBG: keydb_search: searched keybox (resource 0 of 1) => Success
gpgsm: number of matching certificates: 1
[...]
In T8334#220258, @pl13 wrote:

The test certificates do not have a crlDP, so there is no crl check done and no dirmngr is called for this.

Oh, that makes very much sense, thanks for looking into this.
I can confirm, dirmngr is properly started, if certs with crlDPs are used, all fine then:

C:\Users\g10>gpgsm -vv --debug cache,x509,lookup --status-fd 2 -d test.txt.p7m
[...]
gpgsm: no running dirmngr - starting 'C:\\Program Files\\Gpg4win\\..\\GnuPG\\bin\\dirmngr.exe'
[GNUPG:] PROGRESS starting_dirmngr ? 0 0
gpgsm: waiting for the dirmngr to come up ... (8s)
gpgsm: connection to the dirmngr established
gpgsm: asking dirmngr about 36:03:21:23:20:67:CC:26:E7:6A:FB:0D:CE:61:ED:74:60:A3:CB:9D
[...]

This issue would now be about adding a hint to the audit log for a full list of recipients, in S/MIME decryption feedback in Kleopatra.
But besides the amount of recipients, this list only shows the root certificates of the other ones:

I conclude, that this is not worth a comment and I'll close this ticket as invalid.