On 8/18/25 20:58, Phillip Tao wrote:
The problem this is supposed to solve is:1. Easier to implement - By sharing much of the underlying technology with a widely deployed (or rather, hopefully-soon-to-be-widely-deployed) authentication mechanism in DKIM2, it will be easier for both senders and receivers to adopt.
In my understanding DKIM* and unobtrusive signatures will usually be produced by different entities: - unobtrusive signature is produced by a fat MUA or a webmail app - DKIM* signature is produced by the initial MTA.The owners of the signature keys are usually different entities, the sending user owns the e2e unobtrusive signature key, and the email administrator controls the DKIM* signature key.
DKIM* signatures are usually verified by the receiving MTA, not by the MUA. Unobtrusive signatures will probably be verified by the MUA, not by the MTA.
Because of this separation, it seems ok to me to have two separate mechanisms at different places.
The unobtrusive signatures are a property of the message as created by the sender, and to me the message body feels like the proper place for the signature.
If the e2e signature is part of the body, then we can easily distinguish which headers were originally produced by the sending MUA, and which ones were added by MTAs.
By using the currently porposed mechanism, which adds a MIME layer around the inner message, we get a header section inside the body. This will also give us a good place for adding extra headers that are relevant for end-to-end security (for example key material) and that don't need to present at the outer header section. By placing them into the inner section in the body, only, we avoid increasing the outer header section further. Because there is a maximum size for the outer header block, as I understand it, and because future key material for post quantum cryptography might be big, being able to move those extra headers into the body seems like a useful benefit.
Similarly, implementors do not have to worry about cases like the inner headers not matching outer headers.
Andrew, DKG and myself were discussing which consistency checks between inner and outer headers should be done, but we haven't yet updated the draft.
It might be reasonable to limit the consistency check to the user-facing header fields, possibly Subject, From, To, Cc, Date, Reply-to, Followup-To. And if those mismatch, the signature must be considered invalid.
Other outer header fields, which aren't user facing, could be ignored by the MUA. Instead the MUA should process the header fields from the inner signed message.
3. No MIME structure alteration - These signatures are meant to be "unobtrusive". Part of that to, IMO, is that there's absolutely no impact on how the message is treated by the receiving MTA and MUA, regardless of the MUA's support for this scheme. From the draft/DKG's presentation in Madrid, it seems like this draft has been fairly well tested already, and seems compatible. However, it's obviously infeasible to test all existing MUAs, not to mention future versions of MUAs. There's significantly less risk of errant MUA behavior if the actual message body does not need to have a different MIME structure to support this signature scheme.
The classic way of adding e2e-signatures also used a MIME structure in the message body, so we are not using a new approach, just a new syntax.
As I understand it, the MIME structure we are suggesting is a core mechanism of MIME that every application processing MIME must support, ignoring extra layers and processing the data that's inside the extra layer?
This also simplifies interaction with things like Structured Email, in which certain MIME structures signal certain cases.
Does SML ever require multipart/mixed on the outermost layer and give that special meaning?
Does SML require that a specific part needs to be at the top level? Does SML state any requirements for nesting depth? If the answer to all questions is "no", hopefully there's no clash here.It seems that SML uses multipart/related and multipart/alternative. So hopefully the additional outer multipart/mixed layer isn't a problem.
* added mailing list footers break a DKIM-style signature, however, if the footer is added as a wrapper around the body (additional MIME layer added), then the inner signed part can be clearly identified and could still be validated.Would that not violate the e2e mail guidance doc's concept that the cryptographic envelope should be at the top layer? And thus this would be an "errant layer"? Perhaps that's fine/intended, since the guidance doc essentially says that errant layers should be handled unobtrusively.
I agree that the above example will invalidate the unobtrusive signature in the default rendering.
Nevertheless, the signed part inner part could still be detected, and the nested MIME part contains everything that's necessary to verify the signature. A MUA might optionally offer the user to open a rendering of the inner part.
This strategy wouldn't be easily possible with a DKIM* e2e signature, as the MUA would have to produce a combination of outer signature headers and inner MIME parts.
Kai
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
