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

From: [email-masked]
Date: Wed, 31 Jan 2001 07:15:31 -0500

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 <[email-masked]> 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:
	[email-masked].
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.

---

From: Thomas Roessler <[email-masked]>
Date: Wed, 31 Jan 2001 19:33:59 +0100

> 	Filename	: draft-ietf-openpgp-multsig-02.txt

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

Date: Wed, 31 Jan 2001 19:33:59 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked], John W Noerenberg II <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-openpgp-multsig-02.txt
Mail-Followup-To: [email-masked], John W Noerenberg II <[email-masked]>
Sender: [email-masked]

> 	Filename	: draft-ietf-openpgp-multsig-02.txt

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-multsig-02.txt
Date: Wed, 31 Jan 2001 07:15:31 -0500
Sender: [email-masked]

--NextPart

	

Send a message to:
	[email-masked].
In the body type:

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

--OtherAccess--

--NextPart--

Date: Tue, 30 Jan 2001 17:09:19 +0100
From: Thomas Roessler <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Mail-Followup-To: Florian Weimer <[email-masked]>, [email-masked]
Sender: [email-masked]

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

From: Dave <[email-masked]>
To: "customer" <[email-masked]>
Date: Mon, 29 Jan 2001 14:25:17 -0500
Subject: I could go to JAIL for selling this CD!
Sender: [email-masked]

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

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

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: I-D ACTION:draft-ietf-openpgp-mime-03.txt
Date: Fri, 26 Jan 2001 06:43:50 -0500
Sender: [email-masked]

--NextPart

	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 <[email-masked]> 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".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-openpgp-mime-03.txt".

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

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

Content-Type: text/plain
Content-ID:	<[email-masked]>

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

--OtherAccess--

--NextPart--

Date: Fri, 26 Jan 2001 11:57:14 +0100
From: Thomas Roessler <[email-masked]>
To: Kazu Yamamoto <[email-masked]>, [email-masked]
Subject: Re: some requests
Mail-Followup-To: Kazu Yamamoto <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Fri, 26 Jan 2001 11:38:15 +0100
From: Thomas Roessler <[email-masked]>
To: Kazu Yamamoto <[email-masked]>
Cc: [email-masked]
Subject: Re: some requests
Mail-Followup-To: Kazu Yamamoto <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Fri, 26 Jan 2001 16:19:12 +0900 (JST)
To: [email-masked]
Subject: Re: some requests
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

Thomas,

From: Thomas Roessler <[email-masked]>
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

Date: Thu, 25 Jan 2001 23:49:21 +0900 (JST)
To: [email-masked]
Cc: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

From: Werner Koch <[email-masked]>
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

Date: Thu, 25 Jan 2001 15:02:53 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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                                              <[email-masked]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]

Date: Thu, 25 Jan 2001 22:00:34 +0900 (JST)
To: [email-masked]
Cc: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

From: Florian Weimer <[email-masked]>
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

Date: Thu, 25 Jan 2001 13:59:32 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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                                              <[email-masked]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]

To: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
From: Florian Weimer <[email-masked]>
Date: 25 Jan 2001 13:29:40 +0100
Lines: 19
Sender: [email-masked]

Werner Koch <[email-masked]> 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 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: Thu, 25 Jan 2001 21:25:06 +0900 (JST)
To: [email-masked]
Cc: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

Werner,

From: Werner Koch <[email-masked]>
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

Date: Thu, 25 Jan 2001 12:52:24 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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                                              <[email-masked]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]

Date: Thu, 25 Jan 2001 12:39:33 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Mail-Followup-To: [email-masked]
Sender: [email-masked]

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                                              <[email-masked]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]

Date: Thu, 25 Jan 2001 20:12:05 +0900 (JST)
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

Werner, 

From: Werner Koch <[email-masked]>
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

To: [email-masked]
Cc: Thomas Roessler <[email-masked]>
Subject: Re: Finalizing OpenPGP/MIME?
From: Florian Weimer <[email-masked]>
Date: 25 Jan 2001 11:41:37 +0100
Lines: 31
Sender: [email-masked]

Thomas Roessler <[email-masked]> 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 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

To: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
From: Florian Weimer <[email-masked]>
Date: 25 Jan 2001 11:57:38 +0100
Lines: 34
Sender: [email-masked]

Werner Koch <[email-masked]> 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 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: Thu, 25 Jan 2001 11:19:26 +0100
From: Werner Koch <[email-masked]>
To: [email-masked]
Cc: Florian Weimer <[email-masked]>
Subject: Re: Finalizing OpenPGP/MIME?
Mail-Followup-To: [email-masked], Florian Weimer <[email-masked]>
Sender: [email-masked]

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                                              <[email-masked]>
GNU Privacy Guard                                (http://www.gnupg.org)
Free Software Foundation Europe              (http://www.fsfeurope.org)
           [Please see X-* mail header for OpenPGP key info]

Date: Thu, 25 Jan 2001 10:01:45 +0100
From: Thomas Roessler <[email-masked]>
To: Kazu Yamamoto <[email-masked]>
Cc: [email-masked], [email-masked], Florian Weimer <[email-masked]>
Subject: Re: some requests
Mail-Followup-To: Kazu Yamamoto <[email-masked]>, [email-masked], [email-masked], Florian Weimer <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 25 Jan 2001 10:26:12 +0100
From: Thomas Roessler <[email-masked]>
To: Florian Weimer <[email-masked]>
Cc: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Mail-Followup-To: Florian Weimer <[email-masked]>, [email-masked]
Sender: [email-masked]

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

Date: Wed, 24 Jan 2001 20:54:33 +0000
From: Ben Laurie <[email-masked]>
To: OpenPGP WG <[email-masked]>
Subject: Forward Secrecy Extentions for OpenPGP
Sender: [email-masked]

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

Date: Wed, 24 Jan 2001 15:44:32 +0900
From: saku <[email-masked]>
Subject: Re: Finalizing OpenPGP/MIME?
To: [email-masked]
Sender: [email-masked]

Hi everyone.

[From] Kazu Yamamoto <[email-masked]>
[Date] Mon, 22 Jan 2001 14:33:12 +0900 (JST)
[Subject] Re: Finalizing OpenPGP/MIME?
[Message-id] <[email-masked]>
> 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. <[email-masked]> 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

Date: Wed, 24 Jan 2001 14:54:46 +0900
From: saku <[email-masked]>
Subject: Re: Finalizing OpenPGP/MIME?
To: [email-masked]
Sender: [email-masked]

Hi everyone.

[From] Kazu Yamamoto (山本和彦) <[email-masked]>
[Date] Mon, 22 Jan 2001 14:33:12 +0900 (JST)
[Subject] Re: Finalizing OpenPGP/MIME?
[Message-id] <[email-masked]>
> 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

Date: Wed, 24 Jan 2001 12:21:57 +0900 (JST)
To: [email-masked]
Cc: [email-masked]
Subject: Re: some requests
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

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

To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Cc: [email-masked]
Subject: Re: some requests
From: Derek Atkins <[email-masked]>
Date: 23 Jan 2001 14:58:11 -0500
Lines: 48
Sender: [email-masked]

Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]> 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
       [email-masked]                        PGP key available

Date: Tue, 23 Jan 2001 15:33:40 +0900 (JST)
To: [email-masked]
Subject: Re: some requests
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

Derek, 

Thank you for your reply.

From: Derek Atkins <[email-masked]>
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

To: Michael Elkins <[email-masked]>
Cc: Kazu Yamamoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
From: Derek Atkins <[email-masked]>
Date: 22 Jan 2001 13:54:23 -0500
Lines: 22
Sender: [email-masked]

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 <[email-masked]> 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
       [email-masked]                        PGP key available

Date: Mon, 22 Jan 2001 19:13:22 +0100
From: Thomas Roessler <[email-masked]>
To: Michael Elkins <[email-masked]>
Cc: Kazu Yamamoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Mail-Followup-To: Michael Elkins <[email-masked]>, Kazu Yamamoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Mon, 22 Jan 2001 09:34:54 -0800
From: Michael Elkins <[email-masked]>
To: Kazu Yamamoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Sender: [email-masked]

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

To: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Cc: [email-masked]
Subject: Re: some requests
From: Derek Atkins <[email-masked]>
Date: 22 Jan 2001 11:58:18 -0500
Lines: 50
Sender: [email-masked]

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=?=) <[email-masked]> 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
       [email-masked]                        PGP key available

Date: Mon, 22 Jan 2001 21:42:45 +0900 (JST)
To: [email-masked]
Subject: some requests
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

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

Date: Mon, 22 Jan 2001 12:13:08 +0100
From: Thomas Roessler <[email-masked]>
To: Kazu Yamamoto <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Mail-Followup-To: Kazu Yamamoto <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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: [email-masked]
> Cc: [email-masked], [email-masked], [email-masked],
> 	[email-masked], [email-masked], [email-masked]
> Subject: Re: Finalizing OpenPGP/MIME?
> From: Kazu Yamamoto (???????????) <[email-masked]>
> X-Mailer: Mew version 1.95b99 on Emacs 20.7 / Mule 4.1 (AOI)
> 
> From: Thomas Roessler <[email-masked]>
> 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			    <[email-masked]>

Date: Mon, 22 Jan 2001 14:33:12 +0900 (JST)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

From: Thomas Roessler <[email-masked]>
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

Date: Mon, 22 Jan 2001 13:25:49 +0900 (JST)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
From: Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=) <[email-masked]>
Sender: [email-masked]

From: Thomas Roessler <[email-masked]>
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

To: [email-masked]
Cc: [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
From: Florian Weimer <[email-masked]>
Date: 18 Jan 2001 13:57:15 +0100
Lines: 63
Sender: [email-masked]

Thomas Roessler <[email-masked]> 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 	                  [email-masked]
University of Stuttgart           http://cert.uni-stuttgart.de/
RUS-CERT                          +49-711-685-5973/fax +49-711-685-5898

Date: Thu, 18 Jan 2001 08:51:36 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Mail-Followup-To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

On 2001-01-17 16:50:37 -0800, [email-masked] 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				    <[email-masked]>

From: [email-masked]
Date: Wed, 17 Jan 2001 16:50:37 -0800
To: [email-masked], [email-masked]
Subject: Re: Finalizing OpenPGP/MIME?
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

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

Date: Thu, 18 Jan 2001 00:58:33 +0100
From: Thomas Roessler <[email-masked]>
To: [email-masked]
Cc: Ian Bell <[email-masked]>, Michael Elkins <[email-masked]>, Dave Del Torto <[email-masked]>, Raph Levien <[email-masked]>, John W Noerenberg II <[email-masked]>
Subject: Finalizing OpenPGP/MIME?
Mail-Followup-To: [email-masked], Ian Bell <[email-masked]>, Michael Elkins <[email-masked]>, Dave Del Torto <[email-masked]>, Raph Levien <[email-masked]>, John W Noerenberg II <[email-masked]>
Sender: [email-masked]

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

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

From: [email-masked]
DATE: 16 Jan 01 6:44:00 PM
SUBJECT: RE; THANK YOU 
Sender: [email-masked]

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

From: [email-masked]
Date: Mon, 8 Jan 2001 08:53:45 -0800
To: [email-masked], [email-masked]
Subject: Re: learning from history (was: Re: rfc2440bis-02 comments)
Sender: [email-masked]

Dave Del Torto, <[email-masked]>, 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

Date: Sun, 7 Jan 2001 15:29:38 -0800
To: [email-masked]
From: Dave Del Torto <[email-masked]>
Subject: learning from history (was: Re: rfc2440bis-02 comments)
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

At 5:53 pm +0900 2000-12-28, [email-masked] 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)

Date: Sun, 7 Jan 2001 02:09:13 -0800 (PST)
From: "L. Sassaman" <[email-masked]>
To: Marc Horowitz <[email-masked]>
cc: Derek Atkins <[email-masked]>, Dave Del Torto <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Sender: [email-masked]

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

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: El-Gamal signatures again
Date: Sat, 6 Jan 2001 14:04:09 -0500
Sender: [email-masked]

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

Date: Sat, 06 Jan 2001 00:35:05 -0800
To: "Michael Young" <[email-masked]>, <[email-masked]>
From: Rodney Thayer <[email-masked]>
Subject: Re: El-Gamal signatures again
Sender: [email-masked]

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:

Date: Thu, 4 Jan 2001 16:29:02 -0800
To: [email-masked]
From: Dave Del Torto <[email-masked]>
Subject: Re: rfc2440bis-02 comments
Cc: [email-masked], [email-masked]
Sender: [email-masked]

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: +1.415.334.5533 #2
  Executive Director                      web: http://cryptorights.org
  CryptoRights Foundation                 pgp: http://deltor.to/keys/ddt

Date: Thu, 4 Jan 2001 16:25:16 -0800
To: [email-masked]
From: Dave Del Torto <[email-masked]>
Subject: the Vision Thing: OpenPGP/MIME (was: Re: Dash-escaping and the Usenet sig convention)
Sender: [email-masked]

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

Date: Wed, 3 Jan 2001 11:42:00 +0000
To: [email-masked]
From: Ian Bell <[email-masked]>
Subject: Re: Dash-escaping and the Usenet sig convention
Sender: [email-masked]

On Sat, 30 Dec 2000, Rodney Thayer <[email-masked]> 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

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: El-Gamal signatures again
Date: Thu, 28 Dec 2000 17:29:43 -0500
Sender: [email-masked]

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