On Fri 18/Sep/2020 15:35:44 +0200 Ned Freed wrote:
Would it make sense to note this feature explicitly in the header? For
example, one could write:
Content-Transfer-Encoding: base64; nocr; column-width=76
That data would allow to reproduce the exact encoding that was signed, which
was the reason to use base64 in the first place.
Huh? Why are you decoding and then re-encoding the parts of your message, while
attempting to preserve a signature over the encoding? This entire process is
bound to fail, as there is no required canonical form for base64 output, let
alone quoted-printable.
I agree qp is not quite reproducible. However, base64 is most often encoded at
a fixed column width, even if it's not required to be done that way. In many
cases the width is 76, but not always.
And for that matter, why are you attempting to preserve DKIM signatures while
playing games with the message content? DKIM is intended to sign messages in
transit. It is not intended, or designed for, other signature applications.
This list appends a footer, and then encodes the body in base64. That way,
even if I signed using l=, the signature is broken. If I convert the body back
to 8bit, my signature verifies.
However, occasional failures are more likely to occur with 8bit. For example,
lines starting with "From ". So, what if I base64 encoded the before signing?
I'd have to unencode ietfa.amsl's base64 encoding, strip the footer, and then
re-encode. If I use the same column-width and line terminators, the signature
should verify.
[...Merkle tree idea elided ...]
I appreciate the scheme you proposed. I too saw proposals to have
MIME-compatible DKIM signatures. That ship has apparently sailed.
I'm looking at how to verify standard DKIM signatures after a "footer"
transformation. See:
https://tools.ietf.org/html/draft-kucherawy-dkim-transform-02#section-6
Thoughts?
First and foremost, changing the syntax of the CTE header in an incompatible
way, as this proposal does, would cause no end of trouble.
Yes.
As far as line terminators go, the standard is clear. If you don't want to
follow it you're depending on other implementations' tolerance of your crap.
Tolerating this sort of crap is fairly easy, which of course is why folks can
get away with it enough of the time that they aren't forced to fix it. And
tolerating this sort of crap isn't made any easier by providing a means
of announcing it. So there's no benefit to your scheme there.
So even if this proposal was modified to, say:
Content-transfer-encoding-notes: crap=nocr; column-width=76
all it really does is introduce possible silly states.
Those notes may emerge from a mailing list forwarding unscathed, thereby
allowing to still verify the original signature. Cool, no?
Of course nothing prevents you from doing all this locally. If you want to take
messages apart and store only the pieces, nothing prevents you from writing
down the format details of the encodings that were used so you can try and
reproduce them later. You aren't really helped at all by asking the people
generating the encodings to produce these sorts of labels.
I think I agree... To be clear, I agree that I can hardly ask to ietfa.amsl to
detect and annotate my base64 encoding details. Presumably, the mail filter
that produced and signed the original message should also annotate encoding
peculiarities.
Best
Ale
--
_______________________________________________
ietf-822 mailing list
ietf-822(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-822