David Srbecky <dsrbecky(_at_)gmail(_dot_)com> writes:
Simon Josefsson wrote:
David Srbecky <dsrbecky(_at_)gmail(_dot_)com> writes:
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=
'version', 'comment' and 'signature' are taken from the
"signature.asc" file and are intended to replace it.
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....
I am not complaining about of lack of implementation. There are always
going to be people with old or incompatible clients - even if the
implementation involved only a minor change of a single line code! What
I want is to use secure e-mail and not to bother anyone, at all - even
for the cost that only a few people will be able to verify my signature.
Such standard does not exist yet and so I suggest one :-)
I understand. Implement your scheme and write a draft about it! I
think your ideas are too far-fetching to be reasonable added to this
document. There are many details that has to be solved.
I would also add preferred field, which could take values
insecure', 'signed', 'encrypted' and 'signed,encrypted'.
I'm not sure a "signencrypt" value is useful. Thoughts?
It makes it complete, but I agree with you. I do not see a reason why
someone would like to receive encrypted unsigned message. Thus, I would
assume that preference=encrypt also means that recipient wants to
receive messages signed.
The discussion here made me realize there may be merit with all three
variants.
I don't think a "insecure" value is useful; if the preference token is
absent, that would mean the same as insecure.
Not necessarily. Absence of preference token means that sender does not
support preference token or intentionally has not expressed any preference.
On the other hand, preference=insecure means that user does *not* want
to receive any signed or encrypted messages. I would imagine that many
maillists will use this option to keep their messages clean.
I'm not sure this is a good idea. The OpenPGP header is not protected
in any way. If someone inject a 'OpenPGP: preference=insecure' and
that caused MUAs to avoid a default behavior of signing/encrypting
messages, that would be a security problem.
Maybe we can rename preference=insecure to something better. Ideas?
I'm not sure the problem is in the name, it is in the semantics. A
preference token should not enable downgrade attacks.
To sum it up:
OpenPGP: id=b565717f; url=http://josefsson.org/key.txt
Sender does not support preference token or has not expressed any
preference. You must decide whether to sign/encrypt message.
OpenPGP: id=b565717f; url=http://josefsson.org/key.txt; preference=insecure
Sender does *not* want to the receive any signed or encrypted messages.
OpenPGP: id=b565717f; url=http://josefsson.org/key.txt; preference=sign
Sender wants to receive signed unencrypted messages.
OpenPGP: id=b565717f; url=http://josefsson.org/key.txt; preference=encrypt
Sender wants to receive signed encrypted messages.
Makes sense in theory, but I'm worried that the 'insecure' preference
will be incorrectly implemented, and that it would allow downgrade
attacks.
But if you make a good argument, you'll convince me otherwise.
Thanks,
Simon