Re: [openpgp] Backwards compatibility vs streaming verification of v6 clearsigned messages

[Daniel Huigens <[e-mail]>]

Hi dkg,

I agree with most of your points. Some additional data on our
implementations:

> # Replace "SaltedHash" with "Hash"
>
> We could stay within the invariant established by RFC4880 by replacing
> the Armor Header Name "SaltedHash" with "Hash" -- but by expanding the
> definition of what the contents of the field can be. This might itself
> cause some confusion in deployed legacy clients, but given that they may
> well encounter data signed with arbitrary, previously unknown hash
> names, they should be capable of ignoring unknown hash names, just
> like they should be capable of ignoring unknown signature versions,
> unknown public key algorithms, etc.

This is not the case at least for OpenPGP.js. This is because there was
a worry about messages like:

    -----BEGIN PGP SIGNED MESSAGE-----
    Hash: SHA512, -- Hey Alice, I need you to wire $100k to 12345566.

    Thank you!
    -----BEGIN PGP SIGNATURE-----
    [...]

Additionally, the current crypto refresh draft says that:

    If neither a "Hash" nor a "SaltedHash" Armor Header is given, or the
    message digest algorithms (and salts) used in the signatures do not
    match the information in the headers, the signature MUST be
    considered invalid.

The way we implement this is by parsing the hash algorithms in the Hash
header, and match them against the signature packets later. If the hash
algorithms in the header are unknown, the message fails to parse.

---

> I do think it's worth noting that there are *other* brittlenesses that
> might have an effect on this multisigned, cross-version use case too.
> For example, some implementations refuse to validate all signatures in a
> multi-signed message when they encounter *any* signature with an unknown
> version number, unknown public key algorithm, or unknown hash algorithm.
> (...)
> If fixing this one bit of brittleness in the CSF Armor Header doesn't
> actually help a significant number of deployed legacy implementations
> correctly validate the v4 sig in such a multi-signed message, i would
> personally probably be more willing to leave the spec as-is.

I've tried verifying your test message without the SaltedHash header,
and GopenPGP accepts it, but OpenPGP.js >=5.3 unfortunately doesn't.
This is because of a change we made to improve handling unparseable
packets that actually caused a regression here. We'll fix that, but it
does indeed make removing the SaltedHash header somewhat less useful.
(OpenPGP.js <5.3 does accept the message without the SaltedHash header.)

---

All in all, I don't have a strong preference, and I'm OK with all the
options. I might have a slight preference for removing the SaltedHash
header, also because it (technically speaking) constitutes a backwards-
incompatible chance with regards to the spec (as you said), not just
implementations; but perhaps it's not worth the churn to remove it now,
so I'm also fine with keeping the draft as-is.

Best,
Daniel