2.0.29 has been released.

Sorry, I missed that for 2.0.29

To test whether there is a problem with the key signature verifcation test, you
may run your test cases again with the added option --no-sig-cache. These
things are not easy to replicate because they depend on the keys in your keyring
and your ownertrust settings.

gpg2 is unusable under jessie. Just browsing my inbox in icedove/thunderbird
causes the following:

top - 11:08:34 up 17 days, 35 min, 7 users, load average: 4.47, 3.24, 1.93
Tasks: 243 total, 4 running, 239 sleeping, 0 stopped, 0 zombie
%Cpu(s): 60.9 us, 16.3 sy, 0.0 ni, 21.7 id, 1.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 8072496 total, 7827000 used, 245496 free, 117576 buffers
KiB Swap: 7688188 total, 1291184 used, 6397004 free. 1675144 cached Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND

3420 agallag+ 20 0 78616 57736 3572 R 99.5 0.7 6:06.75 gpg2

3494 agallag+ 20 0 33040 11912 3532 R 99.5 0.1 4:52.95 gpg2

3424 agallag+ 20 0 31940 10796 3468 R 99.2 0.1 3:31.33 gpg2

8743 agallag+ 20 0 5129560 2.326g 44372 S 5.3 30.2 1262:07 iceweasel

7743 agallag+ 20 0 1898320 198764 26908 S 2.3 2.5 225:11.77 gnome-shell

3407 root 20 0 0 0 0 S 0.7 0.0 0:00.50 kworker/3:0

4344 jira 20 0 3547040 581920 5216 S 0.7 7.2 84:02.57 java

3610 agallag+ 20 0 25944 3168 2428 R 0.3 0.0 0:00.01 top

3718 root 20 0 364320 63932 41096 S 0.3 0.8 110:25.72 Xorg

5899 agallag+ 20 0 2750304 86372 13620 S 0.3 1.1 2:40.06 dropbox

7858 agallag+ 20 0 419240 25884 9216 S 0.3 0.3 12:40.70
gnome-terminal-
10159 agallag+ 20 0 2155424 602372 46804 S 0.3 7.5 116:15.04 icedove

                                                
    1 root      20   0   15484   1084   1048 S   0.0  0.0   0:06.36 init

I can't use gpg1 in the meantime because I have a smartcard.

Right. SHA-256 never worked because the CSR anyway indicated SHA-1 but signed
using SHA-256.

Note that the signing of a CSR is only there to indicate that one own the
private key. The resulting certificate may use any signing algorithm on the
discretion of the CA.

Does this mean it would also not be possible to generate a CSR with SHA256 as
hash algo with 2.0 at all? I think I've tested this some time ago and it worked
but that might have been 2.1

I'd like to see this fixed as the change was part of the NEWS for 2.0.28 and do
we really want to have a NEWS entry like "The default hash algo for a CSR is now
SHA-1 again because we failed to get SHA-256 working"? :-p

Note: in 2.1 (master) this is correctly implemented.

I had to revert the CSR part of the patch. Done with commit 35d3ced.

There a couple of problems with using aritrary hash algorithm in gpgsm. We
better solve that in master first and then decide whether it makes sense to
backport.

I'll second this report, note that I noticed this change in behaviour
when migrating from Wheezy to Jessie and from gnupg2
2.0.25-99intevation2 to 2.0.26-6

More details copied from gnupg-devel@:
----------Original Message----------
From: Bernhard Reiter <bernhard@intevation.de>
Sent: Tuesday 23 June 2015, 16:21:54
To: gnupg-devel@gnupg.org
Subject: trustdb calculation very slow (gpg2.0 vs gpg1)

Hi
on a Debian GNU/Linux Jessie system I have a defect that
the trust calculation of a cert is taking a lot of time.
Almost 2 minutes with 100%cpu.
This used to be different with early gnupg2 versions I've used
and it is different to gpg (1), where it were 20 seconds.

No report found, thus seem to depend on my trustdb.
Any ideas on how to create a good report/debug?

Details:
How to recreate:
gpg2 --delete-key 52D717F3
time LANG=C gpg2 -v --recv-keys 52D717F3
real 1m57.144s
user 1m46.560s
sys 0m9.296s

as compared to gpg verison 1

gpg2 --delete-key 52D717F3
time LANG=C gpg --recv-keys 52D717F3
real 0m19.840s
user 0m18.192s
sys 0m0.900s

ii gnupg 1.4.18-7 i386 GNU privacy guard - a free PGP re
ii gnupg2 2.0.26-6 i386 GNU privacy guard - a free PGP re

With 2.0.25-99intevation2 on Wheezy I did not notice the issue,
but of course, my trustdb changed over time.

----------Original Message----------
From: "Dr. Peter Voigt" <pvoigt@uos.de>
Sent: Tuesday 23 June 2015, 23:35:14
To: gnupg-devel@gnupg.org
[..]

I am just having a fully configured VirtualBox VM of Jessie with Gnome
3 available, but I am not having this problem:

% time LANG=C gpg2 -v --recv-keys 52D717F3
...
LANG=C gpg2 -v --recv-keys 52D717F3 0.11s user 0.06s system 7% cpu
2.304 total

% dpkg -l gnupg2
Desired=Unknown/Install/Remove/Purge/Hold

Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend

Name Version Architecture
Description

+++-

ii gnupg2 2.0.26-6 amd64 GNU
privacy guard - a free PGP replacement (new v2.x)

---------Original Message----------
From: Bernhard Reiter <bernhard@intevation.de>
Sent: Wednesday 24 June 2015, 09:17:35
To: gnupg-devel@gnupg.org

On Tuesday 23 June 2015 at 23:35:14, Dr. Peter Voigt wrote:

I am just having a fully configured VirtualBox VM of Jessie with Gnome
3 available, but I am not having this problem:

thanks for trying to reproduce!
As your result is showing as well:
It probably depends on my .gnupg data like the contents of my trustdb,
private keys and settings.

Of course I cannot just make this available,
so I am grateful for hints to find out more about the issue.

I could try to export, delete and reimport the trustdb, but because
gpg 1.4 works on it a lot better I assume that it is not a simple structural
problem of my trustdb. (Which I hope both gpg versions would detect.) So I am
not sure, if this is a good step to take.

Hi, thomai,

Please run something like the following:

  echo | gpg2 --sign

Does gpg2 complain the the connection to gpg agent was hijacked? If so, please
disable GNOME Keyring and try to reproduce the problem.

If the problem continues to exist, can you tell me approximately how long your
password is?

Thanks,

Neal

1.5.5 has been released.

Thanks for the log. This reveals a bug which has been with us since the support
for gpgsm: If there is no status line handler but a status line is received
anyway the command handling loop terminates and thus the command/answer order
gets out of sync. In this concrete case this is triggered by sending an option
which starts the agent and that starting emits a "PROGRESS" status line.

My solution is not to stop reading after a status line but record a possible
error code and return that only after OK or ERR.

This will go into 1.5.5 which I am already preparing.

I am unsure I understand, this causes gpgme to fail.

GPGME 2014-12-26 01:12:58 <0x5f44> _gpgme_run_io_cb: call: item=0xd2e804f5b00,
handler (0xd2e804f5970, 13)
GPGME 2014-12-26 01:12:58 <0x5f44> chan_12 <- ERR 50331822 Unknown option <GpgSM>

GPGME 2014-12-26 01:12:58 <0x5f44> gpgme:status_handler: call:
gpgsm=0xd2e804f5970, fd 0xd: ERR line - mapped to: Unknown option

The error return from sending this option is not checked on purpose. We do the
same for all such options.

The patch is a work for problem somewhere in the PC/SC implementaion. I am also
not sure whether a pthread_cancel for a buggy PC/SC library is a good idea.
Terminating the process seems to be a better solution.

If gpgtools wants to apply this pacth, they might of course do so but I don't
want to apply it upstream in particular not to an older version (2.1 is current).

I propose to implement a partly solution as a start: Add a 4th parameter
"allow_ambiguous" to gpgsm_find_cert() in "sm/certlist.c".

When called from "sm/gpgsm.c" or "sm/server.c" or anywhere else, set this
parameter to 0. Then gpgsm_find_cert() will behave like before.

When called by inq_certificate() in "sm/call-dirmngr.c", set this parameter to

1. Then gpgsm_find_cert() will not bail out an ambiguous certificates, but

return the newest one of the matching certificates (according to
validity.notBefore).

(I am not sure what to pass when called by run_command_inq_cb() in
"sm/call-dirmngr.c" because I did not yet understand in which situation this
callback is used.)

As far as I can see, this change never hurts, but it helps when there are
multiple certificates for intermediate CAs with identical subject and identical
key by allowing to use "gpgsm" without "--disable-crl-checs --disable-dirmngr".

See attached patch.

(A complete solution probably requires call-dirmngr to return all matching
certificates and dirmngr to try each of the returned certificates in a loop.)

D199: 601_gnupg.diff

The error "Ambiguous Name" is generated in "sm/certlist.c" in gpgsm_find_cert().

Arguments to this function are:

name:

"/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle
Universitaet Muenster - G02,O=Universitaet Muenster,C=DE"

keyid: NULL

Caller is the function inq_certificate() in "sm/call-dirmngr.c".
Argument to this function is:

line: "SENDCERT

/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle
Universitaet Muenster - G02,O=Universitaet Muenster,C=DE"
This is caused in function gpgsm_dirmngr_isvalid() in "sm/call-dirmngr.c" by
calling assuan_transact() with

  line: "ISVALID A52EFAEFBC86EF98C5E9AA92B3ECEC4101080F0A.1700BFBB98F74B"

When looking up the CRL, GnuPG assumes that there is only one certificate with
the Distinguished Name of the Certification Authority.
But that is not true: Distinguished Names distinguish identities, not
certificates. The same identity can hold multiple certificates at the same time.
So GnuPG must be fixed to allow multiple valid certificates with the same
Distinguished Name.
Wenn looking up a CRL, GnuPG may use any of these certificates.
My proposal: Perhaps you could implement and use a dirmngr function "SENDANYCERT"?

With 2.1.2, the bug still exists:

[/home/permail/RHEL5/devel/gpgfamily/bin/gpgsm] [--no-greeting] [--yes]
[--auto-issuer-key-retrieve] [--batch] [--no-tty] [--homedir]
[/home/p/perske/.perMail/gnupghome] [--base64] [--detach] [--local-user]
[&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436] [--status-fd] [8] [--output]
[/index/permail/RHEL5/devel/sso/work/pgp.fe5316b600000e8a.out] [--sign]
[/index/permail/RHEL5/devel/sso/work/pgp.fe5316b600000e8a.dat]
(using a self-written pinentry replacement)

Output is now reduced, but basically unchanged:

gpgsm: Note: non-critical certificate policy not allowed
gpgsm: certificate not found: Ambiguous name
gpgsm: certificate
#1700BFBB98F74B/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle
Universitaet Muenster - G02,O=Universitaet Muenster,C=DE
gpgsm: checking the CRL failed: Not found
gpgsm: can't sign using '&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436': Not found

Currently used versions:

gnupg-1.4.18.tar.bz2
gnupg-2.1.2.tar.bz2 (build process patched according to T1862)
libassuan-2.2.0.tar.bz2
libgcrypt-1.6.2.tar.bz2
libgpg-error-1.18.tar.bz2
libksba-1.3.2.tar.bz2
npth-1.1.tar.bz2
pinentry-0.9.0.tar.bz2
(my own) pinentry.c

Can you please downgrade to libgpg-error version 1.12 and try again?
I assume that there is a conflict between Pth and the Pthread mutexes from
libgpg-error > 1.12.

You may also consider to update to GnuPG 2.1.3 which does not use Pth anymore.

As I wrote to #712744, distribution nowadays is conservative enough for its
default kernel settings, and it doesn't require each application to have special
settings.

I think that we will be able to close this soon.

I really want to try, but I cannot compile 2.1.2 due to T1862.

Compiling with latest npth instead of latest pth does not change anything.
Without patch = segfault, with patch = works.

Duplicate of T1644

Okay, I changed your role so that you can comment on T1644.

It is very unlikely that we are going to fix that in 2.0, thus be prepared to
move to 2.1.

Can you please try with 2.1.2 ?

T1624 is another issue related to this. GPGex
/ Kleopatra file / folder encrypt does not work with non ASCII characters.

I've commited the patch to gpg4win so it will be part of the 2.2.2 release.

Thanks for summing up the other problems. I've added a reference to this issue
to the "Improve encoding handling" point in the backlog:
http://wiki.gnupg.org/Gpg4win/Wishlist

Thanks Andre for the patch!

I managed to build gpg4win with the patch added and I verified that it seems to
solve the problem reported by me and also in Issues 1373 and 1674!

But I'd like to summarize the problems related to the charset / codepage on MS
Windows of which I am aware, as a reminder:

1. incorrect display of GPG 2 output translated into another language (also

reported in Issue 1373 and Issue 1674): fixed by your patch;

2. passphrases (both for secret keys and symmetrical encryption) with non ASCII

characters set using GPG 1.4.18 are considered not valid using GPG 2.0.26 and
vice versa

3. incorrect display of filenames with non ASCII characters (also in Issue 1409)

4. GPG 2.0.26 and 1.4.18 ignore or weirdly comply with --utf8-strings, --no-

utf8-strings or --charset options for utf-8 encoding of encrypted filenames (see
Issue 1409)

5. charset weirdness searching keyserver for some non-ASCII user IDs under non-

UTF-8 locales (see Issue 1514 - although relates to Linux it seems to occur also
on Windows, both CLI and GPA but not Kleopatra)

Hope this will help to improve the great GnuPG :-)

Good anlysis. Thanks.
Feel free to put it as a patch into gpg4win.
I need to look closer at it because we have have the gettext code also in
libgpg-error. You should also send a DCO for GnuPG.

Pretty picture.

D211: 465_0001-Let-wchar_to_native-convert-to-console-codepage.patch

I've taken a look at this. The problem is that the working conversion code in
jnlib/utf8conv.c is not used on Windows but instead jnlib/w32-gettext.c does
it's own conversion to wchar and then back from wchar to the native codepage
which is simpler and should work.

But the conversion back used the wrong codepage. CP_ACP instead of the codepage
retuned by GetConsoleOutputCP. jnlib/utf8conv.c actually had a comment
explaining why it is neccessary to use GetConsoleOutputCP.

With this changed (see attached patch) I get correct output and can verify /
sign files with non-ascii filenames.

I think gnupg master behaves differently though and I don't have a test setup
for this so the patch is only against STABLE.

Werner any objections into including this patch into GnuPG / Gpg4Win?

With dirmngr 1.1.1 and libgcrypt-1.6.0 (gpg4win-2.2.2-beta19) I have what I
think is a similar error on Windows:

C:\Users\aheinecke>"c:\Program Files\GNU\GnuPG\dirmngr.exe"
dirmngr[3060]: Fatal: can't register GNU Pth with Libgcrypt: Not supported

Doesn't crash though. I've not tested the pth_init patch. If you think this is
useful please tell me and I will do so. I assume it will also fix this problem.

Sorry, the fix does not remove the bug:

[/home/permail/RHEL5/devel/gpgfamily/bin/gpgsm] [--no-greeting] [--yes]
[--auto-issuer-key-retrieve] [--batch] [--no-tty] [--homedir]
[/home/p/perske/.perMail/gnupghome] [--base64] [--detach] [--local-user]
[&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436] [--status-fd] [8] [--output]
[/index/permail/RHEL5/devel/sso/work/pgp.89542620000040ef.out] [--sign]
[/index/permail/RHEL5/devel/sso/work/pgp.89542620000040ef.dat]
(using a self-written pinentry replacement)

gpgsm: note: non-critical certificate policy not allowed
dirmngr[25485.0]: permanently loaded certificates: 0
dirmngr[25485.0]: runtime cached certificates: 0
dirmngr[25485.0]: no CRL available for issuer id
A52EFAEFBC86EF98C5E9AA92B3ECEC4101080F0A
gpgsm: certificate not found: Ambiguous name
dirmngr[25485.0]: assuan_inquire(SENDCERT) failed: IPC call has been cancelled
dirmngr[25485.0]: error fetching certificate by subject: No data
dirmngr[25485.0]: crl_parse_insert failed: Missing certificate
dirmngr[25485.0]: crl_cache_insert via DP failed: Missing certificate
dirmngr[25485.0]: command ISVALID failed: Missing certificate
gpgsm: certificate
#1700BFBB98F74B/1.2.840.113549.1.9.1=#636140756E692D6D75656E737465722E6465,CN=Zertifizierungsstelle
Universitaet Muenster - G02,O=Universitaet Muenster,C=DE
gpgsm: checking the CRL failed: Not found
gpgsm: can't sign using `&7CF2C58D823C0ED461ED6B1FD13F9E96B6F7C436': Not found

Currently used versions:

dirmngr-1.1.1.tar.bz2
dirmngr-1.1.1-pth-fix.patch
gnupg-1.4.17.tar.bz2
gnupg-2.0.24.tar.bz2
libassuan-2.1.1.tar.bz2
libgcrypt-1.6.1.tar.bz2
libgpg-error-1.13.tar.bz2
libksba-1.3.0.tar.bz2
pinentry-0.8.3.tar.bz2
pth-2.0.7.tar.gz
(my own) pinentry.c

The assuan_inquire(SENDCERT) above requests a certificate by distinguished name,
not by authority key identifier (see T1644 (perske on May 23 2014, 07:05 PM / Roundup)), thus it does not matter that the
certificates re-issued by the DFN-PKI kept their authority key identifiers; the
problem is triggered by (correctly) keeping the Distinguished Name.

(I did not yet analyze your bugfix.)

Done for 2.0.14 with commit e790671c

Fixed in 2.0.23.

It is not the keygrip but the authority key identifier based lookup
which fails. Quite obvious if they do that stupid re-issuing. The
problem with dirmngr is only a side-effect of gpg not using the proper
certificate form the chain. Though, the question is which is the
proper certificate? They are both correct. I solved that my looking
for all matching certificates and using the latest one. That should
match reality better. Below is a log using a certificate store with
both DFN certificates. I have not done any Dirmngr tests, though.

The old certificate:

    ID: 0xFFFFFFFFA3EFE945
   S/N: 00C7
Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust

Center/O=Deutsche Telekom AG/C=DE

  Subject: /CN=DFN-Verein PCA Global - G01/OU=DFN-PKI/O=DFN-Verein/C=DE
 validity: 2006-12-19 10:29:00 through 2019-06-30 23:59:00
 key type: 2048 bit RSA
key usage: certSign crlSign

chain length: 2

  fingerprint: F0:28:8F:DA:C6:3A:F7:9A:31:9A:E9:72:F3:95:09:0E:A3:EF:E9:45

The re-issued one:

    ID: 0x55715DB8
   S/N: 0089901115583E879B
Issuer: /CN=Deutsche Telekom Root CA 2/OU=T-TeleSec Trust

Center/O=Deutsche Telekom AG/C=DE

  Subject: /CN=DFN-Verein PCA Global - G01/OU=DFN-PKI/O=DFN-Verein/C=DE
 validity: 2014-02-11 13:11:45 through 2019-07-09 23:59:00
 key type: 2048 bit RSA
key usage: certSign crlSign

chain length: 2

  fingerprint: 2E:EF:D9:C0:99:A2:BB:1C:2B:AC:52:97:BD:FF:D8:C8:55:71:5D:B8

Use gpgsm --dump-cert to see the other info. By deleting one or the
other certificate and importing them in a different order, it is
possible to verify that the latest certificate is use.

$ echo hallo | ~/b/gnupg/sm/gpgsm -ea --disable-crl-checks --debug 1 -r Schnarre
gpgsm: used in a production environment or with production keys!
gpgsm: enabled debug flags: x509
gpgsm: DBG: BEGIN Certificate 'target':
gpgsm: DBG: serial: 13F7C661A329F4
gpgsm: DBG: notBefore: 2012-06-13 08:01:21
gpgsm: DBG: notAfter: 2015-06-13 08:01:21
gpgsm: DBG: issuer:
1.2.840.113549.1.9.1=#706B692D63614062756E6465737461672E6465,CN=Deutscher
Bundestag CA - G01,OU=Deutscher Bundestag,O=Deutscher Bundestag,C=DE
gpgsm: DBG: subject:
1.2.840.113549.1.9.1=#736162696E652E6C657574686575737365722D7363686E617272656E6265726765724062756E6465737461672E6465,CN=Sabine
Leutheusser-Schnarrenberger,OU=MdB,O=Deutscher Bundestag,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5
gpgsm: DBG: SHA1 Fingerprint:
73:99:B8:58:93:E5:F8:E0:D7:7C:BE:7F:D8:4C:14:86:78:A1:E8:03
gpgsm: DBG: END Certificate
gpgsm: failed to open '/home/wk/.gnupg/policies.txt': No such file or directory
gpgsm: note: non-critical certificate policy not allowed
gpgsm: DBG: looking for parent certificate
gpgsm: DBG: found via authid and keyid
gpgsm: DBG: got issuer's certificate:
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 0D688CAF
gpgsm: DBG: notBefore: 2008-12-17 14:39:27
gpgsm: DBG: notAfter: 2019-06-30 00:00:00
gpgsm: DBG: issuer: CN=DFN-Verein PCA Global - G01,OU=DFN-PKI,O=DFN-Verein,C=DE
gpgsm: DBG: subject:
1.2.840.113549.1.9.1=#706B692D63614062756E6465737461672E6465,CN=Deutscher
Bundestag CA - G01,OU=Deutscher Bundestag,O=Deutscher Bundestag,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5
gpgsm: DBG: SHA1 Fingerprint:
0A:0D:87:72:EE:E7:B9:47:AE:A7:FC:58:C5:47:90:7F:75:F9:50:62
gpgsm: DBG: END Certificate
gpgsm: DBG: gcry_pk_verify: Success
gpgsm: certificate is good
gpgsm: DBG: looking for parent certificate
gpgsm: DBG: found via authid and keyid
gpgsm: DBG: got issuer's certificate:
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 0089901115583E879B
gpgsm: DBG: notBefore: 2014-02-11 13:11:45
gpgsm: DBG: notAfter: 2019-07-09 23:59:00
gpgsm: DBG: issuer: CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust
Center,O=Deutsche Telekom AG,C=DE
gpgsm: DBG: subject: CN=DFN-Verein PCA Global - G01,OU=DFN-PKI,O=DFN-Verein,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.11
gpgsm: DBG: SHA1 Fingerprint:
2E:EF:D9:C0:99:A2:BB:1C:2B:AC:52:97:BD:FF:D8:C8:55:71:5D:B8
gpgsm: DBG: END Certificate
gpgsm: DBG: gcry_pk_verify: Success
gpgsm: intermediate certificate is good
gpgsm: DBG: looking for parent certificate
gpgsm: DBG: found via authid and keyid
gpgsm: DBG: got issuer's certificate:
gpgsm: DBG: BEGIN Certificate 'issuer':
gpgsm: DBG: serial: 26
gpgsm: DBG: notBefore: 1999-07-09 12:11:00
gpgsm: DBG: notAfter: 2019-07-09 23:59:00
gpgsm: DBG: issuer: CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust
Center,O=Deutsche Telekom AG,C=DE
gpgsm: DBG: subject: CN=Deutsche Telekom Root CA 2,OU=T-TeleSec Trust
Center,O=Deutsche Telekom AG,C=DE
gpgsm: DBG: hash algo: 1.2.840.113549.1.1.5
gpgsm: DBG: SHA1 Fingerprint:
85:A4:08:C0:9C:19:3E:5D:51:58:7D:CD:D6:13:30:FD:8C:DE:37:BF
gpgsm: DBG: END Certificate
gpgsm: DBG: gcry_pk_verify: Success
gpgsm: root certificate is good
gpgsm: CRLs not checked due to --disable-crl-checks option
gpgsm: validation model used: shell
gpgsm: encrypted data created

Deeper analysis showed that not the keygrip but the DN is misinterpreted as
unique identifyer for a certificate when used in the SENDCERT inquire by
dirmngr. So I correct the title again.

The distinguished name distinguishes human beings or network end points but
neither certificates nor key pairs. For valid reasons, there can be multiple
certificates with the same DN and these certificates may contain the same or
different public keys. The GnuPG suite has to learn to handle this situation.

Using gpgsm with the options --disable-dirmngr --disable-crl-checks made our
webmailer work again, but places all users at inacceptable higher risk. So I
keep the priority setting "critical".

Thanks.

Changing category to dismngr to remind about doing a release.

Looks good, compiling with libgcrypt-1.6.0 and creating a signed S/MIME e-mail
with gpgsm works.

Will you be so kind and test the attached patch?

D186: 419_dirmngr-pth-fix.patch

damn, thats the creation date of the last userid - i was too stupid to read the
draft of hkp.
http://tools.ietf.org/html/draft-shaw-openpgp-hkp-00#section-5.2
-> Close