Mandatory Tags for DKIM Signatures
draft-levine-dkim-conditional-04

Document Type Active Internet-Draft (individual)
Author John Levine 
Last updated 2020-08-30
Stream (None)
Intended RFC status (None)
Formats plain text html xml pdf htmlized (tools) htmlized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date
Responsible AD (None)
Send notices to (None)
Network Working Group                                          J. Levine
Internet-Draft                                      Taughannock Networks
Intended status: Standards Track                          30 August 2020
Expires: 3 March 2021

                   Mandatory Tags for DKIM Signatures
                    draft-levine-dkim-conditional-04

Abstract

   The DKIM protocol applies a cryptographic signature to an e-mail
   message.  This specification extends DKIM to allow new signature tags
   that validators are required to evaluate.  The first such tag
   specifies a second signature that must be present for a signature to
   be valid.

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 https://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 3 March 2021.

Copyright Notice

   Copyright (c) 2020 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 (https://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.

Levine                    Expires 3 March 2021                  [Page 1]
Internet-Draft            DKIM Mandatory Fields              August 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Mandatory DKIM header tags  . . . . . . . . . . . . . . . . .   3
     3.1.  Signature verification features . . . . . . . . . . . . .   3
     3.2.  Processing mandatory tags . . . . . . . . . . . . . . . .   4
     3.3.  Forward signature (!fs) tag . . . . . . . . . . . . . . .   4
   4.  Typical application scenarios . . . . . . . . . . . . . . . .   4
     4.1.  Sender use  . . . . . . . . . . . . . . . . . . . . . . .   4
     4.2.  Forwarder use . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Recipient use . . . . . . . . . . . . . . . . . . . . . .   5
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  -03 to -04  . . . . . . . . . . . . . . . . . . . . . . .   6
     7.2.  -02 to -03  . . . . . . . . . . . . . . . . . . . . . . .   7
     7.3.  -01 to -02  . . . . . . . . . . . . . . . . . . . . . . .   7
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   DKIM [RFC6376] defines a cryptographic header field consisting of a
   series of tags and values.  The values include signed hashes of some
   of the header fields and part or all of the body of a message.  The
   signature contains a domain name that is responsible for the
   signature.  The signature is valid if the hashes in the signature
   match the corresponding hashes of the message at validation time, the
   signature is validated by a public key retrieved from that
   responsible domain's DNS, and it is before the expiration time in the
   signature header field.

   This specification defines the syntax for new tags in a signature
   header field that specify additional conditions that must be
   satisfied for a signature to be valid.  The first such condition
   requires the presence of an additional signature from a specified
   different domain.  It also changes the DKIM version tag to a
   verification features tag to allow the new semantics of conditional
   signatures.

2.  Definitions

   The upper case 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
   [RFC2119].

Levine                    Expires 3 March 2021                  [Page 2]
Internet-Draft            DKIM Mandatory Fields              August 2020

   Syntax descriptions use Augmented BNF (ABNF)[RFC5234].
Show full document text