Skip to content

Change guidance on canonicalization to better achieve signed content canonicalization

This MR aims to address the following concerns:

  • Allow clean and human-readable operation in both 8BITMIME and/or SMTPUTF8 compatible environments (-> if it's known, the "canonical representation" of signed content transfers as-is, meaning that there should in theory be no further transformations to do or undo)
  • What to do with UTF-8 header names and values (-> normalize them to remove any superfluous MIME encoding, normalize domains to U-labels)
  • How to optionally avoid issues during transfer (-> apply transformations that were previously described)
  • How to return to original signed content if 8BITMIME is known unsupported (-> what transformations to do when sending and what might have to be undone when receiving)
  • What to do with content encoding (not the header C-E) (-> keep things UTF-8 if they are UTF-8, convert things to UTF-8 if possible (like text/plain or html) also normalize newlines when allowed.)

I've also tried improving the wording around line ending canonicalization. The current draft says that it must (always) do line ending conversion, but it might not actually be tolerated by the content-type (-> copied RFC3156 wording to only do it to return to content-type specific canonical form, so not on like octet-stream)

This MR does not however address:

  • That if MUAs start comparing inner and outer headers, that they should do so on normalized forms.
  • Codepoints outside of UTF-8 in the "canonical representation". I think they could be forbidden to make it easier to implement.

I also haven't included examples, but if these wording changes are acceptable, I can add those too.

Edited by Taavi Eomäe

Merge request reports

Loading