problems with mutt's gpgme setup

[Christoph Ludwig]

This discussion started at the mutt-dev mailing list
<url:http://marc.theaimsgroup.com/?l=mutt-dev&m=110815211532032&w=2>. I am
taking it here since most of the problems I am dealing with right now
seem to be GnuPG specific.

> On Mon, 14 Feb 2005 17:08:11 +0100, Christoph Ludwig said [amended in order
> to provide context]:
> > If I instruct gpgsm to ignore CRLs then I get senseful signature information,
> > all right. But I still have one Email where mutt shows me contradicting
> > information:
> > 
> > The signature information shows '*BAD* signature claimed to be from:
> > [...]'. IIUC the corresponding root CA has no validity dates whence gpgsm ]
> > rejects the certificate and - in consequence - the signature. (That behaviour
> > is ok IMHO but I'd prefer if the signature information would tell me the
> > reason of the rejection.) However, in mutt's status line I read 'S/MIME

On Mon, Feb 14, 2005 at 09:27:56PM +0100, Werner Koch wrote:
> We discussed this during kmail development over and over and the
> outcome is that kmail has a buttun do check the certificates then.
> Something similar should be done in Mutt too.  Anyway, we won't be
> able to present all things in detail and in a way understandable for
> the average user - thus many situations may only be examined using the
> log files.

I appreciate your argument and I understand that you don't want to bury the
important information underneath details most users are not interested in. But
there should be an easy way from within the MUA to get to a log why the
verification failed. 

Anyway, that issue is not that important for me. If I do not understand why
gpgsm rejects a mail then I have the tools and knowledge to verify the
signature step by step. I brought it up because it is IMO a usability issue
for the average user.


> > signature successfully verified'. That's confusing!
> 
> Yes, it is.  We are working on that.  Note that there might even be
> some messages it can't parse - please report those; we are going to
> fix them.  I have one such fix in CVS (for libksba) so with the next
> gnupg 1.9 version more bugs will get squished out.

OK, I will try it after its release.

> > I don't want to leave the CRL checks disabled whence I need to figure out the
> > problem with dirmngr. The only information I find in the log when verifying a
> > good signature corresponding to a non revoked cert is
> 
> Pleae update to dirmngr 0.9.1 - I fixed a bug which looks like yours.
> 
> > Must the distribution point in the certificate be given in any particular
> > format? (I am going to sign this message so anyone interested can have a look
> 
> Well, LDAP and HHTP are supported. https is not really supported but
> we try simply http instead, which surprisingly often works.
> 
> > at the URI.) Or how can I find out *why* the ldap lookup failed?
> 
> Add 
> 
> debug 2
> 
> to dirmngr.conf

I installed dirmngr 0.9.1. Unfortunately, the problem persists. (I am going to
attach a log to this mail.) dirmngr complains `no hostname in URL or query
failed', even though the URI clearly contains a fully qualfied host. 

I already doublechecked that my iptables script does not block ldap
requests. My coworkers confirmed that the ldap server is running.
So I am a mystified why dirmngr cannot download the CRL.

Has anyone here an idea what's wrong?

> > I try to actually sign a message with the new key then I get an error that the
> > secret key file was not found. The log does not show anything... :-(
> 
> Sure that the public key is available and all certificates up to the
> root?  Try:
> 
>  gpgsm -k --with-validation user_ID_of_new_key
> 
> The user Id is best specified using the fingerprint or the keyid
> (last 8 hex digits); see README.

You were right, there was indeed a problem with the certificate chain. There
were two reasons why I didn't realize the problem:

a) When I imported the PKCS#12 file I assumed my key / certificate pair was
   imported. But gpgsm imported the private key only. Is there a good reason
   why it ignores the certificates? I had to extract the certificate with
   openssl into a PEM file and import the certificate from the PEM file. I
   cannot imagine that you expect Joe Average User to do this.

b) When I selected the certificate for the signature I was presented with the
   following choice:

   1 x  1023/0x19442EB3 RSA  es <cludwig at cdc.informatik.tu-darmstadt.de>
   2 x  1024/0xC1D60643 RSA  es <cludwig at cdc.informatik.tu-darmstadt.de>

   I happened to know that 0x19442EB3 was my old certificate. Since I just had
   imported the PKCS#12 file with my new key I erroneously assumed 0xC1D60643
   to designate my new certificate. (In fact, it designates an old, long
   expired certificate that I had forgotten.) So I selected the latter
   certificate and wondered about the resulting error message.

Because of (b) I have two requests:
1) I'd like to associate a string with each certificate that is printed in
   addition to the certificate ID. Then I could assign each certificate a
   meaningful label.

2) I want to be given a choice among *valid* certificates only when
   selecting a certificate for a signature. 
   Over time, the expired / revoked certificates will accumulate. I cannot
   expunge them from the key / certificate store because I still need to be
   able to decrypt my old mails and verify old signatures.


Do you have any objections? Are these requests feasible?

Regards

Christoph

-- 
http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/cludwig.html
LiDIA: http://www.informatik.tu-darmstadt.de/TI/LiDIA/Welcome.html

-------------- next part --------------
A non-text attachment was scrubbed...
Name: gnupg.log.gz
Type: application/x-gunzip
Size: 4705 bytes
Desc: not available
Url : /pipermail/attachments/20050215/b1a376b3/gnupg.log-0001.bin