Re: problems with mutt's gpgme setup

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 <[email protected]>
> >    2 x  1024/0xC1D60643 RSA  es <[email protected]>
> > 
> >    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