Re: secure sign & encrypt

[Jon Callas <[e-mail]>]

On 5/30/2002 12:15 PM, "Brian M. Carlson" <[e-mail]> wrote:

> You can have this. The standard declares that subpackets 100 to 110 are
> "internal or user-defined". You can even set the critical bit on it if
> you like. This should solve your problem. Your only other problem is to
> convince an implementer to implement this subpacket, or you can
> implement it yourself. Do know that gpg has used 101 in the past for
> internal purposes; this might be a bad choice.
> 
> This subpacket is completely optional; in fact all but two subpackets
> are: the creation time, and the issuer.
> 
> Therefore, this discussion can end, knowing everybody is happy.

The correct solution is to use a notation packet, not the 100-110 range.
That's why they're there.

But other than that, I agree completely. The discussion can end, because the
current protocol has features that support the desired implementation.

    Jon




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4UK7G719311 for ietf-openpgp-bks; Thu, 30 May 2002 13:07:16 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UK7Fn19307 for <[e-mail]>; Thu, 30 May 2002 13:07:15 -0700 (PDT)
Received: from [192.168.1.48] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Thu, 30 May 2002 13:07:14 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Thu, 30 May 2002 13:07:12 -0700
Subject: Re: secure sign & encrypt
From: Jon Callas <[e-mail]>
To: "Brian M. Carlson" <[e-mail]>, Terje Braaten <[e-mail]>
CC: OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <20020530191510.GA4317@stonewall>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 5/30/2002 12:15 PM, "Brian M. Carlson" <[e-mail]> wrote:

> You can have this. The standard declares that subpackets 100 to 110 are
> "internal or user-defined". You can even set the critical bit on it if
> you like. This should solve your problem. Your only other problem is to
> convince an implementer to implement this subpacket, or you can
> implement it yourself. Do know that gpg has used 101 in the past for
> internal purposes; this might be a bad choice.
> 
> This subpacket is completely optional; in fact all but two subpackets
> are: the creation time, and the issuer.
> 
> Therefore, this discussion can end, knowing everybody is happy.

The correct solution is to use a notation packet, not the 100-110 range.
That's why they're there.

But other than that, I agree completely. The discussion can end, because the
current protocol has features that support the desired implementation.

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g4UJFAi18316 for ietf-openpgp-bks; Thu, 30 May 2002 12:15:10 -0700 (PDT)
Received: from mail.hal-pc.org (mail.hal-pc.org [206.180.145.133]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UJF9n18312 for <[e-mail]>; Thu, 30 May 2002 12:15:09 -0700 (PDT)
Received: from [206.180.153.73] (HELO stonewall) by mail.hal-pc.org (CommuniGate Pro SMTP 3.5.6) with SMTP id 11315517; Thu, 30 May 2002 14:15:09 -0500
Received: by stonewall (sSMTP sendmail emulation); Thu, 30 May 2002 19:15:10 +0000
From: "Brian M. Carlson" <[e-mail]>
Date: Thu, 30 May 2002 19:15:10 +0000
To: Terje Braaten <[e-mail]>
Cc: "OpenPGP (E-mail)" <[e-mail]>
Subject: Re: secure sign & encrypt
Message-ID: <20020530191510.GA4317@stonewall>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-ripemd160; protocol="application/pgp-signature"; boundary="C7zPtVaVf+AK4Oqc"
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.28i
X-Operating-System: Linux stonewall 2.4.18-k7 
Content-Conversion: prohibited
X-Request-PGP: http://decoy.wox.org/~bmc/openpgp/pub560553e7.asc
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, May 30, 2002 at 07:38:22AM +0200, Terje Braaten wrote:
>=20
> Michael Young writes that "The intended recipient is only one of many
> pieces of context that a user might mistakenly believe was included
> in the signed material." That is correct, but I will still argue that
> the information on which keys the message is encrypted to (or intended
> to be encrypted to) is special, and belongs in the OpenPGP standard.
>=20
> It is not only mail that can be signed and encrypted with OpenPGP,
> it can be all kinds of electronic documents and messages. When f.ex.
> an "X-To-PGP-Key" header might be an adequate solution for e-mail
> messages, it will not fit at all for other sorts of messages.
> In fact, the only meta data about a message that is common to all
> encrypted messages is the recipient public keys. And since this
> is meta data about the message that is always present, I think
> it is very appropriate to be specified in the protocol a convention
> on how this is to be protected in a message that is signed and encrypted.
>=20
> (If we could just have an optional sub packet on the signature in the fir=
st
> round I would be happy.)

You can have this. The standard declares that subpackets 100 to 110 are
"internal or user-defined". You can even set the critical bit on it if
you like. This should solve your problem. Your only other problem is to
convince an implementer to implement this subpacket, or you can
implement it yourself. Do know that gpg has used 101 in the past for
internal purposes; this might be a bad choice.

This subpacket is completely optional; in fact all but two subpackets
are: the creation time, and the issuer.

Therefore, this discussion can end, knowing everybody is happy.

--=20
Brian M. Carlson
<[e-mail]>
OpenPGP: 0x351336B2DCA1913A

--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7a-cvs (GNU/Linux)
Comment: Ubi libertas, ibi patria.

iQEVAwUBPPZ6PeWR/8lWBVPnAQMvFQf8CzApxL/IDl7g6zjrxwT4GrDCPXXtqWlF
KauU7KPo3tIaEOPcYsggivscNHJx/hb1FZR21WfHsU6JZ11LX+ziO4ZBCXK7YSWo
xScMBQTNksdjV5nGJK4W1sJjgSXwLFtisI11Y54bkr9LEdLea5bZa4KhR/PjB98d
jQtiUx0uaqCz211DiHzkJkYYyN6FeDAEjed4cDNjTILeeCrx4cbfRAsDPqGsfv73
91rdZFYvnojfpMK52GkcsYz0DTKH+kzkaXWhXsd+sTM3cR+bsWUgMB2px8MrXQ61
eesqWcYyc2vJLAAd6SJsbMKMwtaH0PuGlgQwnUpr6H91YMMYrtQOoQ==
=N0sw
-----END PGP SIGNATURE-----

--C7zPtVaVf+AK4Oqc--


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4UEUCP03457 for ietf-openpgp-bks; Thu, 30 May 2002 07:30:12 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4UEUB103453 for <[e-mail]>; Thu, 30 May 2002 07:30:11 -0700 (PDT)
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA24301; Thu, 30 May 2002 10:30:11 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA01003; Thu, 30 May 2002 10:30:10 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id KAA10392; Thu, 30 May 2002 10:30:09 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA28652; Thu, 30 May 2002 10:30:09 -0400 (EDT)
To: Terje Braaten <[e-mail]>
Cc: [e-mail]
From: Derek Atkins <[e-mail]>
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted P GP message is useless
References: <[e-mail]>
Date: 30 May 2002 10:30:09 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 39
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Terje Braaten <[e-mail]> writes:

> > >> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(K||Bob_PK)), msg)
> > >>
> > >> with the additional restriction that the encryption mode 
> > should be one
> > >> of the MDC modes (ie appended MAC with K outside encryption, or
> > >> appended hash of msg inside encryption).
> 
> What a wonderful solution. Hello everybody, we go ahead and change
> the next version of the protocol to this. Ok?

No.  It is definitely not ok.  This breaks backwards compatibiltiy
with implementations of 2440.

No matter what you do it should be backwards compatible with existing
software.  Current implementations should still be able to read it,
even if they don't understand it.

My two suggestions still remain:

  1) Write up an RFC that defines how to use a notation packet to do
     what you want, where that notation packet is included in the
     signature.  Within that notation you can store the original
     recipients list.

  2) Write up an RFC that defines how to use 2440 packets in ESE mode.
     I'm fairly sure that most of the existing 2440 implementation can
     read an ESE message (at least if they implemented their parser
     recursively like I did in PGP 5).

Either of these solutions solve your problem _AND_ remain
2440-compatible.

-derek
-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [e-mail]             www.ihtfp.com


Received: by above.proper.com (8.11.6/8.11.3) id g4U5pHH13589 for ietf-openpgp-bks; Wed, 29 May 2002 22:51:17 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4U5pF113585 for <[e-mail]>; Wed, 29 May 2002 22:51:15 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <L8P7ZZ2M>; Thu, 30 May 2002 07:48:25 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: [e-mail]
Subject: RE: Recipient-verifiable messages, was: forwarding an encrypted P GP message is useless
Date: Thu, 30 May 2002 07:48:24 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4U5pG113586
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

[e-mail] wrote:
> 
> Hal Finney <[e-mail]>:
> > Adam Back writes:
> 
> >> What we proposed is related.  Rather
> >> than the normal encrypted signed message:
> >>
> >> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(msg)), msg)
> >>
> >> we proposed:
> >>
> >> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(K||Bob_PK)), msg)
> >>
> >> with the additional restriction that the encryption mode 
> should be one
> >> of the MDC modes (ie appended MAC with K outside encryption, or
> >> appended hash of msg inside encryption).

What a wonderful solution. Hello everybody, we go ahead and change
the next version of the protocol to this. Ok?

-- 
Terje Bråten



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4U5fLp13390 for ietf-openpgp-bks; Wed, 29 May 2002 22:41:21 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4U5fI113386 for <[e-mail]>; Wed, 29 May 2002 22:41:19 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <L8P7ZZ2J>; Thu, 30 May 2002 07:38:23 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "OpenPGP (E-mail)" <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Thu, 30 May 2002 07:38:22 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4U5fJ113387
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Michael Young writes that "The intended recipient is only one of many
pieces of context that a user might mistakenly believe was included
in the signed material." That is correct, but I will still argue that
the information on which keys the message is encrypted to (or intended
to be encrypted to) is special, and belongs in the OpenPGP standard.

It is not only mail that can be signed and encrypted with OpenPGP,
it can be all kinds of electronic documents and messages. When f.ex.
an "X-To-PGP-Key" header might be an adequate solution for e-mail
messages, it will not fit at all for other sorts of messages.
In fact, the only meta data about a message that is common to all
encrypted messages is the recipient public keys. And since this
is meta data about the message that is always present, I think
it is very appropriate to be specified in the protocol a convention
on how this is to be protected in a message that is signed and encrypted.

(If we could just have an optional sub packet on the signature in the first
round I would be happy.)

-- 
Terje Bråten



Received: by above.proper.com (8.11.6/8.11.3) id g4TL4v713749 for ietf-openpgp-bks; Wed, 29 May 2002 14:04:57 -0700 (PDT)
Received: from [165.227.249.18] (165-227-249-18.client.dsl.net [165.227.249.18]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4TL4sJ13732 for <[e-mail]>; Wed, 29 May 2002 14:04:54 -0700 (PDT)
Mime-Version: 1.0
X-Sender: [e-mail]
Message-Id: <p05111766b91af2b289c5@[165.227.249.18]>
In-Reply-To: <00dd01c20386$f545f9a0$[e-mail]>
References: <[e-mail]> <00dd01c20386$f545f9a0$[e-mail]>
Date: Wed, 29 May 2002 14:04:49 -0700
To: [e-mail]
From: Paul Hoffman / IMC <[e-mail]>
Subject: Re: secure sign & encrypt
Content-Type: text/plain; charset="us-ascii" ; format="flowed"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

The S/MIME WG has wrestled with the same issues, coming to the same 
problems that have appeared here. The latest thinking there can be 
found in the the tread that starts at 
<http://www.imc.org/ietf-smime/mail-archive/msg01238.html>.

--Paul Hoffman, Director
--Internet Mail Consortium


Received: by above.proper.com (8.11.6/8.11.3) id g4QFs1406246 for ietf-openpgp-bks; Sun, 26 May 2002 08:54:01 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4QFrxJ06242 for <[e-mail]>; Sun, 26 May 2002 08:54:00 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id 800C62C93; Sun, 26 May 2002 17:53:59 +0200 (MET DST)
Received: id <m17C0Jw-000QdtC@epsilon>; Sun, 26 May 2002 17:52:36 +0200 (CEST) 
Date: Sun, 26 May 2002 17:52:36 +0200
From: Bodo Moeller <[e-mail]>
To: [e-mail], Hal Finney <[e-mail]>, [e-mail]
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
Message-ID: <20020526175235.A535@epsilon>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0i
In-Reply-To: <no.id>; from [e-mail] on Sun, May 26, 2002 at 03:28:41PM +0000
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Sun, May 26, 2002 at 03:28:41PM +0000, Bodo Moeller wrote:
> Hal Finney <[e-mail]>:
>> Adam Back writes:

>>> we proposed:
>>>
>>> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(K||Bob_PK)), msg)

>> I see, that seems to work well too.  [...]

> Does it?  If Bob is willing to reveal  K  and additional data such as
> padding used for RSA encryption, can't everyone verify that this is
> indeed a valid signature by Alice on 'msg'?

Oops, I've been parsing the parentheses incorrectly.


-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: by above.proper.com (8.11.6/8.11.3) id g4QFZ7Y05970 for ietf-openpgp-bks; Sun, 26 May 2002 08:35:07 -0700 (PDT)
Received: from cdc-info.cdc.informatik.tu-darmstadt.de (cdc-info.cdc.informatik.tu-darmstadt.de [130.83.23.100]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4QFZ5J05966 for <[e-mail]>; Sun, 26 May 2002 08:35:05 -0700 (PDT)
Received: from localhost (cdc-info [130.83.23.100]) by cdc-info.cdc.informatik.tu-darmstadt.de (Postfix) with SMTP id EACCA2C93; Sun, 26 May 2002 17:35:04 +0200 (MET DST)
Received: id <m17Bzwn-000QdtC@epsilon>; Sun, 26 May 2002 17:28:41 +0200 (CEST) 
Message-Id: <m17Bzwn-000QdtC@epsilon>
Date: Sun, 26 May 2002 17:28:41 +0200 (CEST)
To: [e-mail], "Hal Finney" <[e-mail]>, [e-mail]
From: [e-mail] (Bodo Moeller)
Subject: Re: Recipient-verifiable messages, was: forwarding an encrypted PGP message is useless
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hal Finney <[e-mail]>:
> Adam Back writes:

>> What we proposed is related.  Rather
>> than the normal encrypted signed message:
>>
>> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(msg)), msg)
>>
>> we proposed:
>>
>> 	Encrypt_Bob(K), Encrypt(K, Sign_Alice(Hash(K||Bob_PK)), msg)
>>
>> with the additional restriction that the encryption mode should be one
>> of the MDC modes (ie appended MAC with K outside encryption, or
>> appended hash of msg inside encryption).

>> To break that down: we hash Bob's public key so that Bob can't turn
>> around and forge an arbitrary an arbitrary message from Alice to
>> Charlie using signed K.  What Bob is left with is proof that Alice
>> sent him a message, but no evidence of what the message body was.

> I see, that seems to work well too.  [...]

Does it?  If Bob is willing to reveal  K  and additional data such as
padding used for RSA encryption, can't everyone verify that this is
indeed a valid signature by Alice on 'msg'?



-- 
Bodo Möller <[e-mail]>
PGP http://www.informatik.tu-darmstadt.de/TI/Mitarbeiter/moeller/0x36d2c658.html
* TU Darmstadt, Theoretische Informatik, Alexanderstr. 10, D-64283 Darmstadt
* Tel. [phone], Fax [phone]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4P0v2V01037 for ietf-openpgp-bks; Fri, 24 May 2002 17:57:02 -0700 (PDT)
Received: from smtprelay8.dc2.adelphia.net (smtprelay8.dc2.adelphia.net [64.8.50.40]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4P0utL01031 for <[e-mail]>; Fri, 24 May 2002 17:57:01 -0700 (PDT)
Received: from mwyoung ([24.48.51.230]) by smtprelay8.dc2.adelphia.net (Netscape Messaging Server 4.15) with SMTP id GWN6NI02.5S3 for <[e-mail]>; Fri, 24 May 2002 20:57:18 -0400 
Message-ID: <00dd01c20386$f545f9a0$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: secure sign & encrypt
Date: Fri, 24 May 2002 20:56:08 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

To: [e-mail]
Subject: Re: secure sign & encrypt
X-Comment: I, too, was hoping that this would die out before
  the urge to weigh in overwhelmed me, but it hasn't :-).

I generally side with Jon, Hal, and Derek here.  The intended
recipient is only one of many pieces of context that a user
might mistakenly believe was included in the signed material.
Adding a subpacket to address just this one piece of context
doesn't strike me as necessary, particularly since there are
very reasonable solutions within the existing framework:
notation subpackets; or, layered (encrypt-sign-encrypt) processing.

Ultimately the problem is one of user misunderstanding, arguably
exacerbated by the user interfaces in specific implementations.
Either the users need to be better educated, or the implementations
need to do a better job expressing exactly what has been signed
(and, perhaps, for naive users, the indirect implications).
Neither requires a change to the specification, just to the
implementation (of the tool or the user :-).

I appreciate Terje's desire to encode context so that it can be
checked automatically, and a desire for a convention for doing the
encoding, for implementations that want to do so.  I would have no
objection to publishing a convention for encoding the intended
recipients in a notation packet.  That wouldn't have to be part of the
base RFC.  That said, I wouldn't *strenuously* object to this being
documented in the base RFC, or even to a new OPTIONAL subpacket.  I
just don't think it helps enough: it doesn't cover other context;
and, it doesn't help for "legacy" messages.  Here "legacy" means
both old implementations (that don't support the packet) and
old V3 signatures (which don't have subpackets at all).

A few specific comments on one of Terje's notes:

> To word the problem in another way, when Alice send a message to Bob
> that is signed and encrypted, Bob should be able to be sure that it
> was Alice that encrypted the message.

I disagree that this is a fundamental goal -- it is a derived one.
The real goal is more likely that Bob wants to know that the message
is intended for him.  Knowing that Alice encrypted it is neither
necessary nor sufficient to meet this real goal.  I think this
difference is what Derek was getting at when he asked about goals.

> Some solutions:
> - Teach Bob not to trust PGPs sign & encrypt to know who the sender

Perhaps, as a means of teaching Bob:
  - Warn Bob about the limitations, something like:
    "The signature does not name you as the recipient.  This document
     may have been forwarded to you by the original recipient.
     Do not assume that it was intended for you."

    This may seem verbose, but naive users often have problems
    with shorthands for complex concepts: "(Invalid)" comes to mind :-).

    Again, this is the best that you can do for legacy messages, anyway.

> - Make PGP use Encrypt, Sign and Encrypt.

It's fine to have a particular implementation adopt this layering (or
to offer it as an option).  It would be very wrong to legislate this
particular layering.  While users may not understand the implications
of particular layerings, implementors clearly should understand, and
should be trusted to choose the layering appropriate for their
perceived users' needs.  You may want a tool that offers
encrypt-sign-encrypt (to identify the intended recipient); someone
else may want a tool that meets other goals (e.g., anonymity or
plausible deniability).  Any good tool should make it clear what
function it is performing, but that's not a *protocol specification*
issue.

> - Add fingerprints of recipient keys in signature packets (Requires
> a change
>   in the protocol)

Or,
  - Offer to copy context into the plaintext, or into notations.
    For example, an MUA might offer to copy the "To", "cc", and "Subject"
    headers.  It could even inject an "X-To-PGP-Key" header to record the
    key fingerprint/ID for automatic verification by like-minded agents.
    There's no deep reason that this requires a protocol change.

-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3

iQA+AwUBPO7hEFMkvpTT8vCGEQL7FgCYtT6tpDktAg76EHnLwzyjBY6qzgCgudgy
q/a45lzca9Bqq+m6FmlLlVo=
=VplY
-----END PGP SIGNATURE-----




Received: by above.proper.com (8.11.6/8.11.3) id g4O4w7H23848 for ietf-openpgp-bks; Thu, 23 May 2002 21:58:07 -0700 (PDT)
Received: from mailhost2.auckland.ac.nz (mailhost2.auckland.ac.nz [130.216.1.4]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4O4w6L23844 for <[e-mail]>; Thu, 23 May 2002 21:58:06 -0700 (PDT)
Received: from mailhost-mp.auckland.ac.nz (IDENT:[e-mail] [130.216.191.61]) by mailhost2.auckland.ac.nz (8.9.2/8.9.2/8.9.2-ua) with ESMTP id QAA01170; Fri, 24 May 2002 16:58:09 +1200 (NZST)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by mailhost-mp.auckland.ac.nz (Mirapoint Messaging Server MOS 2.9.3.2) with ESMTP id ADO38172; Fri, 24 May 2002 16:58:08 +1200 (NZST)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4O4w8AC008809; Fri, 24 May 2002 16:58:08 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA43063; Fri, 24 May 2002 16:58:06 +1200 (NZST) (sender [e-mail])
Date: Fri, 24 May 2002 16:58:06 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: secure sign & encrypt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

"David P. Kemp" <[e-mail]> writes:

>Each layer does what it does - if you want the security services provided by
>three layers (ESE), or what S/MIME calls triple-wrapping (SES), then you must
>use three layers.

The motivation for S/MIME triple wrap was AFAIK use by automated mail gateways.
If you always have to sign the plaintext then it makes it impossible to create
a mail gateway which only lets signed data in or out, because the gateway would
have to hold all the private keys in order to verify the sigs.  Thus the SES
triple-wrap.  I know Don Davis looked at the RFC which covered this (2633?)
when he was writing his paper and found it didn't really solve the problem.

Peter.


Received: by above.proper.com (8.11.6/8.11.3) id g4NLRq715111 for ietf-openpgp-bks; Thu, 23 May 2002 14:27:52 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NLRoL15107 for <[e-mail]>; Thu, 23 May 2002 14:27:51 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1MXQ>; Thu, 23 May 2002 23:25:18 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: [e-mail]
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 23:25:17 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NLRpL15108
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

What is the problem I try to solve? I thought that had been clear
through the many mails I sent, but let me try to explain again.

1) Don Davis has a pretty good description of the problem in
	http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
	He lists many good reasons why this is a problem in section 4.

2) Many users seem to think that PGPs sign & encrypt function is atomic.
	We can try to teach them that is never was so, and never will be
	(a bad solution in my opinion) or we can give the users what they
	want/expect and make it possible to have an atomic sign & encrypt
	in PGP.

To word the problem in another way, when Alice send a message to Bob
that is signed and encrypted, Bob should be able to be sure that it
was Alice that encrypted the message.

Description of attack:

Alice send a signed & encrypted message to Charlie. Charlie decrypts
it and encrypts and sends it to Bob, trying to convince Bob the message
comes directly from Alice. Since Bob see the message is apparently
made by sign & encrypt he thinks it must be Alice that has encrypted it.


Some solutions:

	- Teach Bob not to trust PGPs sign & encrypt to know who the sender
	  of the message is when it is not in the plain text of the signed
	  message.

	- Make PGP use Encrypt, Sign and Encrypt. (Slower
encryption/decryption
	  and bigger messages.)

	- Add fingerprints of recipient keys in signature packets (Requires
a change
	  in the protocol)
-- 
Terje Bråten



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NKakW13816 for ietf-openpgp-bks; Thu, 23 May 2002 13:36:46 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NKaiL13812 for <[e-mail]>; Thu, 23 May 2002 13:36:44 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1MWR>; Thu, 23 May 2002 22:34:11 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "'Derek Atkins'" <[e-mail]>, Terje Braaten <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 22:34:10 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NKajL13813
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Derek Atkins <[e-mail]> writes:
> 
> Terje Braaten <[e-mail]> writes:
> 
> > Derek Atkins <[e-mail]> wrote:
> > > I'm not sure exactly what you mean by when you say Alice 
> saves a copy
> > > of the session key... How does Alice get that key to 
> Charlie?  Also
> > > keep in mind that the interior and exterior encryptions SHOULD be
> > > using different session keys.  So, I don't understand 
> what you mean?
> > 
> > She could send it to Charlie in a different mail, or add it 
> on the outside
> > of the signature (ES) packet before she encrypt and send it 
> to Charlie.
> > And since she control the building of the message, another solution
> > would be that she could also use the same session key in 
> the interior and
> > exterior encryptions no matter what the protocol says 
> should be done.
> 
> But then Charlie KNOWS that Alice did the dastardly deed.  Moreover,
> you'd need extremely special reader to be able to read such a message,
> because it would not be 2440-compliant.

No, if Alice faked the e-mail headers, he could think it was Bob that
sent it to him, and also revealed to him the session key to the inner
encryption packet. It is exactly the same case as if Alice just had
used SE and signed a packet with the recipient keys in the inner message.
Charlie would KNOW that something was wrong, but not if Alice or Bob
was to blame.

> 
> > > Can you show the packets that Charlie sees?  I don't see any way
> > > to add a new ESK on the interior message without invalidating the
> > > signature....
> > 
> > Charlie sees after decrypting the first layer
> >  PreSig[Alice]{ESK [Bob] Enc { Literal { Message } } }PostSig[Alice]
> 
> Ok, can you show me the complete message Charlie receives (before he
> decrypts the first layer)?  Note that if Charlie sees this message, it
> is quite clear that the message was meant for Bob alone.

Yes, but was it Bob that leaked the information or Alice? See he cannot
know.

> 
> > In addition he has, or can make ESK[Charlie]. This 
> information he can
> > claim he must have got from Bob, since he is the only 
> original recipient.
> 
> How can Charlie insert an ESK[Charlie] and not invalidate the
> signature?

He cannot insert it in the inner encryption packet without invalidating
the signature, but he can make use of it to read the encrypted message.

-- 
Terje Bråten

 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NKTk013642 for ietf-openpgp-bks; Thu, 23 May 2002 13:29:46 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NKTiL13638 for <[e-mail]>; Thu, 23 May 2002 13:29:45 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA12024; Thu, 23 May 2002 16:29:45 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA00224; Thu, 23 May 2002 16:29:45 -0400 (EDT)
Received: from gorf.mit.edu (GORF.MIT.EDU [18.18.1.77]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id QAA19013; Thu, 23 May 2002 16:29:45 -0400 (EDT)
Received: (from warlord@localhost) by gorf.mit.edu (8.9.3) id QAA18233; Thu, 23 May 2002 16:29:45 -0400
To: Terje Braaten <[e-mail]>
Cc: [e-mail], [e-mail]
Subject: Re: secure sign & encrypt
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 May 2002 16:29:45 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 101
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NKTjL13639
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Which attacks are you trying to prevent?

I've seen different people trying to prevent different attacks here.
Pretty much every solution (except the ESE solution) protects against
some of the various attacks but not all of them.  Even better, ESE is
completely 2440-compliant, wheras all these other approaches seem to
require changes to the protocol.

I'd really like to see a clear problem statement (including a threat
model) before we change 2440 or add new packets that really only help
a subset of the problem.  Please write a concise statement about what
threat(s) you see and the problem(s) you want to solve.  Please leave
out the "how you intend to solve the problems".  We should first agree
that:

        a) a problem exists that needs to be solved, and
        b) we are actually trying to solve the right problem.

-derek

Terje Braaten <[e-mail]> writes:

> Derek Atkins <[e-mail]> wrote:
> > 
> > This doesn't help.  Any recipient could re-encrypt the message and
> > change the list of encrypted recipients.
> > 
> 
> Sure it helps against the man in the middle that disastry wanted to
> protect against. Any recipient of an encrypted message can do what
> he like with it anyway, so no of course it does not help against
> any unfaithful recipient.
> 
> -- 
> Terje Bråten
> 
> 
> > > disastry wrote:
> > > > fake pubkey encryption packets can be added
> > > > by man in the middle so that recipient thinks that 
> > message was encrypted
> > > > to him and to other preson.
> > > > 
> > > > I wrote about it here:
> > > > 
> > http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html
> > > 
> > > I think this can be solved by modifying
> > > Sym. Encrypted Integrity Protected Data Packet (Tag 18).
> > > 
> > > Now it is:
> > > 
> > > version byte == 1
> > > encrypted data
> > > 
> > > encrypted data consists of:
> > >   encrypted iv
> > >   encrypted plaintext
> > >   encrypted Modification Detection Code Packet (Tag 19)
> > > 
> > > I suggest:
> > > 
> > > version byte == 2
> > > encrypted data
> > > 
> > > encrypted data consists of:
> > >   encrypted iv
> > >   encrypted Recipients packet (Tag 20)
> > >     (put it before plaintext - if it would be after it would
> > >      be difficult to find where plaintext ends, when decrypting)
> > >   encrypted plaintext
> > >   encrypted Modification Detection Code Packet (Tag 19)
> > > 
> > > Recipients packet
> > >   version byte == 1
> > >   number of recipients, 2 bytes (should be enough..)
> > >   number_of_recipients*20 byte list of fingerprints recipient keys
> > >     (16 byte RSA v3 key fingerprints are appended with 4 zeros
> > >      (or maybe with 4 lowest keyid bytes? I think, it's 
> > even better))
> > > 
> > > 
> > > this ensures that recipient list is intact not only for 
> > signed & encrypted messages
> > > but also for encrypted only messages.
> > > 
> > > __
> > > Disastry  http://disastry.dhs.org/
> > 
> > -- 
> >        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
> >        Member, MIT Student Information Processing Board  (SIPB)
> >        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
> >        [e-mail]                        PGP key available
> > 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NKLpS13489 for ietf-openpgp-bks; Thu, 23 May 2002 13:21:51 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NKLnL13481 for <[e-mail]>; Thu, 23 May 2002 13:21:49 -0700 (PDT)
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id QAA08851; Thu, 23 May 2002 16:21:51 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id QAA27471; Thu, 23 May 2002 16:21:51 -0400 (EDT)
Received: from gorf.mit.edu (GORF.MIT.EDU [18.18.1.77]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id QAA17800; Thu, 23 May 2002 16:21:50 -0400 (EDT)
Received: (from warlord@localhost) by gorf.mit.edu (8.9.3) id QAA18176; Thu, 23 May 2002 16:21:50 -0400
To: Terje Braaten <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: secure sign & encrypt
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 May 2002 16:21:50 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 44
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NKLoL13482
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Terje Braaten <[e-mail]> writes:

> Derek Atkins <[e-mail]> wrote:
> > I'm not sure exactly what you mean by when you say Alice saves a copy
> > of the session key... How does Alice get that key to Charlie?  Also
> > keep in mind that the interior and exterior encryptions SHOULD be
> > using different session keys.  So, I don't understand what you mean?
> 
> She could send it to Charlie in a different mail, or add it on the outside
> of the signature (ES) packet before she encrypt and send it to Charlie.
> And since she control the building of the message, another solution
> would be that she could also use the same session key in the interior and
> exterior encryptions no matter what the protocol says should be done.

But then Charlie KNOWS that Alice did the dastardly deed.  Moreover,
you'd need extremely special reader to be able to read such a message,
because it would not be 2440-compliant.

> > Can you show the packets that Charlie sees?  I don't see any way
> > to add a new ESK on the interior message without invalidating the
> > signature....
> 
> Charlie sees after decrypting the first layer
>  PreSig[Alice]{ESK [Bob] Enc { Literal { Message } } }PostSig[Alice]

Ok, can you show me the complete message Charlie receives (before he
decrypts the first layer)?  Note that if Charlie sees this message, it
is quite clear that the message was meant for Bob alone.

> In addition he has, or can make ESK[Charlie]. This information he can
> claim he must have got from Bob, since he is the only original recipient.

How can Charlie insert an ESK[Charlie] and not invalidate the
signature?

> Terje Bråten

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: by above.proper.com (8.11.6/8.11.3) id g4NKC1S13245 for ietf-openpgp-bks; Thu, 23 May 2002 13:12:01 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NKBxL13238 for <[e-mail]>; Thu, 23 May 2002 13:11:59 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1MVW>; Thu, 23 May 2002 22:09:26 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "'Derek Atkins'" <[e-mail]>, [e-mail]
Cc: [e-mail]
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 22:09:25 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NKC0L13239
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Derek Atkins <[e-mail]> wrote:
> 
> This doesn't help.  Any recipient could re-encrypt the message and
> change the list of encrypted recipients.
> 

Sure it helps against the man in the middle that disastry wanted to
protect against. Any recipient of an encrypted message can do what
he like with it anyway, so no of course it does not help against
any unfaithful recipient.

-- 
Terje Bråten


> > disastry wrote:
> > > fake pubkey encryption packets can be added
> > > by man in the middle so that recipient thinks that 
> message was encrypted
> > > to him and to other preson.
> > > 
> > > I wrote about it here:
> > > 
> http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html
> > 
> > I think this can be solved by modifying
> > Sym. Encrypted Integrity Protected Data Packet (Tag 18).
> > 
> > Now it is:
> > 
> > version byte == 1
> > encrypted data
> > 
> > encrypted data consists of:
> >   encrypted iv
> >   encrypted plaintext
> >   encrypted Modification Detection Code Packet (Tag 19)
> > 
> > I suggest:
> > 
> > version byte == 2
> > encrypted data
> > 
> > encrypted data consists of:
> >   encrypted iv
> >   encrypted Recipients packet (Tag 20)
> >     (put it before plaintext - if it would be after it would
> >      be difficult to find where plaintext ends, when decrypting)
> >   encrypted plaintext
> >   encrypted Modification Detection Code Packet (Tag 19)
> > 
> > Recipients packet
> >   version byte == 1
> >   number of recipients, 2 bytes (should be enough..)
> >   number_of_recipients*20 byte list of fingerprints recipient keys
> >     (16 byte RSA v3 key fingerprints are appended with 4 zeros
> >      (or maybe with 4 lowest keyid bytes? I think, it's 
> even better))
> > 
> > 
> > this ensures that recipient list is intact not only for 
> signed & encrypted messages
> > but also for encrypted only messages.
> > 
> > __
> > Disastry  http://disastry.dhs.org/
> 
> -- 
>        Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
>        Member, MIT Student Information Processing Board  (SIPB)
>        URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
>        [e-mail]                        PGP key available
> 


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NK56S13107 for ietf-openpgp-bks; Thu, 23 May 2002 13:05:06 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NK54L13103 for <[e-mail]>; Thu, 23 May 2002 13:05:04 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1MVQ>; Thu, 23 May 2002 22:02:31 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "'Derek Atkins'" <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 22:02:30 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NK55L13104
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Derek Atkins <[e-mail]> wrote:
> I'm not sure exactly what you mean by when you say Alice saves a copy
> of the session key... How does Alice get that key to Charlie?  Also
> keep in mind that the interior and exterior encryptions SHOULD be
> using different session keys.  So, I don't understand what you mean?

She could send it to Charlie in a different mail, or add it on the outside
of the signature (ES) packet before she encrypt and send it to Charlie.
And since she control the building of the message, another solution
would be that she could also use the same session key in the interior and
exterior encryptions no matter what the protocol says should be done.

> 
> Can you show the packets that Charlie sees?  I don't see any way
> to add a new ESK on the interior message without invalidating the
> signature....

Charlie sees after decrypting the first layer
 PreSig[Alice]{ESK [Bob] Enc { Literal { Message } } }PostSig[Alice]

In addition he has, or can make ESK[Charlie]. This information he can
claim he must have got from Bob, since he is the only original recipient.

-- 
Terje Bråten



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NJgpT12692 for ietf-openpgp-bks; Thu, 23 May 2002 12:42:51 -0700 (PDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NJgnL12688 for <[e-mail]>; Thu, 23 May 2002 12:42:49 -0700 (PDT)
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA26410; Thu, 23 May 2002 15:42:51 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id PAA19705; Thu, 23 May 2002 15:42:50 -0400 (EDT)
Received: from gorf.mit.edu (GORF.MIT.EDU [18.18.1.77]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id PAA01128; Thu, 23 May 2002 15:42:50 -0400 (EDT)
Received: (from warlord@localhost) by gorf.mit.edu (8.9.3) id PAA17943; Thu, 23 May 2002 15:42:50 -0400
To: Terje Braaten <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: secure sign & encrypt
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 May 2002 15:42:50 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 43
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NJgnL12689
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

I'm not sure exactly what you mean by when you say Alice saves a copy
of the session key... How does Alice get that key to Charlie?  Also
keep in mind that the interior and exterior encryptions SHOULD be
using different session keys.  So, I don't understand what you mean?

Can you show the packets that Charlie sees?  I don't see any way
to add a new ESK on the interior message without invalidating the
signature....

-derek

Terje Braaten <[e-mail]> writes:

> David P. Kemp <[e-mail]> wrote:
> > Your proposal for an extra packet does not address this alleged flaw.
> > Note that Alice could sign a message saying "encrypted to 
> > Bob", and then
> > encrypt and send the message to Charlie, thus framing Bob for breach
> > of confidence.
> 
> Now that I have had time to think about it, the same could be done if
> we used ESE. Alice can encrypt the packet to Bob and save a copy of
> the symmetric key used to encrypt the message before encrypting it with
> Bobs public key. Then she sign the encrypted packet, include some extra
> packet with the session key she saved and encrypt it for Charlie.
> Then Charlie receives an ESE packet where he can decrypt the inner
> encryption
> with the symmtreic key provided. And looking at the signature it looks like
> it is originally encrypted for Bob, so it "must" be Bob that has leaked
> the information and also given him the symmetric key.
> 
> So, in that respect my solution is no inferior to ESE regarding security.
> And you avoid the cost of one extra encryption.
> 
> -- 
> Terje Bråten
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NJY4n12432 for ietf-openpgp-bks; Thu, 23 May 2002 12:34:04 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NJY2L12427 for <[e-mail]>; Thu, 23 May 2002 12:34:02 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1M4Y>; Thu, 23 May 2002 21:31:29 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 21:31:27 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NJY3L12428
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David P. Kemp <[e-mail]> wrote:
> Your proposal for an extra packet does not address this alleged flaw.
> Note that Alice could sign a message saying "encrypted to 
> Bob", and then
> encrypt and send the message to Charlie, thus framing Bob for breach
> of confidence.

Now that I have had time to think about it, the same could be done if
we used ESE. Alice can encrypt the packet to Bob and save a copy of
the symmetric key used to encrypt the message before encrypting it with
Bobs public key. Then she sign the encrypted packet, include some extra
packet with the session key she saved and encrypt it for Charlie.
Then Charlie receives an ESE packet where he can decrypt the inner
encryption
with the symmtreic key provided. And looking at the signature it looks like
it is originally encrypted for Bob, so it "must" be Bob that has leaked
the information and also given him the symmetric key.

So, in that respect my solution is no inferior to ESE regarding security.
And you avoid the cost of one extra encryption.

-- 
Terje Bråten



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NIlYu11003 for ietf-openpgp-bks; Thu, 23 May 2002 11:47:34 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NIlWL10999 for <[e-mail]>; Thu, 23 May 2002 11:47:32 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id OAA27966; Thu, 23 May 2002 14:47:33 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id OAA15198; Thu, 23 May 2002 14:47:32 -0400 (EDT)
Received: from gorf.mit.edu (GORF.MIT.EDU [18.18.1.77]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id OAA12253; Thu, 23 May 2002 14:47:32 -0400 (EDT)
Received: (from warlord@localhost) by gorf.mit.edu (8.9.3) id OAA17645; Thu, 23 May 2002 14:47:32 -0400
To: [e-mail]
Cc: [e-mail]
Subject: Re: secure sign & encrypt
References: <[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 May 2002 14:47:27 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 60
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

This doesn't help.  Any recipient could re-encrypt the message and
change the list of encrypted recipients.

-derek

[e-mail] writes:

> disastry wrote:
> > fake pubkey encryption packets can be added
> > by man in the middle so that recipient thinks that message was encrypted
> > to him and to other preson.
> > 
> > I wrote about it here:
> > http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html
> 
> I think this can be solved by modifying
> Sym. Encrypted Integrity Protected Data Packet (Tag 18).
> 
> Now it is:
> 
> version byte == 1
> encrypted data
> 
> encrypted data consists of:
>   encrypted iv
>   encrypted plaintext
>   encrypted Modification Detection Code Packet (Tag 19)
> 
> I suggest:
> 
> version byte == 2
> encrypted data
> 
> encrypted data consists of:
>   encrypted iv
>   encrypted Recipients packet (Tag 20)
>     (put it before plaintext - if it would be after it would
>      be difficult to find where plaintext ends, when decrypting)
>   encrypted plaintext
>   encrypted Modification Detection Code Packet (Tag 19)
> 
> Recipients packet
>   version byte == 1
>   number of recipients, 2 bytes (should be enough..)
>   number_of_recipients*20 byte list of fingerprints recipient keys
>     (16 byte RSA v3 key fingerprints are appended with 4 zeros
>      (or maybe with 4 lowest keyid bytes? I think, it's even better))
> 
> 
> this ensures that recipient list is intact not only for signed & encrypted messages
> but also for encrypted only messages.
> 
> __
> Disastry  http://disastry.dhs.org/

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NHQB508963 for ietf-openpgp-bks; Thu, 23 May 2002 10:26:11 -0700 (PDT)
Received: from nekas.saiknes.lv ([e-mail] [195.2.103.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NHQ9L08959 for <[e-mail]>; Thu, 23 May 2002 10:26:10 -0700 (PDT)
Received: from saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by nekas.saiknes.lv (8.11.4/8.11.4) with ESMTP id g4NHQAR18650 for <[e-mail]>; Thu, 23 May 2002 19:26:10 +0200
Message-ID: <[e-mail]>
Date: Thu, 23 May 2002 19:26:05 +0200
From: [e-mail]
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,lv,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: secure sign & encrypt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

disastry wrote:
> fake pubkey encryption packets can be added
> by man in the middle so that recipient thinks that message was encrypted
> to him and to other preson.
> 
> I wrote about it here:
> http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html

I think this can be solved by modifying
Sym. Encrypted Integrity Protected Data Packet (Tag 18).

Now it is:

version byte == 1
encrypted data

encrypted data consists of:
  encrypted iv
  encrypted plaintext
  encrypted Modification Detection Code Packet (Tag 19)

I suggest:

version byte == 2
encrypted data

encrypted data consists of:
  encrypted iv
  encrypted Recipients packet (Tag 20)
    (put it before plaintext - if it would be after it would
     be difficult to find where plaintext ends, when decrypting)
  encrypted plaintext
  encrypted Modification Detection Code Packet (Tag 19)

Recipients packet
  version byte == 1
  number of recipients, 2 bytes (should be enough..)
  number_of_recipients*20 byte list of fingerprints recipient keys
    (16 byte RSA v3 key fingerprints are appended with 4 zeros
     (or maybe with 4 lowest keyid bytes? I think, it's even better))


this ensures that recipient list is intact not only for signed & encrypted messages
but also for encrypted only messages.

__
Disastry  http://disastry.dhs.org/
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPO0JwDBaTVEuJQxkEQMORgCg/j0R2RUf830eylTBm6zdeAmt76YAnA8p
sqW+9RNiC+62SMx6KSu/waDu
=nqXN
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NGNNe07202 for ietf-openpgp-bks; Thu, 23 May 2002 09:23:23 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NGNLL07198 for <[e-mail]>; Thu, 23 May 2002 09:23:21 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1MRJ>; Thu, 23 May 2002 18:20:48 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: [e-mail]
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 18:20:47 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NGNML07199
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Dominikus Scherkl <[e-mail]> wrote:
> > > Your proposal for an extra packet does not address this alleged
> flaw.
> > > Note that Alice could sign a message saying "encrypted to 
> > > Bob", and then
> > > encrypt and send the message to Charlie, thus framing Bob 
> for breach
> > > of confidence.
> > 
> > No, because then Charlie would know it was something fishy going on.
> > He would not now if Alice or Bob (or some one else) was to blame,
> > but he would get a warning message saying that this is an invalid
> > signed & encrypted message.
> Hey, this is an attack at _Bob_ - Charlie don't needs to be nice!
> The simple possibility of such attacks discredits the trust in beeing
> the original receiver of a message, so we gain nothing!

The only one that could mount such an attack is Alice, the
person that has signed the message. So such an attack would be easily
traceable. The trust in who is the original receiver of a message
will depend on that you trust the signer if test to see if
the signer and encrypter is the same person is false.
Yes, that makes this method a bit weaker than ESE. When the test
fails you cannot infer anything about who was the real recipient.
But if the test to see if the signer and encrypter is the same person
returns true, then you can indeed be sure that the signer and
encrypter is the same person.

-- 
Terje Bråten



Received: by above.proper.com (8.11.6/8.11.3) id g4NFwG206614 for ietf-openpgp-bks; Thu, 23 May 2002 08:58:16 -0700 (PDT)
Received: from guk1d002.glueckkanja.org (mail.glueckkanja.com [62.8.243.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NFwFL06610 for <[e-mail]>; Thu, 23 May 2002 08:58:15 -0700 (PDT)
content-class: urn:content-classes:message
Subject: RE: secure sign & encrypt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 23 May 2002 17:58:11 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secure sign & encrypt
Thread-Index: AcICWAvfN4TlyD+7RU2SFljt5EawVAAACByw
From: "Dominikus Scherkl" <[e-mail]>
To: "Derek Atkins" <[e-mail]>
Cc: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NFwFL06611
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi.

> > I see no other way than "encrypt, sign and encrypt" (ESE)
> > to archive all cyptografic goals which seems inportant to me:

> The interesting thing is that there is nothing STOPPING an application
> from doing this today.  OpenPGP messages like the following are
> perfectly legal syntax, even in 2440:
> 
> ESK [...] Enc { PreSig ESK [...] Enc { Literal { Message } } PostSig }
> 
> Go ahead and implement this.  I'm fairly sure that most of the OpenPGP
> Parsers out there will Do The Right Thing with this (I'm 99% sure that
> PGP 6.5.x will do this, since I wrote that original parser code).

Of course. That's the main advantage of ESE, we can do it without
protocol changes - to insert a new button in the applications will
be enough.
In addition ESE has the property John Callas repeatedly claimed
to be important, and which can't be archived by simply adding
a copy of the header fields to the envelop:
it ensures that the reciever cannot forward a message
without destroying the signature or reveiling that it was
originaly send to him for his eyes only.
Also ESE can't be cheeted by adding fake addresses to the envelop.

And the old SE remains available, if you like the message can be
forwarded but therefore repudiated.

Best Regards
-- 
Dominikus Scherkl
[e-mail]


Received: by above.proper.com (8.11.6/8.11.3) id g4NFeoH06223 for ietf-openpgp-bks; Thu, 23 May 2002 08:40:50 -0700 (PDT)
Received: from guk1d002.glueckkanja.org (mail.glueckkanja.com [62.8.243.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NFenL06219 for <[e-mail]>; Thu, 23 May 2002 08:40:50 -0700 (PDT)
content-class: urn:content-classes:message
Subject: RE: secure sign & encrypt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 23 May 2002 17:40:45 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secure sign & encrypt
Thread-Index: AcICZSy4NfgnE8BTTXuIkzX1WZqMjQACkHIg
From: "Dominikus Scherkl" <[e-mail]>
To: "Terje Braaten" <[e-mail]>
Cc: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NFeoL06220
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi!

> > Your proposal for an extra packet does not address this alleged
flaw.
> > Note that Alice could sign a message saying "encrypted to 
> > Bob", and then
> > encrypt and send the message to Charlie, thus framing Bob for breach
> > of confidence.
> 
> No, because then Charlie would know it was something fishy going on.
> He would not now if Alice or Bob (or some one else) was to blame,
> but he would get a warning message saying that this is an invalid
> signed & encrypted message.
Hey, this is an attack at _Bob_ - Charlie don't needs to be nice!
The simple possibility of such attacks discredits the trust in beeing
the original receiver of a message, so we gain nothing!

Best Regards.
-- 
Dominikus Scherkl
[e-mail]


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NF4ug03895 for ietf-openpgp-bks; Thu, 23 May 2002 08:04:56 -0700 (PDT)
Received: from nekas.saiknes.lv ([e-mail] [195.2.103.13]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NF4sL03891 for <[e-mail]>; Thu, 23 May 2002 08:04:55 -0700 (PDT)
Received: from saiknes.lv (hackserv.saiknes.lv [195.2.103.8]) by nekas.saiknes.lv (8.11.4/8.11.4) with ESMTP id g4NF4rR18610 for <[e-mail]>; Thu, 23 May 2002 17:04:54 +0200
Message-ID: <[e-mail]>
Date: Thu, 23 May 2002 17:04:48 +0200
From: [e-mail]
X-Mailer: Mozilla 4.79 [en] (Windows NT 5.0; U)
X-Accept-Language: en,lv,ru
MIME-Version: 1.0
To: [e-mail]
Subject: Re: secure sign & encrypt
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: RIPEMD160

vedaal wrote:
> ----- Original Message -----
> From: "Terje Braaten" <[e-mail]>
> Sent: Monday, May 20, 2002 7:31 PM
> Subject: RE: secure sign & encrypt
> 
> [...]
> 
>  > The problem is that most users when they decrypt a message
> > that is signed, they will think they can be sure the signer
> > and the encrypter is the same person/entity.
> > It would be a major improvement in the OpenPGP specification
> > to allow applications to ensure that that really is the case.
> 
> [...]
> 
> Functionally, that is the case now in Open PGP.
> 
> Even though a signed and encrypted message can be separated into a
> verifiable free standing signed message, and then
> re-encrypted and sent on to someone else,
> it 'cannot' {afaik} be re-combined into a signed and encrypted message that
> appears the same as a de-novo signed and encrypted message.

it can be done.
it's even not necessary to fully decrypt the message,
one can just decrypt only pubkey encryption to get session key,
then encrypt this session key to other pubkey!

what bothering me more is that fake pubkey encryption packets can be added
by man in the middle so that recipient thinks that message was encrypted
to him and to other preson.

I wrote about it here:
http://lists.gnupg.org/pipermail/gnupg-devel/2001-August/006285.html

__
Disastry  http://disastry.dhs.org/
http://disastry.dhs.org/pgp <----PGP plugins for Netscape and MDaemon
 ^----PGP 2.6.3ia-multi06 (supports IDEA, CAST5, BLOWFISH, TWOFISH,
      AES, 3DES ciphers and MD5, SHA1, RIPEMD160, SHA2 hashes)
-----BEGIN PGP SIGNATURE-----
Version: Netscape PGP half-Plugin 0.15 by Disastry / PGPsdk v1.7.1

iQA/AwUBPOzo3zBaTVEuJQxkEQOppQCgg9Wmo//Q8wR8zKo3CYwmcji4xOsAnjbP
wHIOOfnI8Yf2e8LGYgTisB/p
=y4Ky
-----END PGP SIGNATURE-----


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NEAc801813 for ietf-openpgp-bks; Thu, 23 May 2002 07:10:38 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NEAaL01808 for <[e-mail]>; Thu, 23 May 2002 07:10:36 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1MLX>; Thu, 23 May 2002 16:08:03 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 16:08:02 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NEAbL01809
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

David P. Kemp <mailto:[e-mail]> wrote: 
> Your proposal for an extra packet does not address this alleged flaw.
> Note that Alice could sign a message saying "encrypted to 
> Bob", and then
> encrypt and send the message to Charlie, thus framing Bob for breach
> of confidence.

No, because then Charlie would know it was something fishy going on.
He would not now if Alice or Bob (or some one else) was to blame,
but he would get a warning message saying that this is an invalid
signed & encrypted message.

> 
> You can't take two operations that are inherently separable and create
> a magic hack that makes them inherently and verifiably atomic.  Each
> layer does what it does - if you want the security services provided
> by three layers (ESE), or what S/MIME calls triple-wrapping (SES),
> then you must use three layers.

Well, if you use three layers (ESE), you get the added bonus that you
can easily see what is wrong if someone try to do something bad.
But also with my proposed method you can verify if everything is ok or not.

-- 
Terje Bråten



Received: by above.proper.com (8.11.6/8.11.3) id g4NEAZ801805 for ietf-openpgp-bks; Thu, 23 May 2002 07:10:35 -0700 (PDT)
Received: from colon.colondot.net ([e-mail] [212.135.138.209]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NEAXL01801 for <[e-mail]>; Thu, 23 May 2002 07:10:33 -0700 (PDT)
Received: from mbm by colon.colondot.net with local (Exim 3.33 #1) id 17AtIY-0005tu-00 for [e-mail]; Thu, 23 May 2002 15:10:34 +0100
Date: Thu, 23 May 2002 15:10:34 +0100
From: Matthew Byng-Maddick <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: secure sign & encrypt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, May 23, 2002 at 02:22:19PM +0200
Organization: Colondot.net
Mail-Copies-To: never
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, May 23, 2002 at 02:22:19PM +0200, Terje Braaten wrote:
> Matthew Byng-Maddick <[e-mail]> wrote:
> > As others have pointed out, what is the "atomic sign & 
> > encrypt" of which you
> > speak?
> I envision that in a not too far feature, we can call the
> sign & encrypt function in PGP an atomic sign & encrypt.
> This is the solution of the problem that I have been trying
> to describe all the time.
[...]
> Adding a new signature packet called 'encrypted to' (or something
> like that) would allow OpenPGP applications to implement
> such an atomic sign & encrypt. It could say in the protocol
> that an application MAY implement atomic sign & encrypt,
> and if it does, it MUST do such and such.

Of course, a better way to do this is the obvious one, for the signtext
to start with "Dear Bob," and then you know who it was intended for. This
is the recommendation in the few cryptographic texts I've read about
non-repudiation.

This, of course, requires educating users, <sarcasm>which is a much harder
problem than attempting to solve it in some convoluted (and probably wrong)
cryptographic way.</sarcasm>

If your users don't properly understand the attempted guarantees of the
cryptosystem, then whatever you do to try and make it better, they will
almost certainly make some other assumption about it.

MBM

-- 
Matthew Byng-Maddick         <[e-mail]>           http://colondot.net/


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NDPhB00632 for ietf-openpgp-bks; Thu, 23 May 2002 06:25:43 -0700 (PDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NDPgL00628 for <[e-mail]>; Thu, 23 May 2002 06:25:42 -0700 (PDT)
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA12846; Thu, 23 May 2002 09:25:43 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id JAA01391; Thu, 23 May 2002 09:25:42 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id JAA21426; Thu, 23 May 2002 09:25:42 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id JAA09848; Thu, 23 May 2002 09:25:42 -0400 (EDT)
To: Terje Braaten <[e-mail]>
Cc: [e-mail]
Subject: Re: secure sign & encrypt
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 May 2002 09:25:42 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 28
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NDPgL00629
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Terje Braaten <[e-mail]> writes:

> The method I have suggested is to sign the recipient's name into the
> message, as this avoids another costly encryption. Unfortunately
> this is very disturbing to those that think sign and encrypt must
> and should be independent layers in the protocol. But I think
> there should be possible to open up for certain exceptions to this
> layer thinking when security needs demands it.

As has been pointed out, you do NOT need an automated method to
do this.  Just put a plane user-readable string of the recipient's
identity into the signed message -- the PLAINTEXT message.

This is something that the MUA would do and requires no changes to the
PGP Protocol.

Note that any user with any intelligence would know that a message
that begins "Dear Bob" was _not_ meant for Charlie.

> Terje Bråten

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NDMa500556 for ietf-openpgp-bks; Thu, 23 May 2002 06:22:36 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (stingray.missi.ncsc.mil [144.51.50.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NDMYL00552 for <[e-mail]>; Thu, 23 May 2002 06:22:35 -0700 (PDT)
Received: from stingray.missi.ncsc.mil (root@localhost) by stingray.missi.ncsc.mil with ESMTP id g4NDHo006451; Thu, 23 May 2002 09:17:50 -0400 (EDT)
Message-ID: <[e-mail]>
Date: Thu, 23 May 2002 09:21:50 -0400
From: "David P. Kemp" <[e-mail]>
X-Mailer: Mozilla 4.77 [en] (X11; U; SunOS 5.7 sun4u)
X-Accept-Language: en
MIME-Version: 1.0
To: Terje Braaten <[e-mail]>
CC: OpenPGP <[e-mail]>
Subject: Re: secure sign & encrypt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-H-S-Loop-Check-Ejzfr: 
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Terje Braaten wrote:
> 
> Derek Atkins <[e-mail]> writes:
> 
> > Repeat to yourself: IT IS A FEATURE THAT SIGN AND ENCRYPT ARE
> > SEPARABLE OPERATIONS.  Once you make that statement, there is no way,
> > short of layering violations, to do what you want to do except at the
> > application later duplicating the information.
> 
> And I say it is a security flaw that that sign and encrypt must be
> separable operations, and for the implementation of an atomic and secure
> sign & encrypt you have to make an exception to this layering model.

Your proposal for an extra packet does not address this alleged flaw.
Note that Alice could sign a message saying "encrypted to Bob", and then
encrypt and send the message to Charlie, thus framing Bob for breach
of confidence.

You can't take two operations that are inherently separable and create
a magic hack that makes them inherently and verifiably atomic.  Each
layer does what it does - if you want the security services provided
by three layers (ESE), or what S/MIME calls triple-wrapping (SES),
then you must use three layers.


Received: by above.proper.com (8.11.6/8.11.3) id g4NDAFP29858 for ietf-openpgp-bks; Thu, 23 May 2002 06:10:15 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NDACL29854 for <[e-mail]>; Thu, 23 May 2002 06:10:12 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1MH0>; Thu, 23 May 2002 15:07:39 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: [e-mail]
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 15:07:38 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NDADL29855
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Dominikus Scherkl <mailto:[e-mail]> wrote:
> I see no other way than "encrypt, sign and encrypt" (ESE)
> to archive all cyptografic goals which seems inportant to me:

Yes that is one of the five methods Don Davis wrote about as a solution in
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

I agree with you that SES is not a good solution because it leaves
the signature unprotected at the outer layer.

The method I have suggested is to sign the recipient's name into the
message, as this avoids another costly encryption. Unfortunately
this is very disturbing to those that think sign and encrypt must
and should be independent layers in the protocol. But I think
there should be possible to open up for certain exceptions to this
layer thinking when security needs demands it.

-- 
Terje Bråten


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NCux328368 for ietf-openpgp-bks; Thu, 23 May 2002 05:56:59 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NCuvL28358 for <[e-mail]>; Thu, 23 May 2002 05:56:57 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1MHN>; Thu, 23 May 2002 14:54:24 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 14:54:23 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NCuwL28362
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Derek Atkins <[e-mail]> writes:
> You see, I view this just like regular mail.  There is the envelope
> information, and there is the "letter".  By _CONVENTION_ the person
> writing a letter duplicates the envelope information on the inside.

A very useful picture indeed. The PGP program puts the information
about who it is encrypted to on the envelope on the outside. So
if we want to have this convention the PGP program must also be the
application that put this same information on the inside of the
envelope. The natural place to do this, as I see it, is for the PGP
program to make additional signature packets and put it in the signed
part of the signature.

If the OpenPGP protocol is not changed, there is no way for any PGP
application to implement any such convention. So it has to be a
part of the OpenPGP protocol.


> Repeat to yourself: IT IS A FEATURE THAT SIGN AND ENCRYPT ARE
> SEPARABLE OPERATIONS.  Once you make that statement, there is no way,
> short of layering violations, to do what you want to do except at the
> application later duplicating the information.

And I say it is a security flaw that that sign and encrypt must be
separable operations, and for the implementation of an atomic and secure
sign & encrypt you have to make an exception to this layering model.

-- 
Terje Bråten



Received: by above.proper.com (8.11.6/8.11.3) id g4NCoCK27092 for ietf-openpgp-bks; Thu, 23 May 2002 05:50:12 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NCoAL27085 for <[e-mail]>; Thu, 23 May 2002 05:50:10 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id IAA02093; Thu, 23 May 2002 08:50:11 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA10189; Thu, 23 May 2002 08:46:45 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id IAA02228; Thu, 23 May 2002 08:46:45 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id IAA09756; Thu, 23 May 2002 08:46:45 -0400 (EDT)
To: Terje Braaten <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: secure sign & encrypt
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 May 2002 08:46:45 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 49
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Terje Braaten <[e-mail]> writes:

> The problem is that even though sign & encrypt is not atomic
> now, that is what most users expect. I do not find it
> satisfying as a programmer to have to say to the users
> "Sorry, but the OpenPGP protocol do not allow any atomic
> sign & encrypt that would have solved your problem, so
> you will have to do without."

I disagree that all users are calmoring for this feature, but I
suppose we will have to agree to disagree on that.

> Adding a new signature packet called 'encrypted to' (or something
> like that) would allow OpenPGP applications to implement
> such an atomic sign & encrypt. It could say in the protocol
> that an application MAY implement atomic sign & encrypt,
> and if it does, it MUST do such and such.

Just so long as the user has to specifically specify this
functionality.  Note that this is a tradeoff and you LOSE a nice
feature of PGP in the process.  The feature that you lose is
repudiation of the recipient of a message.  You can honestly say to a
judge "I have no idea how he got that message -- I didn't encrypt it
to him".  Maybe you don't consider that a feature; some people do.

> My suggestion for a protocol for atomic sign & encrypt is
> that the application MUST make an 'encrypted to' packet in
> the signature for each key the message and signature packet
> is encrypted to in the encryption packet.
> These 'encrypted to' packets MUST be in the signed part of the signature.

As has already been suggested, the Notation packet can already do
this.  Just create an "encrypted-to" notation convention and publish
it as and RFC (and then convince people to implement it).  You do not
need any new packets to do what you want.

> An application that implement decrypt & verify MUST/SHOULD warn the user if
> the key used to decrypt the message is not found in an 'encrypted to'
> packet in the signature if the signature contains 'encrypted to'
> packets and thus indicates that the message is created by an atomic
> sign & encrypt.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: by above.proper.com (8.11.6/8.11.3) id g4NCc2P25455 for ietf-openpgp-bks; Thu, 23 May 2002 05:38:02 -0700 (PDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NCc0L25448 for <[e-mail]>; Thu, 23 May 2002 05:38:00 -0700 (PDT)
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA28000; Thu, 23 May 2002 08:38:01 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA24556; Thu, 23 May 2002 08:37:58 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id IAA19511; Thu, 23 May 2002 08:37:55 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id IAA09741; Thu, 23 May 2002 08:37:55 -0400 (EDT)
To: "Dominikus Scherkl" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: secure sign & encrypt
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 May 2002 08:37:55 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 52
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

The interesting thing is that there is nothing STOPPING an application
from doing this today.  OpenPGP messages like the following are
perfectly legal syntax, even in 2440:

ESK [...] Enc { PreSig ESK [...] Enc { Literal { Message } } PostSig }

Go ahead and implement this.  I'm fairly sure that most of the OpenPGP
Parsers out there will Do The Right Thing with this (I'm 99% sure that
PGP 6.5.x will do this, since I wrote that original parser code).

-derek

"Dominikus Scherkl" <[e-mail]> writes:

> Hi.
> 
> > Well, I intended it to become an atomic function.
> Nice. And how? Common public key cryptography doesn't provide
> algorithms to sign an encrypt in a single, undividable step.
> 
> I see no other way than "encrypt, sign and encrypt" (ESE)
> to archive all cyptografic goals which seems inportant to me:
> 
> Two goals require ES:
> - to ensure that the reciever cannot forward a message
>   without destroying the signature or reveiling that it was
>   originaly send to him for his eyes only we must sign after
>   encryption.
> - to convince the receiver he was the original target we 
>   also need to first encryt and than sign.
> 
> two further goals require SE:
> - to ensure the signature is not used for another message
>   we must first sign than encrypt (else especialy for RSA
>   there exist a choosen key attack).
> - to hide that you are sending signed messages you also need
>   to do encryption as the very last step.
> 
> The easiest way to archive all four is ESE, an it is worth
> the time cost of two encryptions, I think.
> 
> Best Regards.
> 
> -- 
> Dominikus Scherkl
> [e-mail]

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NCWAP25336 for ietf-openpgp-bks; Thu, 23 May 2002 05:32:10 -0700 (PDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NCW8L25331 for <[e-mail]>; Thu, 23 May 2002 05:32:08 -0700 (PDT)
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA26452; Thu, 23 May 2002 08:32:08 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id IAA23897; Thu, 23 May 2002 08:32:08 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id IAA28561; Thu, 23 May 2002 08:32:08 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id IAA09727; Thu, 23 May 2002 08:32:08 -0400 (EDT)
To: Terje Braaten <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: secure sign & encrypt
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 May 2002 08:32:08 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 46
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Terje Braaten <[e-mail]> writes:

> Alice makes a love poem, signs & encrypts it and sends it to Bob.
> Some months later they have broken up with each other. Bob decides
> to be mean to Alice, and encrypts the signed love poem and sends it
> to Charlie, faking the From header in the mail so it look likes it is
> from Alice. Then Charlie has a message that is encrypted to him and signed
> by Alice. It seems to Charlie like it is created by sign & encrypt in
> PGP, so he is convinced this must be a message from Alice that she
> has encrypted specially for him.

Note that this will already say:

Good signature from Alic.
Signature made <Date three months ago>

Don't you think Charlie would be suspicious about that?  I would
certainly be suspicious if the signature date wasn't pretty close
to the mail date.  And I would also be suspicious if the mail date
wasn't close to "today".

> What I would like is any PGP implementation to be able to display a message
> like "Good signature from nn. Warning, this message is not made with atomic
> sign & encrypt, and may be encrypted by some one else."

You see, I view this just like regular mail.  There is the envelope
information, and there is the "letter".  By _CONVENTION_ the person
writing a letter duplicates the envelope information on the inside.
This is not done automatically by the Postal Service, nor is it done
automatically by the enveloping process.  A user could just as easily
leave that information out of the letter (thereby opening themselves
to this same attack in meatspace).

This is not something that should be solved at the Protocol Layer.
Repeat to yourself: IT IS A FEATURE THAT SIGN AND ENCRYPT ARE
SEPARABLE OPERATIONS.  Once you make that statement, there is no way,
short of layering violations, to do what you want to do except at the
application later duplicating the information.

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4NCP0b25169 for ietf-openpgp-bks; Thu, 23 May 2002 05:25:00 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NCOwL25165 for <[e-mail]>; Thu, 23 May 2002 05:24:58 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1MFF>; Thu, 23 May 2002 14:22:20 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 14:22:19 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NCOxL25166
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Matthew Byng-Maddick <[e-mail]> wrote:
> 
> As others have pointed out, what is the "atomic sign & 
> encrypt" of which you
> speak?

I envision that in a not too far feature, we can call the
sign & encrypt function in PGP an atomic sign & encrypt.
This is the solution of the problem that I have been trying
to describe all the time.

The problem is that even though sign & encrypt is not atomic
now, that is what most users expect. I do not find it
satisfying as a programmer to have to say to the users
"Sorry, but the OpenPGP protocol do not allow any atomic
sign & encrypt that would have solved your problem, so
you will have to do without."

Adding a new signature packet called 'encrypted to' (or something
like that) would allow OpenPGP applications to implement
such an atomic sign & encrypt. It could say in the protocol
that an application MAY implement atomic sign & encrypt,
and if it does, it MUST do such and such.

My suggestion for a protocol for atomic sign & encrypt is
that the application MUST make an 'encrypted to' packet in
the signature for each key the message and signature packet
is encrypted to in the encryption packet.
These 'encrypted to' packets MUST be in the signed part of the signature.

An application that implement decrypt & verify MUST/SHOULD warn the user if
the key used to decrypt the message is not found in an 'encrypted to'
packet in the signature if the signature contains 'encrypted to'
packets and thus indicates that the message is created by an atomic
sign & encrypt.

-- 
Terje Bråten



Received: by above.proper.com (8.11.6/8.11.3) id g4NBqKg23444 for ietf-openpgp-bks; Thu, 23 May 2002 04:52:20 -0700 (PDT)
Received: from guk1d002.glueckkanja.org (mail.glueckkanja.com [62.8.243.3]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NBqIL23440 for <[e-mail]>; Thu, 23 May 2002 04:52:19 -0700 (PDT)
content-class: urn:content-classes:message
Subject: RE: secure sign & encrypt
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Thu, 23 May 2002 13:52:13 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: secure sign & encrypt
Thread-Index: AcICOijLTUSjlZnGRoy3/gCC46m2kgAEtPHg
From: "Dominikus Scherkl" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4NBqJL23441
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi.

> Well, I intended it to become an atomic function.
Nice. And how? Common public key cryptography doesn't provide
algorithms to sign an encrypt in a single, undividable step.

I see no other way than "encrypt, sign and encrypt" (ESE)
to archive all cyptografic goals which seems inportant to me:

Two goals require ES:
- to ensure that the reciever cannot forward a message
  without destroying the signature or reveiling that it was
  originaly send to him for his eyes only we must sign after
  encryption.
- to convince the receiver he was the original target we 
  also need to first encryt and than sign.

two further goals require SE:
- to ensure the signature is not used for another message
  we must first sign than encrypt (else especialy for RSA
  there exist a choosen key attack).
- to hide that you are sending signed messages you also need
  to do encryption as the very last step.

The easiest way to archive all four is ESE, an it is worth
the time cost of two encryptions, I think.

Best Regards.

-- 
Dominikus Scherkl
[e-mail]


Received: by above.proper.com (8.11.6/8.11.3) id g4NAAdf16913 for ietf-openpgp-bks; Thu, 23 May 2002 03:10:39 -0700 (PDT)
Received: from colon.colondot.net ([e-mail] [212.135.138.209]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4NAAcL16908 for <[e-mail]>; Thu, 23 May 2002 03:10:38 -0700 (PDT)
Received: from mbm by colon.colondot.net with local (Exim 3.33 #1) id 17ApYL-000DAX-00 for [e-mail]; Thu, 23 May 2002 11:10:37 +0100
Date: Thu, 23 May 2002 11:10:37 +0100
From: Matthew Byng-Maddick <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: Re: secure sign & encrypt
Message-ID: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, May 23, 2002 at 11:00:15AM +0200
Organization: Colondot.net
Mail-Copies-To: never
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Thu, May 23, 2002 at 11:00:15AM +0200, Terje Braaten wrote:
> What I would like is any PGP implementation to be able to display a message
> like "Good signature from nn. Warning, this message is not made with atomic
> sign & encrypt, and may be encrypted by some one else."

As others have pointed out, what is the "atomic sign & encrypt" of which you
speak?

MBM

-- 
Matthew Byng-Maddick         <[e-mail]>           http://colondot.net/


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4N92r013820 for ietf-openpgp-bks; Thu, 23 May 2002 02:02:53 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N92oL13814 for <[e-mail]>; Thu, 23 May 2002 02:02:51 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LPCP1L7G>; Thu, 23 May 2002 11:00:16 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Thu, 23 May 2002 11:00:15 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4N92pL13816
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Derek Atkins <[e-mail]> writes:
> 
> You seem to be under the misconception that "sigh & enrypt" is an
> atomic PGP operation.  It is not.  There is "OpenPGP Sign" and there
> is "OpenPGP Encrypt", and these two functions _can_ be combined, but
> the combination is NOT a single atomic function.  It never was.

Well, I intended it to become an atomic function. Many users perceive it
today to be an atomic function, and I think it would be really nice
and a big improvement of the software if it really became a secure
atomic function.


> 
> All PGP ever had was "first sign and then encrypt".  It was just
> user-interface "syntactic sugar" that allows the user to perform both
> tasks together.  However, there is no way for a receiver to tell the
> difference between a one-pass and two-pass "sign and then encrypt".

That is what I see as a major weakness with PGP today. There should be
a difference, and the user should be able to be sure that the signer
and encrypter is the same person if atomic sign & encrypt is used.
It is both very user friendly to make it that way, and it will make
it more secure since it is a already a wide misconception that you
can tell the difference with the current implementation.

[snip]
> > But the point is not to make some human readable boilerplate. The
> > point is that OpenPGP software automatically should be able 
> to detect
> > if the message has been faked to look like it is created by
> > sign & encrypt when it really is not.
> 
> What do you mean?  Can you please explain what attack you believe
> you are preventing?

Alice makes a love poem, signs & encrypts it and sends it to Bob.
Some months later they have broken up with each other. Bob decides
to be mean to Alice, and encrypts the signed love poem and sends it
to Charlie, faking the From header in the mail so it look likes it is
from Alice. Then Charlie has a message that is encrypted to him and signed
by Alice. It seems to Charlie like it is created by sign & encrypt in
PGP, so he is convinced this must be a message from Alice that she
has encrypted specially for him.

What I would like is any PGP implementation to be able to display a message
like "Good signature from nn. Warning, this message is not made with atomic
sign & encrypt, and may be encrypted by some one else."

-- 
Terje Bråten



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4N49fv09884 for ietf-openpgp-bks; Wed, 22 May 2002 21:09:41 -0700 (PDT)
Received: from hermes.cs.auckland.ac.nz (hermes.cs.auckland.ac.nz [130.216.35.151]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4N49dL09880 for <[e-mail]>; Wed, 22 May 2002 21:09:39 -0700 (PDT)
Received: from ruru.cs.auckland.ac.nz (ruru-nfs.cs.auckland.ac.nz [130.216.35.12]) by hermes.cs.auckland.ac.nz (8.12.3/8.12.3) with ESMTP id g4N49Yaq009503; Thu, 23 May 2002 16:09:34 +1200
Received: (from pgut001@localhost) by ruru.cs.auckland.ac.nz (8.9.3/8.8.6/cs-slave) id QAA446700; Thu, 23 May 2002 16:09:33 +1200 (NZST) (sender [e-mail])
Date: Thu, 23 May 2002 16:09:33 +1200 (NZST)
Message-ID: <[e-mail]>
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: secure sign & encrypt
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Derek Atkins <[e-mail]> writes:

>No, the best way around this problem is the USER INTERFACE and EDUCATION.

Jim Schaad posted a good analysis of this a while back.  It's attached below
for people who haven't seen it.

Peter.

-- Snip --

I was hoping that this issue was going to disappear if I ignored it.  I
feel that the problem listed, while potentially interesting, is not one
that can be solved via this type of mechanism.

The problem:  I get a message, signed, and I forward it to you signed
and then possibly encrypted.  You believe that since it was encrypted to
you that nobody else could have sent it but the signer.

Response:  1) A better answer is to put names in e-mail.  2) Am I
suppose to start doing this for all signed mail.  3) How do I convince a
large company like Microsoft that this is even an interesting problem
for them to "fix" in their mail.  4) This does not fix information leaks
in anyway. (A far more interesting problem in my estimation.)

Why this does not work:  I don't know how to begin to tell Microsoft how
to write this code.  The simple case is, if my mail box name is not on
the To/CC line then pop up a warning message.  But this is not an easy
thing to say and program in.

1. When I was working at Microsoft, people sent me mail at the address
"[e-mail]", my mailbox name was
"[e-mail]".  There is no way to determine that these
are or are not the same address.  While in this case they were they
could just have easily been different addresses.

2. Today, the email address that I give people is "[e-mail]",
but this is not the mail box address that I use.  This address forwards
mail to a second address where I down-load my mail from.  Now either the
message is always going to show up for me, or I have a configuration
issue to explain to users (and to write UI for).

3. If I receive e-mail because I am on a mailing list (such as this
mailing list), either I get the message for all mail to that list, or I
have a configureation issue to explain to users (and to write UI for).
This becomes even more fun if you look at nested mailing lists.  This
mailing list address could be contained on one or more other ietf
mailling lists thus I get mail indirectly and infrequently from some
other entity mailing list that I do not know that I am on.

4. BCC addressing causes massive problems.  Either the message always
comes up, I lose the concept of BCC because the address is included, or
a separate signature operation must be included for every BCC
recipeient.  (Does the BCC signature still have the list of all non-BCC
recipients?).  The process of generating addition signature operations
is not acceptable in my estimation, and would likely generate lots of
interesting problems with signed receipts.

5. What are the correct processing rules to deal with the following
situations:
- Nested signatures:  Does this element in an outer signature remove the
requirement for it to be checked on an inner signature?  Does it add or
change the behavior in some way?
- Parallel signature:  What does this mean for two different
side-by-side signatures, possible with different recipient lists?  If I
am on either list I don't need to display this warning?
- Nested Messages:  What happens if I bodily encapsulate an RFC822
message and forward it to you.  Do you check for the encapsulating but
not the embedded message?  Do you check the embedded message for the
from address of the encapsulating message?

I think that this is an interesting accademic problem, until I see a
real world need for a solution I think it should be ignored.

jim


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MNNIn02160 for ietf-openpgp-bks; Wed, 22 May 2002 16:23:18 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MNNGL02156 for <[e-mail]>; Wed, 22 May 2002 16:23:16 -0700 (PDT)
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id TAA14846; Wed, 22 May 2002 19:23:19 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id TAA23433; Wed, 22 May 2002 19:23:18 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id TAA09005; Wed, 22 May 2002 19:23:17 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id TAA08199; Wed, 22 May 2002 19:23:17 -0400 (EDT)
To: Terje Braaten <[e-mail]>
Cc: OpenPGP <[e-mail]>
Subject: Re: secure sign & encrypt
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 22 May 2002 19:23:17 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 41
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Terje Braaten <[e-mail]> writes:

> I do not quite see the relevance of this. Do you think it is bad
> that Charlie can prove that the message was sent to him from Bob
> and not only signed by Bob?
> If Bob want to prevent this he can sign first and then encrypt,
> instead of using the sign & encrypt function in PGP.

You seem to be under the misconception that "sigh & enrypt" is an
atomic PGP operation.  It is not.  There is "OpenPGP Sign" and there
is "OpenPGP Encrypt", and these two functions _can_ be combined, but
the combination is NOT a single atomic function.  It never was.

All PGP ever had was "first sign and then encrypt".  It was just
user-interface "syntactic sugar" that allows the user to perform both
tasks together.  However, there is no way for a receiver to tell the
difference between a one-pass and two-pass "sign and then encrypt".

> It will still be possible to just sign something. It is only when
> you use sign & encrypt the receivers should be able to be sure that
> the one who signed and the one who encrypted the message is the same
> person.

As I said, there is no "combined sign and encrypt" atomic operation in
OpenPGP (or in regular PGP, for that matter).

> But the point is not to make some human readable boilerplate. The
> point is that OpenPGP software automatically should be able to detect
> if the message has been faked to look like it is created by
> sign & encrypt when it really is not.

What do you mean?  Can you please explain what attack you believe
you are preventing?

-derek

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MJmtX26295 for ietf-openpgp-bks; Wed, 22 May 2002 12:48:55 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MJmrL26291 for <[e-mail]>; Wed, 22 May 2002 12:48:53 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LNARYM30>; Wed, 22 May 2002 21:46:23 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 21:46:21 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4MJmsL26292
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> -----Original Message-----
> From: Jon Callas [mailto:[e-mail]]
> Sent: 22. May 2002 21:10
> To: Terje Braaten; OpenPGP
> Subject: Re: secure sign & encrypt
> 
> 
> Hal posted a pointer to my comments on this from last year. 
> I'll weigh in
> again.
> 
> I think this is an issue with semantics. You can't solve 
> semantic problems
> with added syntax, no matter how much syntax you add.

It is important that the syntax will let you express the semantics
you want to use. So yes, this is also a syntax problem.
It is not possible with the current protocol to make PGP applications
that automatically check if the signer and the encrypter is the same
person when sign & encrypt has been used.

> 
> Furthermore, there are risks with this, too. You can still perform a
> redirection attack on a targeted signature. Suppose Alice is 
> trying to do a
> business deal with both Bob and Charlie, and trying to get 
> the best price.
> If Bob sends Charlie a signed message that is targeted to 
> him, it can be
> more embarrassing than if the signature were untargeted. I'm 
> really sorry,
> but if you send a private message to someone who puts it on 
> their web page,
> you might be irked by this.

I do not quite see the relevance of this. Do you think it is bad
that Charlie can prove that the message was sent to him from Bob
and not only signed by Bob?
If Bob want to prevent this he can sign first and then encrypt,
instead of using the sign & encrypt function in PGP.


> 
> One of the things that I try to keep an eye out for is 
> traffic analysis. I
> think it is a feature of OpenPGP that it puts the signatures 
> inside the
> envelope, because if they're outside the envelope, you have

The signature will still be inside the envelope. Only those that
the message are encrypted to will be able to see the signature.

> cryptographically assisted traffic analysis. Targeting in 
> signatures also
> assists traffic analysis, and users who don't understand that signing
> low-context messages is a bad idea aren't going to understand traffic
> analysis issues.

It will still be possible to just sign something. It is only when
you use sign & encrypt the receivers should be able to be sure that
the one who signed and the one who encrypted the message is the same
person.

> 
> Lastly, if you really, really want to do this, there is 
> already support in
> the OpenPGP protocol for it! This is one of the myriad things 
> notations are
> good for. Software can make a signature with a human-readable 
> notation in it
> that is boilerplate. It could say, "Created on <date> by <source> for
> <target>." There's your targeting, just convince some 
> implementer to do it.

But the point is not to make some human readable boilerplate. The
point is that OpenPGP software automatically should be able to detect
if the message has been faked to look like it is created by
sign & encrypt when it really is not.


> Just don't make me use it, thanks. I'll have even less reason to sign
> things.

You will still have the option to do the signing and encryption in
two operations. Then the 'encrypted to' packets will not be present
in the signature.

-- 
Terje Bråten



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MJA4T25265 for ietf-openpgp-bks; Wed, 22 May 2002 12:10:04 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MJA3L25259 for <[e-mail]>; Wed, 22 May 2002 12:10:03 -0700 (PDT)
Received: from [192.168.1.126] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Wed, 22 May 2002 12:10:00 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Wed, 22 May 2002 12:09:47 -0700
Subject: Re: secure sign & encrypt
From: Jon Callas <[e-mail]>
To: Terje Braaten <[e-mail]>, OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hal posted a pointer to my comments on this from last year. I'll weigh in
again.

I think this is an issue with semantics. You can't solve semantic problems
with added syntax, no matter how much syntax you add.

Furthermore, there are risks with this, too. You can still perform a
redirection attack on a targeted signature. Suppose Alice is trying to do a
business deal with both Bob and Charlie, and trying to get the best price.
If Bob sends Charlie a signed message that is targeted to him, it can be
more embarrassing than if the signature were untargeted. I'm really sorry,
but if you send a private message to someone who puts it on their web page,
you might be irked by this.

One of the things that I try to keep an eye out for is traffic analysis. I
think it is a feature of OpenPGP that it puts the signatures inside the
envelope, because if they're outside the envelope, you have
cryptographically assisted traffic analysis. Targeting in signatures also
assists traffic analysis, and users who don't understand that signing
low-context messages is a bad idea aren't going to understand traffic
analysis issues.

Lastly, if you really, really want to do this, there is already support in
the OpenPGP protocol for it! This is one of the myriad things notations are
good for. Software can make a signature with a human-readable notation in it
that is boilerplate. It could say, "Created on <date> by <source> for
<target>." There's your targeting, just convince some implementer to do it.
Just don't make me use it, thanks. I'll have even less reason to sign
things.

    Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MIAE223873 for ietf-openpgp-bks; Wed, 22 May 2002 11:10:14 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MIACL23869 for <[e-mail]>; Wed, 22 May 2002 11:10:12 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LNARYMMH>; Wed, 22 May 2002 20:07:42 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "OpenPGP (E-mail)" <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 20:07:41 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4MIACL23870
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> -----Original Message-----
> From: Hal Finney [mailto:[e-mail]]
> Sent: 22. May 2002 19:09
> To: [e-mail]; [e-mail]
> Subject: RE: secure sign & encrypt
> 
> 
> The problem is that this sign-and-encrypt issue is just the tip of
> the iceberg.  It is not worth redoing the protocol when there 
> are these
> other issues that will remain unresolved.

I disagree with this. The encryption of a message is much more
fundamentally linked to the signing of the same message, both in
practice and in peoples mind. Since we do have a function called
sign & encrypt in PGP, users will assume that it really is a secure
sign & encrypt, and that they can trust it to be one operation where
the signature and the encryption is linked.

Even more sophisticated users like f.ex. Vedaal on this list, seem to
think that already in PGP you can be sure that the signer is the same as
the encrypter if it appears that the message has been made by a PGP
sign & encrypt operation.

[snip]
> I read the paper and closely followed the extensive discussion on the
> cryptography list when this came out last year.  In my opinion the
> consensus among the professionals on that list was that, properly
> understood, there is more to this than a protocol flaw that can be
> easily patched.  It represents a fundamental property of 
> encrypted email.
> Some data is protected and some is not.

And I think we should make who the message is encrypted to a part
of what is protected, as long as PGP offers a function called sign &
encrypt.

> 
> The real solution is to put the entire email, headers and all, into
> the signed envelope, and then for the receiving software to compare
> the protected headers with those on the actual message.  This will
> detect substition of from/to lines as well as other changes, and will
> work for both signed and signed+encrypted messages.
> 
> We do have data structures to support this via PGP/MIME and the
> Message/rfc822 MIME type.  However actually implementing this
> functionality is difficult as it requires close integration with the
> email software.  In practice, probably only email software providers
> would be in a position to provide this level of functionality.

Yes, this is really an issue that should go into the PGP/MIME standard
as well, and there also protect important headers in the mail like
To, From, Cc, Date, etc.
But here we discuss the core OpenPGP standard, and since it includes
detailed specifications on how sign & encrypt is to be done,
this also should be fixed in this standard.

Also note that this problem is not specific to messages sent by e-mail,
but applies to all messages that is signed & encrypted and may not
naturally contain a To or From field.

-- 
Terje Bråten


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MHIgf22227 for ietf-openpgp-bks; Wed, 22 May 2002 10:18:42 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MHIfL22223 for <[e-mail]>; Wed, 22 May 2002 10:18:41 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g4MH93R12841; Wed, 22 May 2002 10:09:03 -0700
Date: Wed, 22 May 2002 10:09:03 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: RE: secure sign & encrypt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

The problem is that this sign-and-encrypt issue is just the tip of
the iceberg.  It is not worth redoing the protocol when there are these
other issues that will remain unresolved.

First, as mentioned before there is still the chance of confusion if a
clearsigned message is misdirected.  Most people will assume that if they
get an email from someone who PGP signed it, that the email was directed
towards them.  The PGP signature will add weight and authority to this
misconception.  Fixing the sign and encrypt problem won't help with this.

Second, there are other issues than sender/recipient which people
may assume implicitly are being protected by PGP.  This could include
message subject and possibly other header fields.  People will often
assume a certain context in interpreting a message based on this data.
If someone gets an email from their boss with the subject "Smithers
account" and the content tells them to "cancel the account immediately",
the subject line is crucially important in interpreting the message.
PGP does not protect this data, but users may not understand this.

I read the paper and closely followed the extensive discussion on the
cryptography list when this came out last year.  In my opinion the
consensus among the professionals on that list was that, properly
understood, there is more to this than a protocol flaw that can be
easily patched.  It represents a fundamental property of encrypted email.
Some data is protected and some is not.

The real solution is to put the entire email, headers and all, into
the signed envelope, and then for the receiving software to compare
the protected headers with those on the actual message.  This will
detect substition of from/to lines as well as other changes, and will
work for both signed and signed+encrypted messages.

We do have data structures to support this via PGP/MIME and the
Message/rfc822 MIME type.  However actually implementing this
functionality is difficult as it requires close integration with the
email software.  In practice, probably only email software providers
would be in a position to provide this level of functionality.

Hal


Received: by above.proper.com (8.11.6/8.11.3) id g4MGD8919587 for ietf-openpgp-bks; Wed, 22 May 2002 09:13:08 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MGD6L19581 for <[e-mail]>; Wed, 22 May 2002 09:13:06 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LNARYMJ5>; Wed, 22 May 2002 18:10:36 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "OpenPGP (E-mail)" <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 18:10:34 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4MGD7L19584
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> -----Original Message-----
> From: Derek Atkins [mailto:[e-mail]]
> Sent: 22. May 2002 16:09
[...]
> No, the best way around this problem is the USER INTERFACE and
> EDUCATION.  If you receive a signed message that looks like:

I have to disagree with you there Derek. It is not possible to
write an user interface that automatically detects this problem if
there is no support for it in the protocol. It has to be specified
in the protocol that under a sign & encrypt operation the application
MUST make an 'encrypted to' packet in the signature for each key
the message and signature packet is encrypted to in the encryption packet.
These 'encrypted to' packets MUST be in the signed part of the signature.

An application that implement decrypt & verify MUST warn the user if
the key used to decrypt the message is not found in an 'encrypted to'
packet in the signature (if it is to be a good signature).

No matter how much you try to educate your users, I think that
yet for a few decades most people will think that when they receive
an email that is both signed and encrypted, most will assume that
they can be sure that the signer and the encrypter is the same person.
I think it will be a very great improvement in the protocol to make
it so that it really can be true.

-- 
Terje Bråten


Received: by above.proper.com (8.11.6/8.11.3) id g4MEP8d13724 for ietf-openpgp-bks; Wed, 22 May 2002 07:25:08 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MEP6L13714 for <[e-mail]>; Wed, 22 May 2002 07:25:06 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LNARYMDK>; Wed, 22 May 2002 16:22:35 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "'vedaal'" <[e-mail]>, [e-mail]
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 16:22:34 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4MEP7L13721
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> -----Original Message-----
> From: vedaal [mailto:[e-mail]]
> Sent: 22. mai 2002 15:01
> To: [e-mail]
> Subject: Re: secure sign & encrypt

[...]
> I thought that a packet that simply records the elapsed time 
> in fractions of
> a second, between signing and encrypting,
> could be added without affecting the signature or encryption 
> packets, and
> might be easier to implement without affecting
> backward compatiblity.

If it is not signed (i.e. a signed signature packet) but only added
to the message on the outside, it is nothing that stops the attacker
from just faking that time packet.

> 
> [...]
> 
> > If it is not a signature packet, I do not understand what would
> > keep the attacker from making a fake timestamp when 
> re-encrypting the
> > message.
> 
> It would be an 'record of actual elapsed time' packet,  
> measured from the
> time the program calls for the time of signing,
> to the time it calls for encrypting.  It would not be 'calculated' by
> measuring the recorded (old) timestamp of the signature,
> and then re-setting the attacker's computer to the same time 
> and measuring
> the fractions of seconds till the encryption.

You say "It would not be 'calculated' by ...", but then you rely
on the attacker using a certain program or implementation of OpenPGP.
When designing a security protocol, we must assume that an attacker
will be able to use any program that he likes or even write his own
programs.
If it is permitted by the protocol, the attacker can do it, even
if it is not possible to do it using the usual implementations of the
protocol.


> 
> { i do not yet know how to read and write code :(  , so it is only my
> opinion of what seems plausibly 'do-able' ,
> it may be that it has flaws that experienced programmers can 
> instantly see,
> if so, i apologize in advance}

You are forgiven.

-- 
Terje Bråten



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4ME9J412947 for ietf-openpgp-bks; Wed, 22 May 2002 07:09:19 -0700 (PDT)
Received: from fort-point-station.mit.edu (FORT-POINT-STATION.MIT.EDU [18.7.7.76]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4ME9HL12942 for <[e-mail]>; Wed, 22 May 2002 07:09:17 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by fort-point-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA21115; Wed, 22 May 2002 10:09:18 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA05121; Wed, 22 May 2002 10:09:17 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA29722; Wed, 22 May 2002 10:09:17 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA06819; Wed, 22 May 2002 10:09:17 -0400 (EDT)
To: "vedaal" <[e-mail]>
Cc: <[e-mail]>
Subject: Re: secure sign & encrypt
References: <[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 22 May 2002 10:09:17 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 93
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

How is the receiver supposed to know what the delta-t is?
How do you deal with different machines of different speeds?
What if the sender is a PalmPilot and the receiver is a Pentium-4 3GHz?
There is absolutely no consistency in the time.

Worse, an attacker who wants to re-send the message already knows what
the original delta-t is, and can add it to any new packets they
create.

Even putting a timestamp into the ESK to enforce "ESK time == Sig
Time" doesn't help you, because there is no way to verify the
timestamp on other ESKs (to see if they've been added).  All you know
is that "This message was encrypted by someone who was able to see the
original" (which could be the sender, or could be one of the
"original" receipients.

No, the best way around this problem is the USER INTERFACE and
EDUCATION.  If you receive a signed message that looks like:

  --- begin message ---
  To: peter, paul, mary
  Subject: Hi
  Date: <now>

  I QUIT!  Have a nice day!
  --- begin signature ---
  <stuff>
  --- end signature ---

(Or think of the same type of message but signed and encrypted)..

Notice how the original recipients are part of the signed message?  If
this gets forwarded to another person, they would know that they were
not an intended recipient.  You cannot change that without
invalidating the signature.

-derek

"vedaal" <[e-mail]> writes:

> ----- Original Message -----
> From: "Terje Braaten" <[e-mail]>
> To: "OpenPGP (E-mail)" <[e-mail]>
> Sent: Wednesday, May 22, 2002 6:51 AM
> Subject: RE: secure sign & encrypt
> 
> [...]
> > > If there could be a packet added linking the time of
> > > encryption to the time
> > > of signing,
> > > {including elapsed time in seconds [or 0.00x seconds], and
> > > therefore not
> > > attackable by trying to re-set the re-encrypting
> > > computer to the time recorded in the original signed message.}
> >
> > I do not understand how you intend this packet to be added.
> > If it is a signature packet, would not the changes to be done
> > be about the same as if we added an 'encrypted to' packet?
> 
> Yes,     it could be done your way too, with about the same amount of
> change.
> 
> I thought that a packet that simply records the elapsed time in fractions of
> a second, between signing and encrypting,
> could be added without affecting the signature or encryption packets, and
> might be easier to implement without affecting
> backward compatiblity.
> 
> [...]
> 
> > If it is not a signature packet, I do not understand what would
> > keep the attacker from making a fake timestamp when re-encrypting the
> > message.
> 
> It would be an 'record of actual elapsed time' packet,  measured from the
> time the program calls for the time of signing,
> to the time it calls for encrypting.  It would not be 'calculated' by
> measuring the recorded (old) timestamp of the signature,
> and then re-setting the attacker's computer to the same time and measuring
> the fractions of seconds till the encryption.
> 
> { i do not yet know how to read and write code :(  , so it is only my
> opinion of what seems plausibly 'do-able' ,
> it may be that it has flaws that experienced programmers can instantly see,
> if so, i apologize in advance}
> 
> --vedaal

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MD3CB08029 for ietf-openpgp-bks; Wed, 22 May 2002 06:03:12 -0700 (PDT)
Received: from hotmail.com (oe36.law3.hotmail.com [209.185.240.204]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MD3AL08022 for <[e-mail]>; Wed, 22 May 2002 06:03:10 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 22 May 2002 06:03:06 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: secure sign & encrypt
Date: Wed, 22 May 2002 09:00:32 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 22 May 2002 13:03:06.0898 (UTC) FILETIME=[0402E720:01C20191]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

----- Original Message -----
From: "Terje Braaten" <[e-mail]>
To: "OpenPGP (E-mail)" <[e-mail]>
Sent: Wednesday, May 22, 2002 6:51 AM
Subject: RE: secure sign & encrypt

[...]
> > If there could be a packet added linking the time of
> > encryption to the time
> > of signing,
> > {including elapsed time in seconds [or 0.00x seconds], and
> > therefore not
> > attackable by trying to re-set the re-encrypting
> > computer to the time recorded in the original signed message.}
>
> I do not understand how you intend this packet to be added.
> If it is a signature packet, would not the changes to be done
> be about the same as if we added an 'encrypted to' packet?

Yes,     it could be done your way too, with about the same amount of
change.

I thought that a packet that simply records the elapsed time in fractions of
a second, between signing and encrypting,
could be added without affecting the signature or encryption packets, and
might be easier to implement without affecting
backward compatiblity.

[...]

> If it is not a signature packet, I do not understand what would
> keep the attacker from making a fake timestamp when re-encrypting the
> message.

It would be an 'record of actual elapsed time' packet,  measured from the
time the program calls for the time of signing,
to the time it calls for encrypting.  It would not be 'calculated' by
measuring the recorded (old) timestamp of the signature,
and then re-setting the attacker's computer to the same time and measuring
the fractions of seconds till the encryption.

{ i do not yet know how to read and write code :(  , so it is only my
opinion of what seems plausibly 'do-able' ,
it may be that it has flaws that experienced programmers can instantly see,
if so, i apologize in advance}

--vedaal


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4MAsAE00528 for ietf-openpgp-bks; Wed, 22 May 2002 03:54:10 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MAs8L00519 for <[e-mail]>; Wed, 22 May 2002 03:54:08 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LNARYLXB>; Wed, 22 May 2002 12:51:37 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "OpenPGP (E-mail)" <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 12:51:36 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4MAs9L00522
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

vedaal <[e-mail]> wrote:
> It seems that one thing that is definitely different in a 
> message that is
> sent as 'sign and encrypt',
> and one that is re-encrypting a signed message, is the time 
> in which it is
> being done.
> 
> An authentic 'sign and encrypt' message, has the signature 
> and encryption
> done within seconds of each other.
> 
> If there could be a packet added linking the time of 
> encryption to the time
> of signing,
> {including elapsed time in seconds [or 0.00x seconds], and 
> therefore not
> attackable by trying to re-set the re-encrypting
> computer to the time recorded in the original signed message.}

I do not understand how you intend this packet to be added.
If it is a signature packet, would not the changes to be done
be about the same as if we added an 'encrypted to' packet?
If it is not a signature packet, I do not understand what would
keep the attacker from making a fake timestamp when re-encrypting the
message.

>  and that packet tied to an MDC, it might serve as a means of 
> detection of
> re-encrypted signed messages.
> 
> It should be able to be done without affecting backward compatibility,
> and those using earlier implementations, could accomplish the 
> same thing (if
> really necessary), by using
> [encrypt, sign & encrypt].

This is also one of the solutions suggested in
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html
to use encrypt, sign, encrypt instead of just sign & encrypt.
It is also possible to use sign, encrypt, sign.

But I think that adds an computational overhead when processing the
encryption/decryption that would be avoided by adding an extra packet
to the signature.

-- 
Terje Bråten



Received: by above.proper.com (8.11.6/8.11.3) id g4MAYA227538 for ietf-openpgp-bks; Wed, 22 May 2002 03:34:10 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4MAY8L27534 for <[e-mail]>; Wed, 22 May 2002 03:34:08 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LNARYLWJ>; Wed, 22 May 2002 12:31:32 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: OpenPGP <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Wed, 22 May 2002 12:31:32 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4MAY9L27535
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Jon Callas <[e-mail]> wrote:
> It's important to understand what's in the envelope and what 
> is not in the
> envelope. The ESK is like the address on an envelope. It's not in the
> envelope. It's outside the envelope and is not protected.

That is a good picture of what is the problem. The solution I proposed
is to put a copy of the address(es) on the outside of the envelope also
inside the envelope. If what is on the outside do not match what is on
the inside the user should get a warning that the message is (most probably)
encrypted by some one else than the person that signed the message.

-- 
Terje Bråten



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LIWK002054 for ietf-openpgp-bks; Tue, 21 May 2002 11:32:20 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LIWJL02050 for <[e-mail]>; Tue, 21 May 2002 11:32:19 -0700 (PDT)
Received: from [192.168.1.126] (63.84.37.127) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Tue, 21 May 2002 11:32:16 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Tue, 21 May 2002 11:31:50 -0700
Subject: Re: secure sign & encrypt
From: Jon Callas <[e-mail]>
To: vedaal <[e-mail]>, OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 5/21/2002 8:36 AM, "vedaal" <[e-mail]> wrote:

> Also, could the MDC be utilized to prevent such substitutions, by detecting
> alterations of any of the packets?

No. The MDC protects the contents of the symmetric encryption. It does not
protect the ESKs. Nothing protects them, beyond their own encryption.

It would be possible, for example, to make an SMTP server that took a PGP
message with several ESKs in one message, and explode that into N messages,
each with only one ESK. If such a thing existed, the receiver could not
detect it. 

As Derek mentioned, you could even put in utterly bogus MDCs. These could
never be detected as bogus unless you happened to have the key that opened
it.

There are a number of interesting "harrassment attacks" that you can do. For
example, let's suppose I run a server that's an intermediate between Alice
and Bob. I intercept a message Alice's message, and then add in an ESK
that's encrypted to the Lotus Notes/NSA key that Adam Back created into a
PGP key. This is utterly bogus -- I just made up some 128 bit number and
encrypted it to that key. But I insert it in the message and send it on to
Bob. If Bob concludes that Alice is CCing the NSA on messages, then that's a
not unreasonable conclusion to draw. I can just sit back and snicker.

It's important to understand what's in the envelope and what is not in the
envelope. The ESK is like the address on an envelope. It's not in the
envelope. It's outside the envelope and is not protected.

    Jon



Received: by above.proper.com (8.11.6/8.11.3) id g4LIOSF01831 for ietf-openpgp-bks; Tue, 21 May 2002 11:24:28 -0700 (PDT)
Received: from hotmail.com (oe23.law3.hotmail.com [209.185.240.16]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LIOQL01827 for <[e-mail]>; Tue, 21 May 2002 11:24:26 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 21 May 2002 11:24:19 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]><[e-mail]><[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: secure sign & encrypt
Date: Tue, 21 May 2002 14:20:45 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 21 May 2002 18:24:19.0023 (UTC) FILETIME=[B8AE0DF0:01C200F4]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

----- Original Message -----
From: "Derek Atkins" <[e-mail]>
To: "vedaal" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, May 21, 2002 12:23 PM
Subject: Re: secure sign & encrypt


> > Also, could the MDC be utilized to prevent such substitutions, by
detecting
> > alterations of any of the packets?
>
> No, because the MDC could be recreated as well.  The MDC is tied to K
> but has no signature associated with it to tie it to the actual
> sender.

It seems that one thing that is definitely different in a message that is
sent as 'sign and encrypt',
and one that is re-encrypting a signed message, is the time in which it is
being done.

An authentic 'sign and encrypt' message, has the signature and encryption
done within seconds of each other.

If there could be a packet added linking the time of encryption to the time
of signing,
{including elapsed time in seconds [or 0.00x seconds], and therefore not
attackable by trying to re-set the re-encrypting
computer to the time recorded in the original signed message.}
 and that packet tied to an MDC, it might serve as a means of detection of
re-encrypted signed messages.

It should be able to be done without affecting backward compatibility,
and those using earlier implementations, could accomplish the same thing (if
really necessary), by using
[encrypt, sign & encrypt].

--just a thought,

vedaal


Received: by above.proper.com (8.11.6/8.11.3) id g4LGNPl27386 for ietf-openpgp-bks; Tue, 21 May 2002 09:23:25 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LGNOL27382 for <[e-mail]>; Tue, 21 May 2002 09:23:24 -0700 (PDT)
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id MAA20361; Tue, 21 May 2002 12:23:25 -0400 (EDT)
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id MAA07588; Tue, 21 May 2002 12:23:25 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by melbourne-city-street.mit.edu (8.9.2/8.9.2) with ESMTP id MAA26632; Tue, 21 May 2002 12:23:15 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id MAA27177; Tue, 21 May 2002 12:23:15 -0400 (EDT)
To: "vedaal" <[e-mail]>
Cc: <[e-mail]>
From: Derek Atkins <[e-mail]>
Subject: Re: secure sign & encrypt
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: 21 May 2002 12:23:14 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 34
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

"vedaal" <[e-mail]> writes:

> Wouldn't that cause a CRC error, indicating that the message was tampered
> with?
> Or could a new CRC be calculated and included in the new re-encrypted
> message?

Which CRC do you mean?  Do you mean the armor CRC?  That's re-created.
Internally, the signature and encryption are completely separable.  If
you sign a message (note: NOT clearsigning), you would get the same
internal structure as you get when you sign and encrypt a message.
The only difference is that in the latter, when you encrypt, you take
the output from the signature transform and encrypt it, rather than
sending it to a file (or to ascii armor).

> Also, could the MDC be utilized to prevent such substitutions, by detecting
> alterations of any of the packets?

No, because the MDC could be recreated as well.  The MDC is tied to K
but has no signature associated with it to tie it to the actual
sender.

> Thanks,
> 
> vedaal
> 
> {i don't know,  so am asking}

-derek

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [e-mail]             www.ihtfp.com


Received: by above.proper.com (8.11.6/8.11.3) id g4LFdf424802 for ietf-openpgp-bks; Tue, 21 May 2002 08:39:41 -0700 (PDT)
Received: from hotmail.com (oe46.law3.hotmail.com [209.185.240.214]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LFddL24798 for <[e-mail]>; Tue, 21 May 2002 08:39:39 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 21 May 2002 08:39:31 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]><[e-mail]> <[e-mail]>
Subject: Re: secure sign & encrypt
Date: Tue, 21 May 2002 11:36:40 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 21 May 2002 15:39:31.0835 (UTC) FILETIME=[B374E4B0:01C200DD]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

----- Original Message -----
From: "Derek Atkins" <[e-mail]>
To: "vedaal" <[e-mail]>
Cc: <[e-mail]>
Sent: Tuesday, May 21, 2002 10:33 AM
Subject: Re: secure sign & encrypt


>
> sorry, vedaal, but you are incorrect.  With current OpenPGP is _IS_
> possible to strip off the encryption from a message and re-encrypt it
> to another user, keeping the signature intact.  In fact, back in the
> early 90's (and mid-90's when we were first designing the pre-OpenPGP
> packets), this was in fact a design goal!
>
> Remember that a signed/encrypted message looks like:
>
>         ESK{PubA, K} ... Enc{K, PreSig{Hash{M}}, Lit{M}, PostSig{Hash{M}}}
>
> Given this format, you can easily replace the K in ESK{} and Enc{}
> without destroying the Presig,Literal,PostSig packets.

Wouldn't that cause a CRC error, indicating that the message was tampered
with?
Or could a new CRC be calculated and included in the new re-encrypted
message?

Also, could the MDC be utilized to prevent such substitutions, by detecting
alterations of any of the packets?

Thanks,

vedaal

{i don't know,  so am asking}


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4LEfbR22240 for ietf-openpgp-bks; Tue, 21 May 2002 07:41:37 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LEfaL22236 for <[e-mail]>; Tue, 21 May 2002 07:41:36 -0700 (PDT)
Received: from grand-central-station.mit.edu (GRAND-CENTRAL-STATION.MIT.EDU [18.7.21.82]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id KAA02400; Tue, 21 May 2002 10:41:37 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by grand-central-station.mit.edu (8.9.2/8.9.2) with ESMTP id KAA14273; Tue, 21 May 2002 10:33:31 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id KAA05878; Tue, 21 May 2002 10:33:30 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id KAA26948; Tue, 21 May 2002 10:33:31 -0400 (EDT)
To: "vedaal" <[e-mail]>
Cc: <[e-mail]>
From: Derek Atkins <[e-mail]>
Subject: Re: secure sign & encrypt
References: <[e-mail]> <[e-mail]>
Date: 21 May 2002 10:33:31 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 72
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

sorry, vedaal, but you are incorrect.  With current OpenPGP is _IS_
possible to strip off the encryption from a message and re-encrypt it
to another user, keeping the signature intact.  In fact, back in the
early 90's (and mid-90's when we were first designing the pre-OpenPGP
packets), this was in fact a design goal!

Remember that a signed/encrypted message looks like:

        ESK{PubA, K} ... Enc{K, PreSig{Hash{M}}, Lit{M}, PostSig{Hash{M}}}

Given this format, you can easily replace the K in ESK{} and Enc{}
without destroying the Presig,Literal,PostSig packets.

Now, it may be that the current _implementations_ do not make it easy
for a user to do so, but that is an implementation detail, not a
protocol detail.  The protocol could allow you to do so.

-derek

"vedaal" <[e-mail]> writes:

> ----- Original Message -----
> From: "Terje Braaten" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, May 20, 2002 7:31 PM
> Subject: RE: secure sign & encrypt
> 
> [...]
> 
>  > The problem is that most users when they decrypt a message
> > that is signed, they will think they can be sure the signer
> > and the encrypter is the same person/entity.
> > It would be a major improvement in the OpenPGP specification
> > to allow applications to ensure that that really is the case.
> 
> [...]
> 
> Functionally, that is the case now in Open PGP.
> 
> Even though a signed and encrypted message can be separated into a
> verifiable free standing signed message, and then
> re-encrypted and sent on to someone else,
> it 'cannot' {afaik} be re-combined into a signed and encrypted message that
> appears the same as a de-novo signed and encrypted message.
> 
> The most that can be done with the separation and re-encryption, is to have
> a message, that upon decryption, is clearsigned,
> or armored signed, and even the armored signed message is clearly of a
> different form than a de novo armored signed message;
> {a de novo armored signed message always has the message block begin with
> the letters 'ow', the separated armored signed
> message never does}.
> 
> Someone receiving a re-encrypted separated signed message, can instantly
> tell upon decryption, that it was an 'intentionally'
> re-encrypted message, and not an original.
> 
> The only time that this could be a problem, is for very new users, who may
> inadvertently get into a habit of clearsigning and then encrypting, instead
> of using the one-function 'sign and encrypt' , and as soon as it is pointed
> out to them that it is simpler and easier to use 'sign and encrypt' single
> function, they will probably do so.
> 
> hth,
> 
> vedaal
> 

-- 
       Derek Atkins
       Computer and Internet Security Consultant
       [e-mail]             www.ihtfp.com


Received: by above.proper.com (8.11.6/8.11.3) id g4LEUma21788 for ietf-openpgp-bks; Tue, 21 May 2002 07:30:48 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LEUjL21783 for <[e-mail]>; Tue, 21 May 2002 07:30:46 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <LK94MCPJ>; Tue, 21 May 2002 16:28:17 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Tue, 21 May 2002 16:28:16 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4LEUlL21785
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

vedaal <[e-mail]> wrote:
> 
> ----- Original Message -----
> From: "Terje Braaten" <[e-mail]>
> To: <[e-mail]>
> Sent: Monday, May 20, 2002 7:31 PM
> Subject: RE: secure sign & encrypt
> 
> [...]
> 
>  > The problem is that most users when they decrypt a message
> > that is signed, they will think they can be sure the signer
> > and the encrypter is the same person/entity.
> > It would be a major improvement in the OpenPGP specification
> > to allow applications to ensure that that really is the case.
> 
> [...]
> 
> Functionally, that is the case now in Open PGP.

How can that be? Which functionality in Open PGP are you referring to?
Is it specified anywhere in the RFC?

> 
> Even though a signed and encrypted message can be separated into a
> verifiable free standing signed message, and then
> re-encrypted and sent on to someone else,
> it 'cannot' {afaik} be re-combined into a signed and 
> encrypted message that
> appears the same as a de-novo signed and encrypted message.
> 
> The most that can be done with the separation and 
> re-encryption, is to have
> a message, that upon decryption, is clearsigned,
> or armored signed, and even the armored signed message is clearly of a
> different form than a de novo armored signed message;
> {a de novo armored signed message always has the message 
> block begin with
> the letters 'ow', the separated armored signed
> message never does}.
> 
> Someone receiving a re-encrypted separated signed message, 
> can instantly
> tell upon decryption, that it was an 'intentionally'
> re-encrypted message, and not an original.

If the attacker only an ordinary user, that might be the case.
But if who the message is supposed to be encrypted to is not signed
when the signature is added, it is only a matter of being a good programmer
to fake a "signed & encrypted" message, given the Open PGP standard
as it is today.

We should not rely on security through obscurity.


-- 
Terje Bråten



Received: by above.proper.com (8.11.6/8.11.3) id g4LCx2G14886 for ietf-openpgp-bks; Tue, 21 May 2002 05:59:02 -0700 (PDT)
Received: from hotmail.com (oe32.law3.hotmail.com [209.185.240.25]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4LCx0L14880 for <[e-mail]>; Tue, 21 May 2002 05:59:00 -0700 (PDT)
Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Tue, 21 May 2002 05:57:57 -0700
X-Originating-IP: [207.127.12.210]
From: "vedaal" <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: Re: secure sign & encrypt
Date: Tue, 21 May 2002 08:56:03 -0400
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4807.1700
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700
Message-ID: <[e-mail]>
X-OriginalArrivalTime: 21 May 2002 12:57:57.0238 (UTC) FILETIME=[2106C960:01C200C7]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

----- Original Message -----
From: "Terje Braaten" <[e-mail]>
To: <[e-mail]>
Sent: Monday, May 20, 2002 7:31 PM
Subject: RE: secure sign & encrypt

[...]

 > The problem is that most users when they decrypt a message
> that is signed, they will think they can be sure the signer
> and the encrypter is the same person/entity.
> It would be a major improvement in the OpenPGP specification
> to allow applications to ensure that that really is the case.

[...]

Functionally, that is the case now in Open PGP.

Even though a signed and encrypted message can be separated into a
verifiable free standing signed message, and then
re-encrypted and sent on to someone else,
it 'cannot' {afaik} be re-combined into a signed and encrypted message that
appears the same as a de-novo signed and encrypted message.

The most that can be done with the separation and re-encryption, is to have
a message, that upon decryption, is clearsigned,
or armored signed, and even the armored signed message is clearly of a
different form than a de novo armored signed message;
{a de novo armored signed message always has the message block begin with
the letters 'ow', the separated armored signed
message never does}.

Someone receiving a re-encrypted separated signed message, can instantly
tell upon decryption, that it was an 'intentionally'
re-encrypted message, and not an original.

The only time that this could be a problem, is for very new users, who may
inadvertently get into a habit of clearsigning and then encrypting, instead
of using the one-function 'sign and encrypt' , and as soon as it is pointed
out to them that it is simpler and easier to use 'sign and encrypt' single
function, they will probably do so.

hth,

vedaal



Received: by above.proper.com (8.11.6/8.11.3) id g4KNYDI16475 for ietf-openpgp-bks; Mon, 20 May 2002 16:34:13 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KNYBL16471 for <[e-mail]>; Mon, 20 May 2002 16:34:11 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <L27XBPRJ>; Tue, 21 May 2002 01:31:47 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: RE: secure sign & encrypt
Date: Tue, 21 May 2002 01:31:47 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4KNYCL16472
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Well, it is not only to add a new packet, but also add to
the user programs a check that if the packet is present in
the signature, the signature block should come from
decrypting a message with one the expected keys.

Clear signed messages should pose no user problems, because
the users generally understands that such the cryptographic
software will not give any confirmation of the origin of the
message.

The problem is that most users when they decrypt a message
that is signed, they will think they can be sure the signer
and the encrypter is the same person/entity.
It would be a major improvement in the OpenPGP specification
to allow applications to ensure that that really is the case.

Have you read the link
http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html

I really think it addresses a real problem.

-- 
Terje Bråten


-----Original Message-----
From: Hal Finney [mailto:[e-mail]]
Sent: 21. mai 2002 00:12
To: [e-mail]; [e-mail]
Subject: Re: secure sign & encrypt


There was quite a bit of discussion about this last year on the
cryptography mailing list.  I thought Jon Callas' message was good,
pointing out the wider ramifications of this kind of "failure":
http://www.mit.edu:8008/bloom-picayune/crypto/8891.

It is really not clear that solving it is as simple as adding a new
packet.  There are still other ways that things can go wrong, such
as simply redirecting a clear-signed message.  The fundamental problem
is that people don't understand what is protected and what isn't in
a signed mail message.

Hal


Received: by above.proper.com (8.11.6/8.11.3) id g4KMM6t14491 for ietf-openpgp-bks; Mon, 20 May 2002 15:22:06 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KMM5L14487 for <[e-mail]>; Mon, 20 May 2002 15:22:05 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g4KMCPf03923; Mon, 20 May 2002 15:12:26 -0700
Date: Mon, 20 May 2002 15:12:26 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: secure sign & encrypt
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

There was quite a bit of discussion about this last year on the
cryptography mailing list.  I thought Jon Callas' message was good,
pointing out the wider ramifications of this kind of "failure":
http://www.mit.edu:8008/bloom-picayune/crypto/8891.

It is really not clear that solving it is as simple as adding a new
packet.  There are still other ways that things can go wrong, such
as simply redirecting a clear-signed message.  The fundamental problem
is that people don't understand what is protected and what isn't in
a signed mail message.

Hal



Received: by above.proper.com (8.11.6/8.11.3) id g4KKTTh10159 for ietf-openpgp-bks; Mon, 20 May 2002 13:29:29 -0700 (PDT)
Received: from csexch.Conceptfr.net (mail.concept-agresso.com [194.250.222.1]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4KKTRL10154 for <[e-mail]>; Mon, 20 May 2002 13:29:27 -0700 (PDT)
Received: by csexch.Conceptfr.net with Internet Mail Service (5.5.2653.19) id <L27XBPPM>; Mon, 20 May 2002 22:27:03 +0200
Message-ID: <[e-mail]>
From: Terje Braaten <[e-mail]>
To: "'[e-mail]'" <[e-mail]>
Subject: secure sign & encrypt
Date: Mon, 20 May 2002 22:27:03 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by above.proper.com id g4KKTSL10155
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi

Take a look at:
http://lists.gnupg.org/pipermail/gnupg-devel/2002-May/007159.html

Have you considered what Adrian writes about here in this forum?
I think it is a very good solution to add a 'intended encryption key' or
somthing like that in the section
5.2.3.1. Signature Subpacket Specification.

-- 
Terje Bråten




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4E3rB307609 for ietf-openpgp-bks; Mon, 13 May 2002 20:53:11 -0700 (PDT)
Received: from merrymeet.com (merrymeet.com [63.73.97.162]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E3rAL07604 for <[e-mail]>; Mon, 13 May 2002 20:53:10 -0700 (PDT)
Received: from [63.73.97.181] (63.73.97.181) by merrymeet.com with ESMTP (Eudora Internet Mail Server 3.1.2); Mon, 13 May 2002 20:53:08 -0700
User-Agent: Microsoft-Entourage/10.0.0.1331
Date: Mon, 13 May 2002 20:53:09 -0700
Subject: Re: Dash-escaping clarification
From: Jon Callas <[e-mail]>
To: David Shaw <[e-mail]>, OpenPGP <[e-mail]>
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 5/13/2002 7:43 PM, "David Shaw" <[e-mail]> wrote:

> Nothing in the draft seems to discourage dash-escaping more than just
> the lines beginning with a dash.  Still, I am concerned with the
> receiving side not knowing that these other lines may be escaped as
> well (they may match on a dash-space-dash at the beginning of the
> line, rather than dash-space).  A sentence saying something like "Any
> other line MAY be dash-escaped as well at the discretion of the
> sender" would be very helpful here.

It's fine with me.

    Jon



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g4E2heP05176 for ietf-openpgp-bks; Mon, 13 May 2002 19:43:40 -0700 (PDT)
Received: from claude.kendall.akamai.com (walrus.ne.client2.attbi.com [65.96.217.88]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g4E2hdL05169 for <[e-mail]>; Mon, 13 May 2002 19:43:39 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g4E2hUH01425 for [e-mail]; Mon, 13 May 2002 22:43:30 -0400
Date: Mon, 13 May 2002 22:43:30 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Dash-escaping clarification
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waxing Crescent (3% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Hi,

Section 7.1 (Dash-Escaped Text) of 2440bis05 says, in part, that
dash-escaped text is "the ordinary cleartext where every line starting
with a dash '-' (0x2D) is prefixed by the sequence dash '-' (0x2D) and
space ' ' (0x20)."

Since the most common use of dash-escaped text is in email, both PGP
and GnuPG (by default) also dash-escape lines starting with the word
"From " (with the space).  This is for the usual mbox-inspired
reasons.  If the "From " line isn't escaped, then some downstream mail
system may escape it, thus breaking the signature.

Nothing in the draft seems to discourage dash-escaping more than just
the lines beginning with a dash.  Still, I am concerned with the
receiving side not knowing that these other lines may be escaped as
well (they may match on a dash-space-dash at the beginning of the
line, rather than dash-space).  A sentence saying something like "Any
other line MAY be dash-escaped as well at the discretion of the
sender" would be very helpful here.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: by above.proper.com (8.11.6/8.11.3) id g48F8m225499 for ietf-openpgp-bks; Wed, 8 May 2002 08:08:48 -0700 (PDT)
Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g48F8kL25494 for <[e-mail]>; Wed, 8 May 2002 08:08:47 -0700 (PDT)
Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g48F93505718; Wed, 8 May 2002 11:09:03 -0400 (EDT)
Sensitivity: 
Subject: Re: How do I do this with OpenPGP?
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Date: Wed, 8 May 2002 10:08:43 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 05/08/2002 11:08:45 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

Thanks again, Hal, the light is beining to dawn.

>> It's a somewhat complicated concept and not usually very useful outside
of relatively closed systems.

I'm working on a closed system.  What you describe is pretty much what I'm
doing.

Basically, instead of just "this is Bob" chaining down the trust, with the
assumption that everyone in that chain of trust is within the organization,
I can verify that everything in the chain back to Trent has the trust
signature packet too, meaning that this link is not just some random
employee but someone empowered to say "this is Bob".  Is that right?

So, if I understand right, Trent will put the trust signature subpacket
onto his certification of his vice-trents.  There might be several layers
here, and finally the supervisors who have face-to-face contact with
someone can sign the UserID, but can't further delegate their signing
authority.  The "level" (depth) lets me do that, and the "amount" isn't
useful for my purpose.

--John







Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47MMlf15307 for ietf-openpgp-bks; Tue, 7 May 2002 15:22:47 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47MMkL15300 for <[e-mail]>; Tue, 7 May 2002 15:22:46 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g47MDDX20087; Tue, 7 May 2002 15:13:13 -0700
Date: Tue, 7 May 2002 15:13:13 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: How do I do this with OpenPGP?
Cc: [e-mail]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

> From: John Dlugosz
>
> Thanks, Hal.
>
> Is Trent's signature on the key itself or on a UserID?
>
> It seems that either has semantic implications, but what do existing
> general-purpose tools do?  I like the latter for my application.

Normally it is on a userid.  It is binding the given name to the key,
that is, the signature is asserting its belief that the name belongs
to the key and vice versa.

> What's the relationship between the "Trust signature" key subpacket, and
> using key types 0x11-0x13?

The trust signature subpacket is used for the signer to publicly declare
that he trusts the key being signed as a signing key.  Normally a
signature just means that the signer is asserting that the name belongs
with the key, and that's what the signature types 0x11-0x13 are for.

Trust signatures are used to enable what we call "meta introducers"
which are signers who are empowered to declare that other keys have
key-signing authority.  For example, in a corporate application the chief
security officer may be declared to be a meta-introducer by the employees,
and he can then delegate signing authority to departmental officers.

It's a somewhat complicated concept and not usually very useful outside
of relatively closed systems.

Hal


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47MGSR15094 for ietf-openpgp-bks; Tue, 7 May 2002 15:16:28 -0700 (PDT)
Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47MGRL15090 for <[e-mail]>; Tue, 7 May 2002 15:16:27 -0700 (PDT)
Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g47MGkQ00409; Tue, 7 May 2002 18:16:46 -0400 (EDT)
Sensitivity: 
Subject: Re: How do I do this with OpenPGP?
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Date: Tue, 7 May 2002 17:16:26 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 05/07/2002 06:16:26 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

Thanks, Hal.

Is Trent's signature on the key itself or on a UserID?

It seems that either has semantic implications, but what do existing
general-purpose tools do?  I like the latter for my application.

What's the relationship between the "Trust signature" key subpacket, and
using key types 0x11-0x13?

--John





"Hal Finney" <[e-mail]> on 05-07-2002 04:56:25 PM

To:    [e-mail], [e-mail]
cc:
Subject:    Re: How do I do this with OpenPGP?


You should use the signature expiration time subpacket, in Trent's
signature on the key.

Hal

> From: John Dlugosz
>
> One of the nice things about OpenPGP is that multiple signatories are
> possible on a key, each "meaning" something.  Basically, it trent signs a
> key, it's OK with me for (purpose A), and the fact that Carl signed it
too
> for some other purpose is beside the point.
>
> But, I want Trent to be able to certify a key for a certain time period.
> Tag 2, type 0x10-0x13 doesn't contain a date.  I suppose there's a more
> complicated way to do this, though?  type 0x1F says "...for statements
that
> non-self certifiers want to make about the key itself" so maybe something
> in there?  Or certifing one of the (time range) subkeys instead of the
main
> key?
>
> Anyone?








Received: by above.proper.com (8.11.6/8.11.3) id g47M9me14891 for ietf-openpgp-bks; Tue, 7 May 2002 15:09:48 -0700 (PDT)
Received: from claude.kendall.akamai.com (akafire.akamai.com [65.202.32.10]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47M9jL14887 for <[e-mail]>; Tue, 7 May 2002 15:09:45 -0700 (PDT)
Received: (from dshaw@localhost) by claude.kendall.akamai.com (8.11.6/8.11.6) id g47M9gf06021 for [e-mail]; Tue, 7 May 2002 18:09:42 -0400
Date: Tue, 7 May 2002 18:09:42 -0400
From: David Shaw <[e-mail]>
To: [e-mail]
Subject: Re: How do I do this with OpenPGP?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.3.26i
X-PGP-Key: 99242560 / 7D92 FD31 3AB6 F373 4CC5 9CA1 DB69 8D71 9924 2560
X-URL: http://www.jabberwocky.com/
X-Phase-Of-Moon: The Moon is Waning Crescent (19% of Full)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On Tue, May 07, 2002 at 04:29:53PM -0500, [e-mail] wrote:
> 
> From: John Dlugosz
> 
> One of the nice things about OpenPGP is that multiple signatories are
> possible on a key, each "meaning" something.  Basically, it trent signs a
> key, it's OK with me for (purpose A), and the fact that Carl signed it too
> for some other purpose is beside the point.
> 
> But, I want Trent to be able to certify a key for a certain time period.
> Tag 2, type 0x10-0x13 doesn't contain a date.  I suppose there's a more
> complicated way to do this, though?  type 0x1F says "...for statements that
> non-self certifiers want to make about the key itself" so maybe something
> in there?  Or certifing one of the (time range) subkeys instead of the main
> key?

I think you are looking for section 5.2.3.10: Signature expiration
time.  Or if the key belongs to Trent's and he wants to make the whole
key go away after a while, then section 5.2.3.6: Key expiration time.

David

-- 
   David Shaw  |  [e-mail]  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson


Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g47M5wr14769 for ietf-openpgp-bks; Tue, 7 May 2002 15:05:58 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47M5vL14764 for <[e-mail]>; Tue, 7 May 2002 15:05:57 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g47LuPs19995; Tue, 7 May 2002 14:56:25 -0700
Date: Tue, 7 May 2002 14:56:25 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: How do I do this with OpenPGP?
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

You should use the signature expiration time subpacket, in Trent's
signature on the key.

Hal

> From: John Dlugosz
>
> One of the nice things about OpenPGP is that multiple signatories are
> possible on a key, each "meaning" something.  Basically, it trent signs a
> key, it's OK with me for (purpose A), and the fact that Carl signed it too
> for some other purpose is beside the point.
>
> But, I want Trent to be able to certify a key for a certain time period.
> Tag 2, type 0x10-0x13 doesn't contain a date.  I suppose there's a more
> complicated way to do this, though?  type 0x1F says "...for statements that
> non-self certifiers want to make about the key itself" so maybe something
> in there?  Or certifing one of the (time range) subkeys instead of the main
> key?
>
> Anyone?


Received: by above.proper.com (8.11.6/8.11.3) id g47LTs113792 for ietf-openpgp-bks; Tue, 7 May 2002 14:29:54 -0700 (PDT)
Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g47LTrL13788 for <[e-mail]>; Tue, 7 May 2002 14:29:53 -0700 (PDT)
Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g47LUDQ23480 for <[e-mail]>; Tue, 7 May 2002 17:30:13 -0400 (EDT)
Sensitivity: 
Subject: How do I do this with OpenPGP?
To: [e-mail]
From: [e-mail]
Date: Tue, 7 May 2002 16:29:53 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.10 |March 22, 2002) at 05/07/2002 05:29:53 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

One of the nice things about OpenPGP is that multiple signatories are
possible on a key, each "meaning" something.  Basically, it trent signs a
key, it's OK with me for (purpose A), and the fact that Carl signed it too
for some other purpose is beside the point.

But, I want Trent to be able to certify a key for a certain time period.
Tag 2, type 0x10-0x13 doesn't contain a date.  I suppose there's a more
complicated way to do this, though?  type 0x1F says "...for statements that
non-self certifiers want to make about the key itself" so maybe something
in there?  Or certifing one of the (time range) subkeys instead of the main
key?

Anyone?

--John




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g43GoAa14707 for ietf-openpgp-bks; Fri, 3 May 2002 09:50:10 -0700 (PDT)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Go8a14703 for <[e-mail]>; Fri, 3 May 2002 09:50:08 -0700 (PDT)
Received: (from hal@localhost) by finney.org (8.11.6/8.11.6) id g43GoK611573; Fri, 3 May 2002 09:50:20 -0700
Date: Fri, 3 May 2002 09:50:20 -0700
From: "Hal Finney" <[e-mail]>
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: common modulus attack on RSA
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

We already have a note relevant to this in section 5.1:

   Note that when an implementation forms several PKESKs with one
   session key, forming a message that can be decrypted by several keys,
   the implementation MUST make new PKCS-1 padding for each key.

This will ensure that the "m" value is different for each encryption key.
That will thwart the common modulus attack and some other possible
attacks.

Hal Finney


> From: John Dlugosz
>
> In "Applied Cryptography", page 472, Schneier warns against ever encrypting
> the same plaintext with two keys having the same n (but different e).
>
> Different public keys may indeed have a common n, either by chance, because
> of an implementation that reuses a small set of n, or a deliberate attack.
>
> The session key is encrypted to multiple public keys.
>
> Looking at section 5.1 of RFC2440, it appears that only the MPI of the
> RSA-encrypted value of m is used.  I'm supposing that m is much smaller
> than n, so the whole thing takes one "block" through RSA.
>
> The other values put into m (the algorithm and the  checksum) are the same,
> too, so m will be identical in every public-key encrypted session key
> packet.


Received: by above.proper.com (8.11.6/8.11.3) id g43FJSl12178 for ietf-openpgp-bks; Fri, 3 May 2002 08:19:28 -0700 (PDT)
Received: from pacific-carrier-annex.mit.edu (PACIFIC-CARRIER-ANNEX.MIT.EDU [18.7.21.83]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43FJPa12174 for <[e-mail]>; Fri, 3 May 2002 08:19:26 -0700 (PDT)
Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by pacific-carrier-annex.mit.edu (8.9.2/8.9.2) with ESMTP id LAA06573; Fri, 3 May 2002 11:19:27 -0400 (EDT)
Received: from manawatu-mail-centre.mit.edu (MANAWATU-MAIL-CENTRE.MIT.EDU [18.7.7.71]) by central-city-carrier-station.mit.edu (8.9.2/8.9.2) with ESMTP id LAA04745; Fri, 3 May 2002 11:19:26 -0400 (EDT)
Received: from kikki.mit.edu (KIKKI.MIT.EDU [18.18.1.142]) by manawatu-mail-centre.mit.edu (8.9.2/8.9.2) with ESMTP id LAA22276; Fri, 3 May 2002 11:19:25 -0400 (EDT)
Received: (from warlord@localhost) by kikki.mit.edu (8.9.3) id LAA07774; Fri, 3 May 2002 11:19:25 -0400 (EDT)
To: [e-mail]
Cc: [e-mail]
Subject: Re: common modulus attack on RSA
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 03 May 2002 11:19:25 -0400
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 51
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

You do realize that the liklihood of using the same 'N' is near zero.
If you and I choose the same N, that means that we can effectively
decrypt each others' messages.

Also, the 'm' being encrypted has random padding, and that random
padding should be unique per key.  In other words, 'm' _should_ be
different for each key anyways.

-derek

[e-mail] writes:

> From: John Dlugosz
> 
> In "Applied Cryptography", page 472, Schneier warns against ever encrypting
> the same plaintext with two keys having the same n (but different e).
> 
> Different public keys may indeed have a common n, either by chance, because
> of an implementation that reuses a small set of n, or a deliberate attack.
> 
> The session key is encrypted to multiple public keys.
> 
> Looking at section 5.1 of RFC2440, it appears that only the MPI of the
> RSA-encrypted value of m is used.  I'm supposing that m is much smaller
> than n, so the whole thing takes one "block" through RSA.
> 
> The other values put into m (the algorithm and the  checksum) are the same,
> too, so m will be identical in every public-key encrypted session key
> packet.
> 
> Perhaps the new draft should note that an implementation could warn about
> multiple recipients with the same n.  Remember, this could be done by
> other-than-chance, such as deliberatly introducing them as an attack.
> Better yet, I'd be happier if another number, chosen by the encryptor, were
> prepended to the session key, different for each recipient (e.g. a simple
> counter).
> 
> Is the note that a new PKCS-1 padding be made doing exactly this?  If so,
> does that add a unique value to the =end= (what I normally think of as
> padding), or does it pre-pend anything, too?  If so, is it guaranteed that
> the length of the final m is shorter than n?
> 
> --John
> 
> 

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       [e-mail]                        PGP key available


Received: by above.proper.com (8.11.6/8.11.3) id g43Ewsl11425 for ietf-openpgp-bks; Fri, 3 May 2002 07:58:54 -0700 (PDT)
Received: from kodakr.kodak.com (kodakr.kodak.com [192.232.119.69]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g43Ewra11420 for <[e-mail]>; Fri, 3 May 2002 07:58:53 -0700 (PDT)
Received: from knotes.kodak.com (knotes2.ko.kodak.com [150.221.122.53]) by kodakr.kodak.com (8.11.1/8.11.1) with ESMTP id g43ExCj07902 for <[e-mail]>; Fri, 3 May 2002 10:59:12 -0400 (EDT)
Subject: common modulus attack on RSA
To: [e-mail]
From: [e-mail]
Date: Fri, 3 May 2002 09:58:51 -0500
Message-ID: <[e-mail]>
X-MIMETrack: Serialize by Router on KNOTES2/ISBP/EKC(Release 5.0.8 |June 18, 2001) at 05/03/2002 10:58:53 AM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

From: John Dlugosz

In "Applied Cryptography", page 472, Schneier warns against ever encrypting
the same plaintext with two keys having the same n (but different e).

Different public keys may indeed have a common n, either by chance, because
of an implementation that reuses a small set of n, or a deliberate attack.

The session key is encrypted to multiple public keys.

Looking at section 5.1 of RFC2440, it appears that only the MPI of the
RSA-encrypted value of m is used.  I'm supposing that m is much smaller
than n, so the whole thing takes one "block" through RSA.

The other values put into m (the algorithm and the  checksum) are the same,
too, so m will be identical in every public-key encrypted session key
packet.

Perhaps the new draft should note that an implementation could warn about
multiple recipients with the same n.  Remember, this could be done by
other-than-chance, such as deliberatly introducing them as an attack.
Better yet, I'd be happier if another number, chosen by the encryptor, were
prepended to the session key, different for each recipient (e.g. a simple
counter).

Is the note that a new PKCS-1 padding be made doing exactly this?  If so,
does that add a unique value to the =end= (what I normally think of as
padding), or does it pre-pend anything, too?  If so, is it guaranteed that
the length of the final m is shorter than n?

--John




Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g437c6L07112 for ietf-openpgp-bks; Fri, 3 May 2002 00:38:06 -0700 (PDT)
Received: from mail.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g437c4a07105 for <[e-mail]>; Fri, 3 May 2002 00:38:04 -0700 (PDT)
Received: from dirichlet.mathematik.uni-bielefeld.de (dirichlet.Mathematik.Uni-Bielefeld.DE [129.70.24.67]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <[e-mail]> for [e-mail]; Fri,  3 May 2002 09:38:02 +0200 (MET DST)
Date: Fri, 03 May 2002 09:37:39 +0200
From: Marc Mutz <[e-mail]>
Subject: Re: Clearsigned messages and MIME
In-reply-to: <[e-mail]>
To: Florian Weimer <[e-mail]>
Cc: [e-mail]
Message-id: <[e-mail]>
Organization: KDE
MIME-version: 1.0
Content-type: Text/Plain; charset=us-ascii
Content-description: clearsigned data
Content-disposition: inline
Content-transfer-encoding: 7BIT
User-Agent: KMail/1.4.5
X-PGP-Key: 0xBDBFE838
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 02 May 2002 22:12, Florian Weimer wrote:
<snip>
> > I think most implementations will only recognize clearsigning on
> > text/plain body parts.  Probably other text subtypes, too.
>
> Already with some ISO 8859 variants, text might look light random
> binary garbage to the casual reader. ;-)

No charset I know of contains NULs. Most of them use CRLF as canonical line 
ends. That's what separates 8bit text from binary data. That even goes so far 
as to require two QP {en,de}coders for the two.

Marc

- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80j5D3oWD+L2/6DgRAlC8AKCWHRWQmqQ7tFKnkiDihVDqm5TmVwCg5Fsr
yY3q08AldnibMdWH9azuCsU=
=mk+N
-----END PGP SIGNATURE-----



Received: by above.proper.com (8.11.6/8.11.3) id g42KCn807053 for ietf-openpgp-bks; Thu, 2 May 2002 13:12:49 -0700 (PDT)
Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by above.proper.com (8.11.6/8.11.3) with SMTP id g42KCla07049 for <[e-mail]>; Thu, 2 May 2002 13:12:47 -0700 (PDT)
Received: (qmail 23491 invoked by uid 1000); 2 May 2002 20:12:13 -0000
To: Marc Mutz <[e-mail]>
Cc: [e-mail]
Subject: Re: Clearsigned messages and MIME
References: <[e-mail]> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: Thu, 02 May 2002 22:12:13 +0200
In-Reply-To: <[e-mail]> (Marc Mutz's message of "Thu, 02 May 2002 14:15:16 +0200")
Message-ID: <[e-mail]>
Lines: 33
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

Marc Mutz <[e-mail]> writes:

> On Wednesday 01 May 2002 12:35, Florian Weimer wrote:
>> How does one implement it correctly?  Add the signatures after
>> generating the actual octet stream, and then apply a suitable
>> Content-Transfer-Encoding afterwards?
>
> octet-stream? Do you want to clearsign binary data?

Sort of, yes.

> I think most implementations will only recognize clearsigning on
> text/plain body parts.  Probably other text subtypes, too.

Already with some ISO 8859 variants, text might look light random
binary garbage to the casual reader. ;-)

> For text, this is what KMail does:
> - apply charset encoding to obtain 8bit text

This results in an octet stream (in contrast to a sequence of
characters).

> - clearsign with --textmode
> - put the result into a text/lpain body part
> - apply CTE, if any.

I see.  Gnus will do the same, in the future.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          [phone]/fax [phone]


Received: by above.proper.com (8.11.6/8.11.3) id g42CFat21645 for ietf-openpgp-bks; Thu, 2 May 2002 05:15:36 -0700 (PDT)
Received: from mail.uni-bielefeld.de (IDENT:[e-mail] [129.70.4.90]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g42CFZa21640 for <[e-mail]>; Thu, 2 May 2002 05:15:35 -0700 (PDT)
Received: from dirichlet.mathematik.uni-bielefeld.de (dirichlet.Mathematik.Uni-Bielefeld.DE [129.70.24.67]) by mail.uni-bielefeld.de (Sun Internet Mail Server sims.4.0.2000.10.12.16.25.p8) with ESMTP id <[e-mail]> for [e-mail]; Thu,  2 May 2002 14:15:33 +0200 (MET DST)
Date: Thu, 02 May 2002 14:15:16 +0200
From: Marc Mutz <[e-mail]>
Subject: Re: Clearsigned messages and MIME
In-reply-to: <[e-mail]>
To: Florian Weimer <[e-mail]>, [e-mail]
Message-id: <[e-mail]>
Organization: KDE
MIME-version: 1.0
Content-type: Text/Plain; charset=us-ascii
Content-description: clearsigned data
Content-disposition: inline
Content-transfer-encoding: 7BIT
User-Agent: KMail/1.4.5
X-PGP-Key: 0xBDBFE838
References: <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wednesday 01 May 2002 12:35, Florian Weimer wrote:
> How does one implement it correctly?  Add the signatures after
> generating the actual octet stream, and then apply a suitable
> Content-Transfer-Encoding afterwards?

octet-stream? Do you want to clearsign binary data? I think most 
implementations will only recognize clearsigning on text/plain body parts. 
Probably other text subtypes, too.

For text, this is what KMail does:
- - apply charset encoding to obtain 8bit text
- - clearsign with --textmode
- - put the result into a text/lpain body part
- - apply CTE, if any.

Marc


- -- 
Marc Mutz <[e-mail]>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE80S3U3oWD+L2/6DgRAvNOAKDzlwaQaWaWvWYH3k+IUv8WrrnX5gCg6M2s
lZQoMIblAnA17QEvlukvQrM=
=ON5U
-----END PGP SIGNATURE-----



Received: from localhost (localhost [[UNIX: localhost]]) by above.proper.com (8.11.6/8.11.3) id g41FcbL17494 for ietf-openpgp-bks; Wed, 1 May 2002 08:38:37 -0700 (PDT)
Received: from mail.mediacompany.com ([e-mail] [195.247.9.20]) by above.proper.com (8.11.6/8.11.3) with ESMTP id g41FcZa17487 for <[e-mail]>; Wed, 1 May 2002 08:38:35 -0700 (PDT)
Received: from yoda.does-not-exist.org (unknown [194.162.150.21]) by mail.mediacompany.com (Postfix) with ESMTP id 39E5F4802; Wed,  1 May 2002 17:38:14 +0200 (CEST)
Received: by yoda.does-not-exist.org (Postfix, from userid 1000) id E2D632ED27; Wed,  1 May 2002 17:38:06 +0200 (CEST)
Date: Wed, 1 May 2002 17:38:06 +0200
From: Thomas Roessler <[e-mail]>
To: Florian Weimer <[e-mail]>
Cc: [e-mail]
Subject: Re: Clearsigned messages and MIME
Message-ID: <[e-mail]>
Mail-Followup-To: Florian Weimer <[e-mail]>, [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
In-Reply-To: <[e-mail]>
User-Agent: Mutt/1.5.0i
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

On 2002-05-01 12:35:56 +0200, Florian Weimer wrote:

>How does one implement it correctly?  Add the signatures after 
>generating the actual octet stream, and then apply a suitable 
>Content-Transfer-Encoding afterwards?

That's how I'd do it.

-- 
Thomas Roessler                        <[e-mail]>


Received: by above.proper.com (8.11.6/8.11.3) id g41AaON03218 for ietf-openpgp-bks; Wed, 1 May 2002 03:36:24 -0700 (PDT)
Received: from Mail.CERT.Uni-Stuttgart.DE (mail.cert.uni-stuttgart.de [129.69.16.17]) by above.proper.com (8.11.6/8.11.3) with SMTP id g41AaNa03214 for <[e-mail]>; Wed, 1 May 2002 03:36:23 -0700 (PDT)
Received: (qmail 7539 invoked by uid 1000); 1 May 2002 10:35:56 -0000
To: [e-mail]
Subject: Clearsigned messages and MIME
From: Florian Weimer <[e-mail]>
Date: Wed, 01 May 2002 12:35:56 +0200
Message-ID: <[e-mail]>
Lines: 8
User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.1 (i686-pc-linux-gnu)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-openpgp/mail-archive/>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>
List-ID: <ietf-openpgp.imc.org>

How does one implement it correctly?  Add the signatures after
generating the actual octet stream, and then apply a suitable
Content-Transfer-Encoding afterwards?

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://CERT.Uni-Stuttgart.DE/people/fw/
RUS-CERT                          [phone]/fax [phone]