Last Call: draft-ietf-dkim-ssp-requirements (Requirements for a DKIM Signing Practices Protocol) to Informational RFC

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



This draft lays out what is destine to become email acceptance criteria based upon DKIM signing practices. DKIM depends upon public- key cryptography and uses public keys published under temporary labels below a _domainkey domain that must be at or above the identity being signed to meet "strict" acceptance criteria. Once SSP is deployed, those wishing to benefit from DKIM protections must ensure their messages meet the "strict" expectation of a signature added by a domain at or above their email-address domain. This "strict" practice is the only significant restriction currently anticipated by these SSP requirements.

What is missing as a requirement in this document that would offer a practical means to facilitate meeting the "strict" requirement established by SSP itself. Currently this requires either some type of undefined exchange of keys, delegation of a DNS zone at or below the _domainkey label, or a CNAME DNS resource record tracking an email provider's public versions of the public key they use, in conjunction with some agreed upon domain selector and the customer's domain reference placed within the signature. None of these solutions are not either very practical or really all that safe. This approach also obscures who actually signed the message and on who's behalf.

There is a requirement that could offer a solution that is both safe and scaleable. This requirement would remove any necessity to use ad- hoc exchanges of keys, delegation one's DNS zone, or setting up fragile CNAMEs coordinated at the customer's domain, tracking the selectors and public keys used by "authorized" email providers. The requirement is to facilitate the authorization of "third-party" domains by name. This can scale and would be far safer and easier to administer as well.

There is a draft that illustrates how this might work for SSP.

This draft has not yet reached the internet-draft directory, so here is a copy that can be viewed now.

http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-tpa-ssp-01.txt
http://www.sonic.net/~dougotis/dkim/draft-otis-dkim-tpa-ssp-01.html

-Doug





_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]