I've been thinking more about the strong objection to "explicit list of signed headers", which is that a new header, e.g. `Message-Evil: no` could be created by a new draft and have very important security properties, but the sending system doesn't know that and hence doesn't include it (as blank) in the signed set of header fields, and then a later system could add it, and that would be bad.
This does require some clever security considerations and correct implementation, but I think my answer is: If a header field is not signed by the current instances, then can be assumed to be blank in all previous instances. Any instance signing a header field which was not signed by the previous instance is assumed to be adding it; and receiving systems MUST NOT assume it was present before. The latest signed copy of that header field MUST be used for any security-related purpose, so if `Message-Instance: i=1` didn't sign it `Message-Instance: i=2` did sign it, with value 'yes' `Message-Instance: i=3` didn't sign it, but changed it to "no" with instructions how to convert back Then the signed value is "yes", and that's the only value which can be used for anything security related, and only when attributing it to the system which signed `i=2`. I believe this is actually sufficient for good security, it doesn't mandate that any instance sign ANYTHING in particular, only the things for which it requires attribution. And of course if you modify anything which was signed by ANY previous instance, you have to provide the algebra to convert back to the value it had. Those algebras don't need to be signed because they either work or they don't. Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
