On Apr 6, 2011, at 12:52 PM, Michael Thomas wrote: > On 04/06/2011 12:34 PM, Steve Atkins wrote: >> On Apr 6, 2011, at 11:05 AM, Michael Thomas wrote: >> \ >> >>> The alternative would be very squirrelly when you think >>> of the general case of multiple signers in the path. >>> >> The approach I suggest has no problems with multiple >> signers even if they, for some reason, all want to add >> conflicting metadata. >> > > Yes it does. In your example, a second signer who isn't > privy to whether it knows the birth date could either sign > it because it wants to keep transport integrity, or not > sign it because it doesn't actually know the veracity of > the X-Birthdate: header. The receiver is then left trying > to figure out who is asserting what, most likely by putting > new rules/requirements on the DKIM signer.
If you look at the example I gave, it mentions which DKIM identity is making the assertion. Authenticated-Birthdate: version=0.1; dkim=corp.example.com; birthdate=1970-02-24 It's easy for the signer to tell what's going on - if there's a dkim sig for d=corp.example.com that covers that header, then it's safe to assume that corp.example.com is the one making that assertion. If foo.bar.com has also signed that header that means... nothing, semantically. foo.bar.com would need to prepend it's own Authenticated-Birthdate header, with "dkim=foo.bar.com" in it, and sign the whole thing. It's not particularly pretty, but it's fairly obvious to the recipient what's going on, and unlikely to break anything. (There's an obvious hole if you have access to a signer that just signs every header, rather than a fixed list of headers, but that's fairly far in to "don't do that" territory). > > Messy and error prone. At least if you put it into the signature > header you know for certain what the signer's intention is. I don't think you do. If you put it in the signature header in an existing field (e.g. i= or s=) then there's no common understanding of the semantics beyond what 4871 has to say about them. If you put it in the signature field in an ad-hoc way, you risk clashing with someone else's use of it. The only safe way to add proprietary gunk into the dkim-signature header is to add it to the IANA DKIM-Signature tag registry (how does that happen? Presumably it requires an RFC?) That's certainly a reasonable approach, but the overhead of doing that (vs adding an ad-hoc field or using a 5322 header) makes me think it unlikely people will do that. Cheers, Steve _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
