[Aegypten] Bogus messages about certificates?

[Ingo Klöcker]

--Boundary-02=_sGKm9fwZNkpvcTM
Content-Type: text/plain;
  charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Content-Description: signed data
Content-Disposition: inline

On Monday 30 September 2002 09:06, Werner Koch wrote to=20
aegypten-intern@intevation.de:
> On Sat, 28 Sep 2002 14:07:01 +0200, Bernhard Reiter said:
> > Needs a good answer.
> > Some things are BUGS (some already known for a long time).
> > Some crypto things about SPHINX need to be explained.
> >
> > From: Ingo Kl=F6cker <kloecker@kde.org>
> > Subject: [Aegypten] Bogus messages about certificates?
> > To: kmail@kde.org, gpa-dev@gnupg.org
> >
> > But the signature on a message which was signed with a certificate
> > that
> > had not expired by the time the message was signed will always be
> > valid
> > (as long as the certificate isn't revoked).
>
> No.  The signature is not valid after the expiration time of the
> certificate.  The reason to use an expiration time is to make it
> impossible for an attacker to issue a signature using a compromised
> key belonging to an expired certificate.  The way a signature
> verification should be handled in the workflow of an office is by
> registering valid signed documents by other means.

I understand. This would mean that every incoming document would have to=20
be signed with a local key which of course must never expire. Do you=20
know of any MUA or MTA that does this?

> The warning we display should mention that the certificate has been
> valid at the *claimed* time the signature has been created but
> nevertheless we can't know anything more. I think we agreed on
> displaying it in green with that warning.

That's fine with me. But then we might also add a warning that a valid=20
signature which was made with a not-expired key could also be forged.=20
Nothing is 100% secure. I don't think it's more likely that an expired=20
key is compromised than that a not-expired key is compromised. In both=20
cases the key must be revoked immediately. In my understanding=20
"expired" simply means "isn't used anymore". It does not mean "could=20
have been compromised in the meantime".

> > Is this also a Sphinx requirement that the certificate has to
> > contain the email address of the sender?
>
> Yes.

Then you should probably implement the function which checks this. ;-)

> > To check whether an email message really came from the sender one
> > simply checks the signature. The address in the From: header is
> > completely irrelevant. Of course, it might be worthwhile to warn
> > the recipient
>
> No it isn't.  A MUA uses the From/Reply-To header for an reply.  This
> can be used to trick the recipient into replying to the wrong person
> and for example agreeing on a contract.

Then the receiving MUA should also complain if the From/Reply-To header=20
doesn't match the key. I don't see where you implemented this in KMail.=20
;-)

> > when the sender's address isn't contained in the signing
> > certificate. But this certainly doesn't make the signature invalid.
>
> No it is not invalid, but a note should be printed.

O.k., but with the option to "Don't show this warning again.". At least=20
for not paranoid KDE users.

> > BTW, do we really have to call it certificate? In the OpenPGP world
> > this is usually called key instead of certificate.
>
> Agreed, however certificate is more exact and so I don't see an
> urgent reason to change it.

Well, the reason is that we use "key" everywhere else in KMail and that=20
"certificate" isn't common language while "key" is. Even GnuPG uses the=20
term certificate only for revocation certificates.

But today the message freeze began. So we shouldn't upset the=20
translators and leave it for now.

Regards,
Ingo

--Boundary-02=_sGKm9fwZNkpvcTM
Content-Type: application/pgp-signature
Content-Description: signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)

iD8DBQA9mKGsGnR+RTDgudgRAn/4AJwKQLUIAzjhzg3S+T48cyaE+6A2KgCghdGE
DA87STLk3a0D8thAbv/8QO8=
=IhxQ
-----END PGP SIGNATURE-----

--Boundary-02=_sGKm9fwZNkpvcTM--