John R. Levine wrote:
>> But this is exactly what DKIM is. You prove yourself fsvo "prove"
>> to the registrar who "certifies" you by virtue of placing your NS
>> records in the root servers instead of issuing a cert.
>
> Registrars, as we all know, rarely check any credential beyond the
> confirmation code from the credit card charge.
hmmmm, doesn't that depend on the cert being purchased? There is a
higher due diligence done for the more expensive "seal" which comes
with a higher indemnity. AFAIK, depending on your PCI level, you
can't get the "el cheapo" cert like the Turbo SSL offered by GoDaddy
because auditors will fail you.
> I'm still not seeing what a cert provides that couldn't be handled by VBR
> or another DKIM signature by the certifier.
+1, I think VBR can address the "wildcard" signer which may not be
desirable (by the receiver and by an 3rd party authority). But I
think you answered this in your RFC security session:
The receiver of a message with a VBR-Info header field MUST ignore
certifiers that it does not trust; otherwise, a bad actor could just
add an authority that it has set up so that it can vouch for itself.
No matter what, like everything else, there needs to be a "White List"
of VBRs that is either defined locally or via a centralized source.
The problem, unlike the browser market, is that SMTP vendors do not
have a common source to do this and even then, they may only want to
do this for selected VBR records, Author Domains and signers.
--
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
