ietf-dkim
[Top] [All Lists]

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

2011-04-06 12:31:30
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org 
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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

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