draft-ietf-uta-email-tls-certs-05.txt | draft-ietf-uta-email-tls-certs-06.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 September 20, 2015 | Updates: 2595, 3207, 3501, 5804 (if December 4, 2015 | |||
approved) | approved) | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: March 23, 2016 | Expires: June 6, 2016 | |||
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-05 | draft-ietf-uta-email-tls-certs-06 | |||
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, updates Section 4.1 of RFC 3207, updates | Section 2.4 of RFC 2595, updates Section 4.1 of RFC 3207, updates | |||
Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804. | Section 11.1 of RFC 3501, updates Section 2.2.1 of RFC 5804. | |||
Status of This Memo | Status of This Memo | |||
skipping to change at page 1, line 35 | skipping to change at page 1, line 35 | |||
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 March 23, 2016. | This Internet-Draft will expire on June 6, 2016. | |||
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 12 | skipping to change at page 2, line 12 | |||
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 . . . . . . . . . . . . . . 3 | 2. Conventions Used in This Document . . . . . . . . . . . . . . 3 | |||
3. Email Server Certificate Verification Rules . . . . . . . . . 3 | 3. Email Server Certificate Verification Rules . . . . . . . . . 3 | |||
4. Compliance Checklist for Certification Authorities . . . . . 4 | 4. Compliance Checklist for Certification Authorities . . . . . 5 | |||
4.1. Notes on handling of SRV-ID by Certificate Authorities . 5 | ||||
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 . . . . . . . . 5 | |||
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 5 | 5.1. Notes on hosted domains . . . . . . . . . . . . . . . . . 6 | |||
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 | 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 6 | |||
8. Security Considerations . . . . . . . . . . . . . . . . . . . 6 | 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 | |||
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 | 8. Security Considerations . . . . . . . . . . . . . . . . . . . 7 | |||
9.1. Normative References . . . . . . . . . . . . . . . . . . 6 | 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 | |||
9.2. Informative References . . . . . . . . . . . . . . . . . 7 | 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 | |||
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 9 | 9.2. Informative References . . . . . . . . . . . . . . . . . 8 | |||
Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 9 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 10 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 | Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 10 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 | ||||
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 [RFC6409] [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 | This document provides a consistent TLS server identity verification | |||
identity verification procedure across multiple email related | procedure across multiple email related protocols. This should make | |||
protocols. This should make it easier for Certification Authorities | it easier for Certification Authorities and ISPs to deploy TLS for | |||
and ISPs to deploy TLS for email use, and would enable email client | email use, and would enable email client developers to write more | |||
developers to write more secure code. | 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]. | |||
The following terms or concepts are used through the document: | The following terms or concepts are used through the document: | |||
reference identifier: (as defined in [RFC6125]) One of the domain | reference identifier: (as defined in [RFC6125]) One of the domain | |||
names associated by the email (i.e., an SMTP, IMAP, POP3 or | names associated by the email (i.e., an SMTP, IMAP, POP3 or | |||
ManageSieve) client with the destination email server and | ManageSieve) client with the target email server and optionally an | |||
optionally an application service type for performing name checks | application service type for performing name checks on the server | |||
on the server certificate. When name checks are applicable, at | certificate. When name checks are applicable, at least one of the | |||
least one of the reference identifiers MUST match an [RFC6125] | reference identifiers MUST match an [RFC6125] DNS-ID or SRV-ID (or | |||
DNS-ID or SRV-ID (or if none are present the [RFC6125] CN-ID) of | if none are present the [RFC6125] CN-ID) of the server | |||
the server certificate. | certificate. | |||
CN-ID, DNS-ID, SRV-ID and URI-ID are identifier types (see [RFC6125] | ||||
for details). For convenience, their short definitions from | ||||
[RFC6125] are listed below: | ||||
CN-ID = a Relative Distinguished Name (RDN) in the certificate | ||||
subject field that contains one and only one attribute-type-and- | ||||
value pair of type Common Name (CN), where the value matches the | ||||
overall form of a domain name (informally, dot- separated letter- | ||||
digit-hyphen labels). | ||||
DNS-ID = a subjectAltName entry of type dNSName | ||||
SRV-ID = a subjectAltName entry of type otherName whose name form | ||||
is SRVName | ||||
URI-ID = a subjectAltName entry of type uniformResourceIdentifier | ||||
whose value includes both (i) a "scheme" and (ii) a "host" | ||||
component (or its equivalent) that matches the "reg-name" rule | ||||
(where the quoted terms represent the associated [RFC5234] | ||||
productions from [RFC3986]). | ||||
3. Email Server Certificate Verification Rules | 3. Email Server Certificate Verification Rules | |||
During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3 | During a TLS negotiation, an email client (i.e., an SMTP, IMAP, POP3 | |||
or ManageSieve client) MUST check its understanding of the server | or ManageSieve client) MUST check its understanding of the server | |||
hostname against the server's identity as presented in the server | hostname against the server's identity as presented in the server | |||
Certificate message, in order to prevent man-in-the-middle attacks. | Certificate message, in order to prevent man-in-the-middle attacks. | |||
This check is only performed after the server certificate passes | ||||
certification path validation as described in Section 6 of [RFC5280]. | ||||
Matching is performed according to the rules specified in Section 6 | Matching is performed according to the rules specified in Section 6 | |||
of [RFC6125], including "certificate pinning" and the procedure on | of [RFC6125], including "certificate pinning" and the procedure on | |||
failure to match. The following inputs are used by the verification | failure to match. The following inputs are used by the verification | |||
procedure used in [RFC6125]: | procedure used in [RFC6125]: | |||
1. For DNS-ID and CN-ID identifier types the client MUST use one or | 1. For DNS-ID and CN-ID identifier types the client MUST use one or | |||
more of the following as "reference identifiers": (a) the right | more of the following as "reference identifiers": (a) the domain | |||
hand side of the email address, (b) the hostname it used to open | portion of the user's email address, (b) the hostname it used to | |||
the connection (without CNAME canonicalization). The client MAY | open the connection (without CNAME canonicalization). The client | |||
also use (c) a value securely derived from (a) or (b), such as | MAY also use (c) a value securely derived from (a) or (b), such | |||
using "secure" DNSSEC validated lookup. | as using "secure" DNSSEC validated lookup. | |||
2. When using email service discovery procedure specified in | 2. When using email service discovery procedure specified in | |||
[RFC6186] the client MUST also use the right hand side of the | [RFC6186] the client MUST also use the domain portion of the | |||
email address as another "reference identifier" to compare | user's email address as another "reference identifier" to compare | |||
against SRV-ID identifier in the server certificate. | against SRV-ID identifier in the server certificate. | |||
The rules and guidelines defined in [RFC6125] apply to an email | The rules and guidelines defined in [RFC6125] apply to an email | |||
server certificates, with the following supplemental rules: | server certificate, with the following supplemental rules: | |||
1. Support for the DNS-ID identifier type (subjectAltName of dNSName | 1. Support for the DNS-ID identifier type (subjectAltName of dNSName | |||
type [RFC5280]) is REQUIRED in Email client software | type [RFC5280]) is REQUIRED in Email client software | |||
implementations. | implementations. | |||
2. Support for the SRV-ID identifier type (subjectAltName of SRVName | 2. Support for the SRV-ID identifier type (subjectAltName of SRVName | |||
type [RFC4985]) is REQUIRED for email client software | type [RFC4985]) is REQUIRED for email client software | |||
implementations that support [RFC6186]. List of SRV-ID types for | implementations that support [RFC6186]. List of SRV-ID types for | |||
email services is specified in [RFC6186]. For the ManageSieve | email services is specified in [RFC6186]. For the ManageSieve | |||
protocol the service name "sieve" is used. | protocol the service name "sieve" is used. | |||
skipping to change at page 4, line 36 | skipping to change at page 5, line 12 | |||
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 Certification 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. See Section 4.1 for more discussion | |||
on what this means for Certification Authorities. | ||||
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 | |||
type (CN attribute from the subject name, see [RFC6125]). | type (CN attribute from the subject name, see [RFC6125]). | |||
4. CA MAY allow "*" (wildcard) as the left-most name component of | 4. CA MAY allow "*" (wildcard) as the left-most name component of | |||
DNS-ID or CN-ID in server certificates it issues. | DNS-ID or CN-ID in server certificates it issues. | |||
4.1. Notes on handling of SRV-ID by Certificate Authorities | ||||
TBD. List some possible recommendations and limitations of different | ||||
approaches. | ||||
5. Compliance Checklist for Mail Service Providers and Certificate | 5. Compliance Checklist for Mail Service Providers and Certificate | |||
Signing Request generation tools | Signing Request generation tools | |||
1. SHOULD include the DNS-ID identifier type (subjectAltName of | 1. MUST include the DNS-ID identifier type in Certificate Signing | |||
dNSName type [RFC5280]) in Certificate Signing Requests for both | Requests for the host name(s) where the email server(s) are | |||
the right hand side of served email addresses, as well as for the | running. SHOULD include the DNS-ID identifier type in | |||
host name where the email server(s) are running. | Certificate Signing Requests for the domain portion of served | |||
email addresses. | ||||
2. If the email services provided are discoverable using DNS SRV as | 2. If the email services provided are discoverable using DNS SRV as | |||
specified in [RFC6186], the Mail Service Provider MUST include | specified in [RFC6186], the Mail Service Provider MUST include | |||
the SRV-ID identifier type (subjectAltName of SRVName type | the SRV-ID identifier type for each type of email service in | |||
[RFC4985]) for each type of email service in Certificate Signing | Certificate Signing Requests. | |||
Requests. | ||||
3. SHOULD include CN-ID identifier type (CN attribute from the | 3. SHOULD include CN-ID identifier type for the host name where the | |||
subject name, see [RFC6125]) for the host name where the email | email server(s) is running in Certificate Signing Requests for | |||
server(s) is running in Certificate Signing Requests for backward | backward compatibility with deployed email clients. (Note, a | |||
compatibility with deployed email clients. (Note, a certificate | certificate can only include a single CN-ID, so if a mail service | |||
can only include a single CN-ID, so if a mail service is running | is running on multiple hosts, either each host has to use | |||
on multiple hosts, either each host has to use different | different certificate with its own CN-ID, a single certificate | |||
certificate with its own CN-ID, a single certificate with | with multiple DNS-IDs, or a single certificate with wildcard in | |||
multiple DNS-IDs, or a single certificate with wildcard in CN-ID | CN-ID can be used). | |||
can be used). | ||||
4. MAY include "*" (wildcard) as the left-most name component of | 4. MAY include "*" (wildcard) as the left-most name component of | |||
DNS-ID or CN-ID in Certificate Signing Requests. | DNS-ID or CN-ID in Certificate Signing Requests. | |||
5.1. Notes on hosted domains | ||||
TBD. Compare one certificate that contains all hosted domains versa | ||||
use of SNI or separate IPs for each hosted domain with its own | ||||
certificate. | ||||
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". A certificate for this | addresses of the form "user@example.net". A certificate for this | |||
service needs to include DNS-IDs of "example.net" (because it is the | service needs to include DNS-IDs of "example.net" (because it is the | |||
right hand side of emails) and "mail.example.net" (this is what a | domain portion of emails) and "mail.example.net" (this is what a user | |||
user of this server enters manually, if not using [RFC6186]). It | of this server enters manually, if not using [RFC6186]). It might | |||
might also include CN-IDs of "mail.example.net" for backward | also include CN-ID of "mail.example.net" for backward compatibility | |||
compatibility with deployed infrastructure. | with deployed infrastructure. | |||
Consider the IMAP-accessible email server from the previous paragraph | Consider the IMAP-accessible email server from the previous paragraph | |||
which is additionally discoverable via DNS SRV lookups in domain | which is additionally discoverable via DNS SRV lookups in domain | |||
"example.net" (DNS SRV records "_imap._tcp.example.net" and | "example.net" (DNS SRV records "_imap._tcp.example.net" and | |||
"_imaps._tcp.example.net"). In addition to DNS-ID/CN-ID identity | "_imaps._tcp.example.net"). In addition to DNS-ID/CN-ID identity | |||
types specified above, a certificate for this service also needs to | types specified above, a certificate for this service also needs to | |||
include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the | include SRV-IDs of "_imap.example.net" (when STARTTLS is used on the | |||
IMAP port) and "_imaps.example.net" (when TLS is used on IMAPS port). | IMAP port) and "_imaps.example.net" (when TLS is used on IMAPS port). | |||
See [RFC6186] for more details. (Note that unlike DNS SRV there is | See [RFC6186] for more details. (Note that unlike DNS SRV there is | |||
no "_tcp" component in SRV-IDs). | no "_tcp" component in SRV-IDs). | |||
Consider the IMAP-accessible email server from the first paragraph | ||||
which is running on a host also known as "mycompany.example.com". In | ||||
addition to DNS-ID identity types specified above, a certificate for | ||||
this service also needs to include DNS-ID of "mycompany.example.com" | ||||
(this is what a user of this server enters manually, if not using | ||||
[RFC6186]). It might also include CN-ID of "mycompany.example.com" | ||||
instead of the CN-ID "mail.example.net" for backward compatibility | ||||
with deployed infrastructure. (This is so, because a certificate can | ||||
only include a single CN-ID) | ||||
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-ID of | |||
"submit.example.net" for backward compatibility with deployed | "submit.example.net" for backward compatibility with deployed | |||
infrastructure. | infrastructure. | |||
Consider a host "mail.example.net" servicing email addresses of the | Consider a host "mail.example.net" servicing email addresses of the | |||
form "user@example.net" and discoverable via DNS SRV lookups in | form "user@example.net" and discoverable via DNS SRV lookups in | |||
domain "example.net", which runs SMTP Submission, IMAPS and POP3S | domain "example.net", which runs SMTP Submission, IMAPS and POP3S | |||
(POP3-over-TLS) and ManageSieve services. Each of the servers can | (POP3-over-TLS) and ManageSieve services. Each of the servers can | |||
use their own certificate specific to their service (see examples | use their own certificate specific to their service (see examples | |||
above). Alternatively they can all share a single certificate that | above). Alternatively they can all share a single certificate that | |||
would include SRV-IDs of "_submission.example.net", | would include SRV-IDs of "_submission.example.net", | |||
"_imaps.example.net", "_pop3s.example.net" and "_sieve.example.net" | "_imaps.example.net", "_pop3s.example.net" and "_sieve.example.net" | |||
along with DNS-IDs of "example.net" and "mail.example.net". It might | along with DNS-IDs of "example.net" and "mail.example.net". It might | |||
also include CN-IDs of "mail.example.net" for backward compatibility | also include CN-ID of "mail.example.net" for backward compatibility | |||
with deployed infrastructure. | with deployed infrastructure. | |||
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 | |||
skipping to change at page 6, line 46 | skipping to change at page 7, line 44 | |||
if they are a target of a DNS SRV lookup) or derived using a secure | if they are a target of a DNS SRV lookup) or derived using a secure | |||
third party service (e.g. DNSSEC-protected SRV records which are | third party service (e.g. DNSSEC-protected SRV records which are | |||
verified by the client or trusted local resolver). Future work in | verified by the client or trusted local resolver). Future work in | |||
this area might benefit from integration with DANE [RFC6698], but it | this area might benefit from integration with DANE [RFC6698], but it | |||
is not covered by this document. | is not covered by this document. | |||
9. References | 9. References | |||
9.1. Normative References | 9.1. Normative References | |||
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | ||||
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, | ||||
<http://www.rfc-editor.org/info/rfc1939>. | ||||
[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, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<http://www.rfc-editor.org/info/rfc2119>. | <http://www.rfc-editor.org/info/rfc2119>. | |||
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", | ||||
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, | ||||
<http://www.rfc-editor.org/info/rfc6409>. | ||||
[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, DOI 10.17487/RFC3207, | Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207, | |||
February 2002, <http://www.rfc-editor.org/info/rfc3207>. | February 2002, <http://www.rfc-editor.org/info/rfc3207>. | |||
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | [RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION | |||
4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, | |||
<http://www.rfc-editor.org/info/rfc3501>. | <http://www.rfc-editor.org/info/rfc3501>. | |||
[RFC1939] Myers, J. and M. Rose, "Post Office Protocol - Version 3", | [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure | |||
STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996, | Subject Alternative Name for Expression of Service Name", | |||
<http://www.rfc-editor.org/info/rfc1939>. | RFC 4985, DOI 10.17487/RFC4985, August 2007, | |||
<http://www.rfc-editor.org/info/rfc4985>. | ||||
[RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely | [RFC5804] Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely | |||
Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, | Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804, | |||
July 2010, <http://www.rfc-editor.org/info/rfc5804>. | July 2010, <http://www.rfc-editor.org/info/rfc5804>. | |||
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | ||||
Verification of Domain-Based Application Service Identity | ||||
within Internet Public Key Infrastructure Using X.509 | ||||
(PKIX) Certificates in the Context of Transport Layer | ||||
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March | ||||
2011, <http://www.rfc-editor.org/info/rfc6125>. | ||||
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., | |||
Housley, R., and W. Polk, "Internet X.509 Public Key | Housley, R., and W. Polk, "Internet X.509 Public Key | |||
Infrastructure Certificate and Certificate Revocation List | Infrastructure Certificate and Certificate Revocation List | |||
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, | |||
<http://www.rfc-editor.org/info/rfc5280>. | <http://www.rfc-editor.org/info/rfc5280>. | |||
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | |||
Subject Alternative Name for Expression of Service Name", | Verification of Domain-Based Application Service Identity | |||
RFC 4985, DOI 10.17487/RFC4985, August 2007, | within Internet Public Key Infrastructure Using X.509 | |||
<http://www.rfc-editor.org/info/rfc4985>. | (PKIX) Certificates in the Context of Transport Layer | |||
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March | ||||
2011, <http://www.rfc-editor.org/info/rfc6125>. | ||||
[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, | Submission/Access Services", RFC 6186, | |||
DOI 10.17487/RFC6186, March 2011, | DOI 10.17487/RFC6186, March 2011, | |||
<http://www.rfc-editor.org/info/rfc6186>. | <http://www.rfc-editor.org/info/rfc6186>. | |||
[RFC6409] Gellens, R. and J. Klensin, "Message Submission for Mail", | ||||
STD 72, RFC 6409, DOI 10.17487/RFC6409, November 2011, | ||||
<http://www.rfc-editor.org/info/rfc6409>. | ||||
9.2. Informative References | 9.2. Informative References | |||
[RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", | [RFC2595] Newman, C., "Using TLS with IMAP, POP3 and ACAP", | |||
RFC 2595, DOI 10.17487/RFC2595, June 1999, | RFC 2595, DOI 10.17487/RFC2595, June 1999, | |||
<http://www.rfc-editor.org/info/rfc2595>. | <http://www.rfc-editor.org/info/rfc2595>. | |||
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | ||||
Resource Identifier (URI): Generic Syntax", STD 66, | ||||
RFC 3986, DOI 10.17487/RFC3986, January 2005, | ||||
<http://www.rfc-editor.org/info/rfc3986>. | ||||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | ||||
Specifications: ABNF", STD 68, RFC 5234, | ||||
DOI 10.17487/RFC5234, January 2008, | ||||
<http://www.rfc-editor.org/info/rfc5234>. | ||||
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication | [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication | |||
of Named Entities (DANE) Transport Layer Security (TLS) | of Named Entities (DANE) Transport Layer Security (TLS) | |||
Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August | Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August | |||
2012, <http://www.rfc-editor.org/info/rfc6698>. | 2012, <http://www.rfc-editor.org/info/rfc6698>. | |||
Appendix A. Acknowledgements | Appendix A. Acknowledgements | |||
Thank you to Chris Newman, Viktor Dukhovni and Sean Turner for | Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ Housley | |||
comments on this document. | and Alessandro Vesely 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. 30 change blocks. | ||||
77 lines changed or deleted | 133 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/ |