1. It would be really nice to explain what each tag means. I'm still not sure I've got it right: c= is basically position-length, yes?
2. It was really confusing to me what the point of b= was in the Delta-Header: header field until I got to the body. Is there actually a use case where it is needed for headers?
3. It might be nice to say that the input is the canonical text of the current signed message, and the output is the canonical text of some previous message (assuming that's correct). That and define the algorithm of what to do with the output canonical text.
4. I'm very confused by one of the examples where some intermediate gateway seems to removing a PDF attachment. It's just using c= in the example, but wouldn't it need to add back the actual PDF which the previous signature signed? That is there would be a b= or t= tag with the attachment's contents
5. the Delta-Header right after page 5 has a Content-Type,[base64]. Is that a typo and should be Content-Type:?
6. In the PDF example, a PDF can be arbitrarily big which obviously begs the question of whether it can be imported into a message header field. There needs to definitely be discussion about that if not normative text.
7. It's not clear that the i= in the Delta headers actually need to be bound to an i= in a signature header field. That is, since DKIM is a trace header, the verifier could simply number them on the fly. Then the protocol isn't bound to DKIM, per se. That would eliminate any possible shenanigans with numbering the signatures. I don't have any concrete example of one, but it makes me wonder there might be some.
8. z= is mentioned but not explained or defined. Mike _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
