Skip to main content

Authentication-Results Registration for S/MIME signature verification
draft-melnikov-authentication-results-smime-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 7281.
Author Alexey Melnikov
Last updated 2013-03-13
RFC stream (None)
Formats
IETF conflict review conflict-review-melnikov-authentication-results-smime, conflict-review-melnikov-authentication-results-smime, conflict-review-melnikov-authentication-results-smime, conflict-review-melnikov-authentication-results-smime, conflict-review-melnikov-authentication-results-smime, conflict-review-melnikov-authentication-results-smime
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Became RFC 7281 (Informational)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-melnikov-authentication-results-smime-00
Network Working Group                                        A. Melnikov
Internet-Draft                                                 Isode Ltd
Intended status: Standards Track                          March 13, 2013
Expires: September 14, 2013

 Authentication-Results Registration for S/MIME signature verification
             draft-melnikov-authentication-results-smime-00

Abstract

   RFC 5451 specifies the Authentication-Results header field for
   conveying results of message authentication checks.  This document
   defines a new authentication method to be used in the Authentication-
   Results header field for S/MIME related signature checks.

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 September 14, 2013.

Copyright Notice

   Copyright (c) 2013 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.

Melnikov               Expires September 14, 2013               [Page 1]
Internet-DrafAuthentication-Results Registration for S/MIME   March 2013

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions Used in This Document . . . . . . . . . . . . . .   2
   3.  "smime" Authentication Method . . . . . . . . . . . . . . . .   2
     3.1.  S/MIME Results  . . . . . . . . . . . . . . . . . . . . .   2
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   3
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   4
   6.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

1.  Introduction

   [RFC5451] specifies the Authentication-Results header field for
   conveying results of message authentication checks.  This document
   defines a new authentication method to be used in the Authentication-
   Results header field for S/MIME related signature checks.

   [[Explain in more details use cases, such as a border MTA performing
   check and MUA showing results.]]

2.  Conventions Used in This Document

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

   The formal syntax uses the Augmented Backus-Naur Form (ABNF)
   [RFC5234] notation including the core rules defined in Appendix B of
   RFC 5234 [RFC5234].

3.  "smime" Authentication Method

3.1.  S/MIME Results

   The result values used by [RFC5751] are as follows:

   +-------------+-----------------------------------------------------+
   | Result code | Meaning                                             |
   +-------------+-----------------------------------------------------+
   | none        | The message was not signed.                         |
   |             |                                                     |
   | pass        | The message was signed, the signature or signatures |
   |             | were acceptable to the verifier, and the            |
   |             | signature(s) passed verification tests.             |
   |             |                                                     |
   | fail        | The message was signed and the signature or         |

Melnikov               Expires September 14, 2013               [Page 2]
Internet-DrafAuthentication-Results Registration for S/MIME   March 2013

   |             | signatures were acceptable to the verifier, but     |
   |             | they failed the verification test(s).               |
   |             |                                                     |
   | policy      | The message was signed but the signature or         |
   |             | signatures were not acceptable to the verifier.     |
   |             |                                                     |
   | neutral     | The message was signed but the signature or         |
   |             | signatures contained syntax errors or were not      |
   |             | otherwise able to be processed.  This result SHOULD |
   |             | also be used for other failures not covered         |
   |             | elsewhere in this list.                             |
   |             |                                                     |
   | temperror   | The message could not be verified due to some error |
   |             | that is likely transient in nature, such as a       |
   |             | temporary inability to retrieve a public key.  A    |
   |             | later attempt may produce a final result.           |
   |             |                                                     |
   | permerror   | The message could not be verified due to some error |
   |             | that is unrecoverable, such as a required header    |
   |             | field being absent.  A later attempt is unlikely to |
   |             | produce a final result.                             |
   +-------------+-----------------------------------------------------+

   A signature is "acceptable to the verifier" if it passes local policy
   checks (or there are no specific local policy checks).  For example,
   a verifier might require that the signature(s) on the message be
   added using the DNS domain present in the From: header field of the
   message, thus making third-party signatures unacceptable.  [RFC5751]
   advises that if a message fails verification, it should be treated as
   an unsigned message.  A report of "fail" here permits the receiver of
   the report to decide how to handle the failure.  A report of
   "neutral" or "none" preempts that choice, ensuring the message will
   be treated as if it had not been signed.

4.  IANA Considerations

   IANA is requested to add the the following entries to the "Email
   Authentication Methods" subregistry of the "Email Authentication
   Parameters" registry:

   +--------+-----------+--------+------------------+------------------+
   | Method | Defined   | ptype  | property         | value            |
   +--------+-----------+--------+------------------+------------------+
   | smime  | [RFC5751] | body   | smime-part       | The MIME body    |
   |        |           |        |                  | part reference   |
   |        |           |        |                  | which contains   |
   |        |           |        |                  | the signature.   |

Melnikov               Expires September 14, 2013               [Page 3]
Internet-DrafAuthentication-Results Registration for S/MIME   March 2013

   |        |           |        |                  | See definition   |
   |        |           |        |                  | of <section> in  |
   |        |           |        |                  | Section 6.4.5 of |
   |        |           |        |                  | [RFC3501]        |
   |        |           |        |                  |                  |
   | smime  | [RFC5751] | body   | smime-identifier | The email        |
   |        |           |        |                  | address          |
   |        |           |        |                  | [RFC5322]        |
   |        |           |        |                  | associated with  |
   |        |           |        |                  | the S/MIME       |
   |        |           |        |                  | signature.       |
   +--------+-----------+--------+------------------+------------------+

   IANA is requested to add the the following entries to the "Email
   Authentication Result Names" subregistry of the "Email Authentication
   Parameters" registry:

   +-------------+--------------+------------+---------------+---------+
   | Code        | Defined      | Auth       | Meaning       | Status  |
   |             |              | Method     |               |         |
   +-------------+--------------+------------+---------------+---------+
   | none        | this         | smime      | [this memo]   | active  |
   |             | document     |            | Section 3.1   |         |
   |             |              |            |               |         |
   | pass        | this         | smime      | [this memo]   | active  |
   |             | document     |            | Section 3.1   |         |
   |             |              |            |               |         |
   | fail        | this         | smime      | [this memo]   | active  |
   |             | document     |            | Section 3.1   |         |
   |             |              |            |               |         |
   | policy      | this         | smime      | [this memo]   | active  |
   |             | document     |            | Section 3.1   |         |
   |             |              |            |               |         |
   | neutral     | this         | smime      | [this memo]   | active  |
   |             | document     |            | Section 3.1   |         |
   |             |              |            |               |         |
   | temperror   | this         | smime      | [this memo]   | active  |
   |             | document     |            | Section 3.1   |         |
   |             |              |            |               |         |
   | permerror   | this         | smime      | [this memo]   | active  |
   |             | document     |            | Section 3.1   |         |
   +-------------+--------------+------------+---------------+---------+

5.  Security Considerations

   TBD

Melnikov               Expires September 14, 2013               [Page 4]
Internet-DrafAuthentication-Results Registration for S/MIME   March 2013

6.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC5234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234, January 2008.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              October 2008.

   [RFC5451]  Kucherawy, M., "Message Header Field for Indicating
              Message Authentication Status", RFC 5451, April 2009.

   [RFC5751]  Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
              Mail Extensions (S/MIME) Version 3.2 Message
              Specification", RFC 5751, January 2010.

Appendix A.  Acknowledgements

   Thank you to Murray S.  Kucherawy for comments and corrections on
   this document.

Author's Address

   Alexey Melnikov
   Isode Ltd
   5 Castle Business Village
   36 Station Road
   Hampton, Middlesex  TW12 2BX
   UK

   EMail: Alexey.Melnikov@isode.com

Melnikov               Expires September 14, 2013               [Page 5]