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.
Off hand,
1 - No Certificate Chaining in DKIM like it is in SSL.
2 - Verifiers need local table for DCA (DKIM Certificate Authority), like
browser have now. They are not just going to accept all DCAs and
the DCA may have give out some payola to get their names
in the table!
3 - No COMMON NAME (ODID), thus one SIGNER for all messages!
- Wildcards - Lost of profits for DCA, they will need at least
ODID and/or AUID as a "Identity Cookie."
4 - What happens if it fails? Even browsers have learned not to be so
quick to continue with the SSL cert failures.
VBR can work as the emulation of the "Chain" concept, but #2 is still
required. #3 is what we missed out in RFC4671 to prepare this market
place. Just like in a SSL certificate the "COMMON-NAME" which would
be the Author Domain (ODID) will help this DCA market and help them
prepare the different pricing tiers of non-wildcard vs wildcard.
--
Hector Santos, CTO
http://www.santronics.com
http://santronics.blogspot.com
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html