> -----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. _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
