draft-ietf-uta-email-tls-certs-08.txt | draft-ietf-uta-email-tls-certs-09.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 December 17, 2015 | Updates: 2595, 3207, 3501, 5804 (if December 29, 2015 | |||
approved) | approved) | |||
Intended status: Standards Track | Intended status: Standards Track | |||
Expires: June 19, 2016 | Expires: July 1, 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-08 | draft-ietf-uta-email-tls-certs-09 | |||
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 June 19, 2016. | This Internet-Draft will expire on July 1, 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 13 | skipping to change at page 2, line 13 | |||
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 . . . . . 5 | 4. Compliance Checklist for Certification Authorities . . . . . 5 | |||
4.1. Notes on handling of SRV-ID by Certification Authorities 5 | 4.1. Notes on handling of delegated email services by | |||
Certification Authorities . . . . . . . . . . . . . . . . 5 | ||||
5. Compliance Checklist for Mail Service Providers and | 5. Compliance Checklist for Mail Service Providers and | |||
Certificate Signing Request generation tools . . . . . . . . 6 | Certificate Signing Request generation tools . . . . . . . . 6 | |||
5.1. Notes on hosting multiple domains . . . . . . . . . . . . 6 | 5.1. Notes on hosting multiple domains . . . . . . . . . . . . 7 | |||
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 7 | 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 | |||
7. Operational Considerations . . . . . . . . . . . . . . . . . 8 | 7. Operational Considerations . . . . . . . . . . . . . . . . . 9 | |||
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 | |||
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 | |||
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
10.1. Normative References . . . . . . . . . . . . . . . . . . 9 | 10.1. Normative References . . . . . . . . . . . . . . . . . . 9 | |||
10.2. Informative References . . . . . . . . . . . . . . . . . 10 | 10.2. Informative References . . . . . . . . . . . . . . . . . 11 | |||
Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 | Appendix A. Acknowledgements . . . . . . . . . . . . . . . . . . 12 | |||
Appendix B. Changes since draft-ietf-uta-email-tls-certs-00 . . 12 | Appendix B. Changes to RFC 2595, RFC 3207, RFC 3501, RFC 5804 . 12 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 | Appendix C. Changes since draft-ietf-uta-email-tls-certs-00 . . 13 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 13 | ||||
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 | |||
skipping to change at page 3, line 16 | skipping to change at page 3, line 18 | |||
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: (formally defined in [RFC6125]) One of the | reference identifier: (formally defined in [RFC6125]) One of the | |||
domain names that the email client (an SMTP, IMAP, POP3 or | domain names that the email client (an SMTP, IMAP, POP3 or | |||
ManageSieve client) associates with the target email server. For | ManageSieve client) associates with the target email server. For | |||
some identifier types, the identifier can also include an | some identifier types, the identifier also includes an application | |||
application service type for performing name checks on the server | service type. Reference identifiers are used for performing name | |||
certificate. When name checks are applicable, at least one of the | checks on server certificates. | |||
reference identifiers MUST match an [RFC6125] DNS-ID or SRV-ID (or | ||||
if none are present the [RFC6125] CN-ID) of the server | ||||
certificate. | ||||
CN-ID, DNS-ID, SRV-ID and URI-ID are identifier types (see [RFC6125] | CN-ID, DNS-ID, SRV-ID and URI-ID are identifier types (see [RFC6125] | |||
for details). For convenience, their short definitions from | for details). For convenience, their short definitions from | |||
[RFC6125] are listed below: | [RFC6125] are listed below: | |||
CN-ID = a Relative Distinguished Name (RDN) in the certificate | CN-ID = a Relative Distinguished Name (RDN) in the certificate | |||
subject field that contains one and only one attribute-type-and- | subject field that contains one and only one attribute-type-and- | |||
value pair of type Common Name (CN), where the value matches the | value pair of type Common Name (CN), where the value matches the | |||
overall form of a domain name (informally, dot- separated letter- | overall form of a domain name (informally, dot- separated letter- | |||
digit-hyphen labels). | digit-hyphen labels). | |||
skipping to change at page 3, line 48 | skipping to change at page 3, line 47 | |||
URI-ID = a subjectAltName entry of type uniformResourceIdentifier | URI-ID = a subjectAltName entry of type uniformResourceIdentifier | |||
whose value includes both (i) a "scheme" and (ii) a "host" | whose value includes both (i) a "scheme" and (ii) a "host" | |||
component (or its equivalent) that matches the "reg-name" rule | component (or its equivalent) that matches the "reg-name" rule | |||
(where the quoted terms represent the associated [RFC5234] | (where the quoted terms represent the associated [RFC5234] | |||
productions from [RFC3986]). | 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 | identity (client's reference identifiers) against the server's | |||
Certificate message, in order to prevent man-in-the-middle attacks. | identity as presented in the server Certificate message, in order to | |||
This check is only performed after the server certificate passes | prevent man-in-the-middle attacks. This check is only performed | |||
certification path validation as described in Section 6 of [RFC5280]. | after the server certificate passes certification path validation as | |||
Matching is performed according to the rules specified in Section 6 | described in Section 6 of [RFC5280]. Matching is performed according | |||
of [RFC6125], including "certificate pinning" and the procedure on | to the rules specified in Section 6 of [RFC6125], including the | |||
failure to match. The following inputs are used by the verification | relative order of matching of different identifier types, | |||
procedure used in [RFC6125]: | "certificate pinning" and the procedure on failure to match. The | |||
following inputs are used by the verification 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 domain | more of the following as "reference identifiers": (a) the domain | |||
portion of the user's email address, (b) the hostname it used to | portion of the user's email address, (b) the hostname it used to | |||
open the connection (without CNAME canonicalization). The client | open the connection (without CNAME canonicalization). The client | |||
MAY also use (c) a value securely derived from (a) or (b), such | MAY also use (c) a value securely derived from (a) or (b), such | |||
as using "secure" DNSSEC [RFC4033][RFC4034][RFC4035] validated | as using "secure" DNSSEC [RFC4033][RFC4034][RFC4035] validated | |||
lookup. | lookup. | |||
2. When using email service discovery procedure specified in | 2. When using email service discovery procedure specified in | |||
skipping to change at page 5, line 9 | skipping to change at page 5, line 11 | |||
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 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]). | |||
(Note that some DNS-IDs may refer to domain portions of email | ||||
addresses, so they might not have corresponding A/AAAA DNS | ||||
records.) | ||||
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. See Section 4.1 for more discussion | each type of email service. See Section 4.1 for more discussion | |||
on what this means for Certification Authorities. | 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 Certification Authorities | 4.1. Notes on handling of delegated email services by Certification | |||
Authorities | ||||
[RFC6186] provides an easy way for organizations to autoconfigure | [RFC6186] provides an easy way for organizations to autoconfigure | |||
email clients. It also allows for delegation of email services to an | email clients. It also allows for delegation of email services to an | |||
email hosting provider. When connecting to such delegated hosting | email hosting provider. When connecting to such delegated hosting | |||
service an email client that attempts to verify TLS server identity | service an email client that attempts to verify TLS server identity | |||
needs to know that if it connects to imap.hosting.example.net that | needs to know that if it connects to imap.hosting.example.net that | |||
such server is authorized to provide email access for an email such | such server is authorized to provide email access for an email such | |||
as alice@example.org. In absence of SRV-IDs, users of compliant | as alice@example.org. In absence of SRV-IDs, users of compliant | |||
email clients would be forced to manually confirm exception, because | email clients would be forced to manually confirm exception, because | |||
the TLS server certificate verification procedures specified in this | the TLS server certificate verification procedures specified in this | |||
document would result in failure to match the TLS server certificate | document would result in failure to match the TLS server certificate | |||
against the expected domain(s). One way to provide such | against the expected domain(s). One way to provide such | |||
authorization is for the TLS certificate for imap.hosting.example.net | authorization is for the TLS certificate for imap.hosting.example.net | |||
to include SRV-ID(s) (or DNS-ID) for the example.org domain. | to include SRV-ID(s) (or DNS-ID) for the example.org domain. | |||
(Another way is for SRV lookups to be protected by DNSSEC, but this | (Another way is for DNS SRV lookups to be protected by DNSSEC, but | |||
solution depends on DNSSEC and thus is not discussed in this | this solution depends on ubiquitous use of DNSSEC and availability of | |||
document. A future update to this document might rectify this.) | DNSSEC-aware APIs and thus is not discussed in this document. A | |||
future update to this document might rectify this.) | ||||
The ability to issue certificates that contain SRV-ID implies the | A certification authority that receives a Certificate Signing Request | |||
ability to verify that entities requesting them are authorized to run | containing multiple unrelated DNS-IDs and/or SRV-IDs (e.g. DNS-ID of | |||
email service for these SRV-IDs. In particular, certification | example.org and DNS-ID of example.com) needs to verify that the | |||
authorities that can't verify such authorization MUST NOT include | entity that supplied such Certificate Signing Request is authorized | |||
email SRV-IDs in certificates they issue. This document doesn't | to provide email service for all requested domains. | |||
specify exact mechanism(s) that can be used to achieve this. | ||||
However, a few special case recommendations are listed below. | The ability to issue certificates that contain an SRV-ID (or a DNS-ID | |||
for the domain part of email addresses) implies the ability to verify | ||||
that entities requesting them are authorized to run email service for | ||||
these SRV-IDs/DNS-IDs. In particular, certification authorities that | ||||
can't verify such authorization (whether for a particular domain or | ||||
in general) MUST NOT include such email SRV-IDs/DNS-IDs in | ||||
certificates they issue. This document doesn't specify exact | ||||
mechanism(s) that can be used to achieve this. However, a few | ||||
special case recommendations are listed below. | ||||
A certification authority willing to sign a certificate containing a | A certification authority willing to sign a certificate containing a | |||
particular DNS-ID SHOULD also support signing a certificate | particular DNS-ID SHOULD also support signing a certificate | |||
containing one or more of email SRV-IDs for the same domain, because | containing one or more of email SRV-IDs for the same domain, because | |||
the SRV-ID effectively provides more restricted access to an email | the SRV-ID effectively provides more restricted access to an email | |||
service for the domain (as opposed to unrestricted use of any | service for the domain (as opposed to unrestricted use of any | |||
services for the same domain, as specified by DNS-ID). | services for the same domain, as specified by DNS-ID). | |||
A certification authority which also provides DNS service for a | A certification authority which also provides DNS service for a | |||
domain can use DNS information to validate SRV-IDs for the domain. | domain can use DNS information to validate SRV-IDs/DNS-IDs for the | |||
domain. | ||||
A certification authority which is also a Mail Service Provider for a | ||||
hosted domain can use that knowdledge to validate SRV-IDs/DNS-IDs for | ||||
the domain. | ||||
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 | |||
Mail Service Providers and Certificate Signing Request generation | ||||
tools | ||||
1. MUST include the DNS-ID identifier type in Certificate Signing | 1. MUST include the DNS-ID identifier type in Certificate Signing | |||
Requests for the host name(s) where the email server(s) are | Requests for the host name(s) where the email server(s) are | |||
running. SHOULD include the DNS-ID identifier type in | running. They SHOULD include the DNS-ID identifier type in | |||
Certificate Signing Requests for the domain portion of served | Certificate Signing Requests for the domain portion of served | |||
email addresses. | 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 for each type of email service in | the SRV-ID identifier type for each type of email service in | |||
Certificate Signing Requests. | Certificate Signing Requests. | |||
3. SHOULD include CN-ID identifier type for the host name where the | 3. SHOULD include CN-ID identifier type for the host name where the | |||
email server(s) is running in Certificate Signing Requests for | email server(s) is running in Certificate Signing Requests for | |||
skipping to change at page 7, line 23 | skipping to change at page 7, line 47 | |||
when the list of domains changes. Use of DNS SRV without SRV-ID | when the list of domains changes. Use of DNS SRV without SRV-ID | |||
requires manual confirmation from users. While preloading pinned | requires manual confirmation from users. While preloading pinned | |||
certificates avoids the need for manual confirmation, this | certificates avoids the need for manual confirmation, this | |||
information can get stale quickly or would require support for a new | information can get stale quickly or would require support for a new | |||
mechanism for distributing preloaded pinned certificates. A single | mechanism for distributing preloaded pinned certificates. A single | |||
certificate (the second choice) requires that when a domain is added, | certificate (the second choice) requires that when a domain is added, | |||
then a new Certificate Signing Request that includes a complete list | then a new Certificate Signing Request that includes a complete list | |||
of all the domains needs to be issued and passed to a CA in order to | of all the domains needs to be issued and passed to a CA in order to | |||
generate a new certificate. Separate IP/port can avoid regenerating | generate a new certificate. Separate IP/port can avoid regenerating | |||
the certificate, but requires more transport layer resources. Use of | the certificate, but requires more transport layer resources. Use of | |||
TLS SNI requires each email client to support it. | TLS SNI requires each email client to use it. | |||
Several Mail Service Providers host hundreds and even thousands of | Several Mail Service Providers host hundreds and even thousands of | |||
domains. This document, as well as its predecessors RFC 2595, RFC | domains. This document, as well as its predecessors RFC 2595, RFC | |||
3207, RFC 3501 and RFC 5804 don't address scaling issues caused by | 3207, RFC 3501 and RFC 5804 don't address scaling issues caused by | |||
use of TLS in multi-tenanted environments. Further work is needed to | use of TLS in multi-tenanted environments. Further work is needed to | |||
address this issue, possibly using DNSSEC or something like POSH | address this issue, possibly using DNSSEC or something like POSH | |||
[RFC7711]. | [RFC7711]. | |||
6. Examples | 6. Examples | |||
skipping to change at page 10, line 11 | skipping to change at page 10, line 33 | |||
[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>. | |||
[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>. | |||
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | ||||
Extensions: Extension Definitions", RFC 6066, | ||||
DOI 10.17487/RFC6066, January 2011, | ||||
<http://www.rfc-editor.org/info/rfc6066>. | ||||
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | |||
Verification of Domain-Based Application Service Identity | Verification of Domain-Based Application Service Identity | |||
within Internet Public Key Infrastructure Using X.509 | within Internet Public Key Infrastructure Using X.509 | |||
(PKIX) Certificates in the Context of Transport Layer | (PKIX) Certificates in the Context of Transport Layer | |||
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March | Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March | |||
2011, <http://www.rfc-editor.org/info/rfc6125>. | 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, | |||
skipping to change at page 11, line 10 | skipping to change at page 11, line 36 | |||
[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. | |||
Rose, "Protocol Modifications for the DNS Security | Rose, "Protocol Modifications for the DNS Security | |||
Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, | Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005, | |||
<http://www.rfc-editor.org/info/rfc4035>. | <http://www.rfc-editor.org/info/rfc4035>. | |||
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax | |||
Specifications: ABNF", STD 68, RFC 5234, | Specifications: ABNF", STD 68, RFC 5234, | |||
DOI 10.17487/RFC5234, January 2008, | DOI 10.17487/RFC5234, January 2008, | |||
<http://www.rfc-editor.org/info/rfc5234>. | <http://www.rfc-editor.org/info/rfc5234>. | |||
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | ||||
Extensions: Extension Definitions", RFC 6066, | ||||
DOI 10.17487/RFC6066, January 2011, | ||||
<http://www.rfc-editor.org/info/rfc6066>. | ||||
[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>. | |||
[RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP | [RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP | |||
(POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, | (POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, | |||
<http://www.rfc-editor.org/info/rfc7711>. | <http://www.rfc-editor.org/info/rfc7711>. | |||
Appendix A. Acknowledgements | Appendix A. Acknowledgements | |||
Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ | Thank you to Chris Newman, Viktor Dukhovni, Sean Turner, Russ | |||
Housley, Alessandro Vesely, Harald Alvestrand and John Levine for | Housley, Alessandro Vesely, Harald Alvestrand and John Levine for | |||
comments on this document. | 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 to RFC 2595, RFC 3207, RFC 3501, RFC 5804 | |||
This section lists detailed changes this document applies to RFC | ||||
2595, RFC 3207, RFC 3501 and RFC 5804. | ||||
The entire Section 2.4 of RFC 2595 is replaced with the following | ||||
text: | ||||
During the TLS negotiation, the client checks its understanding of | ||||
the server identity against the provided server's identity as | ||||
specified in Section 3. | ||||
The 3rd paragraph (and its subparagraphs) in Section 11.1 of RFC 3501 | ||||
is replaced with the following text: | ||||
During the TLS negotiation, the IMAP client checks its | ||||
understanding of the server identity against the provided server's | ||||
identity as specified in Section 3. | ||||
The 3rd paragraph (and its subparagraphs) in Section 4.1 of RFC 3207 | ||||
is replaced with the following text: | ||||
During the TLS negotiation, the Submission client checks its | ||||
understanding of the server identity against the provided server's | ||||
identity as specified in Section 3. | ||||
Sections 2.2.1 and 2.2.1.1 of RFC 5804 are replaced with the | ||||
following text: | ||||
During the TLS negotiation, the ManageSieve client checks its | ||||
understanding of the server identity against the server's identity | ||||
as specified in Section 3. When the reference identity is an IP | ||||
address, the iPAddress subjectAltName SHOULD be used by the client | ||||
for comparison. The comparison is performed as described in | ||||
Section 2.2.1.2 of RFC 5804. | ||||
Appendix C. 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. | |||
As any certificate can only include one CN-ID, corrected examples. | As any certificate can only include one CN-ID, corrected examples. | |||
Split rules to talk seperately about requirements on MUAs, CAs and | Split rules to talk seperately about requirements on MUAs, CAs and | |||
MSPs/CSR generation tools. | MSPs/CSR generation tools. | |||
End of changes. 21 change blocks. | ||||
46 lines changed or deleted | 104 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/ |