Subject: Re: Tailing whitespace, armor lines, and clearsigned messages

From: "Hal Finney" <[email-masked]>
Date: Thu, 21 Mar 2002 15:11:25 -0800

David Shaw writes:
> Now here's the part I don't quite get - if it is okay to allow
> trailing whitespace in the message contents, why is it not okay to
> allow trailing whitespace after the armor header?

The reason for specifying the treatment of trailing whitespace in the
message contents is because that portion is hashed.  What the spec
means here is that trailing whitespace is not included in the hash.
The BEGIN line is not hashed so there is no need to say what to do with
trailing whitespace there.

Technically an implementation could reject messages with trailing
whitespace on the BEGIN line.  However this would violate the principle
of "be liberal in what you accept and conservative in what you send".
The right thing to do, according to this principle, is to create the BEGIN
line with no trailing whitespace, and to ignore any trailing whitespace
on incoming BEGIN lines.

Hal

---

From: David Shaw <[email-masked]>
Date: Thu, 21 Mar 2002 17:48:02 -0500

> trailing whitespace there.

Aha, it just clicked.  "These line endings are considered a part of
the Armor Header Line for the purposes of determining the content they
delimit."  It's just forcing that anything on the armor header line
isn't considered content.

Thanks,

David

-- 
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

Date: Thu, 21 Mar 2002 17:48:02 -0500
From: David Shaw <[email-masked]>
To: Hal Finney <[email-masked]>
Cc: [email-masked]
Subject: Re: Tailing whitespace, armor lines, and clearsigned messages
Mail-Followup-To: Hal Finney <[email-masked]>, [email-masked]
Sender: [email-masked]

> trailing whitespace there.

Aha, it just clicked.  "These line endings are considered a part of
the Armor Header Line for the purposes of determining the content they
delimit."  It's just forcing that anything on the armor header line
isn't considered content.

Thanks,

David

-- 
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

Date: Thu, 21 Mar 2002 15:11:25 -0800
From: "Hal Finney" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Tailing whitespace, armor lines, and clearsigned messages
Sender: [email-masked]

Hal

Date: Thu, 21 Mar 2002 15:35:53 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Tailing whitespace, armor lines, and clearsigned messages
Mail-Followup-To: [email-masked]
Sender: [email-masked]

I would really appreciate a bit of clarification with some of the
wording in 2440bis.

In section 6.2 ("Forming ASCII Armor"), the text says (and it's a
MUST) that there should be nothing after the second set of dashes in
the armor header line.  That is: "-----BEGIN PGP SIGNED MESSAGE-----"
is okay, but "-----BEGIN PGP SIGNED MESSAGE----- " is not okay due to
the extra space on the end.

In section 7.1 ("Dash-Escaped text"), the text says that a signature
on a clearsigned message ignores trailing whitespace.  I've read that
the intent behind that is to give some measure of robustness to the
message so it can get through mail systems that add or remove
whitespace at the end of lines.

If the intent behind ignoring trailing whitespace was to help with
mail corruption, the fact that the message data allows trailing
whitespace doesn't really help since the armor headers surrounding the
message data would also become invalid with any added trailing
whitespace.

I do understand the armor header is not part of the message, and this
is likely just another example of "be conservative in what you
generate, liberal in what you accept".  If I've misread this
somewhere, can someone please help clarify?

Thanks!

David

-- 
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

Date: Wed, 6 Mar 2002 13:45:27 -0500
From: David Shaw <[email-masked]>
To: [email-masked]
Subject: Re: Revocation key difficulty
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Tue, Mar 05, 2002 at 03:43:54PM -0500, Michael Young wrote:

> David Shaw noted this PGP (and now GnuPG) behavior:
> > If the designated revoker's key is not present, then a key "revoked"
> > by the designated revoker key is not treated as revoked.  GnuPG - as
> > of this morning - does it the same way.
> 
> I would argue that silently ignoring a missing revoker is a bad default.
> GnuPG is generally very good about issuing warnings (and offering
> options :-).  Would you be willing to do so here (at least when
> a potential revocation is present)?

Good idea.  I think a warning during key import if a key has a
potential revocation on it is appropriate.

> I know this doesn't thwart would-be attackers.  They can always
> remove the revocation itself.  A warning would simply help
> recognize that the key is effectively incomplete, and that the
> revoker should be retrieved.  (Or, have you adjusted GnuPG to
> automatically retrieve revokers after retrieving a key from a server?)

It doesn't, but that's a good idea as well (to be optional, of
course).

David

-- 
David Shaw          |  Technical Lead
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

From: "Michael Young" <[email-masked]>
To: <[email-masked]>
Subject: Re: Revocation key difficulty
Date: Tue, 5 Mar 2002 15:43:54 -0500
Sender: [email-masked]

David Shaw noted this PGP (and now GnuPG) behavior:
> If the designated revoker's key is not present, then a key "revoked"
> by the designated revoker key is not treated as revoked.  GnuPG - as
> of this morning - does it the same way.

I would argue that silently ignoring a missing revoker is a bad default.
GnuPG is generally very good about issuing warnings (and offering
options :-).  Would you be willing to do so here (at least when
a potential revocation is present)?

I know this doesn't thwart would-be attackers.  They can always
remove the revocation itself.  A warning would simply help
recognize that the key is effectively incomplete, and that the
revoker should be retrieved.  (Or, have you adjusted GnuPG to
automatically retrieve revokers after retrieving a key from a server?)

A signed CRL could provide the means to defeat removal attacks.  I
thought that I'd seen a draft that had considered some form of CRL,
but I can't find it now.  Did that ever come up?  I understand that
this requires a bunch of specification, so I can see why it might have
been rejected.