Subject: "The OpenPGP mail and news header" extenssion

From: David Srbecky <[email-masked]>
Date: Wed, 10 Aug 2005 19:16:31 +0200

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?

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.

 > Should it be in preferred priority order?

Yes.

I would also add 'preferred' field, which could take values 'insecure', 
'signed', 'encrypted' and 'signed,encrypted'.

Regards,
David Srbecky

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 11 Aug 2005 11:48:52 +0200

> file and are intended to replace it.

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.

>  - It would be possible to get the value before you receive any mail 

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.

> I would also add preferred field, which could take values 'insecure', 

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

---

From: David Srbecky <[email-masked]>
Date: Thu, 11 Aug 2005 19:13:57 +0200

> 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'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.

> 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.

Maybe we can rename preference=insecure to something better. Ideas?

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.

Sender wants to receive signed unencrypted messages.

Sender wants to receive signed encrypted messages.

Thanks,
David

---

From: Ian G <[email-masked]>
Date: Thu, 11 Aug 2005 19:10:57 +0100

> assume that preference=encrypt also means that recipient wants to 

Er, I hope not!  There are plenty of reasons to
encrypt-only.  Until someone can define the meaning
of a signature, my standard advice is to not sign,
which I'd recommend for all email, IM and so forth.

iang

---

From: David Srbecky <[email-masked]>
Date: Thu, 11 Aug 2005 20:17:25 +0200

Ian G wrote:
 > David Srbecky wrote:
 >
 >>>> I would also add preferred field, which could take values 
'insecure', 'signed', 'encrypted' and 'signed,encrypted'.
 >> 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.
 > which I'd recommend for all email, IM and so forth.

I take it as that you advice to include preference=sign,encrypt

Out of curiosity, is there any difference between 
preference=sign,encrypt and preference=encrypt,sign ? I mean, does the 
order matter? Can you both sign encrypted message and encrypt signed 
message? (Where the later means that you can not verify signature until 
you decrypt the message)

David

---

From: Richard Laager <[email-masked]>
Date: Thu, 11 Aug 2005 13:15:44 -0500

> Maybe we can rename preference=insecure to something better. Ideas?

Maybe one of these four options: preference={clear,plain}(text)?

Richard Laager

---

From: Simon Josefsson <[email-masked]>
Date: Thu, 11 Aug 2005 21:59:55 +0200

David Srbecky <[email-masked]> writes:

>>> 'version', 'comment' and 'signature' are taken from the
>>> "signature.asc" file and are intended to replace it.

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.

>>> insecure', 'signed', 'encrypted' and 'signed,encrypted'.

The discussion here made me realize there may be merit with all three
variants.

> 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.

> 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

---

From: David Srbecky <[email-masked]>
Date: Thu, 11 Aug 2005 23:55:59 +0200

> document.  There are many details that has to be solved.
This is something I hoped to be helped with. I think I lack the required 
language skill, background knowledge and experience to write a standard.

Do you want to help?

Please!!!

> The discussion here made me realize there may be merit with all three
Three or maybe even four, five? I was trying to decide whether to use 
preference=sign,encrypt or preference=encrypt,sign and I realized that 
they may be different. You can:

  - sign and then encrypt - in which case only the recipient can verify 
signature after decryption
  - encrypt and then sign - in which case anyone can verify the 
signature before decryption, but no-one after decryption
  - sign, encrypt and then sign again - in which case anyone can verify 
signature before decryption and also the recipient can verify signature 
after decryption (in case someone likes to store decrypted messages)

Is that correct?

Anyway, I vote to use preference=encrypt,sign and ignore the rest. At 
least for the moment.

> messages, that would be a security problem.
You are absolutely correct - it is really difficult issue. In other 
words, preference should increase security, but never decrease.

I think it is possible to do just fine without preference=insecure. For 
example, MUA can set the default (minimal) security based on that 
whether recipients email address is on keyserver. If yes, sign by 
default. If no, send insecure message by default. This way, everyone 
with public key will get at least signed message and others (including 
maillists) will get signed messages only if they wish.

Still, the best solution is to complement the preference with attributes 
stored in public key.

Thanks,
David

---

From: Ian G <[email-masked]>
Date: Fri, 12 Aug 2005 08:39:22 +0100

> I take it as that you advice to include preference=sign,encrypt

Yes, that would be better.

> message? (Where the later means that you can not verify signature until 

The order does matter, but in OpenPGP (IIRC) there
is only sign-then-encrypt.  Other systems offer
different orders.

Another possibility is that there are two forms of
signature - being cleartext and binary.  These two
are certainly subject to preferences so you might
want to include them some how.

Then there is the issue of format for delivery,
which would be either of ascii-armored, binary
attachment, or pgp/mime.

(out of those, my setting would be encrypt,ascii).

Some or all of these may be expressed in the preferences
in the keys themselves in some sense.

iang

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 12 Aug 2005 11:38:28 +0200

> message? (Where the later means that you can not verify signature until 

* encrypt(sign(message))

The receiver is the only one being able to read it and knows it comes
from you.

* sign(encrypt(message))

This allows one to send a message, encrypted to another person, that
person sees you send it, because of the signature, and that person can
only read it, because of the crypt.

Advantage here for privacy freaks: the receiver can never prove that the
received message (cleartext) was sent by you. The person can only show
the encrypted form, which doesn't tell a thing, unless that person shows
in public that the person decrypts it, which nicely shows everybody that
that person is telling some secret from you to the world. Of course if
that person doesn't care about the latter then you are still stuffed,
nothing to repudiate.

* encrypt(sign(encrypt(message)))

Like sign(encrypt) except that if somebody finds this thing that they
can't figure out who the sender is, they can only identify the receiver.

Greets,
 Jeroen

---

From: Ben Laurie <[email-masked]>
Date: Sun, 14 Aug 2005 14:18:39 +0100

> Sender wants to receive signed unencrypted messages.

Why would I care whether the sender wants to receive signed messages? 
Surely its all about whether I want to sign my messages? His preference 
is irrelevant, he can check the signature or not as he pleases.

-- 
 >>>ApacheCon Europe<<<                   http://www.apachecon.com/

http://www.apache-ssl.org/ben.html       http://www.thebunker.net/

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: Ben Laurie <[email-masked]>
Date: Sun, 14 Aug 2005 14:24:54 +0100

> that person doesn't care about the latter then you are still stuffed,

More importantly, perhaps, Krawczyk has shown that, in general, sign 
then encrypt is insecure.

--

---

From: David Srbecky <[email-masked]>
Date: Sun, 14 Aug 2005 15:39:12 +0200

> Why would I care whether the sender wants to receive signed messages?

You want to be polite and help to enhance the security.

> is irrelevant, 

Using preference=sign he explicitly expresses that he *wants* to receive
signed messages. For example some people do not sign messages to
maillist, but if the maillist sends you preference=sign, it means that
it really *wants* signed messages.

> he can check the signature or not as he pleases.

How can he do that if you do not sign the message?

The same holds for preference=encrypt.

David

---

From: Ben Laurie <[email-masked]>
Date: Sun, 14 Aug 2005 14:44:37 +0100

Ian G wrote:
> Until someone can define the meaning

Oh, please, the meaning of signatures is perfectly well defined in law.

--

---

From: Ben Laurie <[email-masked]>
Date: Sun, 14 Aug 2005 14:43:40 +0100

> The same holds for preference=encrypt.

A preference for encrypted messages is a different thing, it doesn't 
harm the sender of the message in any way.

Signing messages weakens plausible deniability. It may imply some 
standing that is not necessarily intended. These things can harm the sender.

Cheers,

Ben.

--

---

From: David Srbecky <[email-masked]>
Date: Sun, 14 Aug 2005 15:57:08 +0200

> standing that is not necessarily intended. These things can harm the

If this is your consern, just ignore the flag and never sign messages,
but please, let me tell you that I *prefer* signed messages.

David

---

From: Ian G <[email-masked]>
Date: Sun, 14 Aug 2005 15:00:32 +0100

> Oh, please, the meaning of signatures is perfectly well defined in law.

Sorry I meant digital signatures.

iang

---

From: David Srbecky <[email-masked]>
Date: Sun, 14 Aug 2005 16:12:21 +0200

> document.  There are many details that has to be solved.

Could you please outline a few of these details to be solved?

Thanks,
David

---

From: Ben Laurie <[email-masked]>
Date: Sun, 14 Aug 2005 15:39:32 +0100

> Sorry I meant digital signatures.

Well, in the UK, it is the Law Society's opinion that existing law 
applies equally to digital signatures.

--

---

From: Ian G <[email-masked]>
Date: Sun, 14 Aug 2005 15:52:44 +0100

> applies equally to digital signatures.

Good for them.  So does that mean when user
software uses a digsig to ensure message
integrity, it also committed the user to
a contract?

In general, most of the digsig laws tended to
fall back to stating that a digital signature
was not to be rejected as a signature just
because it was in digital form.  Others said
something much more complicated, and often
created two disctinct legal regimes for digsigs.

In all that, there remains a huge difference
in the meaning of any given signature.  Most
applications have muffed this issue, often
ascribing in vague terms several distinct
purposes at once to the digsig.

(OpenPGP has been most wise and ascribes no
meaning to it, that I know of, which means it
is up to the users to negotiate.)

iang

---

From: Ben Laurie <[email-masked]>
Date: Sun, 14 Aug 2005 15:53:45 +0100

> integrity, it also committed the user to

No, it means much the same as a written signature - that is, whatever 
was intended by the two parties, as should be clear from the signed 
document.

> purposes at once to the digsig.

That's because signatures _are_ vague. IMO, attempts by techies to make 
signatures rigorous are misguided.

--

---

From: Ben Laurie <[email-masked]>
Date: Sun, 14 Aug 2005 16:30:55 +0100

Jeroen Massar wrote:
> On Sun, 2005-08-14 at 14:24 +0100, Ben Laurie wrote:
> 
>>Jeroen Massar wrote:
> 
> <SNIP>
> 
>>>* sign(encrypt(message))
> 
> <SNIP>
> 
> Which exact paper do you mean?

http://eprint.iacr.org/2001/045

> Also note that when you say that that is insecure you are also saying
> that either/both the signing and/or the encryption are insecure in which
> case the solution to the problem should be sought in a different
> place...

I have no idea what you mean.

--

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 14 Aug 2005 17:26:32 +0200

<SNIP>
<SNIP>

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 14 Aug 2005 17:45:05 +0200

> http://eprint.iacr.org/2001/045

Which nicely says, already in the abstract btw, "Thus, while we show the
generic security of SSL to be broken, the current standard
implementations of the protocol that use the above modes of encryption
are safe."

Also, to really take care of your worries, one could do:
encrypt(sign(encrypt(message)) which gives the same properties I
specified before, although with some overhead. It will actually give an
additional property that only the receiver is known and nobody else can
figure out who send the message.

Greets,
 Jeroen

---

From: Ben Laurie <[email-masked]>
Date: Sun, 14 Aug 2005 16:52:29 +0100

> implementations of the protocol that use the above modes of encryption

Sure. What does this have to do with OpenPGP's security?

--

---

From: Ben Laurie <[email-masked]>
Date: Sun, 14 Aug 2005 17:34:14 +0100

Jeroen Massar wrote:
> On Sun, 2005-08-14 at 16:52 +0100, Ben Laurie wrote:
> 
>>Jeroen Massar wrote:
>>
> psst... it was you bringing up that argument about the paper ;)

Indeed - the result is general. The fact that SSL is secure gives no 
comfort for OpenPGP.

--

---

From: Jeroen Massar <[email-masked]>
Date: Sun, 14 Aug 2005 18:31:58 +0200

Greets,
 Jeroen

---

From: Thomas Roessler <[email-masked]>
Date: Sun, 14 Aug 2005 17:40:20 +0200

> Oh, please, the meaning of signatures is perfectly well defined

More precisely, it is perfectly well defined in any number of laws,
in any number of jurisdictions, and with any number of different
results.

(Just like the term "signature" itself, by the way.)

-- 
Thomas Roessler, W3C   <[email-masked]>

---

From: Jon Callas <[email-masked]>
Date: Sun, 14 Aug 2005 16:17:27 -0700

> which I'd recommend for all email, IM and so forth.

Oh, but Ian, it's my preference that you sign messages you send to me.

It's *my* preference that I not sign, as I pretty much agree with you.

This is just like my preference that everyone who phones me use caller 
id, but my preference that I disable it.

	Jon

---

From: Konrad Rosenbaum <[email-masked]>
Date: Mon, 15 Aug 2005 07:50:28 +0200

> standing that is not necessarily intended. These things can harm the

On the other hand: not signing weakens the receivers trust into the sender. 
Just as an example: I can't be sure that your advise to not use signatures 
comes from a knowledgable OpenPGP expert, it could as well come from a 
spammer lobbying against the use of crypto because it harms his business 
model.

	Konrad

---

From: Konrad Rosenbaum <[email-masked]>
Date: Mon, 15 Aug 2005 07:46:04 +0200

> Indeed - the result is general. The fact that SSL is secure gives no

The abstract also states that using the cipher in CBC is secure. When last I 
looked OpenPGP used CBC.

	Konrad

---

From: Ben Laurie <[email-masked]>
Date: Mon, 15 Aug 2005 10:27:44 +0100

> The abstract also states that using the cipher in CBC is secure. When last I 

Look again, then. OpenPGP uses CFB.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 15 Aug 2005 10:29:14 +0100

> spammer lobbying against the use of crypto because it harms his business 

True enough, but the argument should stand no matter who I am.

If you want to protect against spam using signatures there are other 
ways to do it that don't involve signing the content.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 15 Aug 2005 10:27:44 +0100

---

From: Ben Laurie <[email-masked]>
Date: Mon, 15 Aug 2005 10:29:14 +0100

---

From: Simon Josefsson <[email-masked]>
Date: Mon, 15 Aug 2005 11:43:10 +0200

> Could you please outline a few of these details to be solved?

Canonicalization of the content to sign; it is not clear exactly what
data should be signed.  How to cope with gateway's that modify the
message need also be discussed, e.g., you likely will need to use
7-bit MIME to be reasonable sure the message arrive intact.

The OpenPGP header is not intended to be security critical or
trust-worthy.  The point of it was to assist mail clients or mailing
list software to be able to provide a better default user experience.
Changing that header to embed signature information changes
fundamental assumption of what the header should be about, so I'd
rather not work on this now.

I do encourage you to try to experiment with the idea though.  The
tag=value structure of the OpenPGP header would allow you to use the
same header name, although if you want to support S/MIME signatures in
the same header, I think using Signature: may be cleaner.  And in
general, what the header is called is not that important.

Regards,
Simon

---

From: Konrad Rosenbaum <[email-masked]>
Date: Tue, 16 Aug 2005 07:50:55 +0200

On Monday 15 August 2005 11:29, Ben Laurie wrote:
> Konrad Rosenbaum wrote:
> > On the other hand: not signing weakens the receivers trust into the
> > sender. Just as an example: I can't be sure that your advise to not use
> > signatures comes from a knowledgable OpenPGP expert, it could as well
> > come from a spammer lobbying against the use of crypto because it harms
> > his business model.
>

Hmm, bad example. I do not want to protect myself agains spam using 
signatures (bayes filters are far more useful in that area), I want to 
protect myself against impostors claiming to be trustworthy people and fool 
me into doing something stupid.

	Konrad