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
