Subject: [openpgp] incomplete/confusing guidance around "Hash" Armor header for cleartext signing framework

From: Daniel Kahn Gillmor <[email-masked]>
Date: Wed, 17 Mar 2021 09:28:09 -0400

(no hats on, just noticed a textual problem and wanted to record it on
the list)

The current draft (and RFC 4880) seems internally inconsistent about the
mandatory nature of the "Hash" armor header in the Cleartext Signing
Framwork section.

In particular, it defines 'one or more "Hash" Armor Headers' as an
official part of what a clearsigned message looks like, but then it
discusses what it means when such a header is absent.  (and, when the
header is absent, it says it uses MD5, yikes -- that makes this relevant
to the crypto refresh).

Additionally, though multiple headers could be present, "If more than
one message digest is used in the signature, the "Hash" armor header
contains a comma-delimited list of used message digests."

Finally, what should an implementation do if the hash header doesn't
match the digests found in the actual signature?

This text should be reworked to make the expectations clearer, both for
those generating such a message and for those consuming it.  And it
should *not* encourage the use of MD5.

I've noted this as
https://gitlab.com/openpgp-wg/rfc4880bis/-/issues/26.  If anyone wants
to propose a patch that cleans this up, that'd be welcome.

     --dkg

---

From: Ángel <[email-masked]>
Date: Thu, 18 Mar 2021 02:20:02 +0100

On 2021-03-17 at 09:28 -0400, Daniel Kahn Gillmor wrote:
> discusses what it means when such a header is absent. 

And it was copied from rfc2440 as well.

I think the phrase
>      - One or more "Hash" Armor Headers,
should have been
>      - One or more Armor Headers,

Then it covers other armor headers that may be present, such as
"Charset:", and then it suddenly makes sense the following discussion
about a missing Hash header.

Best regards

---

From: Werner Koch <[email-masked]>
Date: Thu, 18 Mar 2021 09:46:04 +0100

>>      - One or more Armor Headers,

Nope becuase ...

> "Charset:", and then it suddenly makes sense the following discussion

There should be only one Charset header.

ctuallay I would like to drop Charset because it is useless becauuse we
can also interpret that the Charset must be UTF-8.  In any case, MIME is
a way better method to define such properties.  Better have that only at
one place to avoid conflicts - and the armor header are not protected
which has led to questions in the past.

Shalom-Salam,

   Werner

-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.

---

From: "brian m. carlson" <[email-masked]>
Date: Thu, 18 Mar 2021 22:59:39 +0000

> should *not* encourage the use of MD5.

I agree that MD5 is right out.  If we expect implementations to need
this to process a message correctly, then it should be mandatory, since
if someone really wants to use MD5, they should be fine declaring that
up front.  Practically, though, nobody will want to use MD5 for that
purpose, because a signature with MD5 doesn't tell you anything
interesting about the integrity of the message, so everyone will need to
declare a hash.

In my implementation, I would personally choose to instantiate only the
provided algorithms, and as such, I would return an error if the values
did not include the required algorithms, failing the operation.
Alternative implementations might choose to instantiate all digests and
just pick the ones they need at the end, at the cost of additional
computational power.  I don't have a strong preference as to what we do,
but I would like to leave the former possibility open because it
drastically simplifies fast one-pass streaming implementations,
especially if the clearsigned data is large.

I also agree with Werner that Charset is no longer interesting and we
should just use UTF-8.  The encoding practically needs to be
ASCII-compatible so that the delimiters and dash stuffing work, so other
Unicode encodings are out, and generally non-Unicode encodings are
considered obsolete.  That does exclude the possibility that someone
uses a mostly text-compatible binary body there that gracefully handles
newline conversions, but I feel like that's unlikely.
-- 
brian m. carlson (he/him or they/them)
Houston, Texas, US

---

From: Ángel <[email-masked]>
Date: Fri, 19 Mar 2021 01:43:42 +0100

> There should be only one Charset header.

No. What I mean is that it only says «One or more "Hash" Armor
Headers,». It doesn't mention other Armor Headers. Charset was an
example I gave of other armor headers that might be there.

And yes, Charset is a weird header. It doesn't make much sense to
define it but say it may be followed or ignored and treated as utf-8
anyway. The sane thing would be to state that when encoding utf-8 MUST
be used, and receivers are not required to implement any other charset.
The behavior if they find a different charset would be up to them, they
could implement more charsets (specially interesting for old content),
show an error message, use a different charset and hope for the best...

> In any case, MIME is a way better method to define such
> properties.  Better have that only at one place to avoid conflicts -
> and the armor header are not protected which has led to questions in
> the past.
> 

I'm not so sure. If it's an armored message, the charset header will be
more right than the document MIME. If it's a clearsigned one, then
either of them may be the correct one. The only safe way would be to
specify the same charset in the MIME Content-Type as in the PGP own
Charset heaer, and that such charset is utf-8.

Best regards

---

From: Werner Koch <[email-masked]>
Date: Fri, 19 Mar 2021 07:48:48 +0100

> up front.  Practically, though, nobody will want to use MD5 for that

You can't do that for existisng data and thus we need to allow such a
default.  New messages should of course not be created using MD5 and
thus for all practical reasons SHA256 will show up there.  In any case
this is mostly irrelevant because what we have here is basically a
one-pass signature packet.  It needs to be matched against the signature
anyway and for the signature we have rules what algorithm may be used
(for new messages).

> interesting about the integrity of the message, so everyone will need to

Right.

> especially if the clearsigned data is large.

Ack.

Salam-Shalom,

   Werner