On 10/13/10 10:53 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] >> On Behalf Of Jim Fenton >> Sent: Wednesday, October 13, 2010 10:42 AM >> To: ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] Collected data >> >> [sticking with Murray's subject line so as not to create two thread >> breakages!] >> >> I don't have any data on how many messages had DK signatures as well as >> DKIM signatures, but at least some do (I checked some I received). I >> don't quite understand your question. The ambiguity that is created >> has to do with the DKIM result, not the DK result. > With this change, a DKIM signature referencing a "g=" key might verify if the > verifier elects to enable this backward compatibility feature. > > Without this change (i.e. the more strict posture), a DKIM signature > referencing a "g=" key won't verify ever. But that's the same as an unsigned > message. > > The harm in the apparent ambiguity seems minimal; it's no worse than if the > signature or key was completely malformed somehow. So is the distinction > important?
With this change, a message signed referencing one of these keys MAY verify. Wouldn't a signer want to fix the problem anyway (remove the empty g=), in order to have their signatures verify more consistently? It also adds more complexity to the specification and to implementations. Besides, DK compatibility should become less of an issue with time since it is a legacy protocol. -Jim _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
