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.
Tony Hansen
[email protected]
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
