On 4/6/11 10:53 PM, Tony Hansen wrote: > On 4/6/2011 4:18 PM, Steve Atkins wrote: >> 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). > This is an interesting approach, but I find this last bit to be the > rather big hole. > > If this approach were chosen, this argues for any such header, to be > within a namespace such as Policy-Semantics or DKIM-Semantics. > >>> 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. > Other RFCs would need to be written that went beyond the two 4871 > requirements of "opaque" and "unique" for i=, that give a mechanism (a > semantic signpost) to the signer for how to specify what those semantics > were. > >> 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?) > Any new tag added to either the dkim signature or the dns key record > MUST (yes, a normative MUST) be written up in an RFC and reach IETF > consensus to be added to either one of the tag registries. See section 7 > of RFC 4871 and the definition of IETF Consensus found in RFC 2434. > >> 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. > For there to be reasonable semantic meaning, it must be understandable. > > Whether it were done by adding semantic signposts for i=, additional tag > values, or additional 5322 headers, it should *not* be done in an ad-hoc > fashion.
+1 /rolf _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
