> DKIM is one of at least 3 different serverside email verification > protocols - the other lesser one is SenderID aka CallerID from > Microsoft, and the really big one is SPF. Yahoo and gmail are the > only people doing DKIM that I know of (check your own gmail headers - > you can see it in there: DomainKey-Signature: a=rsa-sha1; q=dns; ...
Hey Chris, Thanks for pointing those out. The only wildcard that would probably disqualify something like SPF (for example) is the fact that it is actually meant to verify the Sending Server of an email, not necessarily the email address itself (or if a given email address could be attached to a separate piece of information like a persona-url). In the context of DIX, there won't be a single server sending along email addresses, there will be a myriad of IdP's (read: IP addresses) making email assertions to a myriad of Relying Parties. In the DIX realm, what is needed is some kind of mechanism that will allow an IdP (or a domain owner) to make verifiable assertions about a given email address -- e.g., "example.com domain asserts that [EMAIL PROTECTED] is associated with a given persona-url". That way, a relying party can adequately verify the email address assertion. And, since the user authenticated the persona-url (via DIX), then the user must have authority to use the indicated email address. It seems like there are only 3 possible approaches to auto-magically verify that an email address is associated with some other piece of information (without user input): 1.) Put a public key in some standard, known location (e.g., DNS) so that the owner of the domain can sign his/her email assertions, and any Relying Party can trust that the assertion is valid since only the domain owner could - theoretically - place the public key in the "standard, known" location (e.g., DNS). 2.) Attach a signature/certificate to an assertion. The certificate is singed by a third party, and is "Internet Geography" agnostic. The relying party simply has a list of trusted parties, so there is no external verification lookup 3.) Send a symmetric key (like an HMAC) to the Relying Party, and allow them to verify with the key's authority (in the case of email verification, this should, in some way or another, be the domain owner of an email address). This was what I originally proposed, as it doesn't rely on public/private keys, messing with DNS, etc, and can be arbitrarily secured via HTTP(S) or whatever other security mechanism works with HTTP (in the case of DIX). Plus, it's a unique case where we always know who the authority is: The domain owner of a given email address. Best regards, David _______________________________________________ dix mailing list [email protected] https://www1.ietf.org/mailman/listinfo/dix
