David Srbecky <dsrbecky(_at_)gmail(_dot_)com> writes:
Hello,
I have recently discovered the power of OpenPGP. However, some of my
friends now complain that my messages either contain some strange
---SIGNATURE--- (inlining) or some strange attachment (PGP/MIME). Since
I doubt that OpenPGP will ever be supported by *all* MUAs, I thing think
that the only ultimate solution is to save the signature in the header.
I think this simple extension should be sufficient:
OpenPGP: id=12345678;
url=http://example.com/key.txt;
modification=Tue, 9 Aug 2005 13:59:18 +0200 (CEST);
version=GnuPG v1.4.1 (MingW32);
comment=Using GnuPG with Thunderbird;
signature=iD8DBasdQFC+Jqasd5X6K7Lza8L3FgC3GU2joRAkV+AaJ9AqD/Fs=
'modification' holds the date of last modification of the public key;
MUA can use it to detect whether the public key update is necessary.
(not directly related to the topic, but good(?) idea anyway)
'version', 'comment' and 'signature' are taken from the "signature.asc"
file and are intended to replace it.
What do you think?
Hello.
That is an interesting idea, and it does have some nice properties.
However, I'm not sure the OpenPGP community will be helped by having
yet another way of sending signed messages. We have effectively three
different flavors today. (Vanilla OpenPGP, PGP/MIME and a hybrid
scheme.) If you are complaining about of lack of implementation
support now, I doubt things won't be better with a fourth variant....
However, it is good to float this idea, to influence people to think
differently.
FWIW, I now recall a scheme used on UseNet, called X-PGP-Sig, it may
be something like what you propose. I don't have more information on
it though.
PS: My opinion to the "Open Issues:'supports' field" is that is a very
good idea, but OpenPGP header is the wrong location. I think it should
be part of public key itself for two reasons:
- The value would be unique and could be updated from keyserver at any
time
- It would be possible to get the value before you receive any mail
from the given person.
Yes, these are valid reasons. IIRC, there are proposals for a public
key notation packet for similar purposes. However, there are some
situations where BOTH are useful. Or put differently, they are not
mutually exclusive, but rather complementary.
For example, when a mailing list want PGP signed messages. It could
inject a 'OpenPGP: supports=pgpmime' header on all messages. Then
recipient MUAs would be able to turn on PGP signing automatically.
There is no public key that could contain a notation packet that would
inform you of that.
However, I am in general opposed to suggest vanilla PGP in e-mail in
IETF standards until someone actually explain how to implement it.
Vanilla PGP in e-mail is not interoperable today, because there is no
description on how to handle things like non-ASCII, attachments and so
on.
Should it be in preferred priority order?
Yes.
I would also add preferred field, which could take values 'insecure',
'signed', 'encrypted' and 'signed,encrypted'.
I initially thought this was over-engineering, but on second thought,
it may be useful. Consider:
OpenPGP: id=b565717f; url=http://josefsson.org/key.txt; preference=sign
That would tell recipients that I wish to receive signed PGP/MIME
e-mail.
OpenPGP: id=b565717f; url=http://josefsson.org/key.txt; preference=encrypt
That would tell them I want message encrypted. Whether those messages
are also signed could be up to the sender. I'm not sure a
"signencrypt" value is useful. Thoughts?
I don't think a "insecure" value is useful; if the preference token is
absent, that would mean the same as insecure.
Thanks,
Simon