Using Secure DNS to Associate Certificates with Domain Names for S/MIME
RFC 8162
| Document | Type |
RFC - Experimental
(May 2017; No errata)
Was draft-ietf-dane-smime (dane WG)
|
|
|---|---|---|---|
| Last updated | 2017-05-31 | ||
| Replaces | draft-hoffman-dane-smime | ||
| Stream | IETF | ||
| Formats | plain text pdf html bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Ólafur Guðmundsson | ||
| Shepherd write-up | Show (last changed 2017-02-05) | ||
| IESG | IESG state | RFC 8162 (Experimental) | |
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Stephen Farrell | ||
| Send notices to | (None) | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | RFC-Ed-Ack | ||
Internet Engineering Task Force (IETF) P. Hoffman
Request for Comments: 8162 ICANN
Category: Experimental J. Schlyter
ISSN: 2070-1721 Kirei AB
May 2017
Using Secure DNS to Associate Certificates with Domain Names for S/MIME
Abstract
This document describes how to use secure DNS to associate an S/MIME
user's certificate with the intended domain name, similar to the way
that DNS-Based Authentication of Named Entities (DANE), RFC 6698,
does for TLS.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. 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). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 7841.
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/rfc8162.
Copyright Notice
Copyright (c) 2017 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.
Hoffman & Schlyter Experimental [Page 1]
RFC 8162 DNS-Based Authentication for S/MIME May 2017
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Experiment Goal . . . . . . . . . . . . . . . . . . . . . 3
2. The SMIMEA Resource Record . . . . . . . . . . . . . . . . . 4
3. Location of the SMIMEA Record . . . . . . . . . . . . . . . . 4
4. Email Address Variants and Internationalization
Considerations . . . . . . . . . . . . . . . . . . . . . . . 5
5. Mandatory-to-Implement Features . . . . . . . . . . . . . . . 6
6. Application Use of S/MIME Certificate Associations . . . . . 6
7. Certificate Size and DNS . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
9.1. Response Size . . . . . . . . . . . . . . . . . . . . . . 8
9.2. Email Address Information Leak . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 10
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
S/MIME [RFC5751] messages often contain a certificate (some messages
contain more than one certificate). These certificates assist in
authenticating the sender of the message and can be used for
encrypting messages that will be sent in reply. In order for the
S/MIME receiver to authenticate that a message is from the sender
identified in the message, the receiver's Mail User Agent (MUA) must
validate that this certificate is associated with the purported
sender. Currently, the MUA must trust a trust anchor upon which the
sender's certificate is rooted and must successfully validate the
certificate. There are other requirements on the MUA, such as
associating the identity in the certificate with that of the message,
that are out of scope for this document.
Some people want to authenticate the association of the sender's
certificate with the sender without trusting a configured trust
anchor. Others to want mitigate the difficulty of finding
certificates from outside the enterprise. Given that the DNS
Show full document text