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
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;
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
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
NOTE WELL: This list operates according to