Mailing List Archive: problems with mutt's gpgme setup

problems with mutt's gpgme setup

Feb 15, 2005, 10:46 AM

Post #1 of 6 (3011 views)

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@cdc.informatik.tu-darmstadt.de>
2 x 1024/0xC1D60643 RSA es <cludwig@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

Re: problems with mutt's gpgme setup [ In reply to ]

bernhard at intevation

Mar 1, 2005, 1:27 PM

Post #2 of 6 (2928 views)

Permalink

On Tue, Feb 15, 2005 at 06:46:58PM +0100, Christoph Ludwig wrote:

> b) When I selected the certificate for the signature I was presented with the
> following choice:
>
> 1 x 1023/0x19442EB3 RSA es <cludwig@cdc.informatik.tu-darmstadt.de>
> 2 x 1024/0xC1D60643 RSA es <cludwig@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.

Note there are two workarounds at this point:
a) hit the check signature funcation (usually bound to 'c')
b) Once you have figured out which key to use, set a default
sign-as in .muttrc with set smime_default_key=0xXXXXXXXX

> 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.

I think the meaning full label is not necessary and might be even a
bit missleading, if user say "good" or so and the certificate is not good
or so.

> 2) I want to be given a choice among *valid* certificates only when
> selecting a certificate for a signature.

I agree that 2) would be useful, at least the information should be displayed
better in the case of a expired certificate.
If you like you can add this to the ägypten tracker as wish.
https://intevation.de/roundup/aegypten

Best,
Bernhard

Re: problems with mutt's gpgme setup [ In reply to ]

cludwig at cdc

Mar 2, 2005, 3:25 AM

Post #3 of 6 (2925 views)

Permalink

On Tue, Mar 01, 2005 at 09:27:26PM +0100, Bernhard Reiter wrote:
> On Tue, Feb 15, 2005 at 06:46:58PM +0100, Christoph Ludwig wrote:
>
> > b) When I selected the certificate for the signature I was presented with the
> > following choice:
> >
> > 1 x 1023/0x19442EB3 RSA es <cludwig@cdc.informatik.tu-darmstadt.de>
> > 2 x 1024/0xC1D60643 RSA es <cludwig@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.
>
> Note there are two workarounds at this point:
> a) hit the check signature funcation (usually bound to 'c')

Thanks. Let me nit-pick, though: If I am in the key selection menu and press
'?' for help, then I am told that 'c' checks *PGP* keys. Of course, verify-key
also works for x509 certificates, but that is not implied by the help
message.

Another point: The function "verify-key" is unfortunately named IMHO, because
it does not do what its name conveys. (a) If used in a S/MIME setting, it
operates on certificates, not keys. (I am not sure whether the distinction
between a public key and the certificate that binds the key to an identity
matters for Joe Average or if it only causes confusion. OTOH, as soon as one
has two different certificates for one key the terminology needs to be clear.)
(b) I tested the function with certificates in my key store that cannot be
validated. (The first has no valid from / to fields, the second has no
trusted root cert in the key store.) In both cases the relevant data from all
certs in the cert chain is displayed, but I get no message that there is a
problem with the certificates.

> b) Once you have figured out which key to use, set a default
> sign-as in .muttrc with set smime_default_key=0xXXXXXXXX

Sure, that's what I did.

> > 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.
>
> I think the meaning full label is not necessary and might be even a
> bit missleading, if user say "good" or so and the certificate is not good
> or so.

I am not sure I understand your point. I want to associate the label when I
include the certificate in *my* key store. Of course, nobody stops me from
tagging a certificate that expires tomorrow with the string "a super-duper
cert that will be always valid". I can always shoot me in the foot myself. But
then I am the only one who the tag is presented to in the key selection menu. I
therefore do not see how such a label could be abused to deceive someone else.

> > 2) I want to be given a choice among *valid* certificates only when
> > selecting a certificate for a signature.
>
> I agree that 2) would be useful, at least the information should be displayed
> better in the case of a expired certificate.
> If you like you can add this to the ägypten tracker as wish.
> https://intevation.de/roundup/aegypten

Will do, thanks.

I had a discussion with colleagues whether we should ask students taking our
computer lab course to taggle issues we have with the S/MIME support in
GnuPG / mutt. (Don't hold your breath - the number of students who can produce
good quality C/C++ code is unfortunately quite small.) If we actually do this,
where should we coordinate what we ask our students to work on? There might be
patches you do not agree with and that will not go into GnuPG, but if we ask
our students to resolve problems also mentioned on the ägypten tracker then I
want to make sure it's not something you are also working on. (The tracker
shows many items where the last reported activity was several months ago. Does
that mean that nobody is working on them or where they eventually resolved but
for some reason never closed in the tracking system?) And where do you discuss
proposed patches?

Regards

Christoph

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

Re: problems with mutt's gpgme setup [ In reply to ]

bernhard at intevation

Mar 29, 2005, 7:03 AM

Post #4 of 6 (2914 views)

Permalink

Hi Christoph,
sorry for answering so late, this email somehow slipped.
(For future reference: Ping me by email if you think that I might
have missed an email on this public list.)

On Wed, Mar 02, 2005 at 11:25:00AM +0100, Christoph Ludwig wrote:
> On Tue, Mar 01, 2005 at 09:27:26PM +0100, Bernhard Reiter wrote:
> > On Tue, Feb 15, 2005 at 06:46:58PM +0100, Christoph Ludwig wrote:

> > Note there are two workarounds at this point:
> > a) hit the check signature funcation (usually bound to 'c')
>
> Thanks. Let me nit-pick, though: If I am in the key selection menu and press
> '?' for help, then I am told that 'c' checks *PGP* keys. Of course, verify-key
> also works for x509 certificates, but that is not implied by the help
> message.
>
> Another point: The function "verify-key" is unfortunately named IMHO, because
> it does not do what its name conveys. (a) If used in a S/MIME setting, it
> operates on certificates, not keys. (I am not sure whether the distinction
> between a public key and the certificate that binds the key to an identity
> matters for Joe Average or if it only causes confusion. OTOH, as soon as one
> has two different certificates for one key the terminology needs to be clear.)
> (b) I tested the function with certificates in my key store that cannot be
> validated. (The first has no valid from / to fields, the second has no
> trusted root cert in the key store.) In both cases the relevant data from all
> certs in the cert chain is displayed, but I get no message that there is a
> problem with the certificates.

All three points are valid criticism.
When looking at the other bugs, they are not first priority, though.
And I hope we would have enough capacity to deal with the others first. ;)

So help is appreciated. You can create issues for our tracker to
make sure that the points are not lost, too.

> > > 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.
> >
> > I think the meaning full label is not necessary and might be even a
> > bit missleading, if user say "good" or so and the certificate is not good
> > or so.
>
> I am not sure I understand your point. I want to associate the label when I
> include the certificate in *my* key store. Of course, nobody stops me from
> tagging a certificate that expires tomorrow with the string "a super-duper
> cert that will be always valid". I can always shoot me in the foot
> myself. But then I am the only one who the tag is presented to in
> the key selection menu. I therefore do not see how such a label
> could be abused to deceive someone else.

No, it might be used to confuse yourself.
My point is that the standard interface should be so good that you
do not need the labels, thus avoiding that source of confusion for good.

>
> > > 2) I want to be given a choice among *valid* certificates only when
> > > selecting a certificate for a signature.
> >
> > I agree that 2) would be useful, at least the information should
> > be displayed better in the case of a expired certificate. If
> > you like you can add this to the ägypten tracker as wish.
> > https://intevation.de/roundup/aegypten
>
> Will do, thanks.

I haven't seen it yet.
(Did I miss it?)

> I had a discussion with colleagues whether we should ask students taking our
> computer lab course to taggle issues we have with the S/MIME support in
> GnuPG / mutt. (Don't hold your breath - the number of students who can produce
> good quality C/C++ code is unfortunately quite small.)

Yes, and this being in the security area makes this even a larger problem.

> If we actually do this,
> where should we coordinate what we ask our students to work on?

Basically on this list and monitoring the relevant mutt and gnupg lists.

> There might be
> patches you do not agree with and that will not go into GnuPG, but if we ask
> our students to resolve problems also mentioned on the ägypten tracker then I
> want to make sure it's not something you are also working on. (The tracker
> shows many items where the last reported activity was several months ago. Does
> that mean that nobody is working on them or where they eventually resolved but
> for some reason never closed in the tracking system?) And where do you discuss
> proposed patches?

We discuss proposed patches here on this list or via other ways
as some developer meet in person from time to time.
Sometimes is also makes sense to put a patch in the tracker.

The problem is the sheer number of smaller problems that we cannot
tackle alone. If a bug has not been acted upon, you should always ping
in the issue before working on it. Those bugs in the tracker should be real.

Of course we appreciate any help, but you should not that some of
the bugs might turn out really, really hard to fix.
Especially the more annoying ones. Otherwise the people of g10code
would have fixed it long ago. You just need to be prepared that this
is not an easy exercise. ;-)

Best,
Bernhard

Re: problems with mutt's gpgme setup [ In reply to ]

cludwig at cdc

Mar 29, 2005, 7:52 AM

Post #5 of 6 (2950 views)

Permalink

Hi Bernhard,

On Tue, Mar 29, 2005 at 04:03:50PM +0200, Bernhard Reiter wrote:
> sorry for answering so late, this email somehow slipped.

no problem.

> (For future reference: Ping me by email if you think that I might
> have missed an email on this public list.)

Noted, thanks.

> On Wed, Mar 02, 2005 at 11:25:00AM +0100, Christoph Ludwig wrote:
> > On Tue, Mar 01, 2005 at 09:27:26PM +0100, Bernhard Reiter wrote:
> > > On Tue, Feb 15, 2005 at 06:46:58PM +0100, Christoph Ludwig wrote:
>
> > > Note there are two workarounds at this point:
> > > a) hit the check signature funcation (usually bound to 'c')
> >
> > Thanks. Let me nit-pick, though: If I am in the key selection menu and press
> > '?' for help, then I am told that 'c' checks *PGP* keys. Of course, verify-key
> > also works for x509 certificates, but that is not implied by the help
> > message.
> >
> > Another point: The function "verify-key" is unfortunately named IMHO, because
> > it does not do what its name conveys. (a) If used in a S/MIME setting, it
> > operates on certificates, not keys. (I am not sure whether the distinction
> > between a public key and the certificate that binds the key to an identity
> > matters for Joe Average or if it only causes confusion. OTOH, as soon as one
> > has two different certificates for one key the terminology needs to be clear.)
> > (b) I tested the function with certificates in my key store that cannot be
> > validated. (The first has no valid from / to fields, the second has no
> > trusted root cert in the key store.) In both cases the relevant data from all
> > certs in the cert chain is displayed, but I get no message that there is a
> > problem with the certificates.
>
> All three points are valid criticism.
> When looking at the other bugs, they are not first priority, though.
> And I hope we would have enough capacity to deal with the others first. ;)
>
> So help is appreciated. You can create issues for our tracker to
> make sure that the points are not lost, too.

At least the help message in mutt is not that hard to fix, so I will ask our
students to do that first. (If they are not able to fix this problem, then
they won't pass the lab, I guess. :-)

The name of of the function "verify-key" is unfortunate, but it is not worth
changing the function name throughout the code, I guess - as long as the
documentation states clearly what the function does.

The most serious of above problems is (b), I think; and it is probably the
most complicated to fix. I will look into it and decide whether it is
something I can ask our students to work on or whether I better file a problem
report in your issue tracker.

> > > > 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.
> > >
> > > I think the meaning full label is not necessary and might be even a
> > > bit missleading, if user say "good" or so and the certificate is not good
> > > or so.
> >
> > I am not sure I understand your point. I want to associate the label when I
> > include the certificate in *my* key store. Of course, nobody stops me from
> > tagging a certificate that expires tomorrow with the string "a super-duper
> > cert that will be always valid". I can always shoot me in the foot
> > myself. But then I am the only one who the tag is presented to in
> > the key selection menu. I therefore do not see how such a label
> > could be abused to deceive someone else.
>
> No, it might be used to confuse yourself.
> My point is that the standard interface should be so good that you
> do not need the labels, thus avoiding that source of confusion for good.

I doubt whether it is possible to show in one 80 columns line enough
information that (a) always uniquely identifies each certificate and (b)
allows a human to *recognize* each certificate. (a) is guaranteed by the
fingerprint but you cannot expect the users to recall the fingerprints of
their certs. The information required for (b) may vary widely: You may have
certs for the same id, but issued by different CAs. You may have certs that
differ by their validity period only. You may have certs for one ID with
different usage restrictions etc.

Since you don't know in advance by which properties the user is going to
distinguish the certs, you need to show essentially all fields of the cert.
That is too much for one line. And even though I am everything but a usability
expert I expect that you should not dump all fields in a cert selection dialog
or the user won't see the wood for the trees.

That is why I think it is better to leave it to the user to assign some
additional tag that helps him or her to distinguish the available certs.

> > > > 2) I want to be given a choice among *valid* certificates only when
> > > > selecting a certificate for a signature.
> > >
> > > I agree that 2) would be useful, at least the information should
> > > be displayed better in the case of a expired certificate. If
> > > you like you can add this to the ägypten tracker as wish.
> > > https://intevation.de/roundup/aegypten
> >
> > Will do, thanks.
>
> I haven't seen it yet.
> (Did I miss it?)

It seems so. It is issue #305.

> > I had a discussion with colleagues whether we should ask students taking our
> > computer lab course to taggle issues we have with the S/MIME support in
> > GnuPG / mutt. (Don't hold your breath - the number of students who can produce
> > good quality C/C++ code is unfortunately quite small.)
>
> Yes, and this being in the security area makes this even a larger problem.
>
> > If we actually do this,
> > where should we coordinate what we ask our students to work on?
>
> Basically on this list and monitoring the relevant mutt and gnupg lists.
>
> > There might be
> > patches you do not agree with and that will not go into GnuPG, but if we ask
> > our students to resolve problems also mentioned on the ägypten tracker then I
> > want to make sure it's not something you are also working on. (The tracker
> > shows many items where the last reported activity was several months ago. Does
> > that mean that nobody is working on them or where they eventually resolved but
> > for some reason never closed in the tracking system?) And where do you discuss
> > proposed patches?
>
> We discuss proposed patches here on this list or via other ways
> as some developer meet in person from time to time.
> Sometimes is also makes sense to put a patch in the tracker.
>
> The problem is the sheer number of smaller problems that we cannot
> tackle alone. If a bug has not been acted upon, you should always ping
> in the issue before working on it. Those bugs in the tracker should be real.
>
> Of course we appreciate any help, but you should not that some of
> the bugs might turn out really, really hard to fix.
> Especially the more annoying ones. Otherwise the people of g10code
> would have fixed it long ago. You just need to be prepared that this
> is not an easy exercise. ;-)

OK, we will keep it in mind.

Regards

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

Re: problems with mutt's gpgme setup [ In reply to ]

bernhard at intevation

Mar 30, 2005, 2:23 AM

Post #6 of 6 (2918 views)

Permalink

On Tue, Mar 29, 2005 at 04:52:21PM +0200, Christoph Ludwig wrote:
> On Tue, Mar 29, 2005 at 04:03:50PM +0200, Bernhard Reiter wrote:

> > All three points are valid criticism.
> > When looking at the other bugs, they are not first priority, though.
> > And I hope we would have enough capacity to deal with the others first. ;)
> >
> > So help is appreciated. You can create issues for our tracker to
> > make sure that the points are not lost, too.
>
> At least the help message in mutt is not that hard to fix, so I will ask our
> students to do that first. (If they are not able to fix this problem, then
> they won't pass the lab, I guess. :-)

;)

> The name of of the function "verify-key" is unfortunate, but it is not worth
> changing the function name throughout the code, I guess - as long as the
> documentation states clearly what the function does.

I agree.

> The most serious of above problems is (b), I think; and it is probably the
> most complicated to fix. I will look into it and decide whether it is
> something I can ask our students to work on or whether I better file a problem
> report in your issue tracker.

Thanks.

> > My point is that the standard interface should be so good that you
> > do not need the labels, thus avoiding that source of confusion for good.
>
> I doubt whether it is possible to show in one 80 columns line enough
> information that (a) always uniquely identifies each certificate and (b)
> allows a human to *recognize* each certificate. (a) is guaranteed by the
> fingerprint but you cannot expect the users to recall the fingerprints of
> their certs. The information required for (b) may vary widely: You may have
> certs for the same id, but issued by different CAs. You may have certs that
> differ by their validity period only. You may have certs for one ID with
> different usage restrictions etc.
>
> Since you don't know in advance by which properties the user is going to
> distinguish the certs, you need to show essentially all fields of the cert.
> That is too much for one line. And even though I am everything but a usability
> expert I expect that you should not dump all fields in a cert selection dialog
> or the user won't see the wood for the trees.
>
> That is why I think it is better to leave it to the user to assign some
> additional tag that helps him or her to distinguish the available certs.

I agree that there need to be further criteria to limit what is displayed.
My idea is that therefore a label is not necessary, but that the user
can use a different application (e.g. like gpa or kleopatra) to make
the necessary settings so that mutt will only propose the best uids by default.
The goal should be that mutt does not need to select keys at all.

For KMail and KAddressbook during Ägypten2 we implemented settings
that saved the crypto preference of each address.
So the goal should be: In normal situation when sending email: No
key selection should be necessary. Other applications can completely
deal with all options.

> > > > > 2) I want to be given a choice among *valid* certificates only when
> > > > > selecting a certificate for a signature.
> > > >
> > > > I agree that 2) would be useful, at least the information should
> > > > be displayed better in the case of a expired certificate. If
> > > > you like you can add this to the ägypten tracker as wish.
> > > > https://intevation.de/roundup/aegypten
> > >
> > > Will do, thanks.
> >
> > I haven't seen it yet.
> > (Did I miss it?)
>
> It seems so. It is issue #305.

Ah, thanks.

Mailing List Archive

Attached Files:

Attached Files: