Re: Thoughts on an OpenPGP header?
"Peter J. Holzer" <hjp+mutt@xxxxxxxxx> writes:
> On 2004-12-03 18:16:03 +0100, Simon Josefsson wrote:
>> Hi. We are preparing a document that aims to merge all X-PGP,
>> X-PGP-Fingerprint etc headers into one well defined header, for use in
>> mail and news. The document is available from:
>>
>> http://josefsson.org/openpgp-header/
>>
>> I'm writing to see if there is any interest in supporting this in
>> Mutt. General thoughts on the concept or the document would be
>> appreciated, too, of course.
>
> [First off, I am not a mutt developer, just a user (who submits a patch
> every few years :-)]
>
> While I won't debate that some users are adding such a header, I fail to
> see the need for it.
Yes, we should work on clarifying the motivation in the document.
> Either a mail is PGP-signed, or it isn't.
>
> If it is signed, it already contains the key id, algorithm, etc., so
> this doesn't have to be added to the header. There is also already an
> infrastructure for looking up keys, so including an URL where the key
> can be obtained seems to be mostly pointless to me - why not just upload
> the key to a keyserver?
Right.
> If the mail is not signed, including information about a key which may
> or may not be used on other mails seems to be of rather dubious value.
I'm not sure about this. Compare Enigmail, it has a header like this:
X-Enigmail-Supports: pgp-inline, pgp-mime
The OpenPGP: header may serve a similar purpose; to let others know
that you support PGP/MIME. (Discussing pgp-inline should be avoided,
in my opinion, because it has too many problems, and is not
standardized as the IETF way to send OpenPGP through e-mail.)
> So I can see only two scenarios where such a header would be useful:
>
> 1) You want to sign your messages and provide an URL where your key
> can be found to the recipients only, but you don't want your key on a
> keyserver, where everybody could download it and e.g. check its
> position in the web of trust.
Right. Perhaps not a winning scenario, but plausible.
> 2) You don't want to sign you messages for some reason but still want to
> convey the information that you can use PGP if you need to.
Perhaps this is more useful. Compare Enigmail that uses a special
header for this.
> Oh, well - since implementing support for such a header is trivial,
> these two scenarios might suffice.
I think so. The intention is not the require any behavior in MUAs
that support OpenPGP, because this is not something that is critical
to proper operation, but to add a small convenience.
>> but one thing that could be implemented is this: when the user click
>> on a URL in the OpenPGP: header, the URL could be retrieved, and 'gpg
>> --import' is invoked on it.
>
> Mutt can already do this if the mail is signed (it will import the key
> from a keyserver). You can't "click" on anything in mutt, but sending
> the message through a filter to look for an OpenPGP header and import
> the key from the included URL would be simple (a few lines of perl or
> your favorite scripting language).
A possible improvement with OpenPGP: would be to compare the retrieved
key against the size/algo/created values in OpenPGP: to prevent the
0xDEADBEEF attack for v3 keys. I don't know if anyone is worried
about that attack in the real world, though.
>> Another is a "Secure reply" button, that uses the Key ID information
>> in the header, to make a signed/encrypted reply to a message.
>
> The way mutt chooses the key(s) to encrypt a message with could surely
> be improved (in mutt 1.4.x at least, I don't know the current status in
> 1.5.x). Taking the key id from the OpenPGP header might be a good idea.
Presumably it uses the To: e-mail address, and let GnuGP select the
correct key id.
I have had problems with this in the past, because I have many PGP
keys with different IDs, and sometimes GnuGP has selected the wrong
key. The latest 1.2/1.3 branch doesn't have this problem, but 1.9
does.
Further, as far as I know, the OpenPGP specification doesn't say
anything about how to select the "right" key id given an e-mail
address. So documenting a way to do this without relying on GnuPG
specific features might be useful.
Thanks,
Simon