Re: [openpgp] text signatures

["Neal H. Walfield" <[e-mail]>]

On Mon, 28 Nov 2022 20:39:02 +0100,
Daniel Huigens wrote:
> Yeah, I tend to agree. I also brought this up in the MR where this
> change was proposed [1], and we subsequently discussed it in the DT,
> where I suggested to change the proposed text from "is encoded" to
> "MUST be encoded" in order to signal that this is a new instruction
> that only applies to new signatures, and that those indeed MUST be
> UTF-8 encoded

Would it make sense to add a warning to the text that older software
may not have performed the encoding when hashing the signature data?
Then, for historical v3 and v4 signatures, an OpenPGP implementation
could create two hash contexts, one where only line ending
normalization is performed, and another where both line ending and
UTF-8 conversions are performed?

>  (which reflects the new guidance for literal data packets
> in [2] to the same effect).

I find the change to the literal data packet easier to accept than the
above change, since there is a clear break.


Perhaps the change to how signatures are computed in 5.2.4 should only
apply to v5 signatures, since it represents a change in semantics.


> My intention with that (not speaking for
> dkg or the rest of the DT, though) was that for existing signatures,
> it shouldn't apply, but actually the quoted section is general to both
> signing and verification, so probably that intention isn't captured
> by the final text, and it should be changed again.
> 
> Since the literal data packet already says that text data MUST be UTF-8,
> maybe this guidance is redundant, in that case, and can just be removed?
> We might still need some guidance for detached signatures; e.g. we could
> state in section 11.4 that detached text signatures MUST be over UTF-8
> encoded text (and similarly for clearsigned messages as well?)
> 
> Or, from the other direction, we could say that when creating signatures
> the implementation may only set the signature type to text if it's
> confident that it's signing UTF-8 encoded text?

My understanding of the current text in 5.2.4. is that the signing and
verification routines have to do the conversion to UTF-8 on the fly,
i.e., the signed data may not actually be encoded with UTF-8, and the
converted data is not necessarily emitted.  That, of course, implies
that the implementation somehow knows the correct encoding, which I
don't think is always true.


I'd be for requiring that text signatures (signature type 0x1) made by
v5 key be over UTF-8 data.  Otherwise, they should be considered
invalid.

Neal