I would like to make three related suggestions for DKIM2:
1. Include MUAs as a "hops".
This could be explicitly stated, or the concept of a hop could just be broadly
defined enough to include MUAs.
Although DKIM1 was not designed for MUAs to perform validation, DKIM2 makes
this much more feasible. This would be beneficial for many MUAs who may want to
enforce their own policies around DKIM.
2. Have separate hashes per MIME part.
This could still use a bit more fleshing out, but the general sketch of it
would be that each leaf of the MIME tree would be hashed (in its transfer
decoded form), and each multipart would be a hash of the MIME headers and
hashes of their child parts. Basically, it would be a Merkle tree up to the
top-level body hash. The individual part hashes would need to be added to the
DKIM2 header, or possibly as another header.
This has a few benefits:
1. It allows MUAs to validate the DKIM signature for the MIME parts it cares
about, without having to download all parts.
2. It saves forwarding hops some unnecessary computation. For example, if all
you're doing is adding a footer, there's no need to rehash all the other parts
(including large attachments, etc.).
3. It makes the diff algebra easier. For example, if some intermediate hop
removes an attachment, they can easily annotate that as deleting a previously
existing MIME part with some hash.
3. Encourage longer key retention in DNS.
I know the draft currently says that keys MUST exist in DNS for at least 2
weeks, but—apart from an actual key revocation—it's not particularly harmful to
leave the key there for longer.
In order to support receiving MUAs who want to do validation, it would be nice
for the draft to say something like "keys MUST be available for at least two
weeks, but SHOULD be available for at least six months".
- Phillip
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
