This is the conclusion of the Digital Signatures overview series.
4.0 DKIM — Signing at the Domain
There's an Internet standard in the works in the IETF that's meant to address the usability gap in a limited way. It's called Domain Keys Identified Mail (DKIM), and it uses digital signatures for the limited purpose of asserting that a message came from where it says it came from. Now, that's an oversimplification, because, while it seems like "where it came from" ought to be a straightforward thing, it's not; still, the point is to allow example.com to say "this message says it came from someone at example.com, and it did, in fact, come from someone at example.com."
There's value in that assertion for two reasons. One is simply that if I trust example.com not to send fraudulent mail or junk mail, I can now be assured that signed mail, at least, is good, and I can give whatever extra scrutiny I need to give to mail that seems to be from them but does not have a valid signature. The other is that if I'm told, in some way, that example.com is thorough and always signs its mail, I can be very strict, possibly draconian, about handling example.com mail without a valid signature.
An interesting thing about DKIM is that it's designed to be used in the infrastructure only, and to be entirely transparent to the users' email programs. Information can be added to the message to allow the email program to know whether it did or didn't have a valid signature, but the details of the message formatting and the keys and the signing and verification are all handled in the mail servers.
Early versions of DKIM are in use now, and we expect the protocol to be made a "proposed standard" this year. It should give us a new kind of shillelagh to use against "phishing" messages.
5.0 Next Steps
DKIM is one way to take advantage of digital signatures, and its progress is a good thing to see. Still, widespread use of signatures (and, where appropriate, encryption) at the individual level is important — and lacking. We need to fix the user experience (which might well mean fixing something at a lower level) so that everyone can sign their mail and check the signatures on the mail they receive. It has to work reliably, with a good user experience, essentially 100% of the time. If it's 99%, and you get two (non-spam) messages a day, you'll have a problem on the average of once every two months; that's too often.
Once it's working, we have to start using it. We have to make it easier to get certificates, because the process right now is cumbersome and hard to understand. Why not get one with your driver's license or your passport? Why not be able to bring those documents into your Town Clerk's office and get a certificate? Why not find a way to give you a certificate right along with your email address?
Only when it's easy and widely used will we see the value of digitally signed email.
- Galvin, J., Murphy, S., Crocker, S. and N. Freed, "Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted", RFC 1847, October 1995.
- Callas, J., Donnerhacke, L., Finney, H., and R. Thayer, "OpenPGP Message Format", Internet Engineering Task Force, RFC 2440, November 1998.
- Federal Information Processing Standards (FIPS) "Publication 186-2, Digital Signature Standard", January 2000.
- Klensin, J., editor "Simple Mail Transfer Protocol", Internet Engineering Task Force, RFC 2821, April 2001.
- Resnick, P., editor "Internet Message Format", Internet Engineering Task Force, RFC 2822, April 2001.
- Elkins, M., del Torto, D., Levien, R., and T. Roessler, "MIME Security with OpenPGP", Internet Engineering Task Force, RFC 3156, August 2001.
- Housley, R., "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370, August 2002.
- Federal Information Processing Standards (FIPS) "Publication 180-2, Secure Hash Standard (SHS)", U.S. DoC/NIST, August 2002.
- Jonsson, J. and B. Kaliski, "Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications Version 2.1", Internet Engineering Task Force, RFC 3447, February 2003.
- Ramsdell, B., editor "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Certificate Handling", RFC 3850, July 2004.
- Ramsdell, B., editor "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1 Message Specification", RFC 3851, July 2004.
- Hoffman, P., editor "Examples of S/MIME Messages", RFC 4134, July 2005.
- Fenton, J. "Analysis of Threats Motivating DomainKeys Identified Mail (DKIM)", Internet Draft draft-ietf-dkim-threats-03 (waiting for RFC), May 2006.
- Hansen, T., Crocker, D., and P. Hallam-Baker "DomainKeys Identified Mail (DKIM) Service Overview", Internet Draft draft-ietf-dkim-overview-01 (work in progress), June 2006.
- Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM)", Internet Draft draft-ietf-dkim-base-04 (work in progress), July 2006.