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

["brian m. carlson" <[e-mail]>]

On 2021-03-17 at 13:28:09, Daniel Kahn Gillmor wrote:
> (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 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