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.
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.
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.
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?
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.)?
-MSK
-------------------------------------------------------------------------
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
