Closing the loop (well, for our question, anyway...): thanks all for the
feedback & discussion, based on that and the language in
draft-ietf-dkim-rfc4871bis-07, we're going to fix signature validation when we
update the inbound MTAs late summer.
Regards,
Paul
-----Original Message-----
From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] On Behalf Of Hector Santos
Sent: Tuesday, April 12, 2011 12:57 AM
To: SM
Cc: IETF DKIM WG
Subject: Re: [ietf-dkim] [dkim-ops] key validation question
SM wrote:
Adding text in RFCs to prevent lies doesn't usually solve problems.
:-)
Sure, but that is what h= attempts to trap using another level of authenticity
requirements. We can categorized that scenario many ways but its simply about
the domain trying to exclude an method a "bad guy" can use fraudulently.
Overall, my suggestion for the text would be something like:
h= A colon-separated list of hash algorithms that might be used
as acceptable hash algorithms. (plain-text; OPTIONAL,
defaults to allowing only standard registered algorithms).
When signing mail, the signer MUST use one of the h= methods
explicitly specified or implicitly using one the default
standard registered hash algorithms.
Verifiers not recognizing a hash algorithm or does not
match a= value MUST invalidate the signature.
The key in the text proposed earlier is "operational choice" (see what
Tony suggested). It is a fix that does not introduce any requirements.
The text proposed earlier takes into account what is stated in other
sections of draft-ietf-dkim-rfc4871bis-05.
The point in my text is to spell it out. Yes, its an operational
choice, but one that does come with a non-written technical
requirement. If you specified h=, you are expected to use one of the
methods listed for signing. Otherwise, current verifiers will see you
as a "liar" (or bad guy mail) when using something else. :)
--
HLS
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html