On 04/06/2011 10:25 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Michael Thomas >> 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". Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
