Re: I-D ACTION:draft-ietf-openpgp-multsig-02.txt

[Thomas Roessler <[e-mail]>]

On 2001-01-31 07:15:31 -0500, [e-mail] wrote:

> 	Title		: Multiple Signatures using Security Multiparts
> 	Author(s)	: D. Del Torto, R. Levien, T. Roessler
> 	Filename	: draft-ietf-openpgp-multsig-02.txt
> 	Pages		: 6
> 	Date		: 30-Jan-01

This is a repost of the previous draft which was about to expire.

Since we reference this document in the PGP/MIME document, I think
we should most likely try to get both documents into RFC form at the
same time.

Are we going to face any problems with that?   John: It would be
helpful if you could comment on how we should further proceed.

-- 
Thomas Roessler			    <[e-mail]>



Received: by ns.secondary.com (8.9.3/8.9.3) id KAA17593 for ietf-openpgp-bks; Wed, 31 Jan 2001 10:28:24 -0800 (PST)
Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA17584 for <[e-mail]>; Wed, 31 Jan 2001 10:28:21 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin198.pg5-nt.frankfurt.nikoma.de [213.54.36.198]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id TAA89318; Wed, 31 Jan 2001 19:34:56 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 119802ED19; Wed, 31 Jan 2001 19:33:59 +0100 (CET)
Date: Wed, 31 Jan 2001 19:33:59 +0100
From: Thomas Roessler <[e-mail]>
To: [e-mail], John W Noerenberg II <[e-mail]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-multsig-02.txt
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], John W Noerenberg II <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.14i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Jan 31, 2001 at 07:15:31AM -0500
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 2001-01-31 07:15:31 -0500, [e-mail] wrote:

> 	Title		: Multiple Signatures using Security Multiparts
> 	Author(s)	: D. Del Torto, R. Levien, T. Roessler
> 	Filename	: draft-ietf-openpgp-multsig-02.txt
> 	Pages		: 6
> 	Date		: 30-Jan-01

This is a repost of the previous draft which was about to expire.

Since we reference this document in the PGP/MIME document, I think
we should most likely try to get both documents into RFC form at the
same time.

Are we going to face any problems with that?   John: It would be
helpful if you could comment on how we should further proceed.

-- 
Thomas Roessler			    <[e-mail]>


Received: by ns.secondary.com (8.9.3/8.9.3) id EAA18996 for ietf-openpgp-bks; Wed, 31 Jan 2001 04:08:47 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA18990 for <[e-mail]>; Wed, 31 Jan 2001 04:08:45 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09517; Wed, 31 Jan 2001 07:15:32 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-multsig-02.txt
Date: Wed, 31 Jan 2001 07:15:31 -0500
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: Multiple Signatures using Security Multiparts
	Author(s)	: D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-multsig-02.txt
	Pages		: 6
	Date		: 30-Jan-01
	
This document describes how the Security Multiparts defined in RFC
1847 [1] can be used to transport multiple digital signatures.
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the subject.  A web site containing an
archive of the list can be found at
<http://www.imc.org/ietf-openpgp>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-multsig-02.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-multsig-02.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-multsig-02.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-multsig-02.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-multsig-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id IAA03846 for ietf-openpgp-bks; Tue, 30 Jan 2001 08:33:39 -0800 (PST)
Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA03838 for <[e-mail]>; Tue, 30 Jan 2001 08:33:36 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin9.pg12-nt.frankfurt.nikoma.de [213.54.43.9]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id RAA47640; Tue, 30 Jan 2001 17:40:06 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id F09CC2ED15; Tue, 30 Jan 2001 17:09:19 +0100 (CET)
Date: Tue, 30 Jan 2001 17:09:19 +0100
From: Thomas Roessler <[e-mail]>
To: Florian Weimer <[e-mail]>
Cc: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: Florian Weimer <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Jan 25, 2001 at 11:41:37AM +0100
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 2001-01-25 11:41:37 +0100, Florian Weimer wrote:

>>   A MIME body part of this content type contains ASCII-armored
>>   Transferable Public Keys as defined in [1], section 10.1.

> Perhaps you can refer to section 6.2 as well?

I don't think that's necessary.  After all, ASCII-armor is being
referred to all over the text.

-- 
Thomas Roessler			    <[e-mail]>


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA28297 for ietf-openpgp-bks; Mon, 29 Jan 2001 15:08:47 -0800 (PST)
Received: from dfw-smtpout1.email.verio.net (dfw-smtpout1.email.verio.net [129.250.36.41]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA28179; Mon, 29 Jan 2001 15:05:04 -0800 (PST)
Received: from [129.250.38.62] (helo=dfw-mmp2.email.verio.net) by dfw-smtpout1.email.verio.net with esmtp id 14NNRG-0003wb-00; Mon, 29 Jan 2001 23:10:22 +0000
Received: from [206.133.83.14] (helo=localhost) by dfw-mmp2.email.verio.net with esmtp id 14NNPk-0002Od-00; Mon, 29 Jan 2001 23:08:48 +0000
X-Sender: [e-mail]
From: Dave <[e-mail]>
To: "customer" <[e-mail]>
Date: Mon, 29 Jan 2001 14:25:17 -0500
Subject: I could go to JAIL for selling this CD!
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_001__10618077_51917.11"
Message-Id: <[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>

This is a Multipart MIME message.

------=_NextPart_000_001__10618077_51917.11
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 7bit


------=_NextPart_000_001__10618077_51917.11
Content-Type: text/html; charset=iso-8859-1
Content-Transfer-Encoding: base64

PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9u
YWwvL2VuIj4NCjxodG1sPg0KPGhlYWQ+DQogICA8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50
LVR5cGUiIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD1pc28tODg1OS0xIj4NCiAgIDxt
ZXRhIG5hbWU9IkdFTkVSQVRPUiIgY29udGVudD0iTW96aWxsYS80LjYxIFtlbl0gKFdpbjk4
OyBJKSBbTmV0c2NhcGVdIj4NCiAgIDx0aXRsZT5UaGUgQkFOTkVEIENEITwvdGl0bGU+DQo8
L2hlYWQ+DQo8Ym9keT4NCjxmb250IHNpemU9KzE+SGksPC9mb250Pg0KPHA+PGZvbnQgc2l6
ZT0rMT5JIGhhdmUgYmVlbiByZWNpZXZpbmcgZW1haWxzIHNheWluZyB0aGF0IEknbSBjb250
cmlidXRpbmcNCnRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGhlICJtb3JhbCBkZWNh
eSBvZiBzb2NpZXR5IiBieSBzZWxsaW5nIHRoZSBCYW5uZWQgQ0QuJm5ic3A7DQpUaGF0PC9m
b250Pg0KPGJyPjxmb250IHNpemU9KzE+bWF5IGJlLCBidXQgSSBmZWVsIHN0cm9uZ2x5IHRo
YXQgeW91IGhhdmUgYSByaWdodCB0bw0KYmVuZWZpdCBmcm9tPC9mb250Pg0KPGJyPjxmb250
IHNpemU9KzE+dGhpcyBoYXJkLXRvLWZpbmQgaW5mb3JtYXRpb24uPC9mb250Pg0KPHA+PGZv
bnQgY29sb3I9IiNDQzAwMDAiPjxmb250IHNpemU9KzE+U28gSSBhbSBnaXZpbmcgeW91IE9O
RSBMQVNUIENIQU5DRQ0KdG8gb3JkZXI8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9y
PSIjQ0MwMDAwIj48Zm9udCBzaXplPSsxPnRoZSBCYW5uZWQgQ0QhPC9mb250PjwvZm9udD4N
Cjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9MCBDT0xTPTIgV0lEVEg9Ijc1JSIgPg0KPHRy
Pg0KPHRkIFdJRFRIPSIxJSI+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2lt
YWdlcy9zcHkuanBnIiBoZWlnaHQ9MTI4IHdpZHRoPTg2PjwvdGQ+DQoNCjx0ZD48Zm9udCBz
aXplPSsxPldpdGggdGhpcyBwb3dlcmZ1bCBDRCwgeW91IHdpbGwgYmUgYWJsZSB0byBpbnZl
c3RpZ2F0ZQ0KeW91ciBmcmllbmRzLCBlbmVtaWVzIGFuZCBsb3ZlcnMgaW4ganVzdCBtaW51
dGVzIHVzaW5nIHRoZSBJbnRlcm5ldC4mbmJzcDsNCllvdSBjYW4gdHJhY2sgZG93biBvbGQg
ZmxhbWVzIGZyb20gY29sbGVnZSwgb3IgeW91IGNhbiBkaWcgdXAgc29tZSBkaXJ0DQpvbiB5
b3VyIGJvc3MgdG8gbWFrZSBzdXJlIHlvdSBnZXQgdGhhdCBuZXh0IHByb21vdGlvbiE8L2Zv
bnQ+PC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD48Zm9udCBzaXplPSsxPk9yIG1heWJl
IHlvdSB3YW50IGEgZmFrZSBkaXBsb21hIHRvIGhhbmcgb24geW91ciBiZWRyb29tPC9mb250
Pg0KPGJyPjxmb250IHNpemU9KzE+d2FsbC4mbmJzcDsgWW91J2xsIGZpbmQgYWRkcmVzc2Vz
IGZvciBjb21wYW5pZXMgdGhhdA0KbWFrZSB0aGVzZTwvZm9udD4NCjxicj48Zm9udCBzaXpl
PSsxPmRpcGxvbWFzIG9uIHRoZSBCYW5uZWQgQ0QuPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0r
MT5OZWVkIHRvIGRpc2FwcGVhciBmYXN0IGFuZCBuZXZlciBsb29rIGJhY2s/Jm5ic3A7IE5v
IHByb2JsZW0hPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+VXNpbmcgdGhlIEJhbm5lZCBD
RCwgeW91IHdpbGwgbGVhcm4gaG93IHRvIGJ1aWxkIGEgY29tcGxldGVseTwvZm9udD4NCjxi
cj48Zm9udCBzaXplPSsxPm5ldyBpZGVudGl0eS48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsx
Pk9idmlvdXNseSwgdGhlIFBvd2VycyBUaGF0IEJlIGRvbid0IHdhbnQgeW91IHRvIGhhdmUg
dGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+QmFubmVkIENELiZuYnNwOyBUaGV5IGhh
dmUgdGhyZWF0ZW5lZCBtZSB3aXRoIGxhd3N1aXRzLA0KZmluZXMsPC9mb250Pg0KPGJyPjxm
b250IHNpemU9KzE+YW5kIGV2ZW4gaW1wcmlzb25tZW50IHVubGVzcyBJIHN0b3Agc2VsbGlu
ZyBpdCBpbW1lZGlhdGVseS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5CdXQgSSBmZWVs
IHRoYXQgWU9VIGhhdmUgYSBDb25zdGl0dXRpb25hbCByaWdodCB0byBhY2Nlc3M8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0rMT50aGlzIHR5cGUgb2YgaW5mb3JtYXRpb24sIGFuZCBJIGNh
bid0IGJlIGludGltaWRhdGVkLjwvZm9udD4NCjxicj4mbmJzcDsNCjx0YWJsZSBCT1JERVI9
MCBDT0xTPTIgV0lEVEg9IjUwJSIgPg0KPHRyPg0KPHRkIFdJRFRIPSIxMDAlIj48aT48Zm9u
dCBjb2xvcj0iIzMzMzNGRiI+PGZvbnQgc2l6ZT0rMT5VbmNsZSBTYW0gYW5kIHlvdXINCmNy
ZWRpdG9ycyBhcmUgaG9ycmlmaWVkIHRoYXQgSSBhbSBzdGlsbCBzZWxsaW5nIHRoaXMgcHJv
ZHVjdCEmbmJzcDsgVGhlcmUNCm11c3QgYmUgYSBwcmljZSBvbiBteSBoZWFkITwvZm9udD48
L2ZvbnQ+PC9pPjwvdGQ+DQoNCjx0ZCBXSURUSD0iMSUiPjxpbWcgU1JDPSJodHRwOi8vY29t
cHV6b25ldXNhLmNvbS9pbWFnZXMvb3V0bGF3LmpwZyIgaGVpZ2h0PTEyOCB3aWR0aD05Mz48
L3RkPg0KPC90cj4NCjwvdGFibGU+DQoNCjxwPjxmb250IHNpemU9KzE+V2h5IGFyZSB0aGV5
IHNvIHVwc2V0PyBCZWNhdXNlIHRoaXMgQ0QgZ2l2ZXMgeW91IGZyZWVkb20uPC9mb250Pg0K
PGJyPjxmb250IHNpemU9KzE+QW5kIHlvdSBjYW4ndCBidXkgZnJlZWRvbSBhdCB5b3VyIGxv
Y2FsIFdhbG1hcnQuJm5ic3A7DQpZb3Ugd2lsbDwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx
PmhhdmUgdGhlIGZyZWVkb20gdG8gYXZvaWQgY3JlZGl0b3JzLCBqdWRnbWVudHMsIGxhd3N1
aXRzLA0KSVJTPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+dGF4IGNvbGxlY3RvcnMsIGNy
aW1pbmFsIGluZGljdG1lbnRzLCB5b3VyIGdyZWVkeSBleC13aWZlDQpvcjwvZm9udD4NCjxi
cj48Zm9udCBzaXplPSsxPmV4LWh1c2JhbmQsIGFuZCBNVUNIIG1vcmUhPC9mb250Pg0KPHA+
PGZvbnQgc2l6ZT0rMT5KdXN0IGxvb2sgYXQgc29tZSBvZiB0aGUgdGhpbmdzIHlvdSBjYW4g
ZG8gd2l0aCB0aGlzIENEDQouLi48L2ZvbnQ+DQo8dWw+DQo8bGk+DQo8Yj48Zm9udCBjb2xv
cj0iIzAwMDA5OSI+U2F2ZSBodW5kcmVkcyBvciBldmVuIHRob3VzYW5kcyBvZiBkb2xsYXJz
IG9uDQp5b3VyIHRheGVzIGJ5IHVzaW5nIHRoZSBzZWNyZXQgdGF4IHRpcHMgY29udGFpbmVk
IGluIHRoaXMgcGFja2FnZS4mbmJzcDsNClRoZSBJUlMgZG9lcyBOT1Qgd2FudCB5b3UgdG8g
a25vdyB0aGVzZSBsb29waG9sZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u
dCBjb2xvcj0iIzAwMDA5OSI+VHJhY2sgZG93biBmcmllbmRzIGFuZCBvbGQgZmxhbWVzIGZy
b20gdGhlIGNvbWZvcnQNCm9mIHlvdXIgb3duIGhvbWUgd2l0aCBvdXIgSW50ZXJuZXQgaW52
ZXN0aWdhdGlvbiByZXNvdXJjZXMhPC9mb250PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9u
dCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQgd2hlcmUgeW91ciBFWCBpcyBoaWRpbmcgdGhl
aXIgbW9uZXkgdG8NCmF2b2lkIGFsaW1vbnksIGNoaWxkIHN1cHBvcnQsIG9yIGRpdm9yY2Ug
c2V0dGxlbWVudHMuIFRoZW4gZ2V0IHlvdXIgaGFuZHMNCm9uIHRoYXQgbW9uZXkuJm5ic3A7
IEJsZWVkICdlbSBkcnkhJm5ic3A7IFByaXZhdGUgaW52ZXN0aWdhdG9ycyBjaGFyZ2UNCnRo
b3VzYW5kcyBvZiBkb2xsYXJzIGZvciB0aGlzIHNlcnZpY2UsIGJ1dCB5b3UgY2FuIGRvIGl0
IHdpdGggYSBjb21wdXRlcg0KYW5kIGFuIGludGVybmV0IGNvbmVjdGlvbiB3aGVuIHlvdSBi
dXkgdGhlIEJhbm5lZCBDRCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNv
bG9yPSIjMDAwMDk5Ij5MZWFybiBob3cgdG8gdXNlIG9mZnNob3JlIG1vbmV5IGhhdmVucyBh
bmQgYXNzZXQNCnByb3RlY3Rpb24gdHJ1c3RzIHRvIGF2b2lkIGxhd3N1aXRzLCBqdWRnbWVu
dHMsIGFuZCBmb29sIHRoZSBtb3N0IGFnZ3Jlc3NpdmUNCnRheCBjb2xsZWN0b3IhJm5ic3A7
IElmIHlvdXIgbW9uZXkgaXMgc2l0dGluZyBpbiBhIFVTIGJhbmsgYWNjb3VudCwgeW91cg0K
ZnVuZHMgY2FuIGJlIGxldmllZCBvciBmcm96ZW4gY29tcGxldGVseSBhdCBhbnkgdGltZS4m
bmJzcDsgVGhlIFVTIGdvdmVybm1lbnQNCnVzZXMgImNpdmlsIGFzc2V0IGZvcmZlaXR1cmUi
IHRvIHN0ZWFsIGJpbGxpb25zIG9mIGRvbGxhcnMgZWFjaCB5ZWFyIGZyb20NCmhhcmQtd29y
a2luZywgbGF3IGFiaWRpbmcgY2l0aXplbnMuJm5ic3A7IEdldCB5b3VyIG1vbmV5IG91dCBv
ZiB0aGUgY291bnRyeQ0KYmVmb3JlIFVuY2xlIFNhbSBzbmF0Y2hlcyBpdCBhbGwuPC9mb250
PjwvYj48L2xpPg0KDQo8bGk+DQo8Yj48Zm9udCBjb2xvcj0iIzAwMDA5OSI+RmluZCBvdXQg
d2hlcmUgdG8gYnV5ICJmb3JiaWRkZW4gcHJvZHVjdHMiIG9uDQp0aGUgSW50ZXJuZXQuIEZ1
cnRoZXIgZWxhYm9yYXRpb24gc2hvdWxkIG5vdCBiZSBuZWNlc3Nhcnk7IGp1c3QgdXNlIHlv
dXINCmltYWdpbmF0aW9uLjwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29s
b3I9IiMwMDAwOTkiPkdldCBhIGJldHRlciBqb2IgYnkgcHVyY2hhc2luZyBhIGNvbGxlZ2Ug
ZGVncmVlDQooaW5jbHVkaW5nIGEgUGhkISkgZm9yIGEgdmVyeSBsb3cgZmVlLiBObyBzdHVk
eSByZXF1aXJlZCE8L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxiPjxmb250IGNvbG9yPSIj
MDAwMDk5Ij5JZiB5b3VyIEVYIGlzIGNvbWluZyBhZnRlciB5b3VyIG1vbmV5LCBzdGF5IG9u
ZQ0Kc3RlcCBhaGVhZCBvZiB0aGUgbGF3eWVycyBhbmQga2VlcCB0aGVpciBncmVlZHkgaGFu
ZHMgb2ZmIHlvdXIgbG9vdC4gRmluZA0Kb3V0IGhvdyB0byBoaWRlIHlvdXIgbW9uZXkgd2hl
cmUgaXQgd2lsbCBuZXZlciBiZSBmb3VuZC48L2ZvbnQ+PC9iPjwvbGk+DQoNCjxsaT4NCjxi
Pjxmb250IGNvbG9yPSIjMDAwMDk5Ij5Bdm9pZCBsZWdhbCBwcm9ibGVtcywganVkZ21lbnRz
LCBjb252aWN0aW9ucywNCmFuZCBldmVuIHByaXNvbiBzZW50ZW5jZXMgYnkgb2J0YWluaW5n
IGEgY29tcGxldGVseSBuZXcgaWRlbnRpdHkgYW5kIGRpc2FwcGVhcmluZw0Kd2l0aG91dCBh
IHRyYWNlITwvZm9udD48L2I+PC9saT4NCg0KPGxpPg0KPGI+PGZvbnQgY29sb3I9IiMwMDAw
OTkiPkVyYXNlIHlvdXIgY3JpbWluYWwgcmVjb3JkIGFuZCBvYnRhaW4gYSBjb3B5IG9mDQp5
b3VyIEZCSSBmaWxlIHVzaW5nIHRoZSBGcmVlZG9tIG9mIEluZm9ybWF0aW9uIEFjdC4mbmJz
cDsgRmluZCBvdXQgaWYgdGhlDQpnb3Zlcm5tZW50IGlzIGludmVzdGlnYXRpbmcgeW91IE5P
VyBiZWZvcmUgaXQncyB0b28gTEFURSE8L2ZvbnQ+PC9iPjwvbGk+DQo8L3VsPg0KPGZvbnQg
c2l6ZT0rMT5JZiB5b3UgaGF2ZSBiZWVuIHB1dHRpbmcgb2ZmIGJ1eWluZyBUaGUgQmFubmVk
IENELCB3aGF0IGFyZQ0KeW91PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+d2FpdGluZyBm
b3I/Jm5ic3A7IEJpZyBCcm90aGVyIGlzIGFscmVhZHkgYnJlYXRoaW5nIGRvd24NCm15IG5l
Y2ssIHNvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+SSBjYW4ndCBrZWVwIHNlbGxpbmcg
aXQgZm9yZXZlci4mbmJzcDsgSWYgeW91IGtlZXAgd2FpdGluZw0KdG8gcGxhY2U8L2ZvbnQ+
DQo8YnI+PGZvbnQgc2l6ZT0rMT55b3VyIG9yZGVyLCB5b3UgbWF5IG5ldmVyIGZpbmQgVGhl
IEJhbm5lZCBDRCBhZ2Fpbi4mbmJzcDsNCkZvciBvbmx5PC9mb250Pg0KPGJyPjxmb250IHNp
emU9KzE+JDE5Ljk5LCB5b3Ugd2lsbCBnYWluIHZhbHVhYmxlIHBlYWNlLW9mLW1pbmQga25v
d2luZw0KaG93IHRvPC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+c2FmZWd1YXJkIHlvdXJz
ZWxmLCB5b3VyIGZhbWlseSwgYW5kIHlvdXIgbW9uZXkuJm5ic3A7DQpXaG8gY2FuIHB1dCBh
PC9mb250Pg0KPGJyPjxmb250IHNpemU9KzE+cHJpY2Ugb24gZnJlZWRvbT8hPC9mb250Pg0K
PHA+PGk+PHU+PGZvbnQgc2l6ZT0rMT5IZXJlIGlzIGFub3RoZXIgbG9vayBhdCB0aGUgY29u
dGVudHMgb2YgdGhlIEJBTk5FRA0KQ0Q6PC9mb250PjwvdT48L2k+DQo8cD48aW1nIFNSQz0i
aHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3
aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgY29u
ZmlkZW50aWFsIGluZm8gb24gYW55b25lIGluIDMwIG1pbnV0ZXMgb3I8L2ZvbnQ+PC9mb250
Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmxlc3Mgb24gdGhl
IEludGVybmV0LiBZb3UnbGwgYmUNCmFibGUgdG8gdHJhY2sgZG93biB5b3VyPC9mb250Pjwv
Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vbGQgZmxh
bWUsIGZpbmQgb3V0IGhvdyBtdWNoIG1vbmV5DQp5b3VyIGV4IGlzIGhpZGluZzwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW4gdGhl
aXIgYmFuayBhY2NvdW50LCBvciBydW4gYQ0KYmFja2dyb3VuZCBjaGVjayBvbjwvZm9udD48
L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+cHJvZXNw
ZWN0aXZlIGNsaWVudCBvciBlbXBsb3llZS4NCkV2ZW4gZ292ZXJubWVudDwvZm9udD48L2Zv
bnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YWdlbmNpZXMg
aGF2ZSB0cm91YmxlIG9idGFpbmluZw0KbXVjaCBvZiB0aGlzIGluZm9ybWF0aW9uLjwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+WW91
IHdpbGwgaGF2ZSBhbGwgdGhlIHJlc291cmNlcw0Kb2YgYW55IHByb2Zlc3Npb25hbDwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+aW52
ZXN0aWdhdG9yIHJpZ2h0IGF0IHlvdXIgZmluZ2VydGlwcw0KLSBvbiB5b3VyIGhvbWU8L2Zv
bnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNv
bXB1dGVyITwvZm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVz
YS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xv
cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkxpc3Qgb2YgY29tcGFuaWVzIHdobyB3aWxs
IGlzc3VlIHlvdSBhIGNvbGxlZ2U8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIj
NjY2NjY2Ij48Zm9udCBzaXplPSsxPmRlZ3JlZSAoaW5jbHVkaW5nIGEgUGhkLikgZm9yIGEN
CmZlZS4gTm8gc3R1ZHkgcmVxdWlyZWQhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJo
dHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdp
ZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93
IHRvIGdldCBGUkVFIGNhYmxlIGFuZCBEU1MgY2hhbm5lbHMsPC9mb250PjwvZm9udD4NCjxi
cj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5pbmNsdWRpbmcgdGhlIGFk
dWx0IHN0YXRpb25zIGFuZA0KUGF5LVBlci1WaWV3ITwvZm9udD48L2ZvbnQ+DQo8cD48aW1n
IFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhlaWdo
dD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4NCkhv
dyB0byBPYnRhaW4gTWljcm9zb2Z0IFByb2R1Y3RzIGFic29sdXRlbHk8L2ZvbnQ+PC9mb250
Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPkZSRUUsIHRoZSBz
YWZlIGFuZCBMRUdBTCB3YXkhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8v
Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5
Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KTGlzdCBvZiBzdXBwbGll
cnMgb2YgInF1ZXN0aW9uYWJsZSIgaXRlbXMsIHN1Y2g8L2ZvbnQ+PC9mb250Pg0KPGJyPjxm
b250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmFzIGZjYyBiYW5uZWQgY29tbXVu
aWNhdGlvbnMgZGV2aWNlcywNCnNjYW5uZXJzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQg
Y29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+bmlnaHQgdmlzaW9uIGdvZ2dsZXMsIHBh
c3Nwb3J0cywNCmZha2UgaWRlbnRpZmljYXRpb24sPC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5hbmQgZXZlcnl0aGluZyBlbHNlIHRo
YXQgeW91IHdvbid0DQpmaW5kIGluIHRoZSBiYWNrPC9mb250PjwvZm9udD4NCjxicj48Zm9u
dCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5vZiBTb2xkaWVyIG9mIEZvcnR1bmUg
bWFnYXppbmUhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l
dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv
bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KRmluZCBwcm9kdWN0cyB0byByZXNlbGwg
b24gdGhlIEludGVybmV0IHdpdGggb3VyPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xv
cj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5XaG9sZXNhbGUgRGlyZWN0b3J5IGNvbnRhaW5p
bmcNCm92ZXIgMSBtaWxsaW9uPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2
NjY2NiI+PGZvbnQgc2l6ZT0rMT4odGhhdCdzIHJpZ2h0LCBvbmUgbWlsbGlvbiEpIHdob2xl
c2FsZQ0Kc291cmNlcyBmb3I8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2
NjY2Ij48Zm9udCBzaXplPSsxPmNvbXB1dGVycywgZWxlY3Ryb25pY3MsIGJlYW5pZXMsDQp0
cmVuZCBpdGVtcyw8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48
Zm9udCBzaXplPSsxPmpld2VscnksIGNhcnMsIGNvbGxlY3RpYmxlcywgYW5kDQpldmVyeXRo
aW5nIGVsc2UhPC9mb250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25l
dXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNv
bG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPg0KT3ZlciAyNSBtaWxsaW9uIGVtYWlsIGFk
ZHJlc3NlcywgZnJlc2ggYW5kPC9mb250PjwvZm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2
NjY2NiI+PGZvbnQgc2l6ZT0rMT50YXJnZXRlZCEgWW91IGNhbiB1c2UgdGhlc2UgdG8NCmNv
bnRhY3QgdGhlIHBlb3BsZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2
NjYiPjxmb250IHNpemU9KzE+YW5kIHNlbmQgdGhlbSB5b3VyIGFkdmVydGlzZW1lbnRzLjwv
Zm9udD48L2ZvbnQ+DQo8cD48aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1h
Z2VzL2J1dHRvbi5naWYiIGhlaWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2
NiI+PGZvbnQgc2l6ZT0rMT4NCkZpbmQgb3V0IGhvdyB0byBnZXQgYSBjb21wbGV0ZWx5IG5l
dyBpZGVudGl0eS48L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48
Zm9udCBzaXplPSsxPkRpc2FwcGVhciB3aXRob3V0IGEgdHJhY2UhPC9mb250PjwvZm9udD4N
CjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFnZXMvYnV0dG9uLmdp
ZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXpl
PSsxPg0KRmluZCBvdXQgaG93IHRvIEVSQVNFIGJhZCBjcmVkaXQgYW5kIGV2ZW48L2ZvbnQ+
PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPmNyZWF0
ZSBhIHdob2xlIG5ldyBmaWxlIGluIHRoZQ0KY3JlZGl0IGJ1cmVhdSBjb21wdXRlcnMuPC9m
b250PjwvZm9udD4NCjxwPjxpbWcgU1JDPSJodHRwOi8vY29tcHV6b25ldXNhLmNvbS9pbWFn
ZXMvYnV0dG9uLmdpZiIgaGVpZ2h0PTE5IHdpZHRoPTE5Pjxmb250IGNvbG9yPSIjNjY2NjY2
Ij48Zm9udCBzaXplPSsxPg0KTGVhcm4gaG93IHRvIGJlYXQgdGhlIElSUy4gVGF4IHRpcHMg
Zm9yIHRoZTwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250
IHNpemU9KzE+cmVzdCBvZiB1cy48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6
Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9
MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpDb21wbGV0ZSBndWlk
ZSBvbiBob3cgdG8gY2xhaW0gcHVibGljIGxhbmQ8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250
IGNvbG9yPSIjNjY2NjY2Ij48Zm9udCBzaXplPSsxPm9mZmVyZWQgYnkgdGhlIEdvdmVybm1l
bnQuIFlvdQ0KY2FuIGZpbmQgeW91cjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9
IiM2NjY2NjYiPjxmb250IHNpemU9KzE+ZHJlYW0gaG9tZSBmb3IgYSByaWRpY3Vsb3VzbHkg
bG93DQpwcmljZSBvciBidXk8L2ZvbnQ+PC9mb250Pg0KPGJyPjxmb250IGNvbG9yPSIjNjY2
NjY2Ij48Zm9udCBzaXplPSsxPnByb3BlcnRpZXMgdG8gcmVzZWxsIGZvciBhIGh1Z2UNCnBy
b2ZpdCE8L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2Eu
Y29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9
IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBY2NlcHQgY2hlY2tzIGZyb20geW91ciBjdXN0
b21lcnMgYnkgZmF4LDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYi
Pjxmb250IHNpemU9KzE+cGhvbmUgYW5kIGVtYWlsIHdpdGggdGhlIGZ1bGwgd29ya2luZw0K
dmVyc2lvbiBvZjwvZm9udD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxm
b250IHNpemU9KzE+Q2hlY2tlciBTb2Z0d2FyZSBpbmNsdWRlZCE8L2ZvbnQ+PC9mb250Pg0K
PHA+PGltZyBTUkM9Imh0dHA6Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lm
IiBoZWlnaHQ9MTkgd2lkdGg9MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9
KzE+DQpCdXNpbmVzcyBzb2Z0d2FyZSB0byBoZWxwIHlvdSBydW4geW91ciBzbWFsbDwvZm9u
dD48L2ZvbnQ+DQo8YnI+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+YnVz
aW5lc3MsIGluY2x1ZGluZyBsYWJlbCBtYWtlcg0Kc29mdHdhcmUsIG1vbmV5PC9mb250Pjwv
Zm9udD4NCjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5tYW5hZ2Vt
ZW50IHNvZnR3YXJlLCBJUlMgZm9yZ2l2ZW5lc3MNCnByb2dyYW0sPC9mb250PjwvZm9udD4N
Cjxicj48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT5kYXRhYmFzZSBzb2Z0
d2FyZSwgYW5kIG11Y2ggbW9yZS48L2ZvbnQ+PC9mb250Pg0KPHA+PGltZyBTUkM9Imh0dHA6
Ly9jb21wdXpvbmV1c2EuY29tL2ltYWdlcy9idXR0b24uZ2lmIiBoZWlnaHQ9MTkgd2lkdGg9
MTk+PGZvbnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+DQpBIGh1Z2UgY29sbGVj
dGlvbiBvZiBzY3JlZW5zYXZlcnMsIGdyYXBoaWNzLDwvZm9udD48L2ZvbnQ+DQo8YnI+PGZv
bnQgY29sb3I9IiM2NjY2NjYiPjxmb250IHNpemU9KzE+Y2xpcGFydCwgYW5kIGRlc2t0b3Ag
dGhlbWVzIHRvDQpzcGljZSB1cCB5b3VyIGNvbXB1dGVyLjwvZm9udD48L2ZvbnQ+DQo8cD48
aW1nIFNSQz0iaHR0cDovL2NvbXB1em9uZXVzYS5jb20vaW1hZ2VzL2J1dHRvbi5naWYiIGhl
aWdodD0xOSB3aWR0aD0xOT48Zm9udCBjb2xvcj0iIzY2NjY2NiI+PGZvbnQgc2l6ZT0rMT4N
Ck1VQ0gsIE1VQ0ggTU9SRSB0aGF0IHdlIGRvbid0IGhhdmUgcm9vbSB0byBsaXN0ITwvZm9u
dD48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPSsxPldlIGFyZSBzbyBjb25maWRlbnQgdGhhdCB5
b3Ugd2lsbCBsb3ZlIHRoaXMgQ0QgdGhhdCB3ZTwvZm9udD4NCjxicj48Zm9udCBzaXplPSsx
Pm9mZmVyIGEgZnVsbCAzMC1kYXksIG5vIHF1ZXN0aW9ucyBhc2tlZCBtb25leS1iYWNrPC9m
b250Pg0KPGJyPjxmb250IHNpemU9KzE+Z3VhcmFudGVlLiBUbyBvcmRlciB0aGUgIkJhbm5l
ZCBDRCIgcmlnaHQgbm93IGZvciB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5zdXBl
ciBsb3cgcHJpY2Ugb2Ygb25seSAkMTkuOTksIGp1c3QgY2xpY2sgb24gdGhlIGxpbms8L2Zv
bnQ+DQo8YnI+PGZvbnQgc2l6ZT0rMT5iZWxvdyB0byBwYXkgd2l0aCBhIFZpc2Egb3IgTWFz
dGVyY2FyZDo8L2ZvbnQ+DQo8YnI+Jm5ic3A7DQo8dGFibGUgQk9SREVSPTAgQ09MUz0yIFdJ
RFRIPSI1MCUiID4NCjx0cj4NCjx0ZD48Zm9udCBzaXplPSsyPjxhIGhyZWY9Imh0dHA6Ly93
d3cuY29tcHV6b25ldXNhLmNvbS9jY3BheW1lbnQvYmFubmVkY2Q3Mi5odG0iPk9yZGVyDQpO
b3chPC9hPjwvZm9udD48L3RkPg0KDQo8dGQ+DQo8Y2VudGVyPjxpbWcgU1JDPSJodHRwOi8v
Y29tcHV6b25ldXNhLmNvbS9pbWFnZXMvZ3VhcmFudGVlLmdpZiIgaGVpZ2h0PTk2IHdpZHRo
PTk1PjwvY2VudGVyPg0KPC90ZD4NCjwvdHI+DQo8L3RhYmxlPg0KDQo8cD5PciB5b3UgbWF5
IHBheSB3aXRoIGNhc2gsIGNoZWNrIG9yIG1vbmV5IG9yZGVyIGJ5IHByaW50aW5nIHRoZSBv
cmRlcg0KPGJyPmZvcm0gYmVsb3cgYW5kIHNlbmRpbmcgaXQgd2l0aCB5b3VyIHBheW1lbnQu
DQo8cD48Yj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIENVVCBIRVJFIC0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tPC9iPg0KPHA+UHJvZHVjdDogIlRoZSBCYW5uZWQgQ0QiDQo8YnI+UHJp
Y2U6ICQxOS45OSArICQ0LjAxIHNoaXBwaW5nL2hhbmRsaW5nDQo8cD5IT1cgVE8gT1JERVIg
QlkgTUFJTDogUHJpbnQgb3V0IHRoaXMgb3JkZXIgZm9ybSBhbmQgc2VuZCBjYXNoLA0KPGJy
PnBlcnNvbmFsIGNoZWNrLCBtb25leSBvcmRlciBvciBjYXNoaWVyJ3MgY2hlY2sgdG8gdGhl
IGFkZHJlc3MgbGlzdGVkDQpiZWxvdzoNCjxwPlF1aWtzaWx2ZXIgRW50ZXJwcmlzZXMgSW5j
Lg0KPGJyPjM3OTIgQnJvYWR3YXkgIzM5OA0KPGJyPk5ldyBZb3JrLCBOWSAxMDAzMg0KPHA+
WW91ciBTaGlwcGluZyBJbmZvcm1hdGlvbjoNCjxwPllvdXIgTmFtZV9fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQWRkcmVzc19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPllvdXIgQ2l0eV9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJyPlN0YXRl
IC8gWmlwX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPGJy
PlBob25lICM6IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xw0KPGJyPihGb3IgcHJvYmxlbXMgd2l0aCB5b3VyIG9yZGVyIG9ubHkuIE5vIHNhbGVzbWVu
IHdpbGwgY2FsbC4pDQo8cD5FbWFpbCBBZGRyZXNzX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXw0KPHA+UGxlYXNlIG5vdGUgdGhhdCBtYWlsLWluIG9yZGVycyBt
YXkgYmUgZGVsYXllZCAyLTQgd2Vla3MuDQo8cD5bIF0gSSBhbSBlbmNsb3NpbmcgYSBjaGVj
ayBvciBtb25leSBvcmRlciBmb3IgJDI0LjAwDQo8cD5bIF0gSSBhbSBtYWlsaW5nIG15IGNy
ZWRpdCBjYXJkIG51bWJlci4gKE5vdGUgeW91ciBjYXJkIHdpbGwgYmUgY2hhcmdlZA0KZm9y
ICQyNC4wMCkNCjxwPklmIHBheWluZyBieSBjcmVkaXQgY2FyZCwgcGxlYXNlIGZpbGwgaW4g
dGhlIGluZm9ybWF0aW9uIGJlbG93Og0KPHA+Q3JlZGl0IENhcmQgTnVtYmVyOl9fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQo8YnI+RXhwaXJhdGlvbiBEYXRlOl9fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KPGJyPlNpZ25hdHVyZTpfX19fX19fX19fX19fX19fX19f
X19fX19fDQo8YnI+RGF0ZTpfX19fX19fX19fX19fX19fX19fXw0KPHA+Tk9URTogVGhpcyBD
RCBpcyBmb3IgaW5mb3JtYXRpb25hbCwgZWR1Y2F0aW9uYWwsIG9yDQo8YnI+ZW50ZXJ0YWlu
bWVudCBwdXJwb3NlcyBvbmx5LiZuYnNwOyBTb21lIG9mIHRoZSBhY3Rpdml0aWVzDQo8YnI+
ZGVzY3JpYmVkIG9uIHRoaXMgQ0QgbWF5IGJlIGlsbGVnYWwgaWYgY2FycmllZCBvdXQuDQo8
YnI+VGhpcyBDRCBjb250YWlucyBsaW5rcyBhbmQgYWRkcmVzc2VzIG9mIGNvbXBhbmllcw0K
PGJyPmFuZCBpbmRpdmlkdWFscyB3aGljaCBwcm9kdWNlIHZhcmlvdXMgcHJvZHVjdHMsIG9y
DQo8YnI+b2ZmZXIgdmFyaW91cyBzZXJ2aWNlcywgd2hpY2ggbWF5IGJlIGlsbGVnYWwgaW4g
eW91cg0KPGJyPmNvdW50cnksIHN0YXRlLCBvciBjaXR5LiZuYnNwOyBIb3dldmVyLCBpdCBp
cyBwZXJmZWN0bHkNCjxicj5MRUdBTCB0byBwdXJjaGFzZSBhbmQgcG9zc2VzcyB0aGUgQmFu
bmVkIENEIGluIHRoZQ0KPGJyPlVuaXRlZCBTdGF0ZXMgb2YgQW1lcmljYS4mbmJzcDsgQ29u
dGFpbnMgYXBwcm94aW1hdGVseQ0KPGJyPjEwMCBtZWdzIG9mIGluZm9ybWF0aW9uLg0KPHA+
U2hpcHBpbmcgb3V0c2lkZSBVU0EgYWRkICQxMC4wMA0KPHA+KioqKioqKioqKioqKioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioNCjxicj5Zb3UgYXJl
IHJlY2lldmluZyBhbiB1bnNvbGljaXRlZCBjb21tZXJjaWFsIGVtYWlsIGZyb20NCjxicj5R
dWlrc2lsdmVyIEVudGVycHJpc2VzIEluYy4mbmJzcDsgV2UgcmVjb2duaXplIHRoYXQgeW91
IG1heQ0KPGJyPm5vdCB3aXNoIHRvIHJlY2lldmUgc3VjaCBlbWFpbHMgaW4gdGhlIGZ1dHVy
ZSwgYW5kIHdlDQo8YnI+aGF2ZSBwcm92aWRlZCBhIGxpbmsgdG8gYXV0b21hdGljYWxseSBh
bmQgaW5zdGFudGx5DQo8YnI+cmVtb3ZlIHlvdXJzZWxmOiA8YSBocmVmPSJodHRwOi8vd3d3
LmNvbXB1em9uZXVzYS5jb20vcmVtb3ZlLmh0bSI+UkVNT1ZFPC9hPg0KPGJyPlRoaXMgbWVz
c2FnZSBpcyBiZWluZyBzZW50IHRvIHlvdSBpbiBjb21wbGlhbmNlIHdpdGgNCjxicj5mZWRl
cmFsIGd1aWRlbGluZXMgZ292ZXJuaW5nIHRoZSB0cmFuc21pc3Npb24gb2YNCjxicj51bnNv
bGljaXRlZCBjb21tZXJjaWFsIGVtYWlsLCBpbmNsdWRpbmcgdGhlIHByb3Zpc2lvbiBvZg0K
PGJyPmNvbnRhY3QgaW5mb3JtYXRpb24gZm9yIG91ciBjb21wYW55IHdpdGhpbiB0aGlzIGVt
YWlsLCBhDQo8YnI+dmFsaWQgcmV0dXJuIGVtYWlsIGFkZHJlc3MsIGFuZCBhIHdheSBmb3Ig
Y3VzdG9tZXJzDQo8YnI+dG8gcmVtb3ZlIHRoZW1zZWx2ZXMuJm5ic3A7IFBsZWFzZSBub3Rl
LCBob3dldmVyLCB0aGF0IG91cg0KPGJyPmVtYWlsIGFkZHJlc3Mgd2FzIHZhbGlkIGF0IHRo
ZSB0aW1lIG9mIHNlbmRpbmcsIGJ1dCBtYXkNCjxicj5iZSBjYW5jZWxsZWQgYnkgdGhlIElT
UCBzaG9ydGx5IHRoZXJlYWZ0ZXIgZHVlIHRvIG91cg0KPGJyPnVzZSBvZiB1bnNvbGljaXRl
ZCBlbWFpbC4mbmJzcDsgWW91IGNhbiByZWFkIGFib3V0IHRoZSB2YXJpb3VzDQo8YnI+bGF3
cyBnb3Zlcm5pbmcgdW5zb2xpY2l0ZWQgZW1haWw6IGh0dHA6Ly9zcGFtbGF3cy5jb20NCjxi
cj4iVW5zb2xpY2l0ZWQgY29tbWVyY2lhbCBlbGVjdHJvbmljIG1haWwgY2FuIGJlIGFuIGlt
cG9ydGFudA0KPGJyPm1lY2hhbmlzbSB0aHJvdWdoIHdoaWNoIGJ1c2luZXNzZXMgYWR2ZXJ0
aXNlIGFuZCBhdHRyYWN0DQo8YnI+Y3VzdG9tZXJzIGluIHRoZSBvbmxpbmUgZW52aXJvbm1l
bnQuIiZuYnNwOyAtLSBVLlMuIENvbmdyZXNzLA0KPGJyPkguUi4gMTA2dGggQ09OR1JFU1Mg
MmQgU2Vzc2lvbiBILiBSLiAzMTEzIFNlYy4gMiAoYSkzIEp1bHkNCjxicj4xOSwgMjAwMCBo
dHRwOi8vd3d3LnNwYW1sYXdzLmNvbS9mZWRlcmFsL2hyMzExMy5odG1sDQo8YnI+KioqKioq
KioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioqKioN
Cjxicj4mbmJzcDsNCjxicj4mbmJzcDsNCjwvYm9keT4NCjwvaHRtbD4NCg==

------=_NextPart_000_001__10618077_51917.11--



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA04617 for ietf-openpgp-bks; Fri, 26 Jan 2001 03:37:30 -0800 (PST)
Received: from ietf.org (odin.ietf.org [132.151.1.176]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA04613 for <[e-mail]>; Fri, 26 Jan 2001 03:37:28 -0800 (PST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04068; Fri, 26 Jan 2001 06:43:50 -0500 (EST)
Message-Id: <[e-mail]>
Mime-Version: 1.0
Content-Type: Multipart/Mixed; Boundary="NextPart"
To: IETF-Announce: ;
Cc: [e-mail]
From: [e-mail]
Reply-to: [e-mail]
Subject: I-D ACTION:draft-ietf-openpgp-mime-03.txt
Date: Fri, 26 Jan 2001 06:43:50 -0500
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>

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the An Open Specification for Pretty Good Privacy Working Group of the IETF.

	Title		: MIME Security with OpenPGP
	Author(s)	: M. Elkins, D. Del Torto, R. Levien, T. Roessler
	Filename	: draft-ietf-openpgp-mime-03.txt
	Pages		: 12
	Date		: 25-Jan-01
	
This document describes how the OpenPGP Message Format [1] can be
used to provide privacy and authentication using the Multipurpose
Internet Mail Extensions (MIME) security content types described in
RFC1847 [2].
This draft is being discussed on the 'ietf-openpgp' mailing list.  To
join the list, send a message to <[e-mail]> with
the single word 'subscribe' in the subject.  An archive of the
working group's list is located at <http://www.imc.org/ietf-openpgp>.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-openpgp-mime-03.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-openpgp-mime-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-mime-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.
		
		
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[e-mail]"

Content-Type: text/plain
Content-ID:	<[e-mail]>

ENCODING mime
FILE /internet-drafts/draft-ietf-openpgp-mime-03.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-openpgp-mime-03.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[e-mail]>

--OtherAccess--

--NextPart--




Received: by ns.secondary.com (8.9.3/8.9.3) id DAA03477 for ietf-openpgp-bks; Fri, 26 Jan 2001 03:25:54 -0800 (PST)
Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA03465 for <[e-mail]>; Fri, 26 Jan 2001 03:25:52 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin123.pg10-nt.frankfurt.nikoma.de [213.54.41.123]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id MAA14019; Fri, 26 Jan 2001 12:32:08 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 079612ED15; Fri, 26 Jan 2001 11:57:15 +0100 (CET)
Date: Fri, 26 Jan 2001 11:57:14 +0100
From: Thomas Roessler <[e-mail]>
To: Kazu Yamamoto <[e-mail]>, [e-mail]
Subject: Re: some requests
Message-ID: <[e-mail]>
Mail-Followup-To: Kazu Yamamoto <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Jan 26, 2001 at 11:38:15AM +0100
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>

Here's the latest text:

  Note: If any line begins with the string "From", it is strongly
  suggested that either the Quoted-Printable or Base64 MIME encoding
  be applied.  If Quoted-Printable is used, at least one of the
  characters in the string should be encoded using the hexadecimal
  coding rule.  This is because many mail transfer and delivery
  agents treat "From " (the word "from" followed immediately by a
  space character) as the start of a new message and thus insert a
  right angle-bracket (>) in front of any line beginning with "From"
  to distinguish this case, invalidating the signature.

-- 
Thomas Roessler			    <[e-mail]>


Received: by ns.secondary.com (8.9.3/8.9.3) id CAA26326 for ietf-openpgp-bks; Fri, 26 Jan 2001 02:34:04 -0800 (PST)
Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA26321 for <[e-mail]>; Fri, 26 Jan 2001 02:34:02 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin7.pg7-nt.frankfurt.nikoma.de [213.54.38.7]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id LAA77952; Fri, 26 Jan 2001 11:40:01 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id E2E0A2ED15; Fri, 26 Jan 2001 11:38:15 +0100 (CET)
Date: Fri, 26 Jan 2001 11:38:15 +0100
From: Thomas Roessler <[e-mail]>
To: Kazu Yamamoto <[e-mail]>
Cc: [e-mail]
Subject: Re: some requests
Message-ID: <[e-mail]>
Mail-Followup-To: Kazu Yamamoto <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <[e-mail]>; from [e-mail] on Fri, Jan 26, 2001 at 04:19:12PM +0900
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 2001-01-26 16:19:12 +0900, Kazu Yamamoto wrote:

> > +     Note: If any line begins with the string "From", it is strongly
> > +     recommended that Quoted-Printable encoding be applied and that at
> > +     least one of the characters in the string is encoded using the
> > +     hexadecimal coding rule.  This is because many mail transfer
> > +     agents treat "From " (the word "from" followed immediately by a
> > +     space character) as the start of a new message and thus insert a
> > +     right angle-bracket (>) in front of any line beginning with "From"
> > +     to distinguish this case, invalidating the signature.

> This language is strongly recommending QP to any character sets
> including ISO-2022-*, for which QP is not suitable.

It should be clear from the context that this note does not
recommend quoted-printable when you are using base64 anyways.

> And I believe the redundant encoding above should be a user choice,
> should not be required by the spec.

Now, guess why this is in a Note section, and not in the body of the
text.  But we can even replace "strongly recommended" by
"suggested".

(And no, this won't be in draft-03 which I submitted yesterday.)

-- 
Thomas Roessler			    <[e-mail]>


Received: by ns.secondary.com (8.9.3/8.9.3) id XAA27139 for ietf-openpgp-bks; Thu, 25 Jan 2001 23:12:11 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA27130 for <[e-mail]>; Thu, 25 Jan 2001 23:12:09 -0800 (PST)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id QAA08751 for <[e-mail]>; Fri, 26 Jan 2001 16:18:30 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA22595 for <[e-mail]>; Fri, 26 Jan 2001 16:18:30 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id QAA29193 for <[e-mail]>; Fri, 26 Jan 2001 16:18:30 +0900 (JST)
Date: Fri, 26 Jan 2001 16:19:12 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: some requests
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.95b100 on Emacs 20.7 / Mule 4.1 (AOI)
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>

Thomas,

From: Thomas Roessler <[e-mail]>
Subject: Re: some requests

> (1) iso-2022-{jp,kr} is a character encoding which can be
>     represented in 7bit data,

Yes.

> (2) base64 is the encoding best applied when MIME encodings are used
>     at all, and

99.999% e-mail communication in Japan is done without any MIME
encoding.  If Japanese HAVE TO chose one of two MIME encodings, 
we chose base64, not quoted-printable.

> (3) this will make messages unreadable to most mail user agents used
>     in Asia.

Not most. Some.

> I suppose that your preferred solution would be to mandate
> binary-mode signatures, so there is no need to give extra protection
> to trailing whitespace.  However, specifying this would mean that
> most current implementations don't conform to the spec, unless I'm
> severely mistaken.  Florian?

I considered about the binary signature.

- Since RFC 2015 doesn't say about the text/binary signatures, both
  signatures are valid.

- Some implementations (including Mew) are using the binary signatures
  actually.

- Some PGP/MIME implementations on UNIX (and/or Mac?) can't verify the
  binary signatures since they reply on PGP to canonicalize
  line-delimiters.

- But some of them (including exmh if I remember correctly) have
  already fixed this problem.

- I guess that PGP/MIME implementations on Windows don't suffer from
  this problem since its line delimiter is CRLF.

- OpenPGP changed the semantics of the PGP text signature. So, we
  should clarify the binary/text signature stuff.

> +     Note: If any line begins with the string "From", it is strongly
> +     recommended that Quoted-Printable encoding be applied and that at
> +     least one of the characters in the string is encoded using the
> +     hexadecimal coding rule.  This is because many mail transfer
> +     agents treat "From " (the word "from" followed immediately by a
> +     space character) as the start of a new message and thus insert a
> +     right angle-bracket (>) in front of any line beginning with "From"
> +     to distinguish this case, invalidating the signature.

This is worse than the original. Note that ISO-2022-* text can contain
lines which start with "From " since ISO-2022-* is a switching
mechanism for multiple character tables including US-ASCII.

This language is strongly recommending QP to any character sets
including ISO-2022-*, for which QP is not suitable.

And I believe the redundant encoding above should be a user choice,
should not be required by the spec.

--Kazu


Received: by ns.secondary.com (8.9.3/8.9.3) id GAA01203 for ietf-openpgp-bks; Thu, 25 Jan 2001 06:42:30 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id GAA01199 for <[e-mail]>; Thu, 25 Jan 2001 06:42:28 -0800 (PST)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id XAA18540; Thu, 25 Jan 2001 23:48:41 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id XAA18409; Thu, 25 Jan 2001 23:48:41 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id XAA19965; Thu, 25 Jan 2001 23:48:40 +0900 (JST)
Date: Thu, 25 Jan 2001 23:49:21 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mew version 1.95b100 on Emacs 20.7 / Mule 4.1 (AOI)
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>

From: Werner Koch <[e-mail]>
Subject: Re: Finalizing OpenPGP/MIME?

> I think it is good style to create data in a correct fashion but be
> liberal in what to accept.

Yes, of course. However, this is a signature service. I can't tell
whether such inconsistency is modification by a bad guy or just
composer's hard coding.

--Kazu


Received: by ns.secondary.com (8.9.3/8.9.3) id FAA28063 for ietf-openpgp-bks; Thu, 25 Jan 2001 05:53:25 -0800 (PST)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id FAA28057 for <[e-mail]>; Thu, 25 Jan 2001 05:53:23 -0800 (PST)
Received: from (alberti.gnupg.de) [192.168.123.3]  by kasiski.gnupg.de with esmtp (Exim 3.16 #1 (Debian)) id 14Ln4n-0003YT-00; Thu, 25 Jan 2001 15:08:37 +0100
Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14LmzF-0007Qt-00; Thu, 25 Jan 2001 15:02:53 +0100
Date: Thu, 25 Jan 2001 15:02:53 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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, Jan 25, 2001 at 10:00:34PM +0900
X-PGP-KeyID: 621CC013
X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D  CD75 5DE2 4996 5B03D 58A2
X-Request-PGP: finger:[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>

On Thu, 25 Jan 2001, Kazu Yamamoto wrote:

> > But it's not in the CVS HEAD branch, and I checked only that. ;-)
> 
> At least, GNUPG 1.04 provides this feature. My UA relies on it.

HEAD is the development branche and a lot of things did change.  I
known that I have to merge in the new stuff from STABLE-BRANCH-1-0.

  Werner
  

-- 
Werner Koch                                              <[e-mail]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]


Received: by ns.secondary.com (8.9.3/8.9.3) id EAA22962 for ietf-openpgp-bks; Thu, 25 Jan 2001 04:53:46 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22950 for <[e-mail]>; Thu, 25 Jan 2001 04:53:45 -0800 (PST)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id VAA15525; Thu, 25 Jan 2001 21:59:54 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA02623; Thu, 25 Jan 2001 21:59:53 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA25025; Thu, 25 Jan 2001 21:59:53 +0900 (JST)
Date: Thu, 25 Jan 2001 22:00:34 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mew version 1.95b100 on Emacs 20.7 / Mule 4.1 (AOI)
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>

From: Florian Weimer <[e-mail]>
Subject: Re: Finalizing OpenPGP/MIME?

> But it's not in the CVS HEAD branch, and I checked only that. ;-)

At least, GNUPG 1.04 provides this feature. My UA relies on it.

--Kazu


Received: by ns.secondary.com (8.9.3/8.9.3) id EAA22829 for ietf-openpgp-bks; Thu, 25 Jan 2001 04:50:01 -0800 (PST)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22824 for <[e-mail]>; Thu, 25 Jan 2001 04:49:59 -0800 (PST)
Received: from (alberti.gnupg.de) [192.168.123.3]  by kasiski.gnupg.de with esmtp (Exim 3.16 #1 (Debian)) id 14Lm5R-0003Th-00; Thu, 25 Jan 2001 14:05:13 +0100
Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14Llzw-0007Ou-00; Thu, 25 Jan 2001 13:59:32 +0100
Date: Thu, 25 Jan 2001 13:59:32 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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, Jan 25, 2001 at 09:25:06PM +0900
X-PGP-KeyID: 621CC013
X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D  CD75 5DE2 4996 5B03D 58A2
X-Request-PGP: finger:[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>

On Thu, 25 Jan 2001, Kazu Yamamoto wrote:

> This is a point. This means that the micalg parameter is meaningless.
> I wonder why we should make an effort to set a correct value to such a
> meaningless value?

I think it is good style to create data in a correct fashion but be
liberal in what to accept.

> Or if you are suggesting just to set a bogus value to the micalg
> parameter because it is meaningless, why don't you support the idea of
> wildcard value?

I won't object against a wildcard or a new value "unknown"

  Werner
  

-- 
Werner Koch                                              <[e-mail]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]


Received: by ns.secondary.com (8.9.3/8.9.3) id EAA22516 for ietf-openpgp-bks; Thu, 25 Jan 2001 04:30:55 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22512 for <[e-mail]>; Thu, 25 Jan 2001 04:30:53 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14LlX2-0002Ez-00 for [e-mail]; Thu, 25 Jan 2001 13:29:40 +0100
To: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 25 Jan 2001 13:29:40 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 19
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>

Werner Koch <[e-mail]> writes:

> On Thu, 25 Jan 2001, Florian Weimer wrote:
> 
> > necessary data to the calling MUA while creating the signature.  (Of
> > course, you can extract it using 'gpg --list-packet', and in fact I
> 
> The 
> 
>     SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
>     
> status output is available since June ;-)

But it's not in the CVS HEAD branch, and I checked only that. ;-)

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by ns.secondary.com (8.9.3/8.9.3) id EAA22126 for ietf-openpgp-bks; Thu, 25 Jan 2001 04:18:15 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA22122 for <[e-mail]>; Thu, 25 Jan 2001 04:18:13 -0800 (PST)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id VAA14617; Thu, 25 Jan 2001 21:24:26 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA27275; Thu, 25 Jan 2001 21:24:25 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA16884; Thu, 25 Jan 2001 21:24:25 +0900 (JST)
Date: Thu, 25 Jan 2001 21:25:06 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mew version 1.95b100 on Emacs 20.7 / Mule 4.1 (AOI)
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>

Werner,

From: Werner Koch <[e-mail]>
Subject: Re: Finalizing OpenPGP/MIME?

> What they should do is to parse the beginning of the message.  Well,
> okay than it is not anymore simple to implemnt it, becuase you need
> a base64 decoder and some OpenPGP packet parsing code.

I know it is easy for you to implement a PGP parser. :-) Also, it is
not so difficult for me to do it. ;-)

Actually, I implemented a parser called "pgpdump". 
	ftp://pgp.iijlab.net/pub/tools/

# gpg --list-packet was not enough for me to visualize PGP packets.

Nonetheless, it is not so easy for many PGP/MIME programmers to embed
such PGP parser functionality to their MIME UAs.

> For PGP I would just ignore that parameter; don't know about S/MIME.

This is a point. This means that the micalg parameter is meaningless.
I wonder why we should make an effort to set a correct value to such a
meaningless value?

Or if you are suggesting just to set a bogus value to the micalg
parameter because it is meaningless, why don't you support the idea of
wildcard value?

P.S.

The micalg parameter and the protocol parameter bites me always.

--Kazu


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA20315 for ietf-openpgp-bks; Thu, 25 Jan 2001 03:42:53 -0800 (PST)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA20311 for <[e-mail]>; Thu, 25 Jan 2001 03:42:51 -0800 (PST)
Received: from (alberti.gnupg.de) [192.168.123.3]  by kasiski.gnupg.de with esmtp (Exim 3.16 #1 (Debian)) id 14Ll2S-0003QV-00; Thu, 25 Jan 2001 12:58:04 +0100
Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14Lkwy-0007Ms-00; Thu, 25 Jan 2001 12:52:24 +0100
Date: Thu, 25 Jan 2001 12:52:24 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[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, Jan 25, 2001 at 11:57:38AM +0100
X-PGP-KeyID: 621CC013
X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D  CD75 5DE2 4996 5B03D 58A2
X-Request-PGP: finger:[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>

On Thu, 25 Jan 2001, Florian Weimer wrote:

> necessary data to the calling MUA while creating the signature.  (Of
> course, you can extract it using 'gpg --list-packet', and in fact I

The 

    SIG_CREATED <type> <pubkey algo> <hash algo> <class> <timestamp> <key fpr>
    
status output is available since June ;-)


-- 
Werner Koch                                              <[e-mail]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id DAA19673 for ietf-openpgp-bks; Thu, 25 Jan 2001 03:30:02 -0800 (PST)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA19662 for <[e-mail]>; Thu, 25 Jan 2001 03:30:00 -0800 (PST)
Received: from (alberti.gnupg.de) [192.168.123.3]  by kasiski.gnupg.de with esmtp (Exim 3.16 #1 (Debian)) id 14Lkq1-0003Ot-00; Thu, 25 Jan 2001 12:45:13 +0100
Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14LkkX-0007MJ-00; Thu, 25 Jan 2001 12:39:33 +0100
Date: Thu, 25 Jan 2001 12:39:33 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[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, Jan 25, 2001 at 08:12:05PM +0900
X-PGP-KeyID: 621CC013
X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D  CD75 5DE2 4996 5B03D 58A2
X-Request-PGP: finger:[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>

On Thu, 25 Jan 2001, Kazu Yamamoto wrote:

> Unfortunately, to my best knowledge, other PGP implementations don't
> have such a feature. So, many PGP/MIME UAs tend to either

What they should do is to parse the beginning of the message.  Well,
okay than it is not anymore simple to implemnt it, becuase you need
a base64 decoder and some OpenPGP packet parsing code.

> And I would like to know how should Multipart/Security UAs treat a
> received Multipart/Security message if the micalg parameter is
> inconsistent with the hash function actually used.

For PGP I would just ignore that parameter; don't know about S/MIME.

  Werner
  

-- 
Werner Koch                                              <[e-mail]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA14256 for ietf-openpgp-bks; Thu, 25 Jan 2001 03:05:51 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA14252 for <[e-mail]>; Thu, 25 Jan 2001 03:05:50 -0800 (PST)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id UAA12706; Thu, 25 Jan 2001 20:11:26 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA15871; Thu, 25 Jan 2001 20:11:25 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id UAA29702; Thu, 25 Jan 2001 20:11:24 +0900 (JST)
Date: Thu, 25 Jan 2001 20:12:05 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mew version 1.95b99 on Emacs 20.7 / Mule 4.1 (AOI)
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>

Werner, 

From: Werner Koch <[e-mail]>
Subject: Re: Finalizing OpenPGP/MIME?

> However, it is pretty easy to set micalg to the correct value, given
> that

This is incorrect.

> a) it should nearly always be SHA1 today

Yes, but not 100%. It is difficult for PGP/MIME UAs, which don't know
PGP format, to set a CORRECT value to the micalg parameter in all
cases.

This is why I asked you to add the feature to GNUPG, that tells hash
function types to UAs so that the UAs can set them to the micalg
parameter. (Thank you for your implementation.)

Unfortunately, to my best knowledge, other PGP implementations don't
have such a feature. So, many PGP/MIME UAs tend to either
1) set a fix value (pgp-sha1 for example) to the micalg parameter
or
2) reply on PGP/MIME functionality of the PGP implementations.

I know this is not a PGP/MIME issue but a Multipart/Security issue.

And I would like to know how should Multipart/Security UAs treat a
received Multipart/Security message if the micalg parameter is
inconsistent with the hash function actually used.

--Kazu


Received: by ns.secondary.com (8.9.3/8.9.3) id CAA14161 for ietf-openpgp-bks; Thu, 25 Jan 2001 02:58:56 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14156 for <[e-mail]>; Thu, 25 Jan 2001 02:58:54 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14LjqT-0001zG-00; Thu, 25 Jan 2001 11:41:37 +0100
To: [e-mail]
Cc: Thomas Roessler <[e-mail]>
Subject: Re: Finalizing OpenPGP/MIME?
References: <[e-mail]> <[e-mail]> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 25 Jan 2001 11:41:37 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 31
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>

Thomas Roessler <[e-mail]> writes:

> > [W] The signature on the example message is invalid.
> 
> Mhhhh.  Do these signatures really have to verify? ,-)

I think the examples should be complete and instructive.  Therefore,
the signatures should be valid.

> > [S] Neither OpenPGP nor OpenPGP/MIME specify the transfer format
> >     of public key blocks, so this section doesn't make much
> >     sense.
> 
> They don't sepcify the storage format, but section 10.1 of RFC 2440
> describes transferable public keys.

Oh, I missed it.  Thanks.

> It could, however, be argued that the OpenPGP/MIME document should
> be a bit more specific about what is expected in
> applications/pgp-keys.  Maybe like this?
> 
>   A MIME body part of this content type contains ASCII-armored
>   Transferable Public Keys as defined in [1], section 10.1.

Perhaps you can refer to section 6.2 as well?

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by ns.secondary.com (8.9.3/8.9.3) id CAA14160 for ietf-openpgp-bks; Thu, 25 Jan 2001 02:58:56 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA14152 for <[e-mail]>; Thu, 25 Jan 2001 02:58:53 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14Lk5y-00020u-00 for [e-mail]; Thu, 25 Jan 2001 11:57:38 +0100
To: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 25 Jan 2001 11:57:38 +0100
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>

Werner Koch <[e-mail]> writes:

[Implications of a wildcard micalg parameter]

> > I don't think we should break one of the basic design goals of MIME.
> 
> Agreed.

I wouldn't suggest that if I had not observed that the parameter isn't
set correctly by many users.

> However, it is pretty easy to set micalg to the correct value, given
> that a) it should nearly always be SHA1 today,

Okay, that's certainly a point.  But there will always be a certain
percentage of PGP 2.6.x users (and according to some rumors, most
people who seriously use OpenPGP technology are in this category).
Maybe it's time for MD5 to finally die by the hands of the
cryptanalysts. ;-)

> b) that I know no mail implementaion which creates a signed message
> without first storing the entire message

The problem isn't that it's technically impossible to generate this
header.  Most OpenPGP implementations simply do not provide the
necessary data to the calling MUA while creating the signature.  (Of
course, you can extract it using 'gpg --list-packet', and in fact I
plan to add this to Gnus some day, but this seems to be rather
hackish.)

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by ns.secondary.com (8.9.3/8.9.3) id CAA10819 for ietf-openpgp-bks; Thu, 25 Jan 2001 02:10:03 -0800 (PST)
Received: from kasiski.gnupg.de (porta.u64.de [194.77.88.106]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA10807 for <[e-mail]>; Thu, 25 Jan 2001 02:09:59 -0800 (PST)
Received: from (alberti.gnupg.de) [192.168.123.3]  by kasiski.gnupg.de with esmtp (Exim 3.16 #1 (Debian)) id 14LjaT-0003Im-00; Thu, 25 Jan 2001 11:25:05 +0100
Received: from wk by alberti.gnupg.de with local (Exim 3.12 #1 (Debian)) id 14LjV0-0007JM-00; Thu, 25 Jan 2001 11:19:26 +0100
Date: Thu, 25 Jan 2001 11:19:26 +0100
From: Werner Koch <[e-mail]>
To: [e-mail]
Cc: Florian Weimer <[e-mail]>
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], Florian Weimer <[e-mail]>
References: <[e-mail]> <[e-mail]> <[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, Jan 25, 2001 at 10:26:12AM +0100
X-PGP-KeyID: 621CC013
X-PGP-CertKey: A4D9 4E92 B098 6AB5 EE9D  CD75 5DE2 4996 5B03D 58A2
X-Request-PGP: finger:[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>

On Thu, 25 Jan 2001, Thomas Roessler wrote:

> > [S] Include wildcard value for "micalg" parameter.  (Makes generating
> >     OpenPGP/MIME messages much easier in some situations, but breaks
> >     one-pass processing, of course.  Today, the majority of
> >     OpenPGP/MIME installations/implementations doesn't deal correctly
> >     with this parameter anyway.)
> 
> I don't think we should break one of the basic design goals of MIME.

Agreed.  For historical reasons, micalg was always md5 and nobody
cared about it because it does not make sense. 

However, it is pretty easy to set micalg to the correct value, given
that a) it should nearly always be SHA1 today, b) that I know no
mail implementaion which creates a signed message without first
storing the entire message (and it does not make sense to create a
multi hundred megabyte signed email becuase the majority of MUAs
will not be able to handle them unless they have a huge swap space
and are alloed to use these amounts of memory) and c) that many MTAs
do limit the maximum size of a message for good reasons.

   Werner
   

-- 
Werner Koch                                              <[e-mail]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA06076 for ietf-openpgp-bks; Thu, 25 Jan 2001 01:30:25 -0800 (PST)
Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06065 for <[e-mail]>; Thu, 25 Jan 2001 01:30:24 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin108.pg7-nt.frankfurt.nikoma.de [213.54.38.108]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id KAA33500; Thu, 25 Jan 2001 10:36:13 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 92B4A2ED2A; Thu, 25 Jan 2001 10:01:45 +0100 (CET)
Date: Thu, 25 Jan 2001 10:01:45 +0100
From: Thomas Roessler <[e-mail]>
To: Kazu Yamamoto <[e-mail]>
Cc: [e-mail], [e-mail], Florian Weimer <[e-mail]>
Subject: Re: some requests
Message-ID: <[e-mail]>
Mail-Followup-To: Kazu Yamamoto <[e-mail]>, [e-mail], [e-mail], Florian Weimer <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
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>

Kazu,

> Just in case you misunderstand my opination. I'm not objecting to 7bit
> restriction of Multipart/Security at this time. (Yes, I don't like it
> but the point is not that.) 

> I'm asking not to recommend (ie SHOULD) MIME encoding for "7bit"
> character set. ISO-2022-{JP,KR} is 7bit (not 8bit) and almost all user
> use it as raw (i.e. without base64) in daily life even with MIME UAs.

I'm trying to understand your point, but still have difficulties.
You are basically arguing that

(1) iso-2022-{jp,kr} is a character encoding which can be
    represented in 7bit data,
(2) base64 is the encoding best applied when MIME encodings are used
    at all, and
(3) this will make messages unreadable to most mail user agents used
    in Asia.

Is this correct?

I suppose that your preferred solution would be to mandate
binary-mode signatures, so there is no need to give extra protection
to trailing whitespace.  However, specifying this would mean that
most current implementations don't conform to the spec, unless I'm
severely mistaken.  Florian?

Anyway, we do of course have these two options:

- Break working implementations by mandating binary mode signatures.
- Break MUAs which aren't MIME-aware by requiring the application of
  MIME encodings when they aren't necessary from a pure MIME point
  of view.

What do people think about this?


While we are on it, I think we should restore the section from draft
-01 concerning "From " lines, and move it, so that section 3 would
look like this now (changed line tagged with "!", added lines tagged
with "+"):

------------------------------

3.  Content-Transfer-Encoding restrictions

   Multipart/signed and multipart/encrypted are to be treated by agents
   as opaque, meaning that the data is not to be altered in any way [2],
   [7]. However, many existing mail gateways will detect if the next hop
   does not support MIME or 8-bit data and perform conversion to either
   Quoted-Printable or Base64.  This presents serious problems for
   multipart/signed, in particular, where the signature is invalidated
   when such an operation occurs.  For this reason all data signed
   according to this protocol MUST be constrained to 7 bits (8-bit data
   MUST be encoded using either Quoted-Printable or Base64).  Note that
   this also includes the case where a signed object is also encrypted
   (see section 6).  This restriction will increase the likelihood that
   the signature will be valid upon receipt.

!  Additionally, if body parts to be signed contain trailing whitespace,
   implementations SHOULD use either Quoted-Printable or Base64 to
   protect these body parts against corruption by transport or delivery
   agents.  Applying this rule also ensures that trailing whitespace in
   the data encoded cannot be modified without invalidating the
   signature.  Applications SHOULD ensure that no trailing whitespace is
   present after the MIME encoding has been applied.

      Note: Trailing white space does not alter the actual contents of a
      Quoted-Printable or Base64 encoded body part, or the meaning of
      MIME headers. However, the presence of trailing white space may
      trigger a compatibility problem which was introduced in [1]: With
      traditional implementations of PGP, trailing whitespace was
      included with signatures of canonical text documents.  [1] changes
      this behaviour in an incompatible way, by specifying that trailing
      white space is ignored in signatures of canonical text documents.

+     Note: If any line begins with the string "From", it is strongly
+     recommended that Quoted-Printable encoding be applied and that at
+     least one of the characters in the string is encoded using the
+     hexadecimal coding rule.  This is because many mail transfer
+     agents treat "From " (the word "from" followed immediately by a
+     space character) as the start of a new message and thus insert a
+     right angle-bracket (>) in front of any line beginning with "From"
+     to distinguish this case, invalidating the signature.

   Data that is ONLY to be encrypted is allowed to contain 8-bit
   characters and therefore need not be converted to a 7-bit format.

      Implementor's note: It cannot be stressed enough that applications
      using this standard follow MIME's suggestion that you "be
      conservative in what you generate, and liberal in what you
      accept."  In this particular case it means it would be wise for an
      implementation to accept messages with any content-transfer-
      encoding, but restrict generation to the 7-bit format required by
      this memo.  This will allow future compatibility in the event the
      Internet SMTP framework becomes 8-bit friendly.

------------------------------

Cheers,

-- 
Thomas Roessler			    <[e-mail]>


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id BAA06030 for ietf-openpgp-bks; Thu, 25 Jan 2001 01:30:15 -0800 (PST)
Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id BAA06017 for <[e-mail]>; Thu, 25 Jan 2001 01:30:12 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin108.pg7-nt.frankfurt.nikoma.de [213.54.38.108]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id KAA33508; Thu, 25 Jan 2001 10:36:20 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 3D8A32ED2B; Thu, 25 Jan 2001 10:26:12 +0100 (CET)
Date: Thu, 25 Jan 2001 10:26:12 +0100
From: Thomas Roessler <[e-mail]>
To: Florian Weimer <[e-mail]>
Cc: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: Florian Weimer <[e-mail]>, [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <[e-mail]>; from [e-mail] on Thu, Jan 18, 2001 at 01:57:15PM +0100
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 2001-01-18 13:57:15 +0100, Florian Weimer wrote:
> [T] Replace 'RFC 1847' with 'RFC 1847'. (Consistency)

ok.

> [T] Replace 'multipart ASCII armor OpenPGP format' with
>     'multi-part ASCII armor OpenPGP format' (cf. OpenPGP)

ok.

> [S] Make MIME multipart mechanism in favor of OpenPGP multi-part messages
>     REQUIRED.  (It is hard to imagine how OpenPGP multi-part messages can
>     interoperate with other implementations.)

I don't think this REQUIRED actually is required.

> [S] Include wildcard value for "micalg" parameter.  (Makes generating
>     OpenPGP/MIME messages much easier in some situations, but breaks
>     one-pass processing, of course.  Today, the majority of
>     OpenPGP/MIME installations/implementations doesn't deal correctly
>     with this parameter anyway.)

I don't think we should break one of the basic design goals of MIME.

> Still Section 5, enumeration (2):
> 
> [T] Spell 'recommended' in capital letters.

Now in section 3, and I don't think we should make it a
capital-letters recommended.

> [W] Replace 'mail transfer agents' with 'mail delivery agents' (or
>     both).  In general, only MDAs touch messages in this way, not MTAs.

"mail transfer and delivery agents"

> Still Section 5, example message:
> 
> [W] The signature on the example message doesn't seem to be valid (?).
>     BITNET is dead.

Consider this part of the example as a historical courtesy.

> Section 6.1:

> [W] The signature on the example message is invalid.

Mhhhh.  Do these signatures really have to verify? ,-)

> [S] Neither OpenPGP nor OpenPGP/MIME specify the transfer format
>     of public key blocks, so this section doesn't make much
>     sense.

They don't sepcify the storage format, but section 10.1 of RFC 2440
describes transferable public keys.  It could, however, be argued
that the OpenPGP/MIME document should be a bit more specific about
what is expected in applications/pgp-keys.  Maybe like this?

  A MIME body part of this content type contains ASCII-armored
  Transferable Public Keys as defined in [1], section 10.1.


> [T] Replace 'OP' with 'OpenPGP'.

Thanks.

I suppose it's getting time for a new draft.  I'll submit one to
internet-drafts, and not consider it final. *sigh*

-- 
Thomas Roessler			    <[e-mail]>


Received: by ns.secondary.com (8.9.3/8.9.3) id MAA15891 for ietf-openpgp-bks; Wed, 24 Jan 2001 12:48:50 -0800 (PST)
Received: from freeby.ben.algroup.co.uk (sockittome.aldigital.co.uk [194.128.162.252]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id MAA15886 for <[e-mail]>; Wed, 24 Jan 2001 12:48:45 -0800 (PST)
Received: from algroup.co.uk (wiese.ben.algroup.co.uk [193.133.15.150]) by freeby.ben.algroup.co.uk (8.6.12/8.6.12) with ESMTP id UAA10985 for <[e-mail]>; Wed, 24 Jan 2001 20:54:57 GMT
Message-ID: <[e-mail]>
Date: Wed, 24 Jan 2001 20:54:33 +0000
From: Ben Laurie <[e-mail]>
X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U)
X-Accept-Language: en
MIME-Version: 1.0
To: OpenPGP WG <[e-mail]>
Subject: Forward Secrecy Extentions for OpenPGP
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 20 September 2000 the IESG requested that this WG consider whether
the I-D "Forward Secrecy Extensions for OpenPGP" should be a Standards
Track rather than an Informational document. Considerable time has
passed without much comment or consensus, so we ask the WG to submit its
views to this mailing list by Wednesday February 7th 2001, 17:00 GMT. We
will collate these and pass them on to the IESG.

The document can be found at:
http://www.ietf.org/internet-drafts/draft-brown-pgp-pfs-01.txt.

Cheers,

Ben Laurie
Ian Brown

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

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


Received: by ns.secondary.com (8.9.3/8.9.3) id WAA26981 for ietf-openpgp-bks; Tue, 23 Jan 2001 22:38:23 -0800 (PST)
Received: from ns.find.co.jp (IDENT:[e-mail] [202.234.13.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA26977 for <[e-mail]>; Tue, 23 Jan 2001 22:38:21 -0800 (PST)
Received: from ms06 (pc110.japanem.co.jp [210.161.101.110]) by ns.find.co.jp (8.9.3/3.7Wpl2/FIND.00) with SMTP id PAA12530 for <[e-mail]>; Wed, 24 Jan 2001 15:44:31 +0900
Date: Wed, 24 Jan 2001 15:44:32 +0900
From: saku <[e-mail]>
Subject: Re: Finalizing OpenPGP/MIME?
To: [e-mail]
X-PGP-PubKey: http://www.find.co.jp/%7Esaku/SakuPupKey.asc
X-PGP-FP: ABDE C7B9 F635 592A C9F4  AD13 020A 6654 9C89 1697
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Datula version 1.51.08.01 for Windows
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>

Hi everyone.

[From] Kazu Yamamoto <[e-mail]>
[Date] Mon, 22 Jan 2001 14:33:12 +0900 (JST)
[Subject] Re: Finalizing OpenPGP/MIME?
[Message-id] <[e-mail]>
> Let me confirm. Can this problem be solved if we use the binary
> signature?

I think that it is the best way.
However, UA using traditional PGP easily cannot make text mode 
signatur.

I think that it should be as follows.

====
  SHOUD sign by binary mode signatue.

  Note:
   When using traditional PGP, UAs MAY sign by text mode   
   signature after MIME transfer encoding (Base64, Quated-printable,
   etc).  But, that UA is called `weak agent in OpenPGP/MIME'.
====

# sorry. <[e-mail]> is CT:ISO-2022-JP

-- 
saku (SAKUDA Yasunori)
 PGP-KeyID: 0x9C891697 (DH/DSS)
 PGP-FP: ABDE C7B9 F635 592A C9F4  AD13 020A 6654 9C89 1697


Received: by ns.secondary.com (8.9.3/8.9.3) id VAA24596 for ietf-openpgp-bks; Tue, 23 Jan 2001 21:48:38 -0800 (PST)
Received: from ns.find.co.jp (IDENT:[e-mail] [202.234.13.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA24591 for <[e-mail]>; Tue, 23 Jan 2001 21:48:36 -0800 (PST)
Received: from ms06 (pc110.japanem.co.jp [210.161.101.110]) by ns.find.co.jp (8.9.3/3.7Wpl2/FIND.00) with SMTP id OAA12301 for <[e-mail]>; Wed, 24 Jan 2001 14:54:46 +0900
Date: Wed, 24 Jan 2001 14:54:46 +0900
From: saku <[e-mail]>
Subject: Re: Finalizing OpenPGP/MIME?
To: [e-mail]
X-PGP-PubKey: http://www.find.co.jp/%7Esaku/SakuPupKey.asc
X-PGP-FP: ABDE C7B9 F635 592A C9F4  AD13 020A 6654 9C89 1697
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Datula version 1.51.08.01 for Windows
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-2022-JP
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 everyone.

[From] Kazu Yamamoto ($B;3K\OBI'(B) <[e-mail]>
[Date] Mon, 22 Jan 2001 14:33:12 +0900 (JST)
[Subject] Re: Finalizing OpenPGP/MIME?
[Message-id] <[e-mail]>
> Let me confirm. Can this problem be solved if we use the binary
> signature?

I think that it is the best way.
However, UA using traditional PGP easily cannot make text mode 
signatur.

I think that it should be as follows.

====
  SHOUD sign by binary mode signatue.

  Note:
   When using traditional PGP, UAs MAY sign by text mode   
   signature after MIME transfer encoding (Base64, Quated-printable,
   etc).  But, that UA is called `weak agent in OpenPGP/MIME'.
====

-- 
saku (SAKUDA Yasunori)
 PGP-KeyID: 0x9C891697 (DH/DSS)
 PGP-FP: ABDE C7B9 F635 592A C9F4  AD13 020A 6654 9C89 1697


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id TAA20572 for ietf-openpgp-bks; Tue, 23 Jan 2001 19:15:17 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id TAA20567 for <[e-mail]>; Tue, 23 Jan 2001 19:15:15 -0800 (PST)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id MAA24727; Wed, 24 Jan 2001 12:21:19 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA03353; Wed, 24 Jan 2001 12:21:18 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id MAA22902; Wed, 24 Jan 2001 12:21:18 +0900 (JST)
Date: Wed, 24 Jan 2001 12:21:57 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail]
Subject: Re: some requests
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Mailer: Mew version 1.95b99 on Emacs 20.7 / Mule 4.1 (AOI)
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>

Derek,

Just in case you misunderstand my opination. I'm not objecting to 7bit
restriction of Multipart/Security at this time. (Yes, I don't like it
but the point is not that.) 

I'm asking not to recommend (ie SHOULD) MIME encoding for "7bit"
character set. ISO-2022-{JP,KR} is 7bit (not 8bit) and almost all user
use it as raw (i.e. without base64) in daily life even with MIME UAs.

From: Derek Atkins <[e-mail]>
Subject: Re: some requests

> > There are still many non-MIME UA users. 
> 
> Yea, but we're defining a MIME type.  We can't be defining MIME types
> for people who don't use MIME.  For example, the sender doesn't know
> that the recipient does not understand MIME, and if they did they
> shouldn't be sending MIME in the first place.  Sure, we can TRY to be
> as compatible with non-MIME-mailers as we can, but I don't believe
> that we should bend over backwards just to make it easier for them,
> when quite frankly those non-MIME users wont be able to read many MIME
> messages in the first place.

Multipart/Security is designed to maintain both to non-MIME UAs and
MIME-aware-but-Multipart/Security-unaware UAs. Both users can at least
read the first. Yes, it requires 7bit restriction. 

But why should we use base64 to 7bit character set?

> > BTW, do you know any region where base64 is actually used for
> > text/plain? If we use base64, readability becomes drastically poor.
> 
> Yes.  I've been receiving messages from someone in, I believe, Korea
> (I don't have the mail in front of me, but I seem to recall it was a
> .kr address) who has been sending me English text/plain using base-64
> encoding.

I guess this is a bug. Not represents typical UAs in Korea.

> > For example, Chinese people uses GB-2321 character set, which is 8bit
> > and base64 is suitable if required. However, they tend to send GB-2321
> > text with CTE: 8bit (without base64) for readability. (Most SMTP
> > channels in Asia are 8bit clean.)
> 
> I'm currently of the mind that we should not require base-64 encoding,
> but we should encourage base64 encoding.  Basically if you, as a
> sender, know that you have an 8-bit clear channel to your recipient
> you should be allowed to send an 8-bit message.  However, if you are
> not sure you have an 8-bit channel then you should base-64 encode your
> message.  I just wish there were an easy way to determine ahead of
> time if there is an 8-bit clean channel.

Maybe my explanation is wrong. GB-2321 is an example that how base64
is unfriendly to the real world in Asia. Of course, base64 is required
for GB-2321 when a signature is calculated.

Encourage base64 encoding for any and all character sets seems to me a
bad idea. A right way is to encourage people to deply 8bit clean SMTP
channels.

--Kazu


Received: by ns.secondary.com (8.9.3/8.9.3) id LAA09634 for ietf-openpgp-bks; Tue, 23 Jan 2001 11:52:10 -0800 (PST)
Received: from rcn.ihtfp.org ([e-mail] [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA09630 for <[e-mail]>; Tue, 23 Jan 2001 11:52:08 -0800 (PST)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id OAA19012; Tue, 23 Jan 2001 14:58:12 -0500
To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
Cc: [e-mail]
Subject: Re: some requests
References: <[e-mail]> 	<[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 23 Jan 2001 14:58:11 -0500
In-Reply-To: Kazu Yamamoto's message of "Tue, 23 Jan 2001 15:33:40 +0900 (JST)"
Message-ID: <[e-mail]>
Lines: 48
X-Mailer: Gnus v5.5/Emacs 20.3
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>

Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]> writes:

> There are still many non-MIME UA users. 

Yea, but we're defining a MIME type.  We can't be defining MIME types
for people who don't use MIME.  For example, the sender doesn't know
that the recipient does not understand MIME, and if they did they
shouldn't be sending MIME in the first place.  Sure, we can TRY to be
as compatible with non-MIME-mailers as we can, but I don't believe
that we should bend over backwards just to make it easier for them,
when quite frankly those non-MIME users wont be able to read many MIME
messages in the first place.

> BTW, do you know any region where base64 is actually used for
> text/plain? If we use base64, readability becomes drastically poor.

Yes.  I've been receiving messages from someone in, I believe, Korea
(I don't have the mail in front of me, but I seem to recall it was a
.kr address) who has been sending me English text/plain using base-64
encoding.  Quite annoying, I must say.  But it's still being done.
Why?  I don't know.  What if I couldn't read it?  The sender probably
has no choice in the matter.  Is their mailer non-conformant?  I don't
know.  But honestly, if they tried to sign their base-64 message, then
what?  Well, if I couldn't read MIME, I couldn't read their original
message anyways, so what does it matter?

> For example, Chinese people uses GB-2321 character set, which is 8bit
> and base64 is suitable if required. However, they tend to send GB-2321
> text with CTE: 8bit (without base64) for readability. (Most SMTP
> channels in Asia are 8bit clean.)

I'm currently of the mind that we should not require base-64 encoding,
but we should encourage base64 encoding.  Basically if you, as a
sender, know that you have an 8-bit clear channel to your recipient
you should be allowed to send an 8-bit message.  However, if you are
not sure you have an 8-bit channel then you should base-64 encode your
message.  I just wish there were an easy way to determine ahead of
time if there is an 8-bit clean channel.

> --Kazu

-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 ns.secondary.com (8.9.3/8.9.3) id WAA26744 for ietf-openpgp-bks; Mon, 22 Jan 2001 22:27:01 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id WAA26740 for <[e-mail]>; Mon, 22 Jan 2001 22:26:59 -0800 (PST)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id PAA27400 for <[e-mail]>; Tue, 23 Jan 2001 15:33:04 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA22030 for <[e-mail]>; Tue, 23 Jan 2001 15:33:03 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id PAA02702 for <[e-mail]>; Tue, 23 Jan 2001 15:33:03 +0900 (JST)
Date: Tue, 23 Jan 2001 15:33:40 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: Re: some requests
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]>
X-Mailer: Mew version 1.95b99 on Emacs 20.7 / Mule 4.1 (AOI)
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>

Derek, 

Thank you for your reply.

From: Derek Atkins <[e-mail]>
Subject: Re: some requests

> It's a SHOULD: you can be perfectly compliant and NOT implement it.
> That's the point.  A SHOULD is a strong recommendation to do something
> that way, but it is not required to be implemented in order to be
> compliant.  Indeed, it's a directive to an implementor for how to
> solve the problem in an interoperable way.

This explanation sounds that it is an optional. According to RFC 2119,
options should be specified as "MAY".

RFC 2119 also says that the full implications must be understood the
SHOULD functionality. So, for instance, if any Open/PGP UAs for
"qmail", which don't have the "From " problem, don't implement this
encoding stuff, we can't call them fully-conformant.

> PS: How does applying a CTE break interoperability?  Any MIME-aware
> client MUST implement CTE anyways, so it should decode the base64 well
> before it gets up to the user.

There are still many non-MIME UA users. 

BTW, do you know any region where base64 is actually used for
text/plain? If we use base64, readability becomes drastically poor.

For example, Chinese people uses GB-2321 character set, which is 8bit
and base64 is suitable if required. However, they tend to send GB-2321
text with CTE: 8bit (without base64) for readability. (Most SMTP
channels in Asia are 8bit clean.)

--Kazu


Received: by ns.secondary.com (8.9.3/8.9.3) id KAA07145 for ietf-openpgp-bks; Mon, 22 Jan 2001 10:49:03 -0800 (PST)
Received: from rcn.ihtfp.org ([e-mail] [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA07140 for <[e-mail]>; Mon, 22 Jan 2001 10:49:01 -0800 (PST)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id NAA05280; Mon, 22 Jan 2001 13:54:23 -0500
To: Michael Elkins <[e-mail]>
Cc: Kazu Yamamoto <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 22 Jan 2001 13:54:23 -0500
In-Reply-To: Michael Elkins's message of "Mon, 22 Jan 2001 09:34:54 -0800"
Message-ID: <[e-mail]>
Lines: 22
X-Mailer: Gnus v5.5/Emacs 20.3
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>

In text-mode signatures, PGP will auto-canonicalize line-endings,
including removing any trailing white-space, whereas with binary the
canonicalization is not done and trailing white-space is included in
the signature.

-derek

Michael Elkins <[e-mail]> writes:

> Can someone remind me what the difference between text mode and binary mode
> signatures is?  We're always going to need to muck with the line endings, no
> way around that.  But I don't see how that precludes one-pass processing if
> your client is smart enough to canonicalize each line of text and pass it in
> a pipe (or stream) to the OpenPGP engine.
> 
> me

-- 
       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 ns.secondary.com (8.9.3/8.9.3) id KAA04733 for ietf-openpgp-bks; Mon, 22 Jan 2001 10:09:33 -0800 (PST)
Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id KAA04728 for <[e-mail]>; Mon, 22 Jan 2001 10:09:31 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin189.pg12-nt.frankfurt.nikoma.de [213.54.43.189]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id TAA42447; Mon, 22 Jan 2001 19:13:40 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 620E22ED15; Mon, 22 Jan 2001 19:13:22 +0100 (CET)
Date: Mon, 22 Jan 2001 19:13:22 +0100
From: Thomas Roessler <[e-mail]>
To: Michael Elkins <[e-mail]>
Cc: Kazu Yamamoto <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: Michael Elkins <[e-mail]>, Kazu Yamamoto <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Jan 22, 2001 at 09:34:54AM -0800
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 2001-01-22 09:34:54 -0800, Michael Elkins wrote:

> Can someone remind me what the difference between text mode and
> binary mode signatures is?  We're always going to need to muck
> with the line endings, no way around that.  But I don't see how
> that precludes one-pass processing if your client is smart enough
> to canonicalize each line of text and pass it in a pipe (or
> stream) to the OpenPGP engine.

With traditional PGP, text mode just meant that you canonicalized
the line ends.  That is, RFC 2015 had one-pass abilities by
mandating canonicalization.

With OpenPGP, text mode means stripping trailing white space, and
then canonicalizing line ends.  So you'll have to compute two hashes
when going over the message.

(OpenPGP's concept of text mode is basically what traditional PGP
used for clearsigning.)

-- 
Thomas Roessler			    <[e-mail]>


Received: by ns.secondary.com (8.9.3/8.9.3) id JAA01806 for ietf-openpgp-bks; Mon, 22 Jan 2001 09:24:21 -0800 (PST)
Received: from toesinperil.com (IDENT:[e-mail] [216.207.184.47]) by ns.secondary.com (8.9.3/8.9.3) with SMTP id JAA01798 for <[e-mail]>; Mon, 22 Jan 2001 09:24:20 -0800 (PST)
Received: (qmail 5280 invoked by uid 501); 22 Jan 2001 17:34:54 -0000
Date: Mon, 22 Jan 2001 09:34:54 -0800
From: Michael Elkins <[e-mail]>
To: Kazu Yamamoto <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.10i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Jan 22, 2001 at 12:13:08PM +0100
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 Mon, Jan 22, 2001 at 12:13:08PM +0100, Thomas Roessler wrote:
> If everyone would just be using binary signatures, the problem
> wouldn't occur, right.  Bad enough, most current implementations
> seem to rely on text-mode signatures.
> 
> Also, using the new text-mode signatures with the restrictions in
> the draft actually has the nice side-effect of moving PGP/MIME
> closer to one of the features found throughout MIME: Resistance
> against tampering with trailing whitespace.  It's not really helpful
> if changes which don't affect the message's contents are detected by
> PGP/MIME.
> 
> (But, of course, if most people here feel that binary mode should be
> used, we could still change the text.)

Can someone remind me what the difference between text mode and binary mode
signatures is?  We're always going to need to muck with the line endings, no
way around that.  But I don't see how that precludes one-pass processing if
your client is smart enough to canonicalize each line of text and pass it in
a pipe (or stream) to the OpenPGP engine.

me


Received: by ns.secondary.com (8.9.3/8.9.3) id IAA28932 for ietf-openpgp-bks; Mon, 22 Jan 2001 08:52:37 -0800 (PST)
Received: from rcn.ihtfp.org ([e-mail] [204.107.200.33]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA28928 for <[e-mail]>; Mon, 22 Jan 2001 08:52:35 -0800 (PST)
Received: (from warlord@localhost) by rcn.ihtfp.org (8.9.3) id LAA05155; Mon, 22 Jan 2001 11:58:18 -0500
To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
Cc: [e-mail]
Subject: Re: some requests
References: <[e-mail]>
From: Derek Atkins <[e-mail]>
Date: 22 Jan 2001 11:58:18 -0500
In-Reply-To: Kazu Yamamoto's message of "Mon, 22 Jan 2001 21:42:45 +0900 (JST)"
Message-ID: <[e-mail]>
Lines: 50
X-Mailer: Gnus v5.5/Emacs 20.3
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>

Kazu,

It's a SHOULD: you can be perfectly compliant and NOT implement it.
That's the point.  A SHOULD is a strong recommendation to do something
that way, but it is not required to be implemented in order to be
compliant.  Indeed, it's a directive to an implementor for how to
solve the problem in an interoperable way.

Just because it's not the right solution for a couple of environments
only means that those environments SHOULD ignore the SHOULD :)

-derek

PS: How does applying a CTE break interoperability?  Any MIME-aware
client MUST implement CTE anyways, so it should decode the base64 well
before it gets up to the user.

Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]> writes:

> I would like to request one thing to openpgp-mime-02.txt.
> 
> Section 3 says:
> 
>    Additionally, if body parts to be signed contain trailing whitespace,
>    or lines beginning with the five characters "From ", implementations
>    SHOULD use either Quoted-Printable or Base64 to protect these body
>    parts against corruption by transport or delivery agents.  Applying
>    this rule also ensures that trailing whitespace in the data encoded
>    cannot be modified without invalidating the signature.
>       
> I feel that "SHOULD" is too strong. I have two reasons.
> 
> (1) In the ISO-2022 environment (including Korean and Japanese), for
>     long historical reasons, applying CTE: breaks inter-operability
>     between MUAs. Even base64, which is considered more suitable to
>     ISO-2022-{JP,KR} than quoted-printable, should not be applied to
>     ISO-2022-{JP,KR} anyway. So, SHOULD is too strong for this kind
>     of environment.
> 
> (2) This rule implies that MUAs SHOULD search "From " pattern from
>     text in a deeply nested multipart. This is too tough for many
>     MUAs.
> 
> --Kazu

-- 
       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 ns.secondary.com (8.9.3/8.9.3) id EAA09279 for ietf-openpgp-bks; Mon, 22 Jan 2001 04:36:10 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA09275 for <[e-mail]>; Mon, 22 Jan 2001 04:36:08 -0800 (PST)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id VAA07605 for <[e-mail]>; Mon, 22 Jan 2001 21:42:09 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA16779 for <[e-mail]>; Mon, 22 Jan 2001 21:42:09 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id VAA04692 for <[e-mail]>; Mon, 22 Jan 2001 21:42:09 +0900 (JST)
Date: Mon, 22 Jan 2001 21:42:45 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Subject: some requests
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
X-Mailer: Mew version 1.95b99 on Emacs 20.7 / Mule 4.1 (AOI)
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>

I would like to request one thing to openpgp-mime-02.txt.

Section 3 says:

   Additionally, if body parts to be signed contain trailing whitespace,
   or lines beginning with the five characters "From ", implementations
   SHOULD use either Quoted-Printable or Base64 to protect these body
   parts against corruption by transport or delivery agents.  Applying
   this rule also ensures that trailing whitespace in the data encoded
   cannot be modified without invalidating the signature.
      
I feel that "SHOULD" is too strong. I have two reasons.

(1) In the ISO-2022 environment (including Korean and Japanese), for
    long historical reasons, applying CTE: breaks inter-operability
    between MUAs. Even base64, which is considered more suitable to
    ISO-2022-{JP,KR} than quoted-printable, should not be applied to
    ISO-2022-{JP,KR} anyway. So, SHOULD is too strong for this kind
    of environment.

(2) This rule implies that MUAs SHOULD search "From " pattern from
    text in a deeply nested multipart. This is too tough for many
    MUAs.

--Kazu


Received: by ns.secondary.com (8.9.3/8.9.3) id DAA01753 for ietf-openpgp-bks; Mon, 22 Jan 2001 03:12:29 -0800 (PST)
Received: from smtp1.nikoma.de (smtp1.nikoma.de [212.122.128.19]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA01729 for <[e-mail]>; Mon, 22 Jan 2001 03:12:20 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin36.pg7-nt.frankfurt.nikoma.de [213.54.38.36]) by smtp1.nikoma.de (8.9.3/8.9.3) with ESMTP id MAA95270; Mon, 22 Jan 2001 12:17:29 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id A744C2ED2A; Mon, 22 Jan 2001 12:13:08 +0100 (CET)
Date: Mon, 22 Jan 2001 12:13:08 +0100
From: Thomas Roessler <[e-mail]>
To: Kazu Yamamoto <[e-mail]>
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: Kazu Yamamoto <[e-mail]>, [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
References: <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <[e-mail]>; from [e-mail] on Mon, Jan 22, 2001 at 02:33:12PM +0900
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>

If everyone would just be using binary signatures, the problem
wouldn't occur, right.  Bad enough, most current implementations
seem to rely on text-mode signatures.

Also, using the new text-mode signatures with the restrictions in
the draft actually has the nice side-effect of moving PGP/MIME
closer to one of the features found throughout MIME: Resistance
against tampering with trailing whitespace.  It's not really helpful
if changes which don't affect the message's contents are detected by
PGP/MIME.

(But, of course, if most people here feel that binary mode should be
used, we could still change the text.)

On 2001-01-22 14:33:12 +0900, Kazu Yamamoto wrote:
> Date: Mon, 22 Jan 2001 14:33:12 +0900 (JST)
> To: [e-mail]
> Cc: [e-mail], [e-mail], [e-mail],
> 	[e-mail], [e-mail], [e-mail]
> Subject: Re: Finalizing OpenPGP/MIME?
> From: Kazu Yamamoto (???????????) <[e-mail]>
> X-Mailer: Mew version 1.95b99 on Emacs 20.7 / Mule 4.1 (AOI)
> 
> From: Thomas Roessler <[e-mail]>
> Subject: Finalizing OpenPGP/MIME?
> 
> > There haven't been any substantial changes for a long time, and the
> > only thing we still have to resolve in a decent way is that ugly
> > incompatibility with respect to canonical text signatures which
> > hurts us badly, since it does - among other things - ruin
> > one-pass-abilities for OpenPGP/MIME.  I don't think there is any
> > real solution to this problem (or does anyone here have a time
> > machine at hand?). 
> 
> Let me confirm. Can this problem be solved if we use the binary
> signature?
> 
> --Kazu

-- 
Thomas Roessler			    <[e-mail]>


Received: by ns.secondary.com (8.9.3/8.9.3) id VAA23081 for ietf-openpgp-bks; Sun, 21 Jan 2001 21:26:43 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA23077 for <[e-mail]>; Sun, 21 Jan 2001 21:26:41 -0800 (PST)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id OAA25022; Mon, 22 Jan 2001 14:32:39 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA18935; Mon, 22 Jan 2001 14:32:38 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id OAA20206; Mon, 22 Jan 2001 14:32:38 +0900 (JST)
Date: Mon, 22 Jan 2001 14:33:12 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.95b99 on Emacs 20.7 / Mule 4.1 (AOI)
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>

From: Thomas Roessler <[e-mail]>
Subject: Finalizing OpenPGP/MIME?

> There haven't been any substantial changes for a long time, and the
> only thing we still have to resolve in a decent way is that ugly
> incompatibility with respect to canonical text signatures which
> hurts us badly, since it does - among other things - ruin
> one-pass-abilities for OpenPGP/MIME.  I don't think there is any
> real solution to this problem (or does anyone here have a time
> machine at hand?). 

Let me confirm. Can this problem be solved if we use the binary
signature?

--Kazu


Received: by ns.secondary.com (8.9.3/8.9.3) id UAA22347 for ietf-openpgp-bks; Sun, 21 Jan 2001 20:22:37 -0800 (PST)
Received: from mgo.iij.ad.jp ([e-mail] [202.232.15.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id UAA22342 for <[e-mail]>; Sun, 21 Jan 2001 20:22:25 -0800 (PST)
Received: from ns.iij.ad.jp ([e-mail] [192.168.2.8]) by mgo.iij.ad.jp (8.8.8/MGO1.0) with ESMTP id NAA22768; Mon, 22 Jan 2001 13:25:16 +0900 (JST)
Received: from fs.iij.ad.jp ([e-mail] [192.168.2.9]) by ns.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id NAA03508; Mon, 22 Jan 2001 13:25:15 +0900 (JST)
Received: from localhost (mine.iij.ad.jp [192.168.4.209]) by fs.iij.ad.jp (8.8.5/3.5Wpl7) with ESMTP id NAA03290; Mon, 22 Jan 2001 13:25:14 +0900 (JST)
Date: Mon, 22 Jan 2001 13:25:49 +0900 (JST)
Message-Id: <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[e-mail]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
X-Mailer: Mew version 1.95b99 on Emacs 20.7 / Mule 4.1 (AOI)
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>

From: Thomas Roessler <[e-mail]>
Subject: Finalizing OpenPGP/MIME?

> For that reason, I'd propose the changes listed below for a
> draft-*-03.txt.

Probably you know this, but I'm sending a message just in case.

The example in Section 5 has a minor bug:

----
         --bar

        Content-Type: application/pgp-signature
----

should read

----
         --bar
        Content-Type: application/pgp-signature
----

RFC 2015 also has an error in the example in Section 5. We should not
make the same mistake again.

--Kazu


Received: by ns.secondary.com (8.9.3/8.9.3) id EAA04661 for ietf-openpgp-bks; Thu, 18 Jan 2001 04:58:53 -0800 (PST)
Received: from mercury.rus.uni-stuttgart.de (mercury.rus.uni-stuttgart.de [129.69.1.226]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA04652 for <[e-mail]>; Thu, 18 Jan 2001 04:58:51 -0800 (PST)
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4) id 14JEct-0000o9-00; Thu, 18 Jan 2001 13:57:15 +0100
To: [e-mail]
Cc: [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
References: <[e-mail]>
From: Florian Weimer <[e-mail]>
Date: 18 Jan 2001 13:57:15 +0100
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
Lines: 63
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>

Thomas Roessler <[e-mail]> writes:

> To everyone: Please re-read draft-ietf-openpgp-mime-02.txt and
> draft-ietf-openpgp-multsig-01.txt.

Suggestions for typographical corrections are prefixed with [T],
changes in wording with [W], changes to the specification with [S].

Generall:

[T] Use symbolic bibliographic references instead of bare numbers.
    (Makes reading easier.)

Section 1:

[T] Replace 'RFC 1847' with 'RFC 1847'. (Consistency)

Section 2:

[T] Replace 'multipart ASCII armor OpenPGP format' with
    'multi-part ASCII armor OpenPGP format' (cf. OpenPGP)

[S] Make MIME multipart mechanism in favor of OpenPGP multi-part messages
    REQUIRED.  (It is hard to imagine how OpenPGP multi-part messages can
    interoperate with other implementations.)

Section 5:

[S] Include wildcard value for "micalg" parameter.  (Makes generating
    OpenPGP/MIME messages much easier in some situations, but breaks
    one-pass processing, of course.  Today, the majority of
    OpenPGP/MIME installations/implementations doesn't deal correctly
    with this parameter anyway.)

Still Section 5, enumeration (2):

[T] Spell 'recommended' in capital letters.

[W] Replace 'mail transfer agents' with 'mail delivery agents' (or
    both).  In general, only MDAs touch messages in this way, not MTAs.

Still Section 5, example message:

[W] The signature on the example message doesn't seem to be valid (?).
    BITNET is dead.

Section 6.1:

[W] The signature on the example message is invalid.

Section 7:

[S] Neither OpenPGP nor OpenPGP/MIME specify the transfer format of
    public key blocks, so this section doesn't make much sense.

Section 10:

[T] Replace 'OP' with 'OpenPGP'.

-- 
Florian Weimer 	                  [e-mail]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          [phone]/fax [phone]


Received: by ns.secondary.com (8.9.3/8.9.3) id XAA02590 for ietf-openpgp-bks; Wed, 17 Jan 2001 23:48:41 -0800 (PST)
Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id XAA02578 for <[e-mail]>; Wed, 17 Jan 2001 23:48:38 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin173.pg7-nt.frankfurt.nikoma.de [213.54.38.173]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id IAA45628; Thu, 18 Jan 2001 08:54:03 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id 7F0142ED13; Thu, 18 Jan 2001 08:51:36 +0100 (CET)
Date: Thu, 18 Jan 2001 08:51:36 +0100
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Cc: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail], [e-mail]
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
In-Reply-To: <[e-mail]>; from [e-mail] on Wed, Jan 17, 2001 at 04:50:37PM -0800
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 2001-01-17 16:50:37 -0800, [e-mail] wrote:

> What are the issues with regard to implementations of the
> features in these drafts?  Does it matter whether implementations
> exist or will ever appear?  Should the drafts be held until we
> have implementation experience?

draft-ietf-openpgp-mime-02 has no new _features_.  It just adds some
restrictions to cope with the incompatibilities introduced by
OpenPGP.  To the best of my knowledge, most implementations seem to
work that way anyways.

draft-ietf-openpgp-multsig-01 is the one which defines a new
feature.  I'm not aware of a complete implementation of this one.
The reading end side of the draft is done in mutt, however.

-- 
Thomas Roessler				    <[e-mail]>


Received: by ns.secondary.com (8.9.3/8.9.3) id QAA10972 for ietf-openpgp-bks; Wed, 17 Jan 2001 16:45:58 -0800 (PST)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA10963 for <[e-mail]>; Wed, 17 Jan 2001 16:45:56 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id QAA19886; Wed, 17 Jan 2001 16:50:37 -0800
Date: Wed, 17 Jan 2001 16:50:37 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: Finalizing OpenPGP/MIME?
Cc: [e-mail], [e-mail], [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>

What are the issues with regard to implementations of the features in
these drafts?  Does it matter whether implementations exist or will
ever appear?  Should the drafts be held until we have implementation
experience?

Hal Finney


> From: Thomas Roessler <[e-mail]>
>
> I suppose we should somehow bring OpenPGP/MIME to a decent end -
> it's long overdue.
>
> There haven't been any substantial changes for a long time, and the
> only thing we still have to resolve in a decent way is that ugly
> incompatibility with respect to canonical text signatures which
> hurts us badly, since it does - among other things - ruin
> one-pass-abilities for OpenPGP/MIME.  I don't think there is any
> real solution to this problem (or does anyone here have a time
> machine at hand?).  However, looking at the latest draft
> (draft-ietf-openpgp-mime-02.txt), we should most likely document the
> problem in detail.
>
> For that reason, I'd propose the changes listed below for a
> draft-*-03.txt.
>
> To everyone: Please re-read draft-ietf-openpgp-mime-02.txt and
> draft-ietf-openpgp-multsig-01.txt.  Please forward any concerns or
> problems you have to this list, so we can get out new and -
> hopefully - final drafts.
>
> To the co-authors of these documents: Please verify the affiliations
> listed for correctness.
>
> Thanks, and a happy new year to everyone,
> -- 
> Thomas Roessler				    <[e-mail]>


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id PAA08960 for ietf-openpgp-bks; Wed, 17 Jan 2001 15:54:34 -0800 (PST)
Received: from smtp2.nikoma.de (smtp2.nikoma.de [212.122.128.25]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id PAA08955 for <[e-mail]>; Wed, 17 Jan 2001 15:54:29 -0800 (PST)
Received: from sobolev.does-not-exist.org (dialin100.pg5-nt.frankfurt.nikoma.de [213.54.36.100]) by smtp2.nikoma.de (8.9.3/8.9.3) with ESMTP id AAA32199; Thu, 18 Jan 2001 00:59:22 +0100 (CET) (envelope-from [e-mail])
Received: by sobolev.does-not-exist.org (Postfix, from userid 1000) id A223C2ED13; Thu, 18 Jan 2001 00:58:33 +0100 (CET)
Date: Thu, 18 Jan 2001 00:58:33 +0100
From: Thomas Roessler <[e-mail]>
To: [e-mail]
Cc: Ian Bell <[e-mail]>, Michael Elkins <[e-mail]>, Dave Del Torto <[e-mail]>, Raph Levien <[e-mail]>, John W Noerenberg II <[e-mail]>
Subject: Finalizing OpenPGP/MIME?
Message-ID: <[e-mail]>
Mail-Followup-To: [e-mail], Ian Bell <[e-mail]>, Michael Elkins <[e-mail]>, Dave Del Torto <[e-mail]>, Raph Levien <[e-mail]>, John W Noerenberg II <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.13i
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 suppose we should somehow bring OpenPGP/MIME to a decent end -
it's long overdue.

There haven't been any substantial changes for a long time, and the
only thing we still have to resolve in a decent way is that ugly
incompatibility with respect to canonical text signatures which
hurts us badly, since it does - among other things - ruin
one-pass-abilities for OpenPGP/MIME.  I don't think there is any
real solution to this problem (or does anyone here have a time
machine at hand?).  However, looking at the latest draft
(draft-ietf-openpgp-mime-02.txt), we should most likely document the
problem in detail.

For that reason, I'd propose the changes listed below for a
draft-*-03.txt.

To everyone: Please re-read draft-ietf-openpgp-mime-02.txt and
draft-ietf-openpgp-multsig-01.txt.  Please forward any concerns or
problems you have to this list, so we can get out new and -
hopefully - final drafts.

To the co-authors of these documents: Please verify the affiliations
listed for correctness.

Thanks, and a happy new year to everyone,
-- 
Thomas Roessler				    <[e-mail]>



--- draft-ietf-openpgp-mime-02.n	Thu Jan 18 00:31:00 2001
+++ draft-ietf-openpgp-mime-03.n	Thu Jan 18 00:45:15 2001
@@ -8,9 +8,9 @@
 .nr LT 7.2i
 .ds LF Elkins, et al.
 .ds RF FORMFEED[Page %]
-.ds CF Expires February 2001 
+.ds CF Expires July 2001
 .ds LH INTERNET-DRAFT
-.ds RH August 2000
+.ds RH January 2001
 .ds CH MIME Security with OpenPGP
 .ad l
 .in 0
@@ -28,7 +28,7 @@
 expand;
 lr.
 OpenPGP Working Group	M. Elkins
-draft-ietf-openpgp-mime-02.txt	Network Associates, Inc.
+draft-ietf-openpgp-mime-03.txt	Network Associates, Inc.
 Obsoletes: 2015	D. Del Torto
 	CryptoRights Foundation
 	R. Levien
@@ -142,7 +142,19 @@
 protect these body parts against corruption by transport or delivery
 agents.  Applying this rule also ensures that trailing whitespace in
 the data encoded cannot be modified without invalidating the
-signature.
+signature.  Applications SHOULD ensure that no trailing whitespace
+is present after the MIME encoding has been applied.
+.RS
+.pp
+Note: Trailing white space does not alter the actual contents of a
+Quoted-Printable or Base64 encoded body part, or the meaning of MIME
+headers. However, the presence of trailing white space may trigger a
+compatibility problem which was introduced in [1]: With traditional
+implementations of PGP, trailing whitespace was included with
+signatures of canonical text documents.  [1] changes this behaviour
+in an incompatible way, by specifying that trailing white space is
+ignored in signatures of canonical text documents.
+.RE
 .pp
 Data that is ONLY to be encrypted is allowed to contain 8-bit
 characters and therefore need not be converted to a 7-bit format.






Received: by ns.secondary.com (8.9.3/8.9.3) id VAA13562 for ietf-openpgp-bks; Tue, 16 Jan 2001 21:00:07 -0800 (PST)
Received: from zeus.amt.co.kr ([203.248.62.2]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id VAA13532; Tue, 16 Jan 2001 21:00:04 -0800 (PST)
From: [e-mail]
Received: from max1-34.losangeles.corecomm.net by zeus.amt.co.kr with SMTP (Microsoft Exchange Internet Mail Service Version 5.0.1460.8) id DDA0T5HF; Wed, 17 Jan 2001 11:39:59 +0900
DATE: 16 Jan 01 6:44:00 PM
Message-ID: <4w90akI5q93fa>
SUBJECT: RE; THANK YOU 
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>

Dear Friend and Partner, 

Think of all the things you could do if you had more free time and money wasn't an 
object

             What kind of car would you be driving? 

                     Where would you live? 

                           Where would you go on vacation? 
  

Now, for a limited time, 300+ money making and saving secrets can be yours for less 
than $10.00. 

Click here http://www.300moneysecrets.com/    and ORDER NOW!!!!!!!!!!!!!! 
  

Get information now, that could make you millions!!!! 
  


 ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** REMOVE ** 

To be removed from our mailing list, please email [e-mail] All REMOVE requests AUTOMATICALLY honored upon receipt. PLEASE understand that any effort to disrupt, close or block this REMOVE account can only result in difficulties for others wanting to be removed     from our mailing list as it will be impossible to take anyone off the list if the remove instruction can not be received.



Received: by ns.secondary.com (8.9.3/8.9.3) id IAA19770 for ietf-openpgp-bks; Mon, 8 Jan 2001 08:49:45 -0800 (PST)
Received: from finney.org (226-132.adsl2.netlojix.net [207.71.226.132]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id IAA19766 for <[e-mail]>; Mon, 8 Jan 2001 08:49:43 -0800 (PST)
From: [e-mail]
Received: (from hal@localhost) by finney.org (8.9.3/8.9.3) id IAA09321; Mon, 8 Jan 2001 08:53:45 -0800
Date: Mon, 8 Jan 2001 08:53:45 -0800
Message-Id: <[e-mail]>
To: [e-mail], [e-mail]
Subject: Re: learning from history (was: Re: rfc2440bis-02 comments)
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>

Dave Del Torto, <[e-mail]>, writes:
> What we're really discussing is the building of standards that users 
> will control or standards which will help control them.
> [...]
> Until we build ourselves total control over our keys' public 
> attributes and visibility, we're not really being empowered by our 
> crypto (possibly the opposite).

Isn't "total control over... public attributes" something of a
contradiction?  By their nature, public attributes are out in public,
out in the world.  There is no way the owner can exercise "total control"
over them.  Adding features which ostensibly provide this kind of control
could mislead users about what they are accomplishing.

At best we can try to get the key servers to agree on ways of handling
these requests.  But in effect we then bring the multitude of key servers
inside the trust boundary and depend on their cooperation in order to
achieve our trust goals.  This enlarges the trusted computing base and
ultimately weakens security.

> Let's keep in mind that we've been asked at a recent IETF plenary 
> whether or not the IETF should support wiretapping technologies in 
> standards. Those kinds of trial balloons are only the first at the 
> nexus of human rights and security technology.

At the same time we should be cognizant of what is and is not possible.
Giving people the ability to ask key servers to remove their keys will
not achieve the goal of removing those keys from the world's knowledge.

Hal


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id EAA26091 for ietf-openpgp-bks; Mon, 8 Jan 2001 04:19:45 -0800 (PST)
Received: from cryptorights.org (itchy.intermag.com [216.218.196.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id EAA26087 for <[e-mail]>; Mon, 8 Jan 2001 04:19:36 -0800 (PST)
Received: from [192.168.0.70] (208.185.172.2) by cryptorights.org with ESMTP (Eudora Internet Mail Server 3.0.2); Mon, 8 Jan 2001 04:24:25 -0800
Mime-Version: 1.0
Message-Id: <p0510060ab67da5b68b51@[204.179.128.120]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
X-Sender: 
Date: Sun, 7 Jan 2001 15:29:38 -0800
To: [e-mail]
From: Dave Del Torto <[e-mail]>
Subject: learning from history (was: Re: rfc2440bis-02 comments)
Cc: [e-mail], [e-mail], [e-mail]
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>

At 5:53 pm +0900 2000-12-28, [e-mail] wrote:
>...  the points i wish to make are:
>
>   -expiring keys from keyservers is not necessarily a bad idea -- at least
>    your example does not convince me that we would be significantly worse
>    off than the current situation.

Keys are dime-a-dozen: expiring them is economical. People, OTOH,
are valuable, so it's better to expire the keys, but not the people.

>                                    i like Dave Del Torto's statement:
>      Storing your key on a public keyserver is a privilege, not a right.
>      If you can't do the most basic things to maintain it, you're not
>      doing anyone any good, least of all yourself if you want people to
>      use it.


You must also be EMPOWERED to do basic key maintenance on your public 
key. The people who might want to use your key may not not always be 
friendlies. Spammers are only the tip, albeit a sharply annoying one, 
of the iceberg. There are more dangerous threads being woven.

What we're really discussing is the building of standards that users 
will control or standards which will help control them. Keys are good 
for authentication, and can even protect identity (if the anonymix 
allows). But the uncontrolled, irresponsible use of powerful tools 
like the PGP trust model also makes keys great for traffic analysis 
and collecting rosters of cryptographically-bound dissidents. The 
structures are in place to collect names: are you implementing 
technology that makes that scale better?

Until we build ourselves total control over our keys' public 
attributes and visibility, we're not really being empowered by our 
crypto (possibly the opposite). It's hard to get the average user to 
unlearn things. Given the current key formats and the way keyservers 
work, not building full user control over all attributes of their own 
keys on servers amounts to a very bad habit to get the crypto user 
community into.

Let's keep in mind that we've been asked at a recent IETF plenary 
whether or not the IETF should support wiretapping technologies in 
standards. Those kinds of trial balloons are only the first at the 
nexus of human rights and security technology. Technologists have the 
opportunity now --not later-- to establish a positive direction with 
standards and implementations or hand the rudder over to corporations 
and politicians. Ignore this, and these one-way functions are going 
to double back and bite us on the *ss. If Oppenheimer or Einstein 
were alive today, they'd agree that we should luxuriate in this 
discussion now and improve the infrastructure ASAP.

Ask yourself why no major implementor has jumped on the Stealth 
bandwagon in the last 6+ years? Is the fact that RFC2440's 
speculative keyids remain unimplemented an indication of complacency 
in the crypto community?

Who's holding us back?

    dave

__________________________________________________________________________
"The average age of the world's greatest democratic nations has been 200
  years ... from bondage to spiritual faith, from faith to great courage,
  from courage to liberty, from liberty to abundance, from abundance to
  complacency, from complacency to selfishness, from selfishness to apathy,
  from apathy to dependency, and from dependency back again into bondage."
	-- Lord Macaulay (1857)



Received: by ns.secondary.com (8.9.3/8.9.3) id CAA22731 for ietf-openpgp-bks; Sun, 7 Jan 2001 02:04:48 -0800 (PST)
Received: from thetis.deor.org (thetis.deor.org [207.106.86.210]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id CAA22726 for <[e-mail]>; Sun, 7 Jan 2001 02:04:46 -0800 (PST)
Received: from localhost (rabbi@localhost) by thetis.deor.org (8.9.3/8.9.3) with ESMTP id CAA10951; Sun, 7 Jan 2001 02:09:22 -0800
Date: Sun, 7 Jan 2001 02:09:13 -0800 (PST)
From: "L. Sassaman" <[e-mail]>
X-Sender:  <[e-mail]>
To: Marc Horowitz <[e-mail]>
cc: Derek Atkins <[e-mail]>, Dave Del Torto <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: Re: rfc2440bis-02 comments
In-Reply-To: <[e-mail]>
Message-ID: <[e-mail]>
X-AIM: Elom777
X-icq: 10735603
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>

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

On 26 Dec 2000, Marc Horowitz wrote:

> Len, exactly what problem is you proposal intended to solve?  You
> said:
>
>     One of the major complaints I hear about PGP key servers is the inability
>     to delete keys once they are sent to the server. I'd like to request the
>     addition of two new flags for subpacket 23:
>
> Why do these people want to delete their keys?
>
> - They lost the private key or forgot the passphrase.

This doesn't solve that problem. Randy Harmon is putting together some
methods for addressing this issue. However, it could related, as I will
explain.

> - They don't want anybody to know they have a key.

This would aide in suppressing a key whose existence the owner didn't wish
to be public, however.

> - The key is compromised.
>
>   In this case, they should revoke it.

Agreed.

> - I don't want my key on the keyservers at all.
>
>   Your proposal solves this problem, but in my experience, this almost
>   never happens.

I've encountered cases where this is an issue. I believe Dave Del Torto
has as well.

> or is there another problem I've missed?

One case where I could see this being useful is in a network of privately
run key servers (perhaps in a large organization) that wishes to automate
its key server maintenance. Suppose they have a policy of deleting keys
attached to email addresses that are being deleted. Employee "Bob" leaves,
and the account [e-mail] is deleted. A deletion certificate could be
issued and injected into the key server network. Synchronization would take
care of the deletes on all the servers that this key propagates to.

Now, yes, there is another issue here (that I regrettably forgot to
mention in my original message.) Currently the key-server prefs packet is
denoted as being a "self-signature only" feature. Key servers could have a
policy of permitting specified "admin keys" to make alterations to third
party keys using this packet.

This would also help the public key server admins. Currently, if I sent
you a request to delete my key, and you decided you'd be nice and do so,
what are the chances it would stay deleted? However, if the fact that it
is deleted is merged into the key material, the deletion becomes much more
sticky.

(And only key servers configured to honor your admin key would treat it as
deleted, so I don't see any potential for attack here.)

Those are my reasons in a nutshell. This doesn't solve a lot of the
problems, but it addresses some of them, and it hurts nothing.


__

L. Sassaman

Security Architect             |  "The world's gone crazy,
Technology Consultant          |   and it makes no sense..."
                               |
http://sion.quickie.net        |                   --Sting





-----BEGIN PGP SIGNATURE-----
Comment: OpenPGP Encrypted Email Preferred.

iD8DBQE6WEBRPYrxsgmsCmoRAoOnAJ4/xrI8lP/wJZmtsE+d1FgqL5qLJgCeJynG
AKXvyOjETEaZ5olgo6Swaj8=
=I9QV
-----END PGP SIGNATURE-----



Received: by ns.secondary.com (8.9.3/8.9.3) id LAA07846 for ietf-openpgp-bks; Sat, 6 Jan 2001 11:02:37 -0800 (PST)
Received: from smtprelay1.adelphia.net (smtprelay1.adelphia.net [64.8.25.6]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA07841 for <[e-mail]>; Sat, 6 Jan 2001 11:02:35 -0800 (PST)
Received: from mwyoung.transarc.com ([24.48.233.14]) by smtprelay1.adelphia.net (Netscape Messaging Server 4.15) with SMTP id G6R90O00.J71 for <[e-mail]>; Sat, 6 Jan 2001 14:05:12 -0500 
Message-ID: <000a01c07813$76f42f40$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
Subject: Re: El-Gamal signatures again
Date: Sat, 6 Jan 2001 14:04:09 -0500
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 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500
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>

>El Gamal is apparently considered a Very Bad Thing.  Don't do it.


Then take it out of the specification.  I understand that they're
considered dangerous when implemented badly -- the spec already
includes warnings.

But since it's there, it should be accurate and complete.  If we're
afraid to simply take it out because someone may have generated
such signatures, isn't it reasonable to specify it enough that others
could verify them?





Received: by ns.secondary.com (8.9.3/8.9.3) id AAA16383 for ietf-openpgp-bks; Sat, 6 Jan 2001 00:32:34 -0800 (PST)
Received: from limbo.net (IDENT:[e-mail] [209.209.9.8]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id AAA16370 for <[e-mail]>; Sat, 6 Jan 2001 00:32:31 -0800 (PST)
Received: from opcenter2.tillerman.to (IDENT:[e-mail] [216.240.42.201] (may be forged)) by limbo.net (8.9.3/8.9.0) with ESMTP id AAA17917; Sat, 6 Jan 2001 00:37:01 -0800
Message-Id: <5.0.0.25.2.20010106003437.00a902f0@127.0.0.1>
X-Sender: rodney@127.0.0.1
X-Mailer: QUALCOMM Windows Eudora Version 5.0
Date: Sat, 06 Jan 2001 00:35:05 -0800
To: "Michael Young" <[e-mail]>, <[e-mail]>
From: Rodney Thayer <[e-mail]>
Subject: Re: El-Gamal signatures again
In-Reply-To: <011d01c071d4$3b3f8d40$[e-mail]>
Mime-Version: 1.0
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>

El Gamal is apparently considered a Very Bad Thing.  Don't do it.

At 05:29 PM 12/28/00 -0500, Michael Young wrote:
>I never did see anyone answer on the OpenPGP specification of
>El Gamal signatures.  I guessed the following:



Received: by ns.secondary.com (8.9.3/8.9.3) id QAA17865 for ietf-openpgp-bks; Thu, 4 Jan 2001 16:40:41 -0800 (PST)
Received: from cryptorights.org (itchy.intermag.com [216.218.196.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17860 for <[e-mail]>; Thu, 4 Jan 2001 16:40:40 -0800 (PST)
Received: from [204.179.136.159] (204.179.131.84) by cryptorights.org with ESMTP (Eudora Internet Mail Server 3.0.2); Thu, 4 Jan 2001 16:45:12 -0800
Mime-Version: 1.0
Message-Id: <p0510063fb67ac53e2909@[204.179.136.159]>
In-Reply-To: <[e-mail]>
References:  <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
X-Sender: 
Date: Thu, 4 Jan 2001 16:29:02 -0800
To: [e-mail]
From: Dave Del Torto <[e-mail]>
Subject: Re: rfc2440bis-02 comments
Cc: [e-mail], [e-mail]
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>

At 10:34 am +0900 2000-12-29, sen_ml [address elided] wrote:
>From: Marc Horowitz [address elided]
>Subject: Re: rfc2440bis-02 comments
>Date: 26 Dec 2000 22:36:38 -0500
>
>  > Why do these people want to delete their keys?
>
>[ text of various reasons deleted ]
>
>  > - I don't want my key on the keyservers at all.
>
>for reference, below is part of an edited recent post from the
>gnupg-users [address elided] mailing list of someone who doesn't
>want their key on a keyserver at all.
>
>perhaps a survey announced on the various user-oriented pgp lists
>would be useful for collecting feedback on the issue of deleting keys
>from keyservers?
>
>Subject: Re: Deleting Keys on Keyservers
>From: Lazarus Long [address deleted]
>To: GnuPG Users List [address elided]
>Date: Thu, 28 Dec 2000 15:50:23 +0000
>
>On Wed, Dec 27, 2000 at 09:49:55PM +0100, Martin wrote:
>  > From: Martin [address deleted]
>
>  > im just curious. Is there a way to delete a key from a keyserver?
>
>Nope.  Once your key is there, you are hanging out there in the wind for
>spambots to come harvest for all eternity.


Indeed, Sen.

Please see: <http://deltor.to/keys/ddt#update>

    dave

________________________________________________________________________
  Dave Del Torto                          tel: [phone] #2
  Executive Director                      web: http://cryptorights.org
  CryptoRights Foundation                 pgp: http://deltor.to/keys/ddt


Received: (from majordomo@localhost) by ns.secondary.com (8.9.3/8.9.3) id QAA17560 for ietf-openpgp-bks; Thu, 4 Jan 2001 16:25:33 -0800 (PST)
Received: from cryptorights.org (itchy.intermag.com [216.218.196.13]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id QAA17555 for <[e-mail]>; Thu, 4 Jan 2001 16:25:30 -0800 (PST)
Received: from [204.179.136.159] (204.179.131.84) by cryptorights.org with ESMTP (Eudora Internet Mail Server 3.0.2) for <[e-mail]>; Thu, 4 Jan 2001 16:30:01 -0800
Mime-Version: 1.0
Message-Id: <p0510063eb67abc590f9b@[204.179.136.159]>
In-Reply-To: <5.0.0.25.2.20001230123707.0325eeb0@127.0.0.1>
References: <[e-mail]> <pkvL$[e-mail]> <[e-mail]> <5.0.0.25.2.20001230123707.0325eeb0@127.0.0.1>
X-Sender: 
Date: Thu, 4 Jan 2001 16:25:16 -0800
To: [e-mail]
From: Dave Del Torto <[e-mail]>
Subject: the Vision Thing: OpenPGP/MIME (was: Re: Dash-escaping and the Usenet sig convention)
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>

At 12:42 pm -0800 2000-12-30, Rodney Thayer wrote:
>At 08:06 AM 12/12/00 -0800, Jon Callas wrote:
>  >In our last episode ("Re: Dash-escaping and the Usenet sig convention",
>  >shown on 12/12/00), Werner Koch said:
>  >
>  > >The preferred way to encapsulate OpenPGP messages in mail is by using
>  > >MIME as defined in RFC2015.  No need for the old fashioned cleartext
>  > >signing.
>  >
>  >I disagree completely. The correct way to encapsulate messages is with
>  >cleartext. I often delete PGP-MIME messages without reading them because
>  >it's such a pain to deal with them.
>
>I agree with Jon on this.  Insisting that the world suddenly change
>to MIME is not helping the adoption of PGP, in fact, it makes it harder
>as people tend to delete these nasty MIME messages.  It's even worse with
>windows, as the (almost unreadable) "...ems" message looks annoyingly
>similar to a (usually unreadable) SMIME message.  I too tend to
>delete these messages, as they are functionally equivalent to spam.
>
>I think we should be be building systems that INCREASE the usage of
>this technology, not decrease it.
>
>I agree it's the MUA's job to handle this civilly, but until that
>happens, the cleartext solution is much more likely to be usable in
>the real world.


Alas, Jon and Rodney, sometimes it is die-hard positions brought on
by inflexible opinions (present company excluded, of course ;)
  --rather than new solutions responding to technological challenges
and requiring minimal adoption/implementation efforts-- that
represent the real hindrances to crypto deployment.

Whining about .EMS attachments, not to mention trashing them
literally and figuratively as you're doing, solves nothing. It also
ignores the easy workaround. It's like complaining that some people
send you faxes when you prefer email. Buy a fax machine! By
complaining that, just because a common extension isn't yet supported
by MUA devs, this "decreases" usage, you're basically just
illustrating the real problem: refusing to help because of narrow
vision. Instead, why not try calling one of your friends at M$ and
spending five minutes asking her/him to approve the week (max) of
engineering effort it would take to support OpenPGP/MIME. If I can
think of a business case, you certainly could if you tried.

Of course, I admit I may be slightly biased, as a co-author of two
new OP/M (acro-pun intended ;) drafts, one which supercedes RFC2015,
the other adding a useful and basic feature to OpenPGP/MIME (parallel
sigs _could_ be a major benefit to MUA implementors if they had any
vision at all).

In any case, legacy clear-sigs cannot not solve some of our more
"modern" problems and are not usable in the real world because users
(even you, apparently) can't figure out how to open the attachment
and decrypt. Further, the world is moving forwards, not just
sideways. IMHO, the two of you need to get with The Program and
encourage OP/M adoption rather than making this sound like another
religious ASCII-zealotry battle. I like ASCII, even prefer it, but I
live in a real world with >ack-pfft< various file formats... and
those annoying faxes.

    dave

_______________________________________________________________________
"I'm a 'peripheral visionary' ...that means I can see clearly into the
  future ...but only way off to the side."  --Stephen Wright



Received: by ns.secondary.com (8.9.3/8.9.3) id DAA24879 for ietf-openpgp-bks; Wed, 3 Jan 2001 03:40:16 -0800 (PST)
Received: from internal.mail.demon.net (internal.mail.demon.net [193.195.224.3]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id DAA24874 for <[e-mail]>; Wed, 3 Jan 2001 03:40:15 -0800 (PST)
Received: from pillar.turnpike.com (pillar.turnpike.com [194.70.55.2]) by internal.mail.demon.net with ESMTP id LAA21310; Wed, 3 Jan 2001 11:44:39 GMT
Message-ID: <[e-mail]>
Date: Wed, 3 Jan 2001 11:42:00 +0000
To: [e-mail]
From: Ian Bell <[e-mail]>
Subject: Re: Dash-escaping and the Usenet sig convention
References: <[e-mail]> <pkvL$[e-mail]> <[e-mail]> <p04320414b65bfc38d8b9@[63.73.97.184]> <5.0.0.25.2.20001230123707.0325eeb0@127.0.0.1>
In-Reply-To: <5.0.0.25.2.20001230123707.0325eeb0@127.0.0.1>
MIME-Version: 1.0
X-Mailer: Turnpike Integrated Version 5.01 M <U2yaxlNz9mbtXQDcM+J3SutElj>
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 Sat, 30 Dec 2000, Rodney Thayer <[e-mail]> wrote:
>
>I agree with Jon on this.  Insisting that the world suddenly change
>to MIME is not helping the adoption of PGP, in fact, it makes it harder
>as people tend to delete these nasty MIME messages.  It's even worse with
>windows, as the (almost unreadable) "...ems" message

The ".ems" message is a function of the particular client you are using,
not of Windows clients in general.

> looks annoyingly
>similar to a (usually unreadable) SMIME message.  

PGP/MIME signed messages should always be readable by MIME-compliant
clients - the checking of the signature is another matter.

>I think we should be be building systems that INCREASE the usage of
>this technology, not decrease it.

The usage of PGP in the general email-using population will probably
only increase after PGP/MIME becomes much more widely supported. The
ordinary user is going to be very bemused by being told they should use
PGP, only to find that problems arise if they send attachments, use 8bit
characters, forward messages etc.

-- 
Ian Bell                                           T U R N P I K E


Received: by ns.secondary.com (8.9.3/8.9.3) id LAA17549 for ietf-openpgp-bks; Tue, 2 Jan 2001 11:08:58 -0800 (PST)
Received: from fw0.transarc.com (xfw.transarc.ibm.com [192.54.226.51]) by ns.secondary.com (8.9.3/8.9.3) with ESMTP id LAA17544 for <[e-mail]>; Tue, 2 Jan 2001 11:08:57 -0800 (PST)
Received: from mailhost.transarc.ibm.com (mailhost.transarc.ibm.com [9.38.192.124]) by fw0.transarc.com (AIX4.2/UCB 8.7/8.7) with ESMTP id NAA12506 for <[e-mail]>; Tue, 2 Jan 2001 13:44:24 -0500 (EST)
Received: from mwyoung.transarc.com (lig32-227-140-22.us.lig-dial.ibm.com [32.227.140.22]) by mailhost.transarc.ibm.com (8.8.0/8.8.0) with SMTP id PAA08163 for <[e-mail]>; Fri, 29 Dec 2000 15:18:18 -0500 (EST)
Message-ID: <011d01c071d4$3b3f8d40$[e-mail]>
From: "Michael Young" <[e-mail]>
To: <[e-mail]>
Subject: El-Gamal signatures again
Date: Thu, 28 Dec 2000 17:29:43 -0500
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 4.72.3612.1700
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3719.2500
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-----

I never did see anyone answer on the OpenPGP specification of
El Gamal signatures.  I guessed the following:

    Pad as for RSA (PKCS-1).
    MPIs are:
 r (=g^k mod p); and,
 s (=(h-r*x)/k mod p)

Can someone confirm this?

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

iQEVAwUBOku+0GNDnIII+QUHAQFkRgf+N5N2pTD38BWl/le2Svqej/ucsQH+V4xX
6BazcqEWsRm1TIZUXWvEbpGn0sh2C4DEhODmQhMlCNdn4mpQeVvhHPz4n7c4duua
PgQxaglhL/CVp3SNs0kdnYNYIWRrYxQw3QjSOJvqE98ZLGnRIP/gm9q4a9AhttPh
ZCviBnhbkPd2FazhsIE6Nxvp3evayi2SyjXOfxsMgSyIpn6yjChPb+4OX/rMLtJ2
NwrCuP1ZLuxi8eHtfS+vWVe52RYGhrXs2Bb5VvxS+kBRQjuz5lG8RFljnAn1b2qb
HNaAIh+5Ef29huD8k8PV3IZoWLY7kwXTXEanwHVlHZt32j14IMMslQ==
=093E
-----END PGP SIGNATURE-----