[ietf-dkim] [dkim-ops] key validation question

[Hector Santos]

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