ietf-dkim
[Top] [All Lists]

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

2011-04-06 15:20:26

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

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