On 5/19/2011 3:17 PM, Murray S. Kucherawy wrote: >> -----Original Message----- From: [email protected] >> [mailto:[email protected]] On Behalf Of Rolf E. Sonneveld ... >> 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.? ... > The use of plain RSA keys without requiring a third-party certification was a > specific design criterion for DKIM. You could change to using some kind of > certificate that is signed by someone else, but you'd need a new key type and > corresponding signing algorithm(s) that evaluate the more complex keys and > then tie them to whatever your trusted certifiers list is, and would probably > pretty much mandate TCP for DNS. > > It seems to me this is a bullseye for what VBR is capable of providing.
1. There are important differences between 'claims' -- certified or not -- and reputation. Claims are provided by the claimant. Reputation is provided by third-parties. Certs are specific to the claims. Reputation can be about anything. And so on. These really are not equivalent mechanisms, IMO. 2. It might be reasonable to enhance DKIM to support multiple claims. As of now, DKIM has only one: The signer claims to take /some/ responsibility for the message. (DOSETA now supports multiple claims.) 3. As noted, certification was explicitly de-coupled from DKIM. I'll claim that it really is a separate, value-added service and any support of it should be through a separate, value-added mechanism. My own preference would be for using a special header-field that contains the cert, with the specification of using such certs as saying that they are enabled when included in the set of h= covered header fields. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
