draft-ietf-uta-email-tls-certs-02.txt | draft-ietf-uta-email-tls-certs-03.txt | |||
---|---|---|---|---|
Network Working Group A. Melnikov | Network Working Group A. Melnikov | |||
Internet-Draft Isode Ltd | Internet-Draft Isode Ltd | |||
Updates: 2595, 3207, 3501, 5804 (if March 23, 2015 | Updates: 2595, 3207, 3501, 5804 (if June 17, 2015 | |||
approved) | approved) | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: September 24, 2015 | Expires: December 19, 2015 | |||
Updated TLS Server Identity Check Procedure for Email Related Protocols | Updated TLS Server Identity Check Procedure for Email Related Protocols | |||
draft-ietf-uta-email-tls-certs-02 | draft-ietf-uta-email-tls-certs-03 | |||
Abstract | Abstract | |||
This document describes TLS server identity verification procedure | This document describes TLS server identity verification procedure | |||
for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces | for SMTP Submission, IMAP, POP and ManageSieve clients. It replaces | |||
Section 2.4 of RFC 2595. | Section 2.4 of RFC 2595. | |||
Status of This Memo | Status of This Memo | |||
This Internet-Draft is submitted in full conformance with the | This Internet-Draft is submitted in full conformance with the | |||
skipping to change at page 1, line 34 | skipping to change at page 1, line 34 | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at http://datatracker.ietf.org/drafts/current/. | Drafts is at http://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on September 24, 2015. | This Internet-Draft will expire on December 19, 2015. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2015 IETF Trust and the persons identified as the | Copyright (c) 2015 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(http://trustee.ietf.org/license-info) in effect on the date of | (http://trustee.ietf.org/license-info) in effect on the date of | |||
publication of this document. Please review these documents | publication of this document. Please review these documents | |||
skipping to change at page 2, line 10 | skipping to change at page 2, line 10 | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 | |||
2. Conventions Used in This Document . . . . . . . . . . . . . . 2 | 2. Conventions Used in This Document . . . . . . . . . . . . . . 2 | |||
3. Email Server Certificate Verification Rules . . . . . . . . . 3 | 3. Email Server Certificate Verification Rules . . . . . . . . . 3 | |||
4. Compliance Checklist for Certificate Authorities . . . . . . 4 | 4. Compliance Checklist for Certification Authorities . . . . . 4 | |||
5. Compliance Checklist for Mail Service Providers and | 5. Compliance Checklist for Mail Service Providers and | |||
Certificate Signing Request generation tools . . . . . . . . 4 | Certificate Signing Request generation tools . . . . . . . . 4 | |||
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 5 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 6 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 6 | 9.2. Informative References . . . . . . . . . . . . . . . . . 6 | |||
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 7 | |||
Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 7 | Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 7 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
1. Introduction | 1. Introduction | |||
Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is | Use of TLS by SMTP Submission, IMAP, POP and ManageSieve clients is | |||
described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804] | described in [RFC3207], [RFC3501], [RFC2595] and [RFC5804] | |||
respectively. Each of the documents describes slightly different | respectively. Each of the documents describes slightly different | |||
rules for server certificate identity verification (or doesn't define | rules for server certificate identity verification (or doesn't define | |||
any rules at all). In reality, email client and server developers | any rules at all). In reality, email client and server developers | |||
implement many of these protocols at the same time, so it would be | implement many of these protocols at the same time, so it would be | |||
good to define modern and consistent rules for verifying email server | good to define modern and consistent rules for verifying email server | |||
identities using TLS. | identities using TLS. | |||
This document describes the updated TLS server identity verification | This document describes the updated TLS server identity verification | |||
procedure for SMTP Submission [RFC4409] [RFC3207], IMAP [RFC3501], | procedure for SMTP Submission [RFC6409] [RFC3207], IMAP [RFC3501], | |||
POP [RFC1939] and ManageSieve [RFC5804] clients. It replaces | POP [RFC1939] and ManageSieve [RFC5804] clients. It replaces | |||
Section 2.4 of RFC 2595. | Section 2.4 of RFC 2595. | |||
Note that this document doesn't apply to use of TLS in MTA-to-MTA | Note that this document doesn't apply to use of TLS in MTA-to-MTA | |||
SMTP. | SMTP. | |||
The main goal of the document is to provide consistent TLS server | The main goal of the document is to provide consistent TLS server | |||
identity verification procedure across multiple email related | identity verification procedure across multiple email related | |||
protocols. This should make it easier for Certificate Authorities | protocols. This should make it easier for Certification Authorities | |||
and ISPs to deploy TLS for email use, and would enable email client | and ISPs to deploy TLS for email use, and would enable email client | |||
developers to write more secure code. | developers to write more secure code. | |||
2. Conventions Used in This Document | 2. Conventions Used in This Document | |||
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this | |||
document are to be interpreted as described in [RFC2119]. | document are to be interpreted as described in [RFC2119]. | |||
3. Email Server Certificate Verification Rules | 3. Email Server Certificate Verification Rules | |||
skipping to change at page 4, line 5 | skipping to change at page 4, line 5 | |||
5. Email protocols allow use of certain wilcards in identifiers | 5. Email protocols allow use of certain wilcards in identifiers | |||
presented by email servers. The "*" wildcard character MAY be | presented by email servers. The "*" wildcard character MAY be | |||
used as the left-most name component of DNS-ID or CN-ID in the | used as the left-most name component of DNS-ID or CN-ID in the | |||
certificate. For example, a DNS-ID of *.example.com would match | certificate. For example, a DNS-ID of *.example.com would match | |||
a.example.com, foo.example.com, etc. but would not match | a.example.com, foo.example.com, etc. but would not match | |||
example.com. Note that the wildcard character MUST NOT be used | example.com. Note that the wildcard character MUST NOT be used | |||
as a fragment of the left-most name component (e.g., | as a fragment of the left-most name component (e.g., | |||
*oo.example.com, f*o.example.com, or foo*.example.com). | *oo.example.com, f*o.example.com, or foo*.example.com). | |||
4. Compliance Checklist for Certificate Authorities | 4. Compliance Checklist for Certification Authorities | |||
1. CA MUST support issuance of server certificates with DNS-ID | 1. CA MUST support issuance of server certificates with DNS-ID | |||
identifier type (subjectAltName of dNSName type [RFC5280]). | identifier type (subjectAltName of dNSName type [RFC5280]). | |||
2. CA MUST support issuance of server certificates with SRV-ID | 2. CA MUST support issuance of server certificates with SRV-ID | |||
identifier type (subjectAltName of SRVName type [RFC4985]) for | identifier type (subjectAltName of SRVName type [RFC4985]) for | |||
each type of email service. | each type of email service. | |||
3. For backward compatibility with deployed client base, CA MUST | 3. For backward compatibility with deployed client base, CA MUST | |||
support issuance of server certificates with CN-ID identifier | support issuance of server certificates with CN-ID identifier | |||
skipping to change at page 5, line 6 | skipping to change at page 5, line 6 | |||
DNS-ID or CN-ID in Certificate Signing Requests. | DNS-ID or CN-ID in Certificate Signing Requests. | |||
6. Examples | 6. Examples | |||
Consider an IMAP-accessible email server which supports both IMAP and | Consider an IMAP-accessible email server which supports both IMAP and | |||
IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email | IMAPS (IMAP-over-TLS) at the host "mail.example.net" servicing email | |||
addresses of the form "user@example.net" and discoverable via DNS SRV | addresses of the form "user@example.net" and discoverable via DNS SRV | |||
lookups in domain "example.net" (DNS SRV records | lookups in domain "example.net" (DNS SRV records | |||
"_imap._tcp.example.net" and "_imaps._tcp.example.net"). A | "_imap._tcp.example.net" and "_imaps._tcp.example.net"). A | |||
certificate for this service needs to include SRV-IDs of | certificate for this service needs to include SRV-IDs of | |||
"_imap.example.net" and "_imaps.example.net" (see [RFC6186]. Note | "_imap.example.net" (when STARTTLS is used on the IMAP port) and | |||
that unlike DNS SRV there is no "_tcp" component in SRV-IDs) along | "_imaps.example.net" (when TLS is used on IMAPS port). See [RFC6186] | |||
with DNS-IDs of "example.net" and "mail.example.net". It might also | for more details. (Note that unlike DNS SRV there is no "_tcp" | |||
include CN-IDs of "mail.example.net" for backward compatibility with | component in SRV-IDs) along with DNS-IDs of "example.net" and | |||
deployed infrastructure. | "mail.example.net". It might also include CN-IDs of | |||
"mail.example.net" for backward compatibility with deployed | ||||
infrastructure. | ||||
Consider an SMTP Submission server at the host "submit.example.net" | Consider an SMTP Submission server at the host "submit.example.net" | |||
servicing email addresses of the form "user@example.net" and | servicing email addresses of the form "user@example.net" and | |||
discoverable via DNS SRV lookups in domain "example.net" (DNS SRV | discoverable via DNS SRV lookups in domain "example.net" (DNS SRV | |||
records "_submission._tcp.example.net"). A certificate for this | records "_submission._tcp.example.net"). A certificate for this | |||
service needs to include SRV-IDs of "_submission.example.net" (see | service needs to include SRV-IDs of "_submission.example.net" (see | |||
[RFC6186]) along with DNS-IDs of "example.net" and | [RFC6186]) along with DNS-IDs of "example.net" and | |||
"submit.example.net". It might also include CN-IDs of | "submit.example.net". It might also include CN-IDs of | |||
"submit.example.net" for backward compatibility with deployed | "submit.example.net" for backward compatibility with deployed | |||
infrastructure. | infrastructure. | |||
skipping to change at page 5, line 43 | skipping to change at page 5, line 45 | |||
7. IANA Considerations | 7. IANA Considerations | |||
This document doesn't require any action from IANA. | This document doesn't require any action from IANA. | |||
8. Security Considerations | 8. Security Considerations | |||
The goal of this document is to improve interoperability and thus | The goal of this document is to improve interoperability and thus | |||
security of email clients wishing to access email servers over TLS | security of email clients wishing to access email servers over TLS | |||
protected email protocols, by specifying a consistent set of rules | protected email protocols, by specifying a consistent set of rules | |||
that email service providers, email client writers and certificate | that email service providers, email client writers and Certification | |||
authorities can use when creating server certificates. | Authorities can use when creating server certificates. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, March 1997. | Requirement Levels", BCP 14, RFC 2119, March 1997. | |||
[RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, | |||
October 2008. | October 2008. | |||
[RFC4409] Gellens, R. and J. Klensin, "Message Submission for Mail", | [RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", | |||
RFC 4409, April 2006. | STD 72, RFC 6409, November 2011. | |||
[RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | [RFC3207] Hoffman, P., "SMTP Service Extension for Secure SMTP over | |||
Transport Layer Security", RFC 3207, February 2002. | Transport Layer Security", RFC 3207, February 2002. | |||
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | |||
4rev1", RFC 3501, March 2003. | 4rev1", RFC 3501, March 2003. | |||
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | [RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | |||
STD 53, RFC 1939, May 1996. | STD 53, RFC 1939, May 1996. | |||
skipping to change at page 7, line 7 | skipping to change at page 7, line 7 | |||
9.2. Informative References | 9.2. Informative References | |||
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC | [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC | |||
2595, June 1999. | 2595, June 1999. | |||
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email | [RFC6186] Daboo, C., "Use of SRV Records for Locating Email | |||
Submission/Access Services", RFC 6186, March 2011. | Submission/Access Services", RFC 6186, March 2011. | |||
Appendix A. Acknowledgements | Appendix A. Acknowledgements | |||
Thank you to Chris Newman for comments on this document. | Thank you to Chris Newman and Sean Turner for comments on this | |||
document. | ||||
The editor of this document copied lots of text from RFC 2595 and RFC | The editor of this document copied lots of text from RFC 2595 and RFC | |||
6125, so the hard work of editors of these document is appreciated. | 6125, so the hard work of editors of these document is appreciated. | |||
Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 | Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 | |||
[[Note to RFC Editor: Please delete this section before publication]] | [[Note to RFC Editor: Please delete this section before publication]] | |||
Added another example, clarified that subjectAltName and DNS SRV are | Added another example, clarified that subjectAltName and DNS SRV are | |||
using slightly different syntax. | using slightly different syntax. | |||
End of changes. 14 change blocks. | ||||
19 lines changed or deleted | 23 lines changed or added | |||
This html diff was produced by rfcdiff 1.42. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |