Subject: [Fwd: [PGP-USERS] Word Wrap Problems with PGP 9.0.3]

From: Ian G <[email-masked]>
Date: Thu, 08 Dec 2005 09:52:52 +0000

As a fascinating comment on the trickiness that
is cleartext signing, the below just popped up
on a user list.

Obviously, the app offers the useful feature of
reformatting the text according to some metric.
Just as obviously this goes way beyond the
discussion of whether the whitespace should be
stripped from the end, or whether the last
newline is added or imputed or stripped or
ignored...  and the text is likely no longer
comparable canonically or otherwise.

(I never did see a resolution to that question?
What then was the rule on the last newline?)

iang

-------- Original Message --------
Subject: [PGP-USERS] Word Wrap Problems with PGP 9.0.3
Date: Wed, 07 Dec 2005 22:25:34 -0700
From: Nick Andriash
Reply-To: [email-masked]
To: [email-masked]

I just purchased PGP Desktop Pro and am finding that when I go to clearsign
a message, PGP is actually re-flowing and/or word wrapping the text. I use
BeckyMail which is as close to a WYSIWYG Editor as there is. When I finish
typing my message or editing my reply, I used to simply clearsign the
message and send it... there was no word wrapping before signing, except with this latest version of PGP.

Does anyone know if or where the setting for that word wrap may be?

-- 
    ~~Nick Andriash~~
Courtenay, B.C. Canada

__________________________________________________________
  the PGP-USERS mailing list
Home Pg: cryptorights.org/pgp-users
Charter: www.cryptorights.org/lists/pgp-users/charter.html

---

From: [email-masked] (Daniel A. Nagy)
Date: Thu, 8 Dec 2005 11:41:50 +0100

> What then was the rule on the last newline?)

In order for the cleartext signed message to verify, there is no need to add
another newline; the standard allows for text messages where the last line
is not terminated. GPG actually REMOVES the last newline, if the input comes
from the console, in order to allow for cleartext messages with an
unterminated last line. I like this feature a lot.

If terminating the last newline is not required, then one-pass signed and
clearsigned text messages can be converted back-and-forth without access to
the secret key (or any cryptography, for that matter). I think this feature
is worth preserving.

Thus, I propose not requiring the termination of the last line (and not
terminating it automagically).

-- 
Daniel

---

From: Ian G <[email-masked]>
Date: Thu, 08 Dec 2005 11:43:48 +0000

> terminating it automagically).

So, what you are proposing is that when
an unterminated message is signed:

-----BEGIN SIGNED MESSAGE-----

this message was signed unterminated

It recovers as "this message was signed unterminated"
as it went in?  And then this becomes:

-----BEGIN SIGNED MESSAGE-----

this message was already terminated

which extracts as "this message was already terminated
" (i.e., preserving its one newline).

OK, I'd be happy with that.  As long as it is a solid
rule.

But I think we need to hear from the PGP Inc and GPG
architects on this?

iang

---

From: Werner Koch <[email-masked]>
Date: Thu, 08 Dec 2005 13:23:01 +0100

> But I think we need to hear from the PGP Inc and GPG

I recall that we tweaked gpg's behaviour in this regard until all
users were satisfied.  Thus I'd say not to add new requirement to the
specs.

Salam-Shalom,

   Werner

---

From: [email-masked] (Daniel A. Nagy)
Date: Thu, 8 Dec 2005 13:43:35 +0100

On Thu, Dec 08, 2005 at 11:43:48AM +0000, Ian G wrote:

> -----BEGIN PGP SIGNATURE-----
> b1ab1a
> -----END PGP SIGNATURE-----
> 
> -----BEGIN PGP SIGNATURE-----
> b1ab1a
> -----END PGP SIGNATURE-----
> 

Exactly.

-- 
Daniel

---

From: [email-masked] (Daniel A. Nagy)
Date: Thu, 8 Dec 2005 13:49:54 +0100

> users were satisfied.  Thus I'd say not to add new requirement to the

I, for one, like the way GPG behaves in this respect very much. Any change
to the spec that would make gpg's current behavior non-compliant should be
considered harmful, IMHO.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Thu, 8 Dec 2005 09:52:05 -0500

> users were satisfied.  Thus I'd say not to add new requirement to the

I agree.  I think the spec is just fine in this regard: the final CRLF
(the one before the "-----BEGIN PGP SIGNATURE-----") is not part of
the signature.  That allows for the GPG behavior to preserve the
presence or lack of line ending on the last line.

David

---

From: Ben Laurie <[email-masked]>
Date: Mon, 26 Dec 2005 12:29:15 +0000

> presence or lack of line ending on the last line.

However, it doesn't. This strikes me as a bug both in GPG and in the spec.

-- 
http://www.apache-ssl.org/ben.html       http://www.thebunker.net/
**  ApacheCon - Dec 10-14th - San Diego - http://apachecon.com/ **
"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

From: [email-masked] (Daniel A. Nagy)
Date: Mon, 26 Dec 2005 14:43:04 +0100

> However, it doesn't. This strikes me as a bug both in GPG and in the spec.

Yes it does. GPG behaves slightly differently with messages entered from the
console, but that makes a lot of sense, too. I don't see any bugs in either
the specs and GPG. I have coded up my own OpenPGP implementation based on
the spec (http://pgp.epointsystem.org/tool) and it interoperates perfectly
with GPG.

-- 
Daniel

---

From: David Shaw <[email-masked]>
Date: Mon, 26 Dec 2005 10:36:15 -0500

> However, it doesn't. This strikes me as a bug both in GPG and in the spec.

Can you give an example of why you feel this is a bug?

David

---

From: Ian G <[email-masked]>
Date: Mon, 26 Dec 2005 16:20:28 +0000

> Can you give an example of why you feel this is a bug?

I think it is a bug if we decide that the
process of cleartext signing is reversable.

So, if the process of verification creates
a file that is the pre-signed version, then
it has to decide whether the final CRLF has
to be preserved or stripped in the unsigned
output.

So, does this output as a line terminated
string or as an unterminated string? :

-----BEGIN PGP SIGNED MESSAGE-----

my signed text

Now, if we decide that the process of signing
is not one that is deterministically reversable,
it is not an issue.  In practice, verification
is possibly all we need - and we have that.

(I have been unable to convince myself that we
need reversibility - I can't think of a case
where I would want it... but that's just me!)

iang

---

From: David Shaw <[email-masked]>
Date: Mon, 26 Dec 2005 11:39:08 -0500

> process of cleartext signing is reversable.

Can you please give an example of how the current system is not
reversible?

As far as I can see, the current system is quite reversible.  For
example, given a document reading "this is a test" (no line ending,
and the last character in the file is the second t from test), here's
a clear signature:

  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1
  
  test  <<-----  There is a CRLF here, but it is NOT PART OF THE SIG
  -----BEGIN PGP SIGNATURE-----

  blah blah blah
  -----END PGP SIGNATURE-----

Now given a document reading "this is a test<LINEENDING>", here's a
clear signature:

  -----BEGIN PGP SIGNED MESSAGE-----
  Hash: SHA1
 
  test  <<----- There is a CRLF here and it IS PART OF THE SIG
  <<-----  There is a CRLF here, but it is NOT PART OF THE SIG
  -----BEGIN PGP SIGNATURE-----

  blah blah blah
  -----END PGP SIGNATURE-----

In what way is this not reversible?

> to be preserved or stripped in the unsigned

The final CRLF is not part of the document.  If a user/implementation
wants a final CRLF in there that is part of the document, they need to
add one.

Think of the "BEGIN PGP SIGNATURE" string as actually being
"CRLF-----BEGIN PGP SIGNATURE".  It's part of the message structure
and not part of the signed text.

David

---

From: David Shaw <[email-masked]>
Date: Mon, 26 Dec 2005 11:48:43 -0500

On Mon, Dec 26, 2005 at 04:20:28PM +0000, Ian G wrote:

>  xxxxx

Sorry, I did not answer this in my earlier mail.  This is output as an
unterminated string.  If you wanted it to be output as a terminated
string, you'd have generated this:

>  xxxxx

Note the blank line between "my signed text" and the BEGIN PGP
SIGNATURE.

David

---

From: Ben Laurie <[email-masked]>
Date: Mon, 26 Dec 2005 17:03:59 +0000

> the spec (http://pgp.epointsystem.org/tool) and it interoperates perfectly

I have just tested GPG yet again, and cleartext signatures of two files,
one without a newline at the end, and one with, look identical:

test
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (FreeBSD)

Cheers,

Ben.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 26 Dec 2005 17:04:30 +0000

> Can you give an example of why you feel this is a bug?

Because information about the final character is lost.

---

From: Ben Laurie <[email-masked]>
Date: Mon, 26 Dec 2005 17:05:40 +0000

-----BEGIN PGP SIGNATURE-----

blah blah blah
-----END PGP SIGNATURE-----

> and not part of the signed text.

If that were what happened, I'd be happy. But it isn't.

---

From: Ian G <[email-masked]>
Date: Mon, 26 Dec 2005 17:29:01 +0000

> and the last character in the file is the second t from test), here's

OK, I understand all that.  But you've added
a new rule:  on signing, always add the extra
line ending.

And that's what we want to clarify - I don't
think the spec says that.  It simply says that
the last newline is not part of the signature.

By all means, if that's what we agree on, then
we should simply state that in the spec:  always
add a newline on signing, always take it off
on reversing (verifying and stripping sig).

I'm happy with that rule - even though I don't
think that's what all implementations do.

> and not part of the signed text.

Right that all makes perfect sense - to me.
Can we put that in the spec?  Here's what it
says:

     As with binary signatures on text documents, a cleartext signature
     is calculated on the text using canonical <CR><LF> line endings.
     The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
     SIGNATURE-----' line that terminates the signed text is not
     considered part of the signed text.

     When reversing dash-escaping, an implementation MUST strip the
     string "- " if it occurs at the beginning of a line, and SHOULD warn
     on "-" and any character other than a space at the beginning of a
     line.

     Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
     the end of any line is removed when the cleartext signature is
     generated.

Here's what I suggest (changes at ***):

     As with binary signatures on text documents, a cleartext signature
     is calculated on the text using canonical <CR><LF> line endings.
     The line ending (i.e. the <CR><LF>) before the '-----BEGIN PGP
     SIGNATURE-----' line that terminates the signed text is not
*** part of the signed document and SHOULD be added by implementations. ***

     When reversing dash-escaping, an implementation MUST strip the
     string "- " if it occurs at the beginning of a line, and SHOULD warn
     on "-" and any character other than a space at the beginning of a
     line.

     Also, any trailing whitespace -- spaces (0x20) and tabs (0x09) -- at
     the end of any line is removed when the cleartext signature is
     generated.

How's that?

iang

---

From: David Shaw <[email-masked]>
Date: Mon, 26 Dec 2005 15:19:26 -0500

> the last newline is not part of the signature.

Ok, now we're cooking: we agree.  I don't think the spec says that
either.  I am just saying that that behavior is consistent with the
spec, and (I say) a good thing to do, and (to me) follows naturally
from what the spec does say.  That said, GPG doesn't do it, and PGP
(at least the version I have here) does.

Both PGP and GPG are compliant with the spec as written.  If you add
this extra rule to enforce reversibility, GPG will become noncompliant
(fixable, but annoying), and many GPG-created signatures will become
noncompliant (a little more worrisome).

>     the end of any line is removed when the cleartext signature is

I have no objection to that.

David

---

From: [email-masked] (Daniel A. Nagy)
Date: Mon, 26 Dec 2005 22:32:13 +0100

> Version: GnuPG v1.4.2 (FreeBSD)

Yepp, that's a bug in GPG and it does not follow from the spec. My
implementation does not do that. In my opinion, the correct behavior would
be reversible.
The output of gpg --clearsign should be identical to that converted from the
output of gpg -ts.

-- 
Daniel