Network Working Group A. Vesely Internet-Draft September 15, 2010 Intended status: Experimental Expires: March 19, 2011 DKIM Joint Signatures draft-vesely-dkim-joint-sigs-00 Abstract DKIM Joint Signatures provides a means to limit the responsibility of a message that implied by signing it, and possibly transfer the responsibility to a third party. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 19, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Vesely Expires March 19, 2011 [Page 1] Internet-Draft DKIM Joint Signatures September 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 3. The DKIM-Required Field . . . . . . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Normative References . . . . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 5 Vesely Expires March 19, 2011 [Page 2] Internet-Draft DKIM Joint Signatures September 2010 1. Introduction DKIM Joint Signatures provides a means to limit the responsibility of a message that implied by signing it, and possibly transfer the responsibility to a third party. It consists of header data, external to the DKIM-Signature field, that requires a trusted third party signature. Such co-signer takes its share of the responsibility like all signers do, but the meaning of its role is augmented by the new DKIM-Required field. Joint Signatures are especially useful when the message is supposed to be resent or forwarded, e.g. if it is destined to a Mailing List. However, they can be used whenever limiting the responsibility of the Author Domain is considered useful. 2. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 3. The DKIM-Required Field This specification introduces a new message header field defined as follows, using grammar imported from RFC 5322 [RFC5322]. RFC 4871 [RFC4871] describes DKIM. dkim-required = "DKIM-Required:" required-domain CRLF required-domain = dot-atom The presence of a DKIM-Required field affects the validity of any DKIM-Signature that had signed it. A signer MAY add one DKIM- Required field, e.g. if instructed to do so by local configuration. However, a signer MUST NOT add more than one DKIM-Required field. Vesely Expires March 19, 2011 [Page 3] Internet-Draft DKIM Joint Signatures September 2010 When a verifier finds any DKIM-Required field within the header field names in the "h=" tag of the signature being verified, and none of the following conditions hold, the verifier SHOULD ignore the signature and return PERMFAIL (signature did not verify). The conditions are: 1. The required-domain matches the domain in this signature's "d=" tag; 2. another signature in the same message has a "d=" tag matching the required-domain, it includes this DKIM-Required field in its "h=" tag, and it verifies correctly; or 3. the verifier has access to a private key of the required-domain, i.e. it acts on behalf of it, and could produce the signature at point 2 itself if it wanted to. DKIM-Required fields that are not signed can be safely ignored. Software incapable of signing SHOULD NOT add these fields. 4. IANA Considerations The new header would have to be registered. 5. Security Considerations If a signer trusts that the (only) recipient of a message will duly sign it before exploding, and secure SMTP is used, then it MAY safely sign only a few header fields and a limited portion of the body. By adding a DKIM-Required header it effectively limits the responsibility of the Author Domain. Even if final recipients are not aware of this specification, after all required signatures have been added the Author Domain's status and reputation are good. 6. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. Vesely Expires March 19, 2011 [Page 4] Internet-Draft DKIM Joint Signatures September 2010 [RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, October 2008. Author's Address Alessandro Vesely v. L. Anelli 13 Milano, MI 20122 IT Email: vesely@tana.it Vesely Expires March 19, 2011 [Page 5]