OpenPGP data in the CERT RR

John A. Martin jam at
Tue Aug 6 16:43:01 CEST 2002

Hash: SHA1

>>>>> "Simon" == Simon Josefsson
>>>>> "Re: OpenPGP data in the CERT RR"
>>>>>  Tue, 06 Aug 2002 14:25:42 +0200

    Simon> Header-sender ("From:") shouldn't be rewritten, I think,
    Simon> and is a suitable guess.  SMTP envelope sender is pretty
    Simon> useless, yes.

Many outgoing mail relays will munge From: <foobar at> into
<foobar at>.  That is just one example used by many who you might
find reluctant to accept that they shouldn't be doing it.  Besides,
there are a lot of misguided mailers out there.  An X-something header
field would however be likely to be munged only in an effort to
interfere specifically with the PGP operation.

For completeness one might well be lead to consider other originator
header fields, such as "Reply-To" fields.  It would seem that the
complexities of dealing with munged, falsified, or alternate forms may
not be worthwhile compared to the simplicity of an X-something header

Besides the problems faced by users who do not necessarily have full
control of the header-sender fields that may be present in their
mails, consider those who may use a multitude of sender addresses.
Besides encouraging a proliferation of PGP user IDs it seems contrary
to the _privacy_ part of PGP to encourage folks to carry a user ID for
each and every domain from which they may want to send PGP mail.  How
should a contract worker, for example, explain to his clients that
they will have less convenient access to his keys because he chooses
not to list all his clients' domains on his PGP key.

It might avoid a lot of problems to designate an optional mail header
field in the sense of Section 3.6.8 of rfc2822 rather than to overload
existing mail header fields to carry information for purposes other
than the purposes those fields already serve.




More information about the Gnupg-devel mailing list