On 5/19/11 2:32 PM, Rolf E. Sonneveld wrote:
Hi, all,
recently someone asked me whether it would have any added value if the
DKIM public key, which is stored in DNS, would be 'certified' in some
(yet to be determined) way by a 3rd party like VeriSign, Thawte etc.? My
first reaction was, that it made no sense, but I'm no longer sure
whether that's the only possible answer. For example: does it have an
added value if a VeriSign Trust Seal certificate would be used for the
DKIM public key?
Maybe I should send this question to the domainrep list, as 'certifying'
a DKIM public key may have more to do with domain reputation and
accreditation then with DKIM itself.
Anyway, any thoughts on this topic appreciated.
There is value knowing whether labels used to access public keys are valid.
For example, labels should be ensured not to use invalid code points,
whether or not expressed in punycode form. DNS is capable of handling
UTF-8 queries without punycode conversion. Punycode was to bridge
applications unable to handle UTF-8. Now there are two encoding
standards for punycode, one with string-prep and one without.
Simplistic prep has been replaced by a sizable list of 3,329 additional
invalid code-points which now permits use of German essets and the Greek
final sigmas.
At the system level, a name resolver does not know whether a name space
must use punycode for non-ASCII or should use UTF-8. There are two
popular implementations for the local namespace using UTF-8, which means
at the system level multiple encoding methods will need to be tried.
Whether an answer resolved locally would be impossible to determine. An
issue ignored by DKIM.
Also see http://tools.ietf.org/html/rfc5201 (HIP) for another approach
that might make sense when attempting to securely deal with source.
-Doug
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html