Subject: [Chris Newman] COMMENT: draft-ietf-openpgp-rfc2440bis

From: Sam Hartman <[email-masked]>
Date: Fri, 04 May 2007 14:53:21 -0400

Do people in the working group support making the change Chris
proposes?  It is unlikely to be required by the IESG and is unlikely
to delay the document either way.  The question is whether people
believe that it would make the document better.

Subject: COMMENT: draft-ietf-openpgp-rfc2440bis
From: Chris Newman <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 03 May 2007 15:23:23 -0700
List-Id: iesg.ietf.org

<https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=790&filename=draft-ietf-openpgp-rfc2440bis>

The clear signature format in section 7 causes signature crud to appear
in mail readers that do not support PGP.  It's my belief that such "crud"
can be harmful to deployment of technology (e.g., user A starts using
PGP sends signed mail to user B who doesn't use PGP but sees lots of
PGP boilerplate around the email so user B complains to user A about this
and user A decides PGP is too much trouble).  As the IETF has
standardized a mechanism (RFC 3156) which allows mail clients to suppress
most of the "crud," and this mechanism allows a single piece of code to
gracefully handle both PGP and S/MIME, it's my belief we should recommend
greater use of that mechanism to help support greater deployment of
secure email technology.

An additional benefit of RFC 3156 is gateways that alter whitespace or
encodings will keep their hands off that part of the message in a way
they might not otherwise.  The format in section 7 doesn't have that
benefit and is thus somewhat more fragile.

As a result, I am presently voting to abstain on this version of this
document.  That means the document may still proceed to publication
unless several of my peers on the IESG choose to also abstain.  In short,
I feel strongly enough about this to not help this document progress,
but not so strongly that I'm going to actively oppose progression.

Changing the text to say that RFC 3156 SHOULD be used instead
of the format in section 7 for environments that support MIME
multipart messages would cause me to positively support forward
progression of this document.

Also be aware that a large number of the normative references probably
count as downrefs.  If there are any downref sticklers left on the IESG,
it may save time to IETF last call the downrefs in advance if that wasn't
already done.

Section 6 mentions the constant '0x864CFB' while the sample code uses the
constant '0x1864cfb'; which one is correct?

Other nits:
Section 3.7.1.3
Could use int32_t (ISO C 99 standard) rather than nonstandard Int32.
Section 4.2.3
I was confused about packet length vs. body length especially after
reading the last paragraph.  Perhaps make sure you've used the terms
consistently.
Section 7.1
What happens if the "- " prefix causes the line to exceed SMTP line
length limits (998 characters)?

                - Chris

---

From: [email-masked] (Daniel A. Nagy)
Date: Fri, 4 May 2007 22:33:52 +0200

> believe that it would make the document better.

I definitely do agree with Chris that using traditional PGP clearsigned
messages in email is harmful in so many ways. I have actually encountered the
scenario that he describes as hypothetical several times (even in a corporate
setting).

I am fully supportive of the change (and even the recommended wording).

Also, I would like to mention that together with Janis Schuller, we have
devised a very nice way of interoperating between environments which do
support multipart mime and those that do not. Please take a look at this
document:
http://redcent.h1101990.serverkompetenz.net/0000000000000095

It is a Section 7-style clearsigned document, but it can be converted into
an rfc3156-style signed document without using the private key (actually,
just using a text editor).

Note: Squatting the text/plain.epoint.* mime-type namespace was not a nice
thing to do, but that is not the point.

Cheers,

-- 
Daniel

---

From: Ian G <[email-masked]>
Date: Sat, 05 May 2007 00:33:07 +0200

> believe that it would make the document better.

I object, most strongly!

The paragraph at the beginning states quite clearly:

================================
7. Cleartext signature framework

     It is desirable to be able to sign a textual octet 
stream without ASCII armoring the stream itself, so the 
signed text is still readable without special software. In 
order to bind a signature to such a cleartext, this 
framework is used. (Note that this framework is not intended 
to be reversible. RFC 3156 defines another way to sign 
cleartext messages for environments that support MIME.)
================================

This section/feature is not to do with email.  The format 
*MAY* be used over email, and takes some care to permit 
mailers to send that format.  However, this format is about 
signing documents, not sending emails.  The paragraph above 
quite clearly mentions the other context of sending messages 
over email, by referring to RFC 3156.

Specifically, OpenPGP's cleartext signature format is used 
for signing documents that might have legal import.  (E.g., 
human signing that indicates that signatory 
reads/understands/intends/accepts the document, something 
that practically no other RFC addresses.)

According to legal context, separated signatures aren't much 
use, and indeed, will likely raise costs and cause false 
expectations.  MIME, etc, are pretty much useless in a legal 
context because there is no easy way to both prove the 
signature *and* convince a skeptical audience (judge & jury) 
that the document is indeed signed.

Discussions of crud, etc, miss the point.  OpenPGP is not a 
standard for only email encryption, and should not be 
treated as only such.  It *MAY* be and is widely used for 
email, but should not be confused with other more custom 
email encryption designs such as S/MIME, that can only be 
used for email.

Likewise, his point that on "deployment of technology" is 
out of place in a technology that is now 15 years old.  The 
RFC won't change its success one way or another.

(I have no comment on his comment about normative and other 
nitpicks!)

iang

PS:  For more commentary on the legal aspects of using 
OpenPGP cleartext signatures see 
http://iang.org/papers/ricardian_contract.html

---

From: Jon Callas <[email-masked]>
Date: Fri, 4 May 2007 17:19:38 -0700

> believe that it would make the document better.

I object most strongly.

As an implementer, I do lots of work to make OpenPGP/MIME work  
correctly. The problem is that this is not easy, particularly in the  
case where you want to have a very complex message and encryption and  
signatures. It's fine for an implementer to strive for that because  
customers want it. It's wholly another thing for the standard to say it.

Additionally, these "harmful" headers have been around for the last  
fifteen years. It's not like we're suddenly creating these things.

Ian has also said as adequately as I have that OpenPGP's technology  
is used for many other things than email. I don't need to add more.

	Jon

---

From: Jon Callas <[email-masked]>
Date: Fri, 4 May 2007 17:48:35 -0700

> it may save time to IETF last call the downrefs in advance if that  

I ran the last couple revisions through idnits and eliminated all  
downrefs. If there are new ones, we can fix them, but three weeks  
ago, there were none.

> constant '0x1864cfb'; which one is correct?

Section 6. I've corrected it now.

> Could use int32_t (ISO C 99 standard) rather than nonstandard Int32.

Yes, but the sentence following says:

    The above formula is in C, where "Int32" is a type for a 32-bit
    integer, and the variable "c" is the coded count, Octet 10.

> reading the last paragraph.  Perhaps make sure you've used the terms

Okay.

> length limits (998 characters)?

As we said in the previous discussion of clearsigned signatures,  
using them in email isn't the only use of OpenPGP, and may not even  
be the most common one.

If someone generates an OpenPGP clearsigned object that exceeds the  
SMTP line limit length (which is 1000 characters, not 998), then the  
SMTP server might generate an error. It would behoove an  
implementation that uses both OpenPGP and SMTP to follow both standards.

	Jon

---

From: Werner Koch <[email-masked]>
Date: Sat, 05 May 2007 10:51:10 +0200

> believe that it would make the document better.

I fully agree with these comments and they have been the topic of many
discussions in the past 9 years.  However, there is no really agreement
and clear signed messages are actually in wide spread use.  Even if the
RFC would more strongly suggest the use of PGP/MIME, it won't change the
reality.  For some widely deployed mail systems it is even not possible
to use PGP/MIME.

The clear signed messages are well defined and working, no reason to
ban them.

So for the sake of having a good and working standard now, we should not
open this fruitless discussion again but go ahead in the RFC process.

Salam-Shalom,

   Werner

---

From: David Shaw <[email-masked]>
Date: Sat, 5 May 2007 08:44:04 -0400

I agree that we should not change the draft on the 3156 question.
Everything that needed to be said has been said, so I'll just comment

> length limits (998 characters)?

As I see it, nothing, any more than a too-long line would be when not
dash-escaped.  Armor is not email (or any transport) specific.  Just
like the very common line-wrapping problem, if there is a desire to
transport a message through a system that has line length limits, it
is incumbent on the sender to do it in such a way that the message
survives transport.  We even mention this in the draft, albeit in the
context of Armor Headers.

David

---

From: Sam Hartman <[email-masked]>
Date: Sun, 06 May 2007 10:18:17 -0400

>>>>> "Jon" == Jon Callas <[email-masked]> writes:

    Jon> On May 4, 2007, at 11:53 AM, Sam Hartman wrote: Here are some
    Jon> other answers:

    >> Also be aware that a large number of the normative references
    >> probably count as downrefs.  If there are any downref sticklers
    >> left on the IESG, it may save time to IETF last call the
    >> downrefs in advance if that wasn't already done.
    >> 

    Jon> I ran the last couple revisions through idnits and eliminated
    Jon> all downrefs. If there are new ones, we can fix them, but
    Jon> three weeks ago, there were none.

Sorry, I meant to trim this part of Chris's message from what I sent to the WG.

Like Jon, I believe the downref situation is well in hand.  If any
questions are raised on the IESG I can deal with them using an RFC
3967 last call.

--Sam