Authentication-Results Registration for Differentiating among Cryptographic Results
RFC 6008

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 04

Internet Engineering Task Force (IETF)                      M. Kucherawy
Request for Comments: 6008                               Cloudmark, Inc.
Category: Standards Track                                 September 2010
ISSN: 2070-1721

        Authentication-Results Registration for Differentiating
                      among Cryptographic Results

Abstract

   This memo updates the registry of properties in Authentication-
   Results: message header fields to allow a multiple-result report to
   distinguish among one or more cryptographic signatures on a message,
   thus associating specific results with the signatures they represent.

Status of This Memo

   This is an Internet Standards Track document.

   This document is a product of the Internet Engineering Task Force
   (IETF).  It represents the consensus of the IETF community.  It has
   received public review and has been approved for publication by the
   Internet Engineering Steering Group (IESG).  Further information on
   Internet Standards is available in Section 2 of RFC 5741.

   Information about the current status of this document, any errata,
   and how to provide feedback on it may be obtained at
   http://www.rfc-editor.org/info/rfc6008.

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.

Kucherawy                    Standards Track                    [Page 1]
RFC 6008           Auth-Results Header.b Registration     September 2010

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Keywords  . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   3.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . . . 2
   4.  Definition  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
     6.1.  Improvement . . . . . . . . . . . . . . . . . . . . . . . . 4
     6.2.  Result Forgeries  . . . . . . . . . . . . . . . . . . . . . 4
     6.3.  New Schemes with Small Signatures . . . . . . . . . . . . . 4
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
     7.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
     7.2.  Informative References  . . . . . . . . . . . . . . . . . . 5
   Appendix A.  Authentication-Results Example . . . . . . . . . . . . 6
     A.1.  Multiple DKIM Signatures with One Failure . . . . . . . . . 6
   Appendix B.  Acknowledgements . . . . . . . . . . . . . . . . . . . 7

1.  Introduction

   [AUTHRES] defined a new header field for electronic mail messages
   that presents the results of a message authentication effort in a
   machine-readable format.  Absent from that specification was the
   means by which the results of two cryptographic signatures, such as
   those provided by [DKIM], can both have results reported in an
   unambiguous manner.

   Fortunately, [AUTHRES] created IANA registries of reporting
   properties, enabling an easy remedy for this problem.  This memo thus
   registers an additional reporting property allowing a result to be
   associated with a specific digital signature.

2.  Keywords

   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 [KEYWORDS].

3.  Discussion

   A message can contain multiple signatures of a common sender
   authentication mechanism, such as [DKIM].  For example, a DomainKeys
   Identified Mail (DKIM) signer could apply signatures using two or
   more different message canonicalization algorithms to determine the
   resistance of each to being broken in transit.

Kucherawy                    Standards Track                    [Page 2]
RFC 6008           Auth-Results Header.b Registration     September 2010

   By applying supported "ptype.property" combinations (cf. the ABNF in
   [AUTHRES]), a result can be associated with a given signature
   provided the signatures are all unique within one of the registered
   values (e.g., all of them had unique "header.d" or "header.i"
   values).  This is not guaranteed, however; a single signing agent
   might have practical reasons for affixing multiple signatures with
   the same "d=" values while varying other signature parameters.  This