Using Secure DNS to Associate Certificates with Domain Names For S/MIME
draft-ietf-dane-smime-05
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 8162.
|
|
---|---|---|---|
Authors | Paul E. Hoffman , Jakob Schlyter | ||
Last updated | 2014-02-14 | ||
Replaces | draft-hoffman-dane-smime | ||
RFC stream | Internet Engineering Task Force (IETF) | ||
Formats | |||
Reviews |
GENART Last Call review
(of
-15)
by Dale Worley
Ready w/nits
|
||
Additional resources | Mailing list discussion | ||
Stream | WG state | WG Document | |
Document shepherd | (None) | ||
IESG | IESG state | Became RFC 8162 (Experimental) | |
Consensus boilerplate | Unknown | ||
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
draft-ietf-dane-smime-05
quot;) is a valid character in a local part, but would wreak havoc in a domain name unless the application using the name somehow quoted it. Similarly, Hoffman & Schlyter Expires August 18, 2014 [Page 4] Internet-Draft DNS-Based Authentication for S/MIME February 2014 RFC 6530 allows non-ASCII characters in local parts, and encoding a local part with non-ASCII characters with Base32 renders the name usable in applications that use the DNS. Wildcards can be more useful for SMIMEA than they are for TLSA. If a site publishes a trust anchor certificate for all users on the site (certificate usage 0 or 2), it could make sense to use a wildcard resource record such as "*._smimecert.example.com". 4. Mandatory-to-Implement Features S/MIME MUAs conforming to this specification MUST be able to correctly interpret SMIMEA records with certificate usages 0, 1, 2, and 3. S/MIME MUAs conforming to this specification MUST be able to compare a certificate association with a certificate offered by another S/MIME MUA using selector types 0 and 1, and matching type 0 (no hash used) and matching type 1 (SHA-256), and SHOULD be able to make such comparisons with matching type 2 (SHA-512). 5. IANA Considerations 5.1. SMIMEA RRtype This document uses a new DNS RRtype, SMIMEA, whose value will be allocated by IANA from the Resource Record (RR) TYPEs subregistry of the Domain Name System (DNS) Parameters registry. TODO: there needs to be new registries for certificate usages, selectors, and maching types, pre-populated with the values from TLSA. 6. Security Considerations DNS zones that are signed with DNSSEC using NSEC for denial of existence are susceptible to zone-walking, a mechanism that allow someone to enumerate all the names in the zone. Someone who wanted to collect email addresses from a zone that uses SMIMEA might use such a mechanism. DNSSEC-signed zones using NSEC3 for denial of existence are significantly less susceptible to zone-walking. Someone could still attempt a dictionary attack on the zone to find SMIMEA records, just as they can use dictionary attacks on an SMTP server to see which addresses are valid. Client treatment of any information included in the trust anchor is a matter of local policy. This specification does not mandate that such information be inspected or validated by the domain name administrator. Hoffman & Schlyter Expires August 18, 2014 [Page 5] Internet-Draft DNS-Based Authentication for S/MIME February 2014 7. Acknowledgements Miek Gieben and Martin Pels contributed technical ideas and support to this document. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005. [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005. [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006. [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008. [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010. [RFC5754] Turner, S., "Using SHA2 Algorithms with Cryptographic Message Syntax", RFC 5754, January 2010. [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, August 2012. Hoffman & Schlyter Expires August 18, 2014 [Page 6] Internet-Draft DNS-Based Authentication for S/MIME February 2014 8.2. Informative References [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [RFC6530] Klensin, J. and Y. Ko, "Overview and Framework for Internationalized Email", RFC 6530, February 2012. Authors' Addresses Paul Hoffman VPN Consortium Email: paul.hoffman@vpnc.org Jakob Schlyter Kirei AB Email: jakob@kirei.se Hoffman & Schlyter Expires August 18, 2014 [Page 7]