On 04/06/2011 10:25 AM, Murray S. Kucherawy wrote:
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Michael
Sent: Wednesday, April 06, 2011 9:43 AM
To: Steve Atkins
Cc: DKIM WG
Subject: Re: [ietf-dkim] Proposal: Removal of AUID (i= tag/value)
As long as the Authenticated-Birthdate header is included in the
DKIM signature it references, that's pretty much equivalent as
far as senders and receivers who are both using the same
authenticated birthdate spec are concerned, just more flexible
and less likely to clash with or break other DKIM usage.
As I said, that would be a completely new requirement for
headers -- something that we don't do today. Also: you could
get into awkward situations where you'd be required to not
sign something that was present in the message if you couldn't
vouch for its correctness, even if you wanted to vouch for its
transport integrity. If it's in the signature header itself, there's
no such ambiguity.
Either method can ensure the data make it to the verifier intact, to be sure.
But this smells a bit like a layering violation to me. Using a new DKIM tag
to relay meta-data about the signer, rather than the actual signer's identity
(or equivalent), strikes me as something that doesn't belong in DKIM.
Huh? What is a= or d= or s= if not "meta-data about the signer"?
Having cross semantic correlation of what headers mean with the
presence of dkim signatures from various different signers seems
like a lot more of layer violation to me. In any case, we haven't
gone down the route of giving semantics to *why* a signer
signs a given header which is really at the heart of this discussion.
The closest we have is From: that we require to be signed but
the "why" part is still something of a hand wave -- essentially
being "because we said so".
NOTE WELL: This list operates according to