ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] Extensions (was RE: Proposal: Removal of AUID (i= tag/value))

2011-04-06 15:44:02
On 04/06/2011 01:18 PM, Steve Atkins wrote:
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 not particularly pretty, but it's fairly obvious to the recipient
what's going on, and unlikely to break anything.
   

   Bletch. At least this is all theoretical now. Thankfully.

(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).
   

I think it's a little worse than that. It sort of also expects
corp.example.com's mail infrastructure to be consistent,
and that you don't get multiple trips through the signer
infrastructure tickling those inconsistencies. Weird
stuff does happen, especially when you get companies
bolted together.

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.
   

I'm only talking about a standards based approach here.
Non-standard use would make a messy situation even messier.

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.
   

The net-net is that either way, the DKIM signer code would
need to change. So do you want the DKIM signer to need to
parse/understand the semantics of another RFC, or understand
an extension to DKIM itself. I'd worry that the DKIM considerations
in the rush to have the all important X-Brithdate rfc would be
lost on the DKIM signer maintainers. By putting it into the
DKIM header itself, you have to *force* them to pay attention
to the problem if you want the feature.

Mike
_______________________________________________
NOTE WELL: This list operates according to 
http://mipassoc.org/dkim/ietf-list-rules.html

<Prev in Thread] Current Thread [Next in Thread>