On 6/13/06, David Fuelling <[EMAIL PROTECTED]> wrote:
> 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.
I'm missing context here, but this sounds to me like it allows the
relying party to masquerade as the authority.
Cheers,
Ben.
_______________________________________________
dix mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/dix
