Hi Murray, At 13:35 15-11-2007, Murray S. Kucherawy wrote: >There's some debate beginning regarding how to handle a key or SSP query >which returns multiple TXT records. > >The DKIM specification says: > > 4. If the query for the public key returns multiple key records, the > verifier may choose one of the key records or may cycle through > the key records performing the remainder of these steps on each > record at the discretion of the implementer. The order of the > key records is unspecified. If the verifier chooses to cycle > through the key records, then the "return ..." wording in the > remainder of this section means "try the next key record, if any; > if none, return to try another signature in the usual way". > >So what we do now, i.e. take the first record and toss the rest, is >technically compliant. The guidance for handling multiple keys in >response to a query is not normative so we can also come up with a third >scheme.
I suggest leave it that way and log a message when there is more than one key. >You could argue though that we're not actually compliant because this >paragraph talks about multiple key records being returned; if two TXT >records are returned but only one is a DKIM key and the other is some >gibberish, you could argue that only one key record came back and we >should be using that one and discarding the one that's not a DKIM key. >The current implementation just hands back the first TXT record it gets >regardless of its content. Once different service types are introduced, we might have to parse the multiple records to identify the one for email. >So I'm considering my options here about how to address this situation, if >at all. You're invited to comment. > >One expert recommends just leaving it the way we have it; such situations >are likely to be misconfigurations, and since there's no normative >guidance about handling this case, every implementation will do it >differently anyway. For now, it would most likely be due to some misconfiguration. >Do we want to go through the effort of analyzing all of the records >returned and picking out the first one that's clearly a DKIM key? Not at the moment. >Should we go even further and find the key that matches the signature >being verified (e.g. if the signature is signed with rsa-sha256, parse all >of the records and return the first one that allows sha256, also checking >granularity, service type, etc.)? That would be the long term approach. Regards, -sm ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ dkim-milter-discuss mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/dkim-milter-discuss
