Subject: Re: Encrypt subject

From: [email-masked] ("Hal Finney")
Date: Wed, 31 Aug 2005 15:40:25 -0700 (PDT)

Karl Kashofer writes:
> We have Comment: and Hash: lines inside the PGP markers, why cant we
> have Subject: ?
> I think this is a shortcoming of PGP email encryption and should be
> fixed, dont you ?

The problem is that we do sort of have a solution to this already, which
Werner described: use PGP/MIME.  MIME allows for embedding one email
message inside another, and the MIME security extensions, including
PGP/MIME, show how to encrypt such an embedded message.

The problem is that almost no mailers support this.  Few enough even
support PGP/MIME, and then they would also have to be smart enough to
figure out what to do with an embedded email message.  Replacing the
enclosing message's headers with those from the embedded message is not
an obvious thing to do.

Your solution is simpler but it would still require implementation
in the mailers.  They would have to decrypt the message and then move
the data from this new Subject: header up to the outer mail headers.
This requires tight integration between the mail agent and the encryption
layer of a type which generally does not exist today.

Instead of rewriting mail agents to do this, it would probably be more
productive to work to get wider general support for PGP/MIME, along with
support for embedding email messages to protect the headers.

Hal Finney

---

From: Cyrus Daboo <[email-masked]>
Date: Wed, 31 Aug 2005 20:09:37 -0400

Hi Hal,

> ... it would probably be more

What would be useful is a hint to receiving clients to 'promote' the 
embedded message/rfc822 header out of the multipart/signed. Perhaps we 
could have a MIME header in the message/rfc822 part to indicate that. We 
could try something like:

Content-Disposition: promote-headers

or invent a new header for this purpose. The one benefit of 
Content-Disposition is that it is easily accessible via IMAP.

-- 
Cyrus Daboo

Date: Wed, 31 Aug 2005 20:09:37 -0400
From: Cyrus Daboo <[email-masked]>
To: Hal Finney <[email-masked]>, [email-masked]
Subject: Re: Encrypt subject
Sender: [email-masked]

Hi Hal,

> ... it would probably be more

What would be useful is a hint to receiving clients to 'promote' the 
embedded message/rfc822 header out of the multipart/signed. Perhaps we 
could have a MIME header in the message/rfc822 part to indicate that. We 
could try something like:

Content-Disposition: promote-headers

or invent a new header for this purpose. The one benefit of 
Content-Disposition is that it is easily accessible via IMAP.

-- 
Cyrus Daboo

To: [email-masked]
Subject: Re: Encrypt subject
Date: Wed, 31 Aug 2005 15:40:25 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Hal Finney

Date: Wed, 31 Aug 2005 17:26:56 +0200
To: [email-masked]
Subject: Information and meta-information
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

This email about encrypting the subject reminded me of a more general issue
that I wanted to bring up here. I think that the current PGP/MIME standard
has a very annoying flaw that is relatively easy to fix. Here's a short
description:

There is no distinction between PGP/MIME data and regular RFC2440 data,
although all it would take is a flag in the Literal packet. This way, if I
saved the PGP MESSAGE from an application/pgp-encrypted MIME chunk (which is
doable even with MUAs ignorant of PGP/MIME), I could still decrypt it into a
usable file (e.g. a jpeg image).

I would suggest the following modification of RFC2440bis-14:

5.9. Literal Data Packet (Tag 11)

   A Literal Data packet contains the body of a message; data that is
   not to be further interpreted.

   The body of this packet consists of:

     - A one-octet field that describes how the data is formatted.

   If it is a 'b' (0x62), then the literal packet contains binary data.
   If it is a 'm' (0x6D), then the literal packet contains data in MIME
   canonical format.

Date: Wed, 31 Aug 2005 14:26:58 +0100
From: Karl Kashofer <[email-masked]>
To: [email-masked]
Subject: Re: Encrypt subject
Sender: [email-masked]

Hi !

> True enough - so don't put any important information into the subject. Just
> use something standard like "Re: your mail" or use the output of M-x spook if
> you are feeling mischievous.

Well that deprives me of the advantages of having a Subject: line.
(i.e. meaningful listing in email client, sorting and searching,...)

It cant be that the answer to this is "Dont use it." ?

Cheers,
Karl

Date: Wed, 31 Aug 2005 14:11:34 +0100
From: Karl Kashofer <[email-masked]>
To: [email-masked]
Subject: Re: Encrypt subject
Sender: [email-masked]

Hi Werner !

>>However, as has cropped up several times on the enigmail mailinglist, it
>>would be really nice to be able to hide the Subject: header of an email
>>inside the encrypted mail body.
> 
> 
> Simply send your mail as an encrypted message/rfc2822 MIME message and
> put an innocent subject into the header.
> 
> Whether it is useful to decrypt all mails to see just the subject is a
> different question, though.  I use memonic subjects without any
> relation to the actual content; this helps to mentally sort such
> messages.

Isn't that an ugly workaround ?

I know the Subject: is a header and is not part of the message body, but
I am sure most people use PGP as transport security, once the email is
here on my laptop it can be permanently decrypted.

It cant be that hard to put the subject into the body before encryption,
and get it out again after decryption can it ?

Or are there any conceptual issues I am missing ?

Cheers,
Karl

From: "Greg Sabino Mullane" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
CC: [email-masked]
Subject: Re: Encrypt subject
Date: Wed, 31 Aug 2005 13:09:27 -0000
Sender: [email-masked]

> It kind of makes no sense to encrypt the body if a lot of the info can
> be gleaned from the subject.

True enough - so don't put any important information into the subject. Just
use something standard like "Re: your mail" or use the output of M-x spook if
you are feeling mischievous.

- --
Greg Sabino Mullane [email-masked]
PGP Key: 0x14964AC8 200508310906
https://www.biglumber.com/x/web?pk=2529DF6AB8F79407E94445B4BC9B906714964AC8

To: Karl Kashofer <[email-masked]>
Cc: [email-masked]
Subject: Re: Encrypt subject
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 31 Aug 2005 14:20:20 +0200
Sender: [email-masked]

On Wed, 31 Aug 2005 12:28:03 +0100, Karl Kashofer said:

> However, as has cropped up several times on the enigmail mailinglist, it
> would be really nice to be able to hide the Subject: header of an email
> inside the encrypted mail body.

Simply send your mail as an encrypted message/rfc2822 MIME message and
put an innocent subject into the header.

Whether it is useful to decrypt all mails to see just the subject is a
different question, though.  I use memonic subjects without any
relation to the actual content; this helps to mentally sort such
messages.

Salam-Shalom,

   Werner

Date: Wed, 31 Aug 2005 12:28:03 +0100
From: Karl Kashofer <[email-masked]>
To: [email-masked]
Subject: Encrypt subject
Sender: [email-masked]

Hi !

If I am in the wrong place, please advise me where to go.
Sorry if that has been discussed before, but non-searchable
list-archives are an abomination to the lord.

So:
I like PGP, and use it a lot in thunderbird+enigmail.
However, as has cropped up several times on the enigmail mailinglist, it
would be really nice to be able to hide the Subject: header of an email
inside the encrypted mail body.

Are there any ideas/proposals about this ?
It kind of makes no sense to encrypt the body if a lot of the info can
be gleaned from the subject.

It was suggested that one could include something like:
Header-Subject: mysubject
into the encrypted mail, and just get it out again after decryption.
I am sure if that could be put into a RFC of some sort it would be
adopted by clients pretty fast.

Ideas ? Discussion ?

Sorry if I bored you to death,
Cheers,
Karl

Date: Sat, 27 Aug 2005 17:34:25 +0200
To: [email-masked]
Subject: Re: Signature types
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

On Sat, Aug 27, 2005 at 10:25:07AM +0100, Ian G wrote:
> 
> Daniel A. Nagy wrote:
> > ... [some stuff]
> 
> On that section, but not on Daniel's question, it occurs to
> me that the caveat found half way down ("Please note that
> the vagueness...") could be usefully expanded to cover all
> of 5.2.1.

What the claim of the signature is can be indeed very vague, but what kind
of objects are hashed to verify the signature should be unambiguous in the
standard.

I still maintain that there is a very legitimate need for a timestamp
signature on any kind of data that has no meaning beyond the timestamp.

A signature on a signature is also useful (for different purposes), but it
cannot have the same signature type as the above signature, because the
objects that they sign are different.

Using 0x40 (and possibly 0x41) for the first purpose and 0x50 for the second
seems logical and in line with RFC2440.

-- 
Daniel

Date: Sat, 27 Aug 2005 17:26:46 +0200
To: [email-masked]
Subject: Re: Signature types
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

On Sat, Aug 27, 2005 at 09:55:52AM -0400, David Shaw wrote:

> On Sat, Aug 27, 2005 at 09:50:18AM +0200, Daniel A. Nagy wrote:
> > 
> > I am wondering if I understand the following correctly:
> > 
> > 0x40 Timestamp signature.
> > 
> > It is calculated directly on any document like a 0x00 signature (BTW, it
> > would probably makes sense to introduce a 0x41 timestamp for textual
> > documents), but the issuer of the signature does not claim authorship or
> > endorse the document, just states the fact that the document existed at the
> > time when the signature was issued.
> 
> Signature over a signature, just like 0x50.  It's not exactly made
> clear in section 5.2.1, but note that it gets a signature target
> subpacket.  That only makes sense if it is a signature over a
> signature.

If the signature target subpacket is in the hashed part of the signature, it
makes perfect sense with signatures on the document as well, as it binds
the document to the signature (e.g. a party that has access only to the
notary's public key can be assured that it is a valid signature on the
document, provided that the notatry is trusted).

> Note that 0x40 actually existed in rfc-1991 as well (also
> a signature over a signature).

It's actually RFC1991 that got me wondering:

     <40> - time stamping ("I saw this document") (*)
  ...                                          Type <40> is intended to
  be a signature of a signature, as a notary seal on a signed document.

Now, this is contradictory. If a signature does not have any cryptograpic
binding (except the indirect one through the other signature) to the
document, it cannot be used to assert the integrity thereof.

Someone with the public key of the notary cannot verify this claim. Also, it
makes a lot of sense to certify documents that have not been signed. Since
there are no implementations of 0x40 signatures (to my knowledge) it is
worth giving it a thought. A timestamp signature on (possibly unsigned)
documents that can, if required, bind signatures to it is immensely useful

> > This one I do not understand at all:
> > 
> > 0x50 Third-Party Confirmation signature.
> > 
> > What is the signature calculated on? The document? The certified signature?
> > Both?
> 
> The signature.  I thought this one was pretty clear (from 5.2.1):
> 
>         This signature is a signature over some other OpenPGP
> 	signature packet(s). It is analogous to a notary seal on the
> 	signed data.

Except that if it's a signature on the signature, then it cannot be
analogous to a notary seal on the signed data (see above). Yet, a signature
over a signature is also useful, as it can be issued by a blind notary that
doesn't see the document. Also, it does prove to someone with access to all
public keys the integrity of the document.

In sum, if 0x40 would be a timestamp signature on the document while 0x50 a
timestamp signature on the signature, it would make perfect sense, making
both of them useful and not redundant at all. This won't contradict the
wording of RFC2440, while RFC1991 contradicts itself, so being consistent
with that one is hopeless to begin with.

-- 
Daniel

Date: Sat, 27 Aug 2005 09:59:45 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: ISSUE: misleading hash instructions
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

This one is really easy to fix.  In section 5.2.4 (Computing
Signatures), the paragraph ordering implies incorrect things about a
user ID certification signature (which hashes the public key plus user
ID packet).  The description of a user ID certification signature
refers to "the data above", which given the paragraph ordering, is how
to hash a signature for signing, and not a public key.

If we just switch the position of the paragraph beginning "When a
signature is made over a signature packet" with the paragraph
beginning "A certification signature (type 0x10 through 0x13)" the
problem goes away.

David

Date: Sat, 27 Aug 2005 09:55:52 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Signature types
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Sat, Aug 27, 2005 at 09:50:18AM +0200, Daniel A. Nagy wrote:
> 
> I am wondering if I understand the following correctly:
> 
> 0x40 Timestamp signature.
> 
> It is calculated directly on any document like a 0x00 signature (BTW, it
> would probably makes sense to introduce a 0x41 timestamp for textual
> documents), but the issuer of the signature does not claim authorship or
> endorse the document, just states the fact that the document existed at the
> time when the signature was issued.

Signature over a signature, just like 0x50.  It's not exactly made
clear in section 5.2.1, but note that it gets a signature target
subpacket.  That only makes sense if it is a signature over a
signature.  Note that 0x40 actually existed in rfc-1991 as well (also
a signature over a signature).

> This one I do not understand at all:
> 
> 0x50 Third-Party Confirmation signature.
> 
> What is the signature calculated on? The document? The certified signature?
> Both?

The signature.  I thought this one was pretty clear (from 5.2.1):

        This signature is a signature over some other OpenPGP
	signature packet(s). It is analogous to a notary seal on the
	signed data.

David

Date: Sat, 27 Aug 2005 10:25:07 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: Signature types
Sender: [email-masked]

Daniel A. Nagy wrote:
 > ... [some stuff]

On that section, but not on Daniel's question, it occurs to
me that the caveat found half way down ("Please note that
the vagueness...") could be usefully expanded to cover all
of 5.2.1.

Something like:

5.2.1. Signature Types

   There are a number of possible meanings for a signature.
   By convention, OpenPGP suggests meanings by the following
   signature type octets in any given signature.

   Please note that the vagueness of these signature claims
   is not a flaw, but a feature of the system.  Cryptographic
   signing technology alone cannot make these claims true,
   and a relying party would need to examine the intentions
   of any signer, and the wider context of the system and
   environment in order to assess any claims.  OpenPGP places
   final authority and responsibility on the receiver of any
   signature.

   0x01:...

Which then allows a simplification of the post-0x13 comment:

   0x13:...

     Please note that one authority's casual certification
     might be more rigorous than some other authority's
     positive certification. These classifications allow a
     certification authority to issue fine-grained claims.

     Most OpenPGP implementations make their "key signatures" as 0x10
     certifications. Some implementations can issue 0x11-0x13
     certifications, but few differentiate between the types.

As an alternate, such general commentary could append to the
end of the section - but in legal terms, if it is a warning
as to limitations, it should be at the front.  Given the
somewhat poisoned waters of digital signatures, I'd prefer
to see the disclaims before any claims.

iang

PS: are we in final call already?

Date: Sat, 27 Aug 2005 09:50:18 +0200
To: [email-masked]
Subject: Signature types
From: [email-masked] (Daniel A. Nagy)
Sender: [email-masked]

I am wondering if I understand the following correctly:

0x40 Timestamp signature.

It is calculated directly on any document like a 0x00 signature (BTW, it
would probably makes sense to introduce a 0x41 timestamp for textual
documents), but the issuer of the signature does not claim authorship or
endorse the document, just states the fact that the document existed at the
time when the signature was issued.

This one I do not understand at all:

0x50 Third-Party Confirmation signature.

What is the signature calculated on? The document? The certified signature?
Both?

My guess would be that it is calculated on te document and includes in
one (or more) subpackets the canonical hash of the certified signature(s).
In this case the notary certifies the fact that the signatures are valid at
the time of issuing this signature.

But in this case a blind notary that certifies only the fact that the
signature has been made before the time of issuing the singature should use
standalone (0x02) signatures with a target signature subpacket. There is
absolutely no point in 0x50 signatures without target signature subpackets
in this setting, but I might have misunderstood something.

Thanks in advance for the clarification.

-- 
Daniel

Date: Thu, 25 Aug 2005 08:20:06 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Signature calculation problem
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Thu, Aug 25, 2005 at 02:25:43PM +0300, [email-masked] wrote:
> 
> My question is relating in public key signature calculation. Chapter 5.2.4
> Computing signatures in the RFC2440 says: When a signature is made over a
> key, the hash data starts with the octet 0x99, followed by a two-octet
> length of the key, and then the body of the key packet. What about in the
> situation when the public key packet length is 256 or smaller in bytes. In
> that case the length is only 1 octet and the tag is 0x98. Is the octet
> 0x98 replaced to 0x99 and one length octet (0x00) is inserted between
> packet tag and length octet to form a two-octet length? Am I right in
> this?

The hash data always starts with the octet 0x99, even if the key
length is smaller than 256 bytes.  That is the canonical key form used
when making signatures or calculating fingerprints.  For example, data
that is hashed for a key that is 200 bytes long (a pretty small key)
would begin: 0x99 0x00 0xC8.

David

Date: Thu, 25 Aug 2005 14:25:43 +0300 (EEST)
Subject: Signature calculation problem
From: <[email-masked]>
To: <[email-masked]>
Importance: Normal
Sender: [email-masked]

My question is relating in public key signature calculation. Chapter 5.2.4
Computing signatures in the RFC2440 says: When a signature is made over a
key, the hash data starts with the octet 0x99, followed by a two-octet
length of the key, and then the body of the key packet. What about in the
situation when the public key packet length is 256 or smaller in bytes. In
that case the length is only 1 octet and the tag is 0x98. Is the octet
0x98 replaced to 0x99 and one length octet (0x00) is inserted between
packet tag and length octet to form a two-octet length? Am I right in
this?

Date: Wed, 24 Aug 2005 01:01:36 -0400
From: Adam Back <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked], [email-masked], Adam Back <[email-masked]>
Subject: Re: Secret key signature packet
Sender: [email-masked]

I wrote:
> I am not sure of any attack based on modifying the private key in an
> undetectable way... that would generally seem to make invalid
> signatures, and inability to decrypt.  

Actually, let me revise that: I think one could likely mount an attack
based on ability to modify _parts of_ the private key.  eg with RSA
the relation e.d = 1 mod phi(n) would no longer hold and so forth
likely leaking parts of the private key.  And there was a long time
ago some discussion and examples of how one could modify the CFB mode
protection that is used for unsigned bulk encryption in PGP (in modes
that do not have a MDC).

Well lets see if the original poster can explain his use-case.

But I think for the above reason it might be interesting in lets say
an example where you were to keep your private keyring on a network
drive (feeling secure in knowledge you have a good passphrase, or even
perhaps a computer generated password that you have written down); the
attack then would be that someone could modify the private keyring
perhaps adaptively and thereby compute the private key.

(Or similar attack private key ring on USB key; but USB key not
physically secured, left where attacker can selectively change bits).

btw for this use-case I think using the MDC mode for encrytping the
private part would be a good step.  Might be interesting also to MAC
(with key derived from passphrase) any non-encrypted parts of the
private (and public) keyrings.

Adam

Date: Tue, 23 Aug 2005 14:37:49 -0400
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Secret key signature packet
Mail-Followup-To: [email-masked]
OpenPGP: id=99242560; url=http://www.jabberwocky.com/david/keys.asc
Sender: [email-masked]

On Tue, Aug 23, 2005 at 01:51:49PM -0400, Adam Back wrote:
> 
> I might be misunderstanding but I read the original poster to be maybe
> hinting at modification detection of the private key ring somehow.
> 
> I am not sure of any attack based on modifying the private key in an
> undetectable way... that would generally seem to make invalid
> signatures, and inability to decrypt.  

Could the original poster be thinking of the Klima-Rosa attack and the
secret key "s2k 254" SHA-1 protection?

David

Date: Tue, 23 Aug 2005 13:51:49 -0400
From: Adam Back <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked], [email-masked], Adam Back <[email-masked]>
Subject: Re: Secret key signature packet
Sender: [email-masked]

I might be misunderstanding but I read the original poster to be maybe
hinting at modification detection of the private key ring somehow.

I am not sure of any attack based on modifying the private key in an
undetectable way... that would generally seem to make invalid
signatures, and inability to decrypt.  

On the other hand changing the trust markers, or changing public
encryption keys of other parties -- that would seem dangerous.

So there would be value in that, tho AFAIK this info is on the public
key ring.

(Also with some implementations I've noticed they can operate just with
the private keyring as the private key is a superset of the public
key.)

Also the threat model is a bit arguable; if an attacker can modify the
keyrings, he could likely also insert a keyboard logger; maybe there
is some difference tho if for example the software is kept separate,
and there is some risk of attacker modifying the just the data on the
keyring storage device.

Adam

On Tue, Aug 23, 2005 at 09:06:32AM -0700, "Hal Finney" wrote:
> 
> From: <[email-masked]>
> > What is the content of the secret key signature packet? I know that open
> > pgp doesn`t support secret key signing so hash left 2 bytes, DSA r and DSA
> > s are not included in the signature packet. I assume that the content is:
> >
> > -Version number (1 octet)
> > -Signature type (1 octet)
> > -Public key algorithm (1 octet)
> > -Hash algorithm (1 octet)
> > -Hashed subpackets (n octets)
> > -Sub packet (issuer key id 8 octets)
> 
> I'm sorry, I don't know what you mean by a secret key signature packet.
> As I noted earlier, we don't sign secret keys.  There would be no point
> in creating a "signature" packet that was missing the signature fields,
> r and s.
> 
> Maybe this will help.  OpenPGP implementations usually store the public
> keys separately from the secret keys.  Traditionally these stores are
> called "key rings".  The public key ring contains public keys (your
> own public key and also those belonging to other people), user ids, and
> signatures.  The secret key ring contains your own secret keys and their
> user ids.  There is no need for signature packets on the secret key ring.
> If there are any signature packets there, they will be signatures over
> just the public key portion of the secret key packets.  They are not
> secret key signatures, there is no such thing.
> 
> Hal Finney

To: [email-masked], [email-masked]
Subject: Re: Secret key signature packet
Date: Tue, 23 Aug 2005 09:06:32 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

From: <[email-masked]>
> What is the content of the secret key signature packet? I know that open
> pgp doesn`t support secret key signing so hash left 2 bytes, DSA r and DSA
> s are not included in the signature packet. I assume that the content is:
>
> -Version number (1 octet)
> -Signature type (1 octet)
> -Public key algorithm (1 octet)
> -Hash algorithm (1 octet)
> -Hashed subpackets (n octets)
> -Sub packet (issuer key id 8 octets)

I'm sorry, I don't know what you mean by a secret key signature packet.
As I noted earlier, we don't sign secret keys.  There would be no point
in creating a "signature" packet that was missing the signature fields,
r and s.

Maybe this will help.  OpenPGP implementations usually store the public
keys separately from the secret keys.  Traditionally these stores are
called "key rings".  The public key ring contains public keys (your
own public key and also those belonging to other people), user ids, and
signatures.  The secret key ring contains your own secret keys and their
user ids.  There is no need for signature packets on the secret key ring.
If there are any signature packets there, they will be signatures over
just the public key portion of the secret key packets.  They are not
secret key signatures, there is no such thing.

Hal Finney

Date: Tue, 23 Aug 2005 14:02:17 +0300 (EEST)
Subject: Secret key signature packet
From: <[email-masked]>
To: <[email-masked]>
Importance: Normal
Sender: [email-masked]

What is the content of the secret key signature packet? I know that open
pgp doesn`t support secret key signing so hash left 2 bytes, DSA r and DSA
s are not included in the signature packet. I assume that the content is:

-Version number (1 octet)
-Signature type (1 octet)
-Public key algorithm (1 octet)
-Hash algorithm (1 octet)
-Hashed subpackets (n octets)
-Sub packet (issuer key id 8 octets)

Is this right?

Date: Wed, 17 Aug 2005 14:16:27 +0100
From: Ben Laurie <[email-masked]>
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: Encrypt then sign insecure?
Sender: [email-masked]

Hal Finney wrote:
>>Hal Finney wrote:
>>
>>>Krawczyk's paper is about combining MAC and symmetric encryption.
>>>That's not what OpenPGP does.  We don't do MACs.
>>
>>Actually, the only point of the MAC is to tell whether decryption 
>>succeeded. Signatures do the same job.
> 
> 
> I have to apologize to Ben, he's right about this.  I went back and
> re-read Krawczyk's paper and it does apply to signatures as well as
> MACs.

Thankyou.

> However, the actual result is somewhat different from what is often
> stated, which is that MAC-then-encrypt is potentially insecure.  What he
> actually shows is that encryption that is secure against passive attacks
> (like chosen plaintext) is not necessarily secure against active attacks
> (like altering the ciphertext en route), and that this is not prevented
> by MAC-ing the data before encrypting.  As Ben points out, it is also
> not prevented by signing the data before encrypting.
> 
> In fact, nothing you do to the data before encrypting can prevent
> the attack Krawczyk shows, because he assumes certain properties of
> the decryption engine which cause it to abort before it even tries to
> process the decrypted data.  Although Krawczyk suggests that "in a sense"
> the MAC can make things worse, in fact his attack never calls the MAC
> (nor would it verify a signature).  He corrupts the data en route such
> that the decryption engine barfs on it, so the plaintext never gets
> processed at the receiving end.  The attacker is assumed to be able to
> notice this response, which leaks information about the plaintext.

So, a MAC/signature _can_ help, if the failure is visible to the attacker.

> Krawczyk basically shows that you can't use an encryption function which
> is really weak against active attacks, and then assume that an inner
> signature or MAC will save you.  If the encryption function is bad enough,
> there is nothing you can do if you are going to wait until you decrypt.
> The only solution is to check integrity before beginning decryption.
> 
> The bottom line is that at some level we do need to assume that our
> encryption functions do not have the horrible properties that Krawczyk
> had to assume in order to make his construction go through.

This was my point about not being clear what the actual limits for those 
properties are. I guess he requires, at least, a function where its 
possible to change the ciphertext without changing the plaintext. This 
is not a property of any cipher I'd be likely to use.

Cheers,

Ben.

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

To: [email-masked], [email-masked]
Subject: Re: Encrypt then sign insecure?
Cc: [email-masked]
Date: Tue, 16 Aug 2005 14:50:32 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

> Hal Finney wrote:
> > Krawczyk's paper is about combining MAC and symmetric encryption.
> > That's not what OpenPGP does.  We don't do MACs.
>
> Actually, the only point of the MAC is to tell whether decryption 
> succeeded. Signatures do the same job.

I have to apologize to Ben, he's right about this.  I went back and
re-read Krawczyk's paper and it does apply to signatures as well as
MACs.

However, the actual result is somewhat different from what is often
stated, which is that MAC-then-encrypt is potentially insecure.  What he
actually shows is that encryption that is secure against passive attacks
(like chosen plaintext) is not necessarily secure against active attacks
(like altering the ciphertext en route), and that this is not prevented
by MAC-ing the data before encrypting.  As Ben points out, it is also
not prevented by signing the data before encrypting.

In fact, nothing you do to the data before encrypting can prevent
the attack Krawczyk shows, because he assumes certain properties of
the decryption engine which cause it to abort before it even tries to
process the decrypted data.  Although Krawczyk suggests that "in a sense"
the MAC can make things worse, in fact his attack never calls the MAC
(nor would it verify a signature).  He corrupts the data en route such
that the decryption engine barfs on it, so the plaintext never gets
processed at the receiving end.  The attacker is assumed to be able to
notice this response, which leaks information about the plaintext.

Krawczyk basically shows that you can't use an encryption function which
is really weak against active attacks, and then assume that an inner
signature or MAC will save you.  If the encryption function is bad enough,
there is nothing you can do if you are going to wait until you decrypt.
The only solution is to check integrity before beginning decryption.

The bottom line is that at some level we do need to assume that our
encryption functions do not have the horrible properties that Krawczyk
had to assume in order to make his construction go through.

Hal Finney

Date: Tue, 16 Aug 2005 11:07:38 +0100
From: Ben Laurie <[email-masked]>
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: Encrypt then sign insecure?
Sender: [email-masked]

Hal Finney wrote:
> Ben Laurie wrote:
> 
>>Hal Finney wrote:
>>
>>>This paper doesn't apply to systems like OpenPGP which compose public
>>>key signatures with public key encryption.  Rather, it investigates the
>>>composition of symmetric encryption (e.g. AES) with MAC.
>>
>>...
>>This does not seem to me to be true. OpenPGP uses symmetric encryption 
>>under the hood, and signs the plaintext rather than the ciphertext. All 
>>that is needed is an oracle which will say whether the signature is 
>>correct or not.
> 
> 
> Krawczyk's paper is about combining MAC and symmetric encryption.
> That's not what OpenPGP does.  We don't do MACs.

Actually, the only point of the MAC is to tell whether decryption 
succeeded. Signatures do the same job.

>>Furthermore, OpenPGP does not use CBC, so the security proof from the 
>>paper doesn't help.
> 
> That's true, but the point is that the paper is not about systems like
> OpenPGP at all.

Yes it is. The required properties are: a) encryption and b) the 
possibility to detect errors in the plaintext.

Cheers,

Ben.

-- 
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: Konrad Rosenbaum <[email-masked]>
To: [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Date: Tue, 16 Aug 2005 07:50:55 +0200
Sender: [email-masked]

--nextPart2879028.Mq6ueB6cKK
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

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

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

	Konrad

--nextPart2879028.Mq6ueB6cKK
Content-Type: application/pgp-signature

--nextPart2879028.Mq6ueB6cKK--

To: [email-masked], [email-masked]
Subject: Re: Encrypt then sign insecure?
Cc: [email-masked]
Date: Mon, 15 Aug 2005 20:47:24 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Ben Laurie wrote:
> Hal Finney wrote:
> > This paper doesn't apply to systems like OpenPGP which compose public
> > key signatures with public key encryption.  Rather, it investigates the
> > composition of symmetric encryption (e.g. AES) with MAC.
> ...
> This does not seem to me to be true. OpenPGP uses symmetric encryption 
> under the hood, and signs the plaintext rather than the ciphertext. All 
> that is needed is an oracle which will say whether the signature is 
> correct or not.

Krawczyk's paper is about combining MAC and symmetric encryption.
That's not what OpenPGP does.  We don't do MACs.

> Furthermore, OpenPGP does not use CBC, so the security proof from the 
> paper doesn't help.

That's true, but the point is that the paper is not about systems like
OpenPGP at all.

Hal Finney

To: [email-masked], [email-masked]
Subject: Re: Calculating signature over private key
Date: Mon, 15 Aug 2005 20:44:17 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

<[email-masked]> writes:
> I am calculating a signature over private keypair. How the data to be
> signed differs from the public key? Are the fields: Salt, Initial vector,
> Coded count, encrypted dsa x, encrypted sha1 hash (20 octets) included to
> the signed data? Can someone clarify this?

OpenPGP does not support the notion of calculating a signature over a
private keypair.

Generally a signature is done on a public key as part of a certification
of that key that will be publicly available.  Signing a private key
would not be useful because the private key material is normally not
shared with others, so signature verification would be impossible.

Hal

Date: Mon, 15 Aug 2005 18:04:49 +0300 (EEST)
Subject: Calculating signature over private key
From: <[email-masked]>
To: <[email-masked]>
Importance: Normal
Sender: [email-masked]

I am calculating a signature over private keypair. How the data to be
signed differs from the public key? Are the fields: Salt, Initial vector,
Coded count, encrypted dsa x, encrypted sha1 hash (20 octets) included to
the signed data? Can someone clarify this?

Date: Mon, 15 Aug 2005 15:16:06 +0100
From: Ben Laurie <[email-masked]>
To: Hal Finney <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: Section 5.2.3 of latest draft: bis14.
Sender: [email-masked]

Hal Finney wrote:
> Levi Broderick writes:
> 
>>I noticed that the following bullet is missing from the latest draft.
>>It used to appear between 'One-octet hash algorithm' and 'Hashed
>>subpacket data set' in section 5.2.3.
>>
>>      - Two-octet scalar octet count for following hashed subpacket
>>        data. Note that this is the length in octets of all of the hashed
>>        subpackets; a pointer incremented by this number will skip over
>>        the hashed subpackets.
> 
> 
> This is definitely an error and needs to be fixed.

I believe the idea was to eliminate this and the following instance for 
unhashed subpacket data sets, since the count is defined there.

> A couple of other relatively minor points relating to this section.
> 
> We now use the term "data set" for the hashed and unhashed subpackets:
> 
>       - Hashed subpacket data set. (zero or more subpackets)
> 
>       - Two-octet scalar octet count for the following unhashed
>         subpacket data. Note that this is the length in octets of all of
>         the unhashed subpackets; a pointer incremented by this number
>         will skip over the unhashed subpackets.
> 
>       - Unhashed subpacket data set. (zero or more subpackets)
> 
> "Data set" is defined in the next section, 5.2.3.1:
> 
>     A subpacket data set consists of zero or more signature subpackets,
>     preceded by a two-octet scalar count of the length in octets of all
>     the subpackets; a pointer incremented by this number will skip over
>     the subpacket data set.
> 
> This definition could be interpreted to mean that the data set includes
> the two-octet scalar count.  In fact, in the layout in 5.2.3 the data
> set does not include the scalar count.  5.2.3.1 could be reworded to say
> "A subpacket data set consists of zero or more signature subpackets,
> AND IS preceded by a two-octet scalar count..."

There's no penalty for clarity, right? So why not add "Note that the 
count is the number of bytes to skip after the count itself has been 
read", for instance.

Cheers,

Ben.

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

Date: Mon, 15 Aug 2005 10:43:55 +0100
From: Ben Laurie <[email-masked]>
To: Hal Finney <[email-masked]>
CC: [email-masked]
Subject: Re: Encrypt then sign insecure?
Sender: [email-masked]

Hal Finney wrote:
> I have changed the subject line as this is in regard to Ben's citation
> of Hugo Krawczyk's paper on the order of signing and encryption,
> http://eprint.iacr.org/2001/045, also published in Crypto 01.
> 
> This paper doesn't apply to systems like OpenPGP which compose public
> key signatures with public key encryption.  Rather, it investigates the
> composition of symmetric encryption (e.g. AES) with MAC.
> 
> Krawczyk shows that it is not always safe to first MAC and then
> symmetrically encrypt, even if your MAC is secure and your symmetric
> encryption algorithm is secure.  He does this by coming up with rather
> artificial types of MAC and encryption which are individually secure
> but which interact in a bad way when when put together like this.
> 
> Krawczyk also shows some constructions that ARE always safe, including
> doing CBC with a secure cipher, then MACing the ciphertext.
> 
> Again, this analysis is not applicable to the PK digital signatures and
> hybrid public/private key encryption used in OpenPGP.

This does not seem to me to be true. OpenPGP uses symmetric encryption 
under the hood, and signs the plaintext rather than the ciphertext. All 
that is needed is an oracle which will say whether the signature is 
correct or not.

Furthermore, OpenPGP does not use CBC, so the security proof from the 
paper doesn't help.

I agree that the paper uses rather an artificial cipher (though the MAC 
can be any MAC) but it isn't clear to me what the limits of the attack are.

Cheers,

Ben.

-- 
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: Simon Josefsson <[email-masked]>
To: David Srbecky <[email-masked]>
Cc: openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Mon, 15 Aug 2005 11:43:10 +0200
Sender: [email-masked]

David Srbecky <[email-masked]> writes:

> Simon Josefsson wrote:
>> 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.
>> 
>
> 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

Date: Mon, 15 Aug 2005 10:29:14 +0100
From: Ben Laurie <[email-masked]>
To: Konrad Rosenbaum <[email-masked]>
CC: [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

Konrad Rosenbaum wrote:
> On Sunday 14 August 2005 15:43, Ben Laurie wrote:
> 
>>Signing messages weakens plausible deniability. It may imply some
>>standing that is not necessarily intended. These things can harm the
>>sender.
> 
> 
> 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.

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.

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

Date: Mon, 15 Aug 2005 10:27:44 +0100
From: Ben Laurie <[email-masked]>
To: Konrad Rosenbaum <[email-masked]>
CC: [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

Konrad Rosenbaum wrote:
> On Sunday 14 August 2005 18:34, Ben Laurie wrote:
> 
>>Indeed - the result is general. The fact that SSL is secure gives no
>>comfort for OpenPGP.
> 
> 
> The abstract also states that using the cipher in CBC is secure. When last I 
> looked OpenPGP used CBC.

Look again, then. OpenPGP uses CFB.

-- 
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: Konrad Rosenbaum <[email-masked]>
To: [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Date: Mon, 15 Aug 2005 07:50:28 +0200
Sender: [email-masked]

--nextPart1763041.dj7BaThLhZ
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 14 August 2005 15:43, Ben Laurie wrote:
> Signing messages weakens plausible deniability. It may imply some
> standing that is not necessarily intended. These things can harm the
> sender.

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

	Konrad

--nextPart1763041.dj7BaThLhZ
Content-Type: application/pgp-signature

--nextPart1763041.dj7BaThLhZ--

From: Konrad Rosenbaum <[email-masked]>
To: Ben Laurie <[email-masked]>, [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Date: Mon, 15 Aug 2005 07:46:04 +0200
Sender: [email-masked]

--nextPart4536509.UfVxNzYH4h
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 14 August 2005 18:34, Ben Laurie wrote:
> Indeed - the result is general. The fact that SSL is secure gives no
> comfort for OpenPGP.

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

	Konrad

--nextPart4536509.UfVxNzYH4h
Content-Type: application/pgp-signature

--nextPart4536509.UfVxNzYH4h--

From: Konrad Rosenbaum <[email-masked]>
To: [email-masked]
Subject: Re: Applicability of signed messages as proof of sending
Date: Mon, 15 Aug 2005 07:38:58 +0200
Sender: [email-masked]

--nextPart3033786.ECMKuvl0Cn
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

On Sunday 14 August 2005 19:00, Ian G wrote:
> Ben Laurie wrote:
> > On wired networks they are easy for the network admins to mount. The
> > practice is sufficiently commonplace that many corps have their own CA
> > keys in employees' browsers so they can forge X509 certs.
>
> Hmmm.  Is that the sole reason?  Or one of many reasons?
>
> And how often do they conduct this attack?

There are web-proxies on the market which do this in order to be able to=20
track HTTPS connections of employees. This is illegal or at least of=20
doubtful legality in most European countries, so I can't provide you with=20
examples of companies who do this.

	Konrad

--nextPart3033786.ECMKuvl0Cn
Content-Type: application/pgp-signature

--nextPart3033786.ECMKuvl0Cn--

From: Jon Callas <[email-masked]>
Subject: Re: Encrypt then sign insecure?
Date: Sun, 14 Aug 2005 16:45:53 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

> On Sun August 14 2005 12:36, Hal Finney wrote:
>>
>> I have changed the subject line as this is in regard to Ben's citation
>> of Hugo Krawczyk's paper on the order of signing and encryption,
>> http://eprint.iacr.org/2001/045, also published in Crypto 01.
>>
>> This paper doesn't apply to systems like OpenPGP which compose public
>> key signatures with public key encryption.  Rather, it investigates 
>> the
>> composition of symmetric encryption (e.g. AES) with MAC.
>
> The same cannot be said of Davis' analysis of issues in
> http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
>
>

Davis is merely making a mountain out of a molehill. Cryptography 
cannot protect you from sending a message to a bad actor. Not even 
things like OTR can [1]. A word to the wise is that you shouldn't sign 
any message that you would be embarrassed to be made public.

Nonetheless, there's definitely a need to have secure messages that 
aren't signed. That's why we have the MDC construction in OpenPGP, so 
that you can have a reasonable assurance that a message arrived to you 
intact.

	Jon

[1] This is not a slam on OTR, which I think is brilliant. It is merely 
an observation that if you use a full privacy-enabled system like OTR 
and someone pastes a copy of your conversation into their livejournal, 
the people who read that transcript will presume it to be accurate. 
Furthermore, the fact that you used a juicy technology like OTR will 
make people *more* not less likely to believe it was accurate. This is 
an observation on human nature.

From: Jon Callas <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
Date: Sun, 14 Aug 2005 16:17:27 -0700
To: OpenPGP <[email-masked]>
Sender: [email-masked]

On 11 Aug 2005, at 11:10 AM, Ian G wrote:

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

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: Bruce Lilly <[email-masked]>
Reply-To: Bruce Lilly <[email-masked]>
Organization: Bruce Lilly
To: "Hal Finney" <[email-masked]>
Subject: Re: Encrypt then sign insecure?
Date: Sun, 14 Aug 2005 18:32:17 -0400
Cc: [email-masked]
Sender: [email-masked]

On Sun August 14 2005 12:36, Hal Finney wrote:
> 
> I have changed the subject line as this is in regard to Ben's citation
> of Hugo Krawczyk's paper on the order of signing and encryption,
> http://eprint.iacr.org/2001/045, also published in Crypto 01.
> 
> This paper doesn't apply to systems like OpenPGP which compose public
> key signatures with public key encryption.  Rather, it investigates the
> composition of symmetric encryption (e.g. AES) with MAC.

The same cannot be said of Davis' analysis of issues in
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

Date: Sun, 14 Aug 2005 17:40:20 +0200
From: Thomas Roessler <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: Ian G <[email-masked]>, David Srbecky <[email-masked]>, Simon Josefsson <[email-masked]>, openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
Mail-Followup-To: Ben Laurie <[email-masked]>, Ian G <[email-masked]>, David Srbecky <[email-masked]>, Simon Josefsson <[email-masked]>, openpgp <[email-masked]>
Sender: [email-masked]

On 2005-08-14 14:44:37 +0100, Ben Laurie wrote:

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

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

To: [email-masked]
Subject: Encrypt then sign insecure?
Date: Sun, 14 Aug 2005 09:36:14 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

I have changed the subject line as this is in regard to Ben's citation
of Hugo Krawczyk's paper on the order of signing and encryption,
http://eprint.iacr.org/2001/045, also published in Crypto 01.

This paper doesn't apply to systems like OpenPGP which compose public
key signatures with public key encryption.  Rather, it investigates the
composition of symmetric encryption (e.g. AES) with MAC.

Krawczyk shows that it is not always safe to first MAC and then
symmetrically encrypt, even if your MAC is secure and your symmetric
encryption algorithm is secure.  He does this by coming up with rather
artificial types of MAC and encryption which are individually secure
but which interact in a bad way when when put together like this.

Krawczyk also shows some constructions that ARE always safe, including
doing CBC with a secure cipher, then MACing the ciphertext.

Again, this analysis is not applicable to the PK digital signatures and
hybrid public/private key encryption used in OpenPGP.

Hal Finney

Date: Sun, 14 Aug 2005 18:00:30 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Ben Laurie <[email-masked]>
Cc: Richard Laager <[email-masked]>, [email-masked]
Subject: Re: Applicability of signed messages as proof of sending
Sender: [email-masked]

Ben Laurie wrote:
> 
> Richard Laager wrote:
> 
>> I'll admit that MITM attacks are rare and sophisticated,...
> 
> 
> I wish we could kill this myth that MitM is "rare and sophisticated". On 
> wireless networks, they are common and trivial.

I don't think there is any myth that it is sophisticated
or trivial - it gets done many times at conferences of
hackers.  The claim that is made is that it is expensive.

As to whether it is common - the myth is easy to dispel
by presenting some facts.  Most times I've seen it claimed
it has turned out to be something else.

Got any?  Facts, not claims that is....  It would be an
enourmous service to the developers to know how much
weight to put on MITM.  Right now, theory says none
because there is no case history.

> On wired networks they are easy for the network admins to mount. The 
> practice is sufficiently commonplace that many corps have their own CA 
> keys in employees' browsers so they can forge X509 certs.

Hmmm.  Is that the sole reason?  Or one of many reasons?

And how often do they conduct this attack?

> Keylogging is a _much_ harder attack to mount.

Doesn't seem to slow down the phishers much...

iang

Date: Sun, 14 Aug 2005 17:34:14 +0100
From: Ben Laurie <[email-masked]>
To: Jeroen Massar <[email-masked]>
CC: [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

Jeroen Massar wrote:
> On Sun, 2005-08-14 at 16:52 +0100, Ben Laurie wrote:
> 
>>Jeroen Massar wrote:
>>
>>>On Sun, 2005-08-14 at 16:30 +0100, Ben Laurie wrote:
>>>
>>>
>>>>Jeroen Massar wrote:
>>>>
>>>>
>>>>>On Sun, 2005-08-14 at 14:24 +0100, Ben Laurie wrote:
>>>>>
>>>>>
>>>>>
>>>>>>Jeroen Massar wrote:
>>>>>
>>>>><SNIP>
>>>>>
>>>>>>>* sign(encrypt(message))
>>>>>
>>>>><SNIP>
>>>>>
>>>>>>More importantly, perhaps, Krawczyk has shown that, in general, sign 
>>>>>>then encrypt is insecure.
>>>>>
>>>>>
>>>>>Which exact paper do you mean?
>>>>
>>>>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."
>>
>>Sure. What does this have to do with OpenPGP's security?
> 
> 
> 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.

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

Subject: Re: "The OpenPGP mail and news header" extenssion
From: Jeroen Massar <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Organization: Unfix
Date: Sun, 14 Aug 2005 18:31:58 +0200
Sender: [email-masked]

--=-l7bRLdaw9zlLEtvSAxe0
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2005-08-14 at 16:52 +0100, Ben Laurie wrote:
> Jeroen Massar wrote:
> > On Sun, 2005-08-14 at 16:30 +0100, Ben Laurie wrote:
> >=20
> >>Jeroen Massar wrote:
> >>
> >>>On Sun, 2005-08-14 at 14:24 +0100, Ben Laurie wrote:
> >>>
> >>>
> >>>>Jeroen Massar wrote:
> >>>
> >>><SNIP>
> >>>
> >>>>>* sign(encrypt(message))
> >>>
> >>><SNIP>
> >>>
> >>>>More importantly, perhaps, Krawczyk has shown that, in general, sign=20
> >>>>then encrypt is insecure.
> >>>
> >>>
> >>>Which exact paper do you mean?
> >>
> >>http://eprint.iacr.org/2001/045
> >=20
> >=20
> > Which nicely says, already in the abstract btw, "Thus, while we show th=
e
> > generic security of SSL to be broken, the current standard
> > implementations of the protocol that use the above modes of encryption
> > are safe."
>=20
> Sure. What does this have to do with OpenPGP's security?

psst... it was you bringing up that argument about the paper ;)

Greets,
 Jeroen

--=-l7bRLdaw9zlLEtvSAxe0
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-l7bRLdaw9zlLEtvSAxe0--

Date: Sun, 14 Aug 2005 16:52:29 +0100
From: Ben Laurie <[email-masked]>
To: Jeroen Massar <[email-masked]>
CC: [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

Jeroen Massar wrote:
> On Sun, 2005-08-14 at 16:30 +0100, Ben Laurie wrote:
> 
>>Jeroen Massar wrote:
>>
>>>On Sun, 2005-08-14 at 14:24 +0100, Ben Laurie wrote:
>>>
>>>
>>>>Jeroen Massar wrote:
>>>
>>><SNIP>
>>>
>>>>>* sign(encrypt(message))
>>>
>>><SNIP>
>>>
>>>>More importantly, perhaps, Krawczyk has shown that, in general, sign 
>>>>then encrypt is insecure.
>>>
>>>
>>>Which exact paper do you mean?
>>
>>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."

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

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

Subject: Re: "The OpenPGP mail and news header" extenssion
From: Jeroen Massar <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Organization: Unfix
Date: Sun, 14 Aug 2005 17:45:05 +0200
Sender: [email-masked]

--=-r7pY+udQXx+apkaFRbHW
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2005-08-14 at 16:30 +0100, Ben Laurie wrote:
> Jeroen Massar wrote:
> > On Sun, 2005-08-14 at 14:24 +0100, Ben Laurie wrote:
> >=20
> >>Jeroen Massar wrote:
> >=20
> > <SNIP>
> >=20
> >>>* sign(encrypt(message))
> >=20
> > <SNIP>
> >=20
> >>More importantly, perhaps, Krawczyk has shown that, in general, sign=20
> >>then encrypt is insecure.
> >=20
> >=20
> > Which exact paper do you mean?
>=20
> 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

--=-r7pY+udQXx+apkaFRbHW
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-r7pY+udQXx+apkaFRbHW--

Date: Sun, 14 Aug 2005 16:42:19 +0100
From: Ben Laurie <[email-masked]>
To: Richard Laager <[email-masked]>
CC: [email-masked]
Subject: Re: Applicability of signed messages as proof of sending
Sender: [email-masked]

Richard Laager wrote:
> I'll admit that MITM attacks are rare and sophisticated, but if you're
> not guarding against them, the only take you prevent is casual snooping
> on the wire. If you're only going to worry about casual snooping, you
> could just as well use rot13 as your "encryption". (Granted, I'm
> exaggerating a little, but why bother with something as complex and
> secure as OpenPGP to prevent casual snooping.) Your points about
> keyloggers, etc. are very valid.

I wish we could kill this myth that MitM is "rare and sophisticated". On 
wireless networks, they are common and trivial.

On wired networks they are easy for the network admins to mount. The 
practice is sufficiently commonplace that many corps have their own CA 
keys in employees' browsers so they can forge X509 certs.

Keylogging is a _much_ harder attack to mount.

Cheers,

Ben.

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

Date: Sun, 14 Aug 2005 16:30:55 +0100
From: Ben Laurie <[email-masked]>
To: Jeroen Massar <[email-masked]>
CC: [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

Jeroen Massar wrote:
> On Sun, 2005-08-14 at 14:24 +0100, Ben Laurie wrote:
> 
>>Jeroen Massar wrote:
> 
> <SNIP>
> 
>>>* sign(encrypt(message))
> 
> <SNIP>
> 
>>More importantly, perhaps, Krawczyk has shown that, in general, sign 
>>then encrypt is insecure.
> 
> 
> 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.

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

Subject: Re: "The OpenPGP mail and news header" extenssion
From: Jeroen Massar <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Organization: Unfix
Date: Sun, 14 Aug 2005 17:26:32 +0200
Sender: [email-masked]

--=-xVcgsN8SJbUFh/zhWQcX
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Sun, 2005-08-14 at 14:24 +0100, Ben Laurie wrote:
> Jeroen Massar wrote:
<SNIP>
> > * sign(encrypt(message))
<SNIP>
> More importantly, perhaps, Krawczyk has shown that, in general, sign=20
> then encrypt is insecure.

Which exact paper do you mean?

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

Greets,
 Jeroen

--=-xVcgsN8SJbUFh/zhWQcX
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-xVcgsN8SJbUFh/zhWQcX--

Date: Sun, 14 Aug 2005 15:53:45 +0100
From: Ben Laurie <[email-masked]>
To: Ian G <[email-masked]>
CC: openpgp <[email-masked]>
Subject: Re: The undefined nature of the digital signature
Sender: [email-masked]

Ian G wrote:
> Ben Laurie wrote:
> 
>> Well, in the UK, it is the Law Society's opinion that existing law 
>> 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?

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.

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

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

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

Date: Sun, 14 Aug 2005 15:52:44 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Ben Laurie <[email-masked]>
Cc: openpgp <[email-masked]>
Subject: The undefined nature of the digital signature
Sender: [email-masked]

Ben Laurie wrote:

> Well, in the UK, it is the Law Society's opinion that existing law 
> 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

Date: Sun, 14 Aug 2005 15:39:32 +0100
From: Ben Laurie <[email-masked]>
To: Ian G <[email-masked]>
CC: David Srbecky <[email-masked]>, Simon Josefsson <[email-masked]>, openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

Ian G wrote:
> Ben Laurie wrote:
> 
>> Ian G wrote:
>>
>>> 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.
>>
>>
>>
>> Oh, please, the meaning of signatures is perfectly well defined in law.
> 
> Sorry I meant digital signatures.

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

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

Date: Sun, 14 Aug 2005 16:12:21 +0200
From: David Srbecky <[email-masked]>
To: openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
OpenPGP: id=2DC6523A; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9068C91B33740587D712CE84
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Simon Josefsson wrote:
> 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.
> 

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

Thanks,
David

--------------enig9068C91B33740587D712CE84
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig9068C91B33740587D712CE84--

Date: Sun, 14 Aug 2005 15:57:08 +0200
From: David Srbecky <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
OpenPGP: id=2DC6523A; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigFEB9E5FADEFABAF2CFD656CB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

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

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

--------------enigFEB9E5FADEFABAF2CFD656CB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigFEB9E5FADEFABAF2CFD656CB--

Date: Sun, 14 Aug 2005 15:00:32 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Ben Laurie <[email-masked]>
Cc: David Srbecky <[email-masked]>, Simon Josefsson <[email-masked]>, openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

Ben Laurie wrote:
> Ian G wrote:
> 
>> 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.
> 
> 
> Oh, please, the meaning of signatures is perfectly well defined in law.

Sorry I meant digital signatures.

iang

Date: Sun, 14 Aug 2005 14:44:37 +0100
From: Ben Laurie <[email-masked]>
To: Ian G <[email-masked]>
CC: David Srbecky <[email-masked]>, Simon Josefsson <[email-masked]>, openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

Ian G wrote:
> 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.

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

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

Date: Sun, 14 Aug 2005 14:43:40 +0100
From: Ben Laurie <[email-masked]>
To: David Srbecky <[email-masked]>
CC: [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

David Srbecky wrote:
> Ben Laurie wrote:
> 
>>David Srbecky wrote:
>>
>>
>>>OpenPGP: id=b565717f; url=http://josefsson.org/key.txt; preference=sign
>>>
>>>Sender wants to receive signed unencrypted messages.
>>
>>
>>Why would I care whether the sender wants to receive signed messages?
> 
> 
> You want to be polite and help to enhance the security.
> 
> 
>>Surely its all about whether I want to sign my messages? His preference
>>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.

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.

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

Date: Sun, 14 Aug 2005 15:39:12 +0200
From: David Srbecky <[email-masked]>
To: Ben Laurie <[email-masked]>
Cc: [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
OpenPGP: id=2DC6523A; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigC47F4C96962E0B3469E8841A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

Ben Laurie wrote:
> David Srbecky wrote:
> 
>> OpenPGP: id=b565717f; url=http://josefsson.org/key.txt; preference=sign
>>
>> Sender wants to receive signed unencrypted messages.
> 
> 
> Why would I care whether the sender wants to receive signed messages?

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

> Surely its all about whether I want to sign my messages? His preference
> 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

--------------enigC47F4C96962E0B3469E8841A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigC47F4C96962E0B3469E8841A--

Date: Sun, 14 Aug 2005 14:24:54 +0100
From: Ben Laurie <[email-masked]>
To: Jeroen Massar <[email-masked]>
CC: David Srbecky <[email-masked]>, [email-masked], [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

Jeroen Massar wrote:
> On Thu, 2005-08-11 at 20:17 +0200, David Srbecky wrote:
> 
> 
>>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)
> 
> 
> * 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.

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

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

Date: Sun, 14 Aug 2005 14:18:39 +0100
From: Ben Laurie <[email-masked]>
To: David Srbecky <[email-masked]>
CC: Simon Josefsson <[email-masked]>, openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

David Srbecky wrote:
> OpenPGP: id=b565717f; url=http://josefsson.org/key.txt; preference=sign
> 
> 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

Cc: <[email-masked]>
From: Jon Callas <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
Date: Sat, 13 Aug 2005 09:32:06 -0700
To: "James Scott" <[email-masked]>
Sender: [email-masked]

On 12 Aug 2005, at 2:26 PM, James Scott wrote:

> You might like to note that the IETF MASS pre-working group is 
> currently
> discussing just such a proposal, called DKIM.  This is based on an 
> amalgam
> of Yahoo Domain Keys, and Cisco Identified Internet Mail.
>
> Refer to http://mipassoc.org/mass/ for further details.
>

Actually, you should look at <http://mipassoc.org/dkim/>, which is the 
present accurate place. The above will redirect you to the latter, but 
it's better to go to the latter.

	Jon

From: "James Scott" <[email-masked]>
To: <[email-masked]>
Subject: RE: "The OpenPGP mail and news header" extenssion
Date: Sat, 13 Aug 2005 09:26:41 +1200
Organization: Liverton Limited
Sender: [email-masked]

Simon Josefsson wrote:
> David Srbecky <[email-masked]> writes:
> 
> > Simon Josefsson wrote:
> >> David Srbecky <[email-masked]> 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=
...[snip]
> 
> 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.
> 

You might like to note that the IETF MASS pre-working group is currently
discussing just such a proposal, called DKIM.  This is based on an amalgam
of Yahoo Domain Keys, and Cisco Identified Internet Mail.

Refer to http://mipassoc.org/mass/ for further details.

James

Date: Fri, 12 Aug 2005 19:52:25 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: [email-masked]
Subject: Re: Applicability of signed messages as proof of sending
Sender: [email-masked]

Richard Laager wrote:
> Gaim (please not GAIM) ...

I took that one offline, as everyone here knows 'the story.'

For the patient, here's a link I came across today on
OpenPGP's web of trust.  Nice graphs!

http://www.cs.uu.nl/people/henkp/henkp/pgp/pathfinder/plot/

And here's today's emailtapping news.  The court of appeals
reversed a ruling, and said that ISPs could not copy and
read emails.  Meanwhile a survey found that small firms were
failing to copy and escrow emails as instructed.  And companies
can now bring in massive eavesdropping tech to catch insiders
doing bad things.

E-mail wiretap case can proceed, court says
http://news.com.com/E-mail+wiretap+case+can+proceed,+court+says/2100-1028_3-5829228.html?tag=nefd.top
Study Finds Small Securities Firms Still Fail To Comply With SEC E-mail Archiving Regulations
http://www.compliancepipeline.com/showArticle.jhtml?articleID=168601153
When E-Mail Isn't Monitored
http://itmanagement.earthweb.com/secu/article.php/3526881

iang

Subject: Re: Applicability of signed messages as proof of sending
From: Richard Laager <[email-masked]>
To: [email-masked]
Organization: Wikstrom Telecom Internet
Date: Fri, 12 Aug 2005 11:23:08 -0500
Sender: [email-masked]

On Fri, 2005-08-12 at 10:39 +0100, Ian G wrote:
> Len Sassaman wrote:
> > On Thu, 11 Aug 2005, Ian G wrote:
 
> > Right. I'm one of those people. This does, however, leave one open to MITM
> > attacks -- which are probably not that large of a threat in the general
> > case, but when dealing with centralized, proprietary IM systems, could
> > very well be a realistic problem. (This is why Trillian's SecureIM
> > solution fails my sniff test.)
> 
> Right.  That's an interesting point.  So GAIM
> uses AIM which is a proprietary IM system.  Now,
> if that was all it was, *and* one assumed that
> MITM in AIM was a real threat, then this would
> be plausible logically, but still weak in terms
> of validation.

Gaim (please not GAIM) supports a variety of protocols besides AIM, so
that does change the threat model a bit. It'd be significantly easier to
do a MITM attack on more documented and decentralized protocols.

I'll admit that MITM attacks are rare and sophisticated, but if you're
not guarding against them, the only take you prevent is casual snooping
on the wire. If you're only going to worry about casual snooping, you
could just as well use rot13 as your "encryption". (Granted, I'm
exaggerating a little, but why bother with something as complex and
secure as OpenPGP to prevent casual snooping.) Your points about
keyloggers, etc. are very valid.

Richard Laager

Subject: Re: "The OpenPGP mail and news header" extenssion
From: Jeroen Massar <[email-masked]>
To: David Srbecky <[email-masked]>
Cc: [email-masked], [email-masked]
Organization: Unfix
Date: Fri, 12 Aug 2005 11:38:28 +0200
Sender: [email-masked]

--=-jT5SQ3qhMHNmGSOQlTfn
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Thu, 2005-08-11 at 20:17 +0200, David Srbecky wrote:

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

* 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

--=-jT5SQ3qhMHNmGSOQlTfn
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

--=-jT5SQ3qhMHNmGSOQlTfn--

Date: Fri, 12 Aug 2005 10:39:26 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Len Sassaman <[email-masked]>
Cc: [email-masked]
Subject: Re: Applicability of signed messages as proof of sending
Sender: [email-masked]

Len Sassaman wrote:
> On Thu, 11 Aug 2005, Ian G wrote:

(Does anyone want us to take this offline?  Just
shout...)

>>Right but this needs to be integrated into the
>>real world.  Firstly, what does that signature
>>mean?  What was it doing there?  Because this
>>question is unanswered, and I'd say, unanswerable,
>>most people (in my experience) don't use signed
>>email.  They simply encrypt.
> 
> 
> Right. I'm one of those people. This does, however, leave one open to MITM
> attacks -- which are probably not that large of a threat in the general
> case, but when dealing with centralized, proprietary IM systems, could
> very well be a realistic problem. (This is why Trillian's SecureIM
> solution fails my sniff test.)

Right.  That's an interesting point.  So GAIM
uses AIM which is a proprietary IM system.  Now,
if that was all it was, *and* one assumed that
MITM in AIM was a real threat, then this would
be plausible logically, but still weak in terms
of validation.

The node threats are well documented:  they are
the viral and spyware threats on each party's
nodes, and the party defection threat (your wife
takes you to court, your boss grabs all your
messages from others).  So even in the face of an
attacker who could conduct an MITM at AIM level,
he still has better opportunities in keyloggers
and so forth on your or your counter party's
machine, and he's much more likely to go for an
attack he can blame on someone else than to drag
in AOL into an active attack.  AFAIK, the TLAs
will happily insert viruses and keyloggers into
your PC, but they won't do an MITM.

So why bother to defend against an unvalidated
MITM attack and ignore the validated attacks
that the user is actually having to deal with?

In short, ignore MITM, or slot it later on.  Look
at what PRZ's new VoIP product does - sets up a
chain of hashes.  Why?  Because he's been thinking
about unprotected email and PGP email for the last
15 years, and he can see that MITM, if it exists,
is a very very specialised threat that does not
effect the 99.99% of the body net.

(anyone found any doco on that btw?)

>>Secondly, the way court works is that if one
>>party tables a message, it's generally accepted
>>at face value.  In practice, the mere presence
>>of the message is its own authentication.
> 
> 
> Actually, rules of evidence are a lot more complicated, particularly in
> criminal proceedings. It's pure speculation on my part to assume a
> non-reputable signature on a message would lessen doubt about tampering
> when presented to a third party, but I think it's reasonable speculation,
> and a problem worth avoiding.

Of course.  I'm speaking from the small experience
of having seen several (digitally) signed
documents being presented in a couple of civil
forums so it's an empirical observation, and there
simply isn't enough experience to deal with this
question.

But in sum, the digsigs were considered "mostly
harmless".  At least, whatever view we techies
have for digsigs was not matched by the way they
were received.

One of the reasons
is that neither side dared to question the
authenticity of a document that was tabled,
signed or unsigned.  That's because the risk
of being shown to be wrong was extraordinarily
high, so what tended to happen was that both
sides said "they had not seen that document"
which shifts the attention to whether the doc
was seen by both parties, something that the
digsig doesn't cover.

>>>OTR allows is users to have strong authentication of encrypted messages
>>>without the *additional risk* that normal digital signatures introduce.
>>
>>Turn it around and ask how important strong
>>authentication is?  When was the last time you
>>needed it in email or IM?  I suggest it is something
>>that we inherited from some military threat model
>>that isn't really relevant to our environment.
> 
> 
> I can't agree with this, particularly in the IM environment. It would be
> trivial for one of the large IM service providers to intercept encrypted,
> but unauthenticated traffic through their systems. If you don't trust the
> IM service provider, it is essential that you have end-to-end encryption
> and authentication.

No, this is all based on conjecture.  Normal
rational users, if they don't trust the IM
service provider either switch to another,
guard their talk such that it doesn't matter,
or use nyms.

And, practically speaking, the cost to the
IM service provider in challenging that trust
is way way higher than any plausible benefit
that users could lose if they were MITM'd.

It's just not a threat that matters that much,
even though it is trivial to show that it is
possible.  Covering the MITM is as relevent as
a bullet-proof pocket protector.  Nice for geeks
to own, but not a fashion accessory that users
are likely to go for.

>>brought up in court, Alice might be in a
>>strictly worse position.  On the one hand,
>>she is being dared to lie to the judge,
>>and on the other, she's been seen to use a
>>tool that has a sole advantage of repudiation.
> 
> 
> I'd hardly say that OTR's sole advantage is repudiation. Transparent
> encryption, perfect forward secrecy,

Those are very valuable.

> and a quickly growing user-base are
> also significant advantages. OTR is a privacy tool. Avoiding the
> non-repudiation trap is a form of privacy.
 >
> Simply put, users shouldn't be forced to make non-repudiatable attestations
> in order to achieve privacy for their communications.

No, this is to assume that dig sigs are indeed
non-repudiable attestations.  It's very easy
to repudiate a digital signature.  You just say
you are using some proxy tool and you have no
idea what it does.  The non-repudiable digsig
is a mistake by the crypto community, best off
being totally expunged from the language.

Don't try and repair such a badly broken tool,
remove it from the toolbox and throw it away.

It's complications like these that mean that we
recommend that you should never sign using digsigs
unless you know what it means.  And also why the
protocols have moved over to using secure MACs,
as they don't carry the same stigma as having
any meaning outside the protocol.

iang

Date: Fri, 12 Aug 2005 08:39:22 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Srbecky <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

David Srbecky wrote:
> I take it as that you advice to include preference=sign,encrypt

Yes, that would be better.

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

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

Date: Thu, 11 Aug 2005 23:55:59 +0200
From: David Srbecky <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
OpenPGP: id=234B89FE; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig1C1A54B93FC265A366DAB143
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Simon Josefsson wrote:
> 
> 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.
> 
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
> variants.
>  
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.

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

--------------enig1C1A54B93FC265A366DAB143
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig1C1A54B93FC265A366DAB143--

From: Simon Josefsson <[email-masked]>
To: David Srbecky <[email-masked]>
Cc: openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 11 Aug 2005 21:59:55 +0200
Sender: [email-masked]

David Srbecky <[email-masked]> writes:

> Simon Josefsson wrote:
>> David Srbecky <[email-masked]> 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

Date: Thu, 11 Aug 2005 12:06:00 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Ian G <[email-masked]>
Cc: [email-masked]
Subject: Re: Applicability of signed messages as proof of sending
Sender: [email-masked]

On Thu, 11 Aug 2005, Ian G wrote:

> Right but this needs to be integrated into the
> real world.  Firstly, what does that signature
> mean?  What was it doing there?  Because this
> question is unanswered, and I'd say, unanswerable,
> most people (in my experience) don't use signed
> email.  They simply encrypt.

Right. I'm one of those people. This does, however, leave one open to MITM
attacks -- which are probably not that large of a threat in the general
case, but when dealing with centralized, proprietary IM systems, could
very well be a realistic problem. (This is why Trillian's SecureIM
solution fails my sniff test.)

> Secondly, the way court works is that if one
> party tables a message, it's generally accepted
> at face value.  In practice, the mere presence
> of the message is its own authentication.

Actually, rules of evidence are a lot more complicated, particularly in
criminal proceedings. It's pure speculation on my part to assume a
non-reputable signature on a message would lessen doubt about tampering
when presented to a third party, but I think it's reasonable speculation,
and a problem worth avoiding.

> > OTR allows is users to have strong authentication of encrypted messages
> > without the *additional risk* that normal digital signatures introduce.
>
> Turn it around and ask how important strong
> authentication is?  When was the last time you
> needed it in email or IM?  I suggest it is something
> that we inherited from some military threat model
> that isn't really relevant to our environment.

I can't agree with this, particularly in the IM environment. It would be
trivial for one of the large IM service providers to intercept encrypted,
but unauthenticated traffic through their systems. If you don't trust the
IM service provider, it is essential that you have end-to-end encryption
and authentication.

> brought up in court, Alice might be in a
> strictly worse position.  On the one hand,
> she is being dared to lie to the judge,
> and on the other, she's been seen to use a
> tool that has a sole advantage of repudiation.

I'd hardly say that OTR's sole advantage is repudiation. Transparent
encryption, perfect forward secrecy, and a quickly growing user-base are
also significant advantages. OTR is a privacy tool. Avoiding the
non-repudiation trap is a form of privacy.

Simply put, users shouldn't be forced to make non-repudiatable attestations
in order to achieve privacy for their communications.

--Len.

Date: Thu, 11 Aug 2005 20:17:25 +0200
From: David Srbecky <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: "The OpenPGP mail and news header" extenssion
OpenPGP: id=234B89FE; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig442891C5D0EF41ECF9DA8B29
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Ian G wrote:
 > David Srbecky wrote:
 >
 >>>> 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.
 >
 >
 > 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.

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

--------------enig442891C5D0EF41ECF9DA8B29
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig442891C5D0EF41ECF9DA8B29--

Subject: Re: "The OpenPGP mail and news header" extenssion
From: Richard Laager <[email-masked]>
To: [email-masked]
Organization: Wikstrom Telecom Internet
Date: Thu, 11 Aug 2005 13:15:44 -0500
Sender: [email-masked]

On Thu, 2005-08-11 at 19:13 +0200, David Srbecky wrote:
> Maybe we can rename preference=insecure to something better. Ideas?

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

Richard Laager

Date: Thu, 11 Aug 2005 19:10:57 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Srbecky <[email-masked]>
Cc: Simon Josefsson <[email-masked]>, openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
Sender: [email-masked]

David Srbecky wrote:
>>> 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.

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

Date: Thu, 11 Aug 2005 19:09:07 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Len Sassaman <[email-masked]>
Cc: [email-masked]
Subject: Applicability of signed messages as proof of sending
Sender: [email-masked]

Len Sassaman wrote:
> On Thu, 11 Aug 2005, Ian G wrote:
> 
> 
>>That is, OTR only works when it doesn't matter.
>>
>>This is taking crypto into the real world and not
>>realising the real world has an ability to do things
>>too.  In practice, if any one tried the OTR approach
>>in court, they would quite rightly be screwed.
>>
>>I think we are drifting off the OpenPGP charter
>>though.
> 
> 
> I'll try to bring this back to OpenPGP for a minute.

Well, seeing as there is another thread on
the relationship of signing to encryption,
let's carry on :)

 > The problem, as I see
> it, is that if Alice uses OpenPGP to sign and encrypt his messages, she's
> actually facing a worse situation in court than if she hadn't been using
> OpenPGP, should the other party turn against her. There now exists
> cryptographic signature data to establish, beyond the word of the other
> party, that Alice definitively send the messages in question.

Right but this needs to be integrated into the
real world.  Firstly, what does that signature
mean?  What was it doing there?  Because this
question is unanswered, and I'd say, unanswerable,
most people (in my experience) don't use signed
email.  They simply encrypt.

Secondly, the way court works is that if one
party tables a message, it's generally accepted
at face value.  In practice, the mere presence
of the message is its own authentication.

Only if the other party were to repudiate it
would there be any question and then the notion
of digsigs could be brought in.  But even then,
it is (IMHO) rather unlikely that any opinion
would turn on such issues, as courts have their
own ways of dealing with such things already.
In general practice, people do not lie about
documents in court, neither forging documents
nor repudiating ones they themselves authored.

And this is before any consideration of digsigs
or OTR.  So while your argument might be logical,
it's relevance to actual practice is not clear.

> OTR allows is users to have strong authentication of encrypted messages
> without the *additional risk* that normal digital signatures introduce.

Turn it around and ask how important strong
authentication is?  When was the last time you
needed it in email or IM?  I suggest it is something
that we inherited from some military threat model
that isn't really relevant to our environment.

Once that disappears, there isn't really much point
in OTR, and you may be better off just sending
totally unauthenticated messages.  With PFS, if
you like.  Others disagree of course.

> Alice is no better off in the court scenario that you describe, using OTR
> vs. not using anything, but this way she can use an encryption system that
> doesn't expose her to greater potential danger, should the other party
> defect.

I fear it is the other way around?

As a minor issue, if OTR's claim is that it
encourages Alice to repudiate, and that were
brought up in court, Alice might be in a
strictly worse position.  On the one hand,
she is being dared to lie to the judge,
and on the other, she's been seen to use a
tool that has a sole advantage of repudiation.

What is she going to do?  Lie about the message,
but accept the fact that she uses a tool that
encourages her to lie about messages?

This problem is a really difficult one, and I
do like the fact that they attacked the problem.
I've been toying with legal ways around this for
years and have never yet came across a way that
was worth it.

I think it's really important to move towards
PFS as a standard part of the crypto makup, for
this and other reasons.  But short of making
messages disappear from your machine, I've yet
to think of a way to make this happen in a strict
p2p environment.

iang

Date: Thu, 11 Aug 2005 19:13:57 +0200
From: David Srbecky <[email-masked]>
To: Simon Josefsson <[email-masked]>
Cc: openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
OpenPGP: id=234B89FE; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig96FAC7289BABAEC127475F60
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Simon Josefsson wrote:
> David Srbecky <[email-masked]> 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 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.

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

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.

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.

Thanks,
David

--------------enig96FAC7289BABAEC127475F60
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig96FAC7289BABAEC127475F60--

Date: Thu, 11 Aug 2005 16:24:27 +0100
From: Ian Brown <[email-masked]>
To: Len Sassaman <[email-masked]>
CC: Ian G <[email-masked]>, [email-masked]
Subject: Re: Draft Minutes of OpenPGP
Sender: [email-masked]

> OTR allows is users to have strong authentication of encrypted messages
> without the *additional risk* that normal digital signatures introduce.
> Alice is no better off in the court scenario that you describe, using OTR
> vs. not using anything, but this way she can use an encryption system that
> doesn't expose her to greater potential danger, should the other party
> defect.

Adam Back and I suggested a way of doing this with OpenPGP at Usenix in 
1998: http://www.cs.ucl.ac.uk/staff/i.brown/nts.htm

Date: Thu, 11 Aug 2005 08:14:27 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Ian G <[email-masked]>
Cc: [email-masked]
Subject: Re: Draft Minutes of OpenPGP
Sender: [email-masked]

On Thu, 11 Aug 2005, Ian G wrote:

> That is, OTR only works when it doesn't matter.
>
> This is taking crypto into the real world and not
> realising the real world has an ability to do things
> too.  In practice, if any one tried the OTR approach
> in court, they would quite rightly be screwed.
>
> I think we are drifting off the OpenPGP charter
> though.

I'll try to bring this back to OpenPGP for a minute. The problem, as I see
it, is that if Alice uses OpenPGP to sign and encrypt his messages, she's
actually facing a worse situation in court than if she hadn't been using
OpenPGP, should the other party turn against her. There now exists
cryptographic signature data to establish, beyond the word of the other
party, that Alice definitively send the messages in question.

OTR allows is users to have strong authentication of encrypted messages
without the *additional risk* that normal digital signatures introduce.
Alice is no better off in the court scenario that you describe, using OTR
vs. not using anything, but this way she can use an encryption system that
doesn't expose her to greater potential danger, should the other party
defect.

--Len.

Date: Thu, 11 Aug 2005 16:04:44 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: Len Sassaman <[email-masked]>
Cc: [email-masked]
Subject: Re: Draft Minutes of OpenPGP
Sender: [email-masked]

Len Sassaman wrote:
> On Thu, 4 Aug 2005, Ian Grigg wrote:
> 
> 
>>Currently, IM is mostly unsecured (there is this thing
>>to do with SSL to the server, but as the threat is on
>>the node, that's ignorable).  The way to approach
>>securing chat (IMHO) is to layer OpenPGP over the
>>top in a transparent fashion.
> 
> 
> OpenPGP has a lot of characteristics that one wouldn't particularly want
> in an IM privacy protocol.

Sure, it's a very general comment (and more specifically,
I note that my own secure IM protocol doesn't as yet
enjoy OpenPGP).

 > You might want to take a look at the "Off The
> Record Messaging" system designed by Goldberg and Borisov. Their WPES
> paper addresses the rationale behind ditching the OpenPGP threat model.
> 
> http://www.cypherpunks.ca/otr/#docs

Ah, now IMHO they bungled the threat model.  Normally
this wouldn't be an issue (I encourage all crypto
experiments, even ones I think suck!), but the authors
then go on to suggest that the user can repudiate and
is protected because no-one can prove the messages were
sent.

The threat is on the node, and this includes your
other party.  If your other party says you sent the
messages, then your silence, or your claim that it
can't be proven, are inadequate.  You actually have
to say you didn't send the messages.  So this means
that the property of repudiability is only available
if you lie, which is not only a contradictory
approach, but also extraordinarily dangerous and
in practice useless in court or in any adversarial
setting.

That is, OTR only works when it doesn't matter.

This is taking crypto into the real world and not
realising the real world has an ability to do things
too.  In practice, if any one tried the OTR approach
in court, they would quite rightly be screwed.

I think we are drifting off the OpenPGP charter
though.

> (More generally, I agree with the sentiment that ASCII-armored OpenPGP is
> important for use with other protocols besides email, and should be the
> canonical format for OpenPGP, email and otherwise.)

Cool!

iang

Date: Thu, 11 Aug 2005 14:14:08 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Srbecky <[email-masked]>
Cc: openpgp <[email-masked]>
Subject: Re: New 'User Attribute Packet' subpacket - Named Attribute Subpacket (type 0)
Sender: [email-masked]

David Srbecky wrote:
> Hello,
> 
> In my humble opinion this is the most important attribute of all. That's 
> why I suggest assigning it the special type 0. This attribute is 
> supposed to be used for any user specific, program specific or 
> experimental data. It is similar to the mail X- headers - it allows 
> users to store identifiable information, which is not suitable for 
> standardization or is not standardized yet.

This sounds like a new feature request.  I vote no,
we are in last call.  Apologies, I think you've turned
up too late for this one.

iang

Date: Thu, 11 Aug 2005 14:07:54 +0100
From: Ian G <[email-masked]>
Organization: http://financialcryptography.com/
To: David Srbecky <[email-masked]>
Cc: openpgp <[email-masked]>
Subject: Re: Rename 'User Attribute Packet' subpacket - Photo ID Subpacket (type 1)
Sender: [email-masked]

David Srbecky wrote:
> Hello,
> 
> I suggest that 'Image Attribute Subpacket' is renamed to 'Photo ID 
> Subpacket' or anything similarly specific. 'Image Attribute Subpacket' 
> defines data type, but not what the data actually represent. What if 
> user stored two or more images? How do you guess what the individual 
> attributes hold?

Er, that doesn't sound likely.  What happens if someone
assumes that the image is an ID because OpenPGP said so?

The OpenPGP philosophy is to say nothing that it cannot
cryptographically show.  What a photo contains cannot be
so shown.

> For example, what if someone stores Photo ID and company logo? How do 
> you differentiate them? I suggest this one is specified to be a Photo ID 
> and any other content must be stored elsewhere.

Only people can determine the difference between a
Photo ID and a company logo.  It's up to them, the
tech plays no part in this.  You might be suggesting
that a user-signed comment be appended to the subpacket.

Bear in mind that this group is in "last call" so any
suggested changes should be pretty darn urgent.

iang

Date: Thu, 11 Aug 2005 14:22:38 +0200
From: David Srbecky <[email-masked]>
To: openpgp <[email-masked]>
Subject: New 'User Attribute Packet' subpacket - Property Subpacket (type 3)
OpenPGP: id=2DC6523A; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigF5D60A9762DE3E5175233751
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Follow-up to post: "The OpenPGP mail and news header" extenssion

Hello,

There are a lot of little attributes we may want to store with the 
public key. For example:

1 - supports MIME format
2 - supports inline format
3 - supports header format
4 - preferred format
5 - prefers signed mail
6 - prefers encrypted mail
7 - public key url
etc...

There are two approaches I would like to suggest which could solve this:

  - We can assign a subpacket for every such attribute

  - We can create specific subpacket to hold theses attributes:

Property Subpacket (type 3)
-------------------------------------
Subpacket specific data:
    id - identifier - eg. 1
    data - depends on id - eg. true

The advantage of this approach is that one relatively unimportant 
attribute will not consume whole 'User Attribute Packet' subpacket. 
Also, it should make deprecating/updating easier since all these 
attributes are members of one subpacket type.

I really can not decide which approach is better.

'Property Subpacket' does not really describe the purpose of the 
subpacket, but I could not find any better name. Any suggestions?

Regards,
David Srbecky

--------------enigF5D60A9762DE3E5175233751
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigF5D60A9762DE3E5175233751--

Date: Thu, 11 Aug 2005 14:21:03 +0200
From: David Srbecky <[email-masked]>
To: openpgp <[email-masked]>
Subject: New 'User Attribute Packet' subpacket - vCard Subpacket (type 2)
OpenPGP: id=2DC6523A; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5BE3228DC7DBC544FC64ECC6
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

You can store you name, email and Photo ID in your public key, but what 
about other information? I suggest to standardize 'vCard Subpacket'. 
vCard is already known and supported format in MUAs and so the cost of 
implementing this should be minimal.

vCard Subpacket (type 2)
----------------------------------
Subpacket specific data:
     data - content of the vCard file

Regards,
David Srbecky

--------------enig5BE3228DC7DBC544FC64ECC6
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5BE3228DC7DBC544FC64ECC6--

Date: Thu, 11 Aug 2005 14:20:22 +0200
From: David Srbecky <[email-masked]>
To: openpgp <[email-masked]>
Subject: Rename 'User Attribute Packet' subpacket - Photo ID Subpacket (type 1)
OpenPGP: id=2DC6523A; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7B92E6CF5728EBAE3369E6BE
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

I suggest that 'Image Attribute Subpacket' is renamed to 'Photo ID 
Subpacket' or anything similarly specific. 'Image Attribute Subpacket' 
defines data type, but not what the data actually represent. What if 
user stored two or more images? How do you guess what the individual 
attributes hold?

For example, what if someone stores Photo ID and company logo? How do 
you differentiate them? I suggest this one is specified to be a Photo ID 
and any other content must be stored elsewhere.

Regards,
David Srbecky

--------------enig7B92E6CF5728EBAE3369E6BE
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7B92E6CF5728EBAE3369E6BE--

Date: Thu, 11 Aug 2005 14:19:36 +0200
From: David Srbecky <[email-masked]>
To: openpgp <[email-masked]>
Subject: New 'User Attribute Packet' subpacket - Named Attribute Subpacket (type 0)
OpenPGP: id=2DC6523A; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig5DCE95A148219DC07FFDC45B
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

In my humble opinion this is the most important attribute of all. That's 
why I suggest assigning it the special type 0. This attribute is 
supposed to be used for any user specific, program specific or 
experimental data. It is similar to the mail X- headers - it allows 
users to store identifiable information, which is not suitable for 
standardization or is not standardized yet.

Named Attribute Subpacket (type 0)
----------------------------------
Subpacket specific data:
    datatype - identifier - eg. 4 - UTF8 string
    name - UTF8 string - eg. "ICQ#"
    data - depends on datatype - eg. "123-456-789"

NB: size of data is given by the size of subpacket minus the size of 
datatype identifier and the size of the name.

Datatypes:
    0 - reserved
    1 - no data (it is just named flag)
    2 - boolean
    3 - integer
    4 - UTF8 string
    5 - URL
    6 - image
    7 - binary
    8 - binary file
    100-110 - private or experimental use

NB: Binary type holds just some unspecified binary data. On the other 
hand, binary file type holds file that can be saved to disk and the name 
of the attribute represents its filename (including path???).

I believe that this attribute would allow the user to store anything he 
wants in his public key. It does not matter what it is, the important 
thing is that is would be possible. Let the users and developers be 
creative!

Regards,
David Srbecky

--------------enig5DCE95A148219DC07FFDC45B
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig5DCE95A148219DC07FFDC45B--

From: Simon Josefsson <[email-masked]>
To: David Srbecky <[email-masked]>
Cc: openpgp <[email-masked]>
Subject: Re: "The OpenPGP mail and news header" extenssion
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Thu, 11 Aug 2005 11:48:52 +0200
Sender: [email-masked]

David Srbecky <[email-masked]> 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

Date: Wed, 10 Aug 2005 20:14:15 +0200
From: David Srbecky <[email-masked]>
To: openpgp <[email-masked]>
Subject: "The OpenPGP mail and news header" extenssion
OpenPGP: id=2DC6523A; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

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

PPS: Just out of curiosity, why are you using

OpenPGP: id=12345678;
          url=http://example.com/key.txt;

and not

OpenPGP-ID: 12345678
OpenPGP-URL: http://example.com/key.txt

I know, it looks better, but I am afraid it might be more difficult to 
implement and it might discourage developers from accepting the standard.

Regards,
David Srbecky

Date: Wed, 10 Aug 2005 19:16:31 +0200
From: David Srbecky <[email-masked]>
To: openpgp <[email-masked]>
Subject: "The OpenPGP mail and news header" extenssion
OpenPGP: id=2DC6523A; url=http://www.volny.cz/davejp/OpenPGP.asc
Sender: [email-masked]

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE8895556DBA372FE22521D17
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit

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

--------------enigE8895556DBA372FE22521D17
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigE8895556DBA372FE22521D17--

Date: Wed, 10 Aug 2005 09:47:09 -0700 (PDT)
From: Len Sassaman <[email-masked]>
To: Ian Grigg <[email-masked]>
Cc: [email-masked]
Subject: Re: Draft Minutes of OpenPGP
Sender: [email-masked]

On Thu, 4 Aug 2005, Ian Grigg wrote:

> Currently, IM is mostly unsecured (there is this thing
> to do with SSL to the server, but as the threat is on
> the node, that's ignorable).  The way to approach
> securing chat (IMHO) is to layer OpenPGP over the
> top in a transparent fashion.

OpenPGP has a lot of characteristics that one wouldn't particularly want
in an IM privacy protocol. You might want to take a look at the "Off The
Record Messaging" system designed by Goldberg and Borisov. Their WPES
paper addresses the rationale behind ditching the OpenPGP threat model.

http://www.cypherpunks.ca/otr/#docs

(More generally, I agree with the sentiment that ASCII-armored OpenPGP is
important for use with other protocols besides email, and should be the
canonical format for OpenPGP, email and otherwise.)

To: [email-masked]
Subject: Re: Draft Minutes of OpenPGP
Date: Thu,  4 Aug 2005 09:34:48 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

Derek wrote:
>         - update milestones - proposal given.
>
> -- Proposed Milestones
>
>         - No Objections

What were the proposed milestones?

Hal Finney

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Draft Minutes of OpenPGP
Date: Thu, 4 Aug 2005 07:09:58 -0700
To: Ian Grigg <[email-masked]>
Sender: [email-masked]

On 4 Aug 2005, at 4:08 AM, Ian Grigg wrote:

> I don't think it is necessary to "kill mime" but I don't
> have much hope for its survival.  As it only works
> when the other client also understands the format,
> it is facing an uphill battle.  ascii-armouring works
> much better as the user becomes the fallback.
>

Thank you, Ian.

Nor do I want to "kill mime." I don't want to kill MIME. That 
mischaracterizes what I said.

All I want is not to be forced to do MIME. Unfortunately, it appears 
that there are a lot of people who denigrate text, and think that if 
you say, "Hey, I like text!" then that means you want to kill MIME.

	Jon

From: Ian Grigg <[email-masked]>
To: [email-masked]
Subject: Re: Draft Minutes of OpenPGP
Date: Thu, 4 Aug 2005 12:08:15 +0100
Sender: [email-masked]

On Thursday 04 August 2005 09:46, Derek Atkins wrote:

>  [Jon]  - Wants support to plain inline text - kill mime and only use plain text as a personal preference.

I'd agree with this.  OpenPGP needs to support a
basic mechanism to use open text channels in the
most robust fashion.  The ascii-armouring has passed
the test of time in this fashion.

I don't think it is necessary to "kill mime" but I don't
have much hope for its survival.  As it only works
when the other client also understands the format,
it is facing an uphill battle.  ascii-armouring works
much better as the user becomes the fallback.

OpenPGP needs to think in terms of email being
a lesser and lesser influence.  IMO, email is dying.
That's debateable, but what is clear is that the star
of IM is on the ascendancy, and the email thing is
losing that battle.

Currently, IM is mostly unsecured (there is this thing
to do with SSL to the server, but as the threat is on
the node, that's ignorable).  The way to approach
securing chat (IMHO) is to layer OpenPGP over the
top in a transparent fashion.

That means ascii-armouring for the moment.

Other systems will have similar engineering demands.
Trying to integrate two disparate systems together is
hard.

iang
-- 
Advances in Financial Cryptography, Issue 2:
   https://www.financialcryptography.com/mt/archives/000498.html
Mark Stiegler, An Introduction to Petname Systems
Nick Szabo, Scarce Objects
Ian Grigg, Triple Entry Accounting

Date: Thu, 4 Aug 2005 11:31:39 +0200
From: Thomas Roessler <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Draft Minutes of OpenPGP
Mail-Followup-To: Derek Atkins <[email-masked]>, [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 2005-08-04 10:46:36 +0200, Derek Atkins wrote:

>                         Thomas ? - two formats - with and w/o tag
>			 - please elimiate the tag version.

I was asking to remove the untagged version, not the tagged one.

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

From: Derek Atkins <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Draft Minutes of OpenPGP
Date: Thu, 04 Aug 2005 10:46:36 +0200
Sender: [email-masked]

--=-=-=

Attached are the draft minutes for the OpenPGP meeting.  In short:

1) 2440bis should go to WGLC later this month
2) new milestones were proposed by the chair and no objections noted
3) there appears to be interest in adopting new work: the message-header

-derek

--=-=-=
Content-Disposition: attachment; filename=Minutes-63.txt
Content-Description: draft minutes

AGENDA --

-- Introduction and Agenda Bashing

         No changes 

-- 2440 bis status

        - In "pentultimate last call" for some time (over a year) - now only doing tweaks to the document.
        - If you want changes in wording - need to be compatable and suggest text.
        - Only open issue is David Shaw's BNF request for literal+literal.  No reason not to include David Shaw's request, but not in draft 14.  Should go into 15
        - Run last call and finish this document
        - Use difference documents for new work - downside is that not everything will be in a small number of documents.  Good news is that will have a fixed definitive document

--  2440 next steps
        - Go to Last call. finish by end of August
        - Try for a bake off? try for Draft Standard. (early in '06)
        - update milestones - proposal given.
        - Draft standard would be tried for 6 months after IESG approval.
        
        - New Life
        -       New documents not hit 2440bis.
        -       

-- Proposed Milestones

        - No Objections

--- Message Header

        - draft-josefsson-openpgp-mailnews-header-01.txt

        - standardize some X- headers for PGP.
        - Lookup URL and key id of a sender
        - simplified original by dropping some unnecessary data.
                - key id - longer fingerprint - url to key

        - What is the problem to be solved?
                - Not completely clear
                - invent header that could be used programatically to lookup key and keyid of sender
                - Manual cut & paste?
                - request for additinoal current usage of old headers for inclusion in the doument.

        - Open Issuses:
                - Add token to state strong preference for reciving PGP and potentially the PGP format to be sent.
                        - IETF process restricted to MIME?
                        - place same info into a packet?

                - Keyserver field?
                        - unsure of what this would be really for.  Next expansion of the idea.

                - BNF problems on the draft need corrections.

         Open MIKE
                JON - Supports idea of draft - supports "supports token"  - PGP has a similar item already used.  used with different values for different reading devices.

                        - Wants support to plain inline text - kill mime and only use plain text as a personal preference.

                - response - Need additional proposals to solve some of the problems?

                        JON - display problems not format issues - Don't ban text only w/o mime wrappers.
                        8-bit character set problems with servers - 
                        
                        Vigourous dispute on issues with character sets.

                        Thomas ? - two formats - with and w/o tag - please elimiate the tag version.
                        
                        ??? - Please add finger print header - used for validation.

                                - possible support already?

                        JON - KeyID is a trucated fingerprint - allow for longer id to get fuller fingerprint w/o much additional parsing.  

                                - -00 to -01 allowed for longer KeyID from a fixed length.

--- Open Discussion

        - Meeting closed.

--=-=-=

-- 
       Derek Atkins                 617-623-3745
       [email-masked]             www.ihtfp.com
       Computer and Internet Security Consultant

--=-=-=--

To: [email-masked], [email-masked]
Subject: Re: PGP questions
Date: Wed,  3 Aug 2005 13:40:52 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

This list is for technical discussion of the data formats used by
the OpenPGP standard.  You might want to try the pgp-users mailing
list, http://www.cryptorights.org/lists/pgp-users/ .

Hal Finney

> From: "g kare" <[email-masked]>
> To: [email-masked]
> Subject: PGP questions
> Date: Wed, 03 Aug 2005 19:08:44 +0000
>
>
> Hi,
>
> I am trying to get my company to upgrade to PGP 9, but he is voicing concern 
> that PGP has gone through so many management changes, that is reluctant to 
> spend $$$ on PGP.
>
> Can anyone speculate on what the future holds for PGP Corp?  Is there a 
> future for them?
>
> Are there any viable alternative products to PGP?
>
>
> Thanks,
>
> Gary

From: Simon Josefsson <[email-masked]>
To: Derek Atkins <[email-masked]>
Cc: [email-masked]
Subject: OpenPGP header (was: Re: Meet in Paris?)
OpenPGP: id=B565716F; url=http://josefsson.org/key.txt
Date: Wed, 03 Aug 2005 23:02:12 +0200
Sender: [email-masked]

I forgot to raise the question of whether the WG wishes to adopt this
document as a work item.  Is there interest in doing so?

I fear the precise wording to deal with a "supports" token may be
contentious, and will likely bring back the PGP/MIME vs vanilla PGP in
e-mail environments discussion, so hold that in mind when deciding.

I think there are two orthogonal questions that a "supports" token
could address:

  1) Preference between PGP/MIME, vanilla PGP, or hybrid.
  2) To signal that the originator wants personal e-mail PGP
     encrypted.

It may be overloading to have the same token address both matters;
arguing for two new tokens.  It may also be that either one of 1) or
2) should not be done now.  As a proponent of a PGP/MIME-only e-mail
world -- possibly except for the few cases [1] when vanilla PGP can be
used interoperable -- I would not mind if 1) was not supported at all.

Thanks,
Simon

[1] US-ASCII, no format=flowed, no lines starting with From or '-',
see <http://josefsson.org/inline-openpgp-considered-harmful.html>

Derek Atkins <[email-masked]> writes:

> I'd be happy to put you on for 5-10 minutes?  I really don't
> think it will slow down 2440bis.
>
> -derek
>
> Simon Josefsson <[email-masked]> writes:
>
>> Derek Atkins <[email-masked]> writes:
>>
>>> Hi,
>>>
>>> Do the members of this working group feel we need a meeting
>>> in Paris?  I think we might want to meet in order to consider
>>> work beyond 2440bis (e.g. PFS, Mail-Headers, or other work
>>> that's been proposed).
>>
>> I would likely be around to talk about the OpenPGP mail header [1], if
>> there is interest.  Feedback from OpenPGP experts on the usefulness of
>> adding a "supports" token to the header is one open issue that may be
>> useful to discuss.
>>
>> I'd hate to see anything slow down 2440bis further though.
>>
>> [1] http://josefsson.org/openpgp-header/
>>
>>
>
> -- 
>        Derek Atkins                 617-623-3745
>        [email-masked]             www.ihtfp.com
>        Computer and Internet Security Consultant

To: "g kare" <[email-masked]>
Cc: [email-masked]
Subject: Re: PGP questions
From: Werner Koch <[email-masked]>
Organisation: g10 Code GmbH
OpenPGP: id=5B0358A2; url=finger:[email-masked]
Date: Wed, 03 Aug 2005 21:58:14 +0200
Sender: [email-masked]

On Wed, 03 Aug 2005 19:08:44 +0000, g kare said:

> Can anyone speculate on what the future holds for PGP Corp?  Is there
> a future for them?

This is a list of the IETF OpenPGP WG; it is purely a technical list
and not a business oriented one.  Please ask elsewhere.

> Are there any viable alternative products to PGP?

Sure, I'd say.

Shalom-Salam,

   Werner

From: "g kare" <[email-masked]>
To: [email-masked]
Subject: PGP questions
Date: Wed, 03 Aug 2005 19:08:44 +0000
Sender: [email-masked]

Hi,

I am trying to get my company to upgrade to PGP 9, but he is voicing concern 
that PGP has gone through so many management changes, that is reluctant to 
spend $$$ on PGP.

Can anyone speculate on what the future holds for PGP Corp?  Is there a 
future for them?

Are there any viable alternative products to PGP?

Thanks,

Gary

To: [email-masked], [email-masked]
Subject: Re: Secret key encryption
Date: Wed,  3 Aug 2005 09:24:09 -0700 (PDT)
From: [email-masked] ("Hal Finney")
Sender: [email-masked]

> I need to encrypt secret data of the keypair to prevent attackers from
> misusing the keypair. I am using 3DES symmetric algorithm in encrypting
> and decrypting the secret key. As a s2k specifier I use Iterated and
> Salted S2K, so in the encryption process I need the secret passphrase, 
> the Coded count,  an 8-octet salt value and an 8-octet Initial Vector. My
> question is: is the Initial vector some arbitrary data like salt values
> are? In this case it would be some 64-bit random number. And what about
> the coded count value? What affects to the value? I have generated my keys
> so far with gnu privacy guard software and the count has always been 96
> (65536) in every key. I didn`t find solution to this from the RFC2440. Can
> someone clarify this?

Yes, the IV should be a 64 bit random number.

The purpose of the coded count is to slow down dictionary attacks.  In a
dictionary attack, someone who gets access to the secret key ring tries
all possible pass phrases.  By slowing down the operation of turning a
passphrase into the 3DES key that unlocks the secret key, it makes the
dictionary attacker's job harder.

Choosing a value for the coded count is a tradeoff.  Larger values will
help defend against dictionary attacks, but they will also slow down
the process of unlocking the key for legitimate users.  If keys in your
application will be unlocked by human users typing in their passphrases,
then larger coded counts would be acceptable, providing for delays of 1/10
or even 1/2 second or more.  If your application must expose the secret
key data structure, again larger coded counts would be appropriate.
On the other hand, if your application involves an automated system
which must frequently unlock keys, and/or if you are confident that
your passphrases are strong and can't be found with a dictionary attack,
and/or if you have good security to keep the secret key ring from being
exposed, then you might go with a lower coded count.  Those are the kinds
of considerations that will help you balance the tradeoffs.

Hal Finney

Cc: [email-masked]
From: Jon Callas <[email-masked]>
Subject: Re: Literal+Literal
Date: Wed, 3 Aug 2005 05:57:00 -0700
To: David Shaw <[email-masked]>
Sender: [email-masked]

On 21 Jul 2005, at 3:03 PM, David Shaw wrote:

>
> A while back (2003), I noticed a inconsistency in the draft.  The
> problem was one of those fiddly grammar things: some text in the draft
> said that multiple literal packets in a row were legal, and some other
> text said that it wasn't.  For example, in that draft,
> COMPRESSED(literal+literal) was legal in section 5.6, and illegal in
> 10.2.
>
> To resolve that, I suggested that we simply change 10.2 (the grammar
> section) to allow literal+literal.  That's how the draft reads now.
> Several people have commented that this is raising more problems than
> it is solving, and they're right.  Literal+literal raises a whole
> collection of issues with how to hash the data in a construction like
> onepass+literal+literal+sig.  It also requires parsers to be more
> complex (though at least the parsers in PGP and GPG always worked this
> way).
>
> I'd like to change the text to fix this, and solve this problem a
> different way: rather than resolve the inconsistency by making
> literal+literal legal everywhere, better to resolve the inconsistency
> by making literal+literal illegal everywhere.
>
> The specific changes would be:
>
> Section 5.6 (Compressed Data Packet) - change "literal data packets"
> to "a literal data packet".
>
> Section 5.7 (Symmetrically Encrypted Data Packet) - change "literal
> data packets" to "a literal data packet".
>
> Section 5.13 (Sym. Encrypted Integrity Protected Data Packet) - change
> "literal data packets or compressed data packets" to "a literal data
> packet or compressed data packet".
>
> Then in section 10.2, revert from this:
>
>     Literal Message :- Literal Data Packet |
>                       Literal Message, Literal Data Packet.
>
> to this:
>
>     Literal Message :- Literal Data Packet
>
> David
>
>

Done. Will be in bis15.

	Jon

Date: Wed, 3 Aug 2005 10:57:10 +0300 (EEST)
Subject: Secret key encryption
From: <[email-masked]>
To: <[email-masked]>
Importance: Normal
Sender: [email-masked]

I need to encrypt secret data of the keypair to prevent attackers from
misusing the keypair. I am using 3DES symmetric algorithm in encrypting
and decrypting the secret key. As a s2k specifier I use Iterated and
Salted S2K, so in the encryption process I need the secret passphrase, 
the Coded count,  an 8-octet salt value and an 8-octet Initial Vector. My
question is: is the Initial vector some arbitrary data like salt values
are? In this case it would be some 64-bit random number. And what about
the coded count value? What affects to the value? I have generated my keys
so far with gnu privacy guard software and the count has always been 96
(65536) in every key. I didn`t find solution to this from the RFC2440. Can
someone clarify this?