On 5/19/2011 3:17 PM, Murray S. Kucherawy wrote:
-----Original Message----- From: ietf-dkim-bounces(_at_)mipassoc(_dot_)org
[mailto:ietf-dkim-bounces(_at_)mipassoc(_dot_)org] 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