| < draft-saintandre-tls-server-id-check-13.txt | draft-saintandre-tls-server-id-check-14.txt > | |||
|---|---|---|---|---|
| Network Working Group P. Saint-Andre | Network Working Group P. Saint-Andre | |||
| Internet-Draft Cisco | Internet-Draft Cisco | |||
| Intended status: Standards Track J. Hodges | Intended status: Standards Track J. Hodges | |||
| Expires: July 9, 2011 PayPal | Expires: July 16, 2011 PayPal | |||
| January 5, 2011 | January 12, 2011 | |||
| Representation and Verification of Domain-Based Application Service | Representation and Verification of Domain-Based Application Service | |||
| Identity within Internet Public Key Infrastructure Using X.509 (PKIX) | Identity within Internet Public Key Infrastructure Using X.509 (PKIX) | |||
| Certificates in the Context of Transport Layer Security (TLS) | Certificates in the Context of Transport Layer Security (TLS) | |||
| draft-saintandre-tls-server-id-check-13 | draft-saintandre-tls-server-id-check-14 | |||
| Abstract | Abstract | |||
| Many application technologies enable secure communication between two | Many application technologies enable secure communication between two | |||
| entities by means of Internet Public Key Infrastructure Using X.509 | entities by means of Internet Public Key Infrastructure Using X.509 | |||
| (PKIX) certificates in the context of Transport Layer Security (TLS). | (PKIX) certificates in the context of Transport Layer Security (TLS). | |||
| This document specifies procedures for representing and verifying the | This document specifies procedures for representing and verifying the | |||
| identity of application services in such interactions. | identity of application services in such interactions. | |||
| Status of this Memo | Status of this Memo | |||
| skipping to change at page 1, line 37 ¶ | skipping to change at page 1, line 37 ¶ | |||
| 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 July 9, 2011. | This Internet-Draft will expire on July 16, 2011. | |||
| Copyright Notice | Copyright Notice | |||
| Copyright (c) 2011 IETF Trust and the persons identified as the | Copyright (c) 2011 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 33 ¶ | skipping to change at page 2, line 33 ¶ | |||
| 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 15 | 2.2. DNS Domain Names . . . . . . . . . . . . . . . . . . . . . 15 | |||
| 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 16 | 2.3. Subject Naming in PKIX Certificates . . . . . . . . . . . 16 | |||
| 2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17 | 2.3.1. Implementation Notes . . . . . . . . . . . . . . . . . 17 | |||
| 3. Designing Application Protocols . . . . . . . . . . . . . . . 18 | 3. Designing Application Protocols . . . . . . . . . . . . . . . 18 | |||
| 4. Representing Server Identity . . . . . . . . . . . . . . . . . 19 | 4. Representing Server Identity . . . . . . . . . . . . . . . . . 19 | |||
| 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 19 | |||
| 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 | 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 20 | |||
| 5. Requesting Server Certificates . . . . . . . . . . . . . . . . 21 | 5. Requesting Server Certificates . . . . . . . . . . . . . . . . 21 | |||
| 6. Verifying Service Identity . . . . . . . . . . . . . . . . . . 22 | 6. Verifying Service Identity . . . . . . . . . . . . . . . . . . 22 | |||
| 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22 | 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 22 | |||
| 6.2. Constructing a List of Reference Identifiers . . . . . . . 22 | 6.2. Constructing a List of Reference Identifiers . . . . . . . 23 | |||
| 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 22 | 6.2.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 23 | |||
| 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 24 | 6.2.2. Examples . . . . . . . . . . . . . . . . . . . . . . . 25 | |||
| 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25 | 6.3. Preparing to Seek a Match . . . . . . . . . . . . . . . . 25 | |||
| 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 26 | 6.4. Matching the DNS Domain Name Portion . . . . . . . . . . . 27 | |||
| 6.4.1. Checking of Traditional Domain Names . . . . . . . . . 27 | 6.4.1. Checking of Traditional Domain Names . . . . . . . . . 27 | |||
| 6.4.2. Checking of Internationalized Domain Names . . . . . . 27 | 6.4.2. Checking of Internationalized Domain Names . . . . . . 27 | |||
| 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27 | 6.4.3. Checking of Wildcard Certificates . . . . . . . . . . 27 | |||
| 6.4.4. Checking of Common Names . . . . . . . . . . . . . . . 28 | 6.4.4. Checking of Common Names . . . . . . . . . . . . . . . 28 | |||
| 6.5. Matching the Application Type Portion . . . . . . . . . . 28 | 6.5. Matching the Application Type Portion . . . . . . . . . . 29 | |||
| 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 28 | 6.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 29 | 6.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29 | 6.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 29 | |||
| 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 29 | 6.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 29 | |||
| 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29 | 6.6.2. Case #2: No Match Found, Pinned Certificate . . . . . 29 | |||
| 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 29 | 6.6.3. Case #3: No Match Found, No Pinned Certificate . . . . 30 | |||
| 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 29 | 6.6.4. Fallback . . . . . . . . . . . . . . . . . . . . . . . 30 | |||
| 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 | |||
| 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30 | 7.1. Pinned Certificates . . . . . . . . . . . . . . . . . . . 30 | |||
| 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 30 | 7.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 31 | |||
| 7.3. Internationalized Domain Names . . . . . . . . . . . . . . 32 | 7.3. Internationalized Domain Names . . . . . . . . . . . . . . 32 | |||
| 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 32 | 7.4. Multiple Identifiers . . . . . . . . . . . . . . . . . . . 32 | |||
| 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 | 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33 | |||
| 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 34 | |||
| 11.1. Normative References . . . . . . . . . . . . . . . . . . . 33 | 11.1. Normative References . . . . . . . . . . . . . . . . . . . 34 | |||
| 11.2. Informative References . . . . . . . . . . . . . . . . . . 34 | 11.2. Informative References . . . . . . . . . . . . . . . . . . 35 | |||
| Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 39 | Appendix A. Sample Text . . . . . . . . . . . . . . . . . . . . . 40 | |||
| Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 41 | Appendix B. Prior Art . . . . . . . . . . . . . . . . . . . . . . 41 | |||
| B.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 41 | B.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 41 | |||
| B.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 42 | B.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 42 | |||
| B.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 43 | B.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 44 | |||
| B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 46 | B.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 47 | |||
| B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 48 | B.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
| B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 49 | B.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 49 | |||
| B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 50 | B.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 50 | |||
| B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 51 | B.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 52 | |||
| B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 52 | B.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
| B.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 53 | B.10. SNMP (2010) . . . . . . . . . . . . . . . . . . . . . . . 53 | |||
| B.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 54 | B.11. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
| Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 | Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 55 | |||
| 1. Introduction | 1. Introduction | |||
| 1.1. Motivation | 1.1. Motivation | |||
| The visible face of the Internet largely consists of services that | The visible face of the Internet largely consists of services that | |||
| employ a client-server architecture in which an interactive or | employ a client-server architecture in which an interactive or | |||
| skipping to change at page 21, line 43 ¶ | skipping to change at page 21, line 43 ¶ | |||
| This section provides rules and guidelines for service providers | This section provides rules and guidelines for service providers | |||
| regarding the information to include in certificate signing requests | regarding the information to include in certificate signing requests | |||
| (CSRs). | (CSRs). | |||
| In general, service providers are encouraged to request certificates | In general, service providers are encouraged to request certificates | |||
| that include all of the identifier types that are required or | that include all of the identifier types that are required or | |||
| recommended for the application service type that will be secured | recommended for the application service type that will be secured | |||
| using the certificate to be issued. | using the certificate to be issued. | |||
| If the certificate will be used for only a single application service | If the certificate might be used for any type of application service, | |||
| type, then the service provider is encouraged to request a | then the service provider is encouraged to request a certificate that | |||
| includes only a DNS-ID. | ||||
| If the certificate will be used for only a single type of application | ||||
| service, then the service provider is encouraged to request a | ||||
| certificate that includes a DNS-ID and, if appropriate for the | certificate that includes a DNS-ID and, if appropriate for the | |||
| service type, an SRV-ID or URI-ID that limits the deployment scope of | service type, an SRV-ID or URI-ID that limits the deployment scope of | |||
| the certificate to only the defined service type. | the certificate to only the defined service type. | |||
| If the certificate will be used for multiple application service | If a service provider offering multiple service types (e.g., a world | |||
| types, then the service provider is discouraged from requesting one | wide web service, an email service, and an instant messaging service) | |||
| certificate with multiple kinds of SRV-IDs or URI-IDs identifying | wishes to limit the applicability of certificates using SRV-IDs or | |||
| each different application service type. Instead, the service | URI-IDs, then the service provider is encouraged to request multiple | |||
| provider is encouraged to request either (a) one certificate per | certificates, i.e., one certificate per service type. Conversely, | |||
| service type or (b) a single certificate that contains only an | the service provider is discouraged from requesting a single | |||
| identifier type of DNS-ID representing the DNS domain name(s) for the | certificate containing multiple SRV-IDs or URI-IDs identifying each | |||
| provided service(s). | different application service type. This guideline does not apply to | |||
| service type "bundles" that are used to identify manifold distinct | ||||
| access methods to the same underlying application (e.g., an email | ||||
| application with access methods denoted by the service types of | ||||
| "imap", "imaps", "pop3", "pop3s", and "submission" as described in | ||||
| [EMAIL-SRV]). | ||||
| 6. Verifying Service Identity | 6. Verifying Service Identity | |||
| This section provides rules and guidelines for implementers of | This section provides rules and guidelines for implementers of | |||
| application client software regarding algorithms for verification of | application client software regarding algorithms for verification of | |||
| application service identity. | application service identity. | |||
| 6.1. Overview | 6.1. Overview | |||
| At a high level, the client verifies the application service's | At a high level, the client verifies the application service's | |||
| skipping to change at page 25, line 6 ¶ | skipping to change at page 25, line 17 ¶ | |||
| other than those of type Common Name and MUST NOT check for RDNs | other than those of type Common Name and MUST NOT check for RDNs | |||
| other than those of type Common Name in the presented identifiers. | other than those of type Common Name in the presented identifiers. | |||
| 6.2.2. Examples | 6.2.2. Examples | |||
| A web browser that is connecting via HTTPS to the website at | A web browser that is connecting via HTTPS to the website at | |||
| "www.example.com" might have two reference identifiers: a DNS-ID of | "www.example.com" might have two reference identifiers: a DNS-ID of | |||
| "www.example.com" and, as a fallback, a CN-ID of "www.example.com". | "www.example.com" and, as a fallback, a CN-ID of "www.example.com". | |||
| A mail user agent that is connecting via IMAP to the email service at | A mail user agent that is connecting via IMAP to the email service at | |||
| "example.net" (resolved as "mail.example.net") might have two | "example.net" (resolved as "mail.example.net") might have four | |||
| reference identifiers: an SRV-ID of "_imaps.example.net" (see | reference identifiers: SRV-IDs of "_imaps.example.net" and | |||
| [EMAIL-SRV]) and a DNS-ID of "example.net". | "_imaps.mail.example.net" (see [EMAIL-SRV]) and DNS-IDs of | |||
| "example.net" and "mail.example.net". (A legacy email user agent | ||||
| would not support [EMAIL-SRV] and therefore would probably be | ||||
| explicitly configured to connect to "mail.example.net", whereas an | ||||
| SRV-aware user agent would derive "example.net" from an email address | ||||
| of the form "user@example.net" but might also accept | ||||
| "mail.example.net" as the DNS domain name portion of reference | ||||
| identifiers for the service.) | ||||
| A voice-over-IP (VoIP) user agent that is connecting via SIP to the | A voice-over-IP (VoIP) user agent that is connecting via SIP to the | |||
| voice service at "voice.example.edu" might have only one reference | voice service at "voice.example.edu" might have only one reference | |||
| identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). | identifier: a URI-ID of "sip:voice.example.edu" (see [SIP-CERTS]). | |||
| An instant messaging (IM) client that is connecting via XMPP to the | An instant messaging (IM) client that is connecting via XMPP to the | |||
| IM service at "im.example.org" might have three reference | IM service at "im.example.org" might have three reference | |||
| identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), | identifiers: an SRV-ID of "_xmpp-client.im.example.org" (see [XMPP]), | |||
| a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of | a DNS-ID of "im.example.org", and an XMPP-specific "XmppAddr" of | |||
| "im.example.org" (see [XMPP]). | "im.example.org" (see [XMPP]). | |||
| skipping to change at page 28, line 11 ¶ | skipping to change at page 28, line 29 ¶ | |||
| against anything but the left-most label of the reference | against anything but the left-most label of the reference | |||
| identifier (e.g., *.example.com would match foo.example.com but | identifier (e.g., *.example.com would match foo.example.com but | |||
| not bar.foo.example.com or example.com). | not bar.foo.example.com or example.com). | |||
| 3. The client MAY match a presented identifier in which the wildcard | 3. The client MAY match a presented identifier in which the wildcard | |||
| character is not the only character of the label (e.g., | character is not the only character of the label (e.g., | |||
| baz*.example.net and *baz.example.net and b*z.example.net would | baz*.example.net and *baz.example.net and b*z.example.net would | |||
| be taken to match baz1.example.net and foobaz.example.net and | be taken to match baz1.example.net and foobaz.example.net and | |||
| buzz.example.net, respectively). However, the client SHOULD NOT | buzz.example.net, respectively). However, the client SHOULD NOT | |||
| attempt to match a presented identifier where the wildcard | attempt to match a presented identifier where the wildcard | |||
| character is embedded within an NR-LDH label, A-label, or U-label | character is embedded within an A-label or U-label [IDNA-DEFS] of | |||
| [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]. | an internationalized domain name [IDNA-PROTO]. | |||
| 6.4.4. Checking of Common Names | 6.4.4. Checking of Common Names | |||
| As noted, a client MUST NOT seek a match for a reference identifier | As noted, a client MUST NOT seek a match for a reference identifier | |||
| of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, | of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, | |||
| URI-ID, or any application-specific identifier types supported by the | URI-ID, or any application-specific identifier types supported by the | |||
| client. | client. | |||
| Therefore, if and only if the presented identifiers do not include a | Therefore, if and only if the presented identifiers do not include a | |||
| DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types | DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types | |||
| skipping to change at page 28, line 34 ¶ | skipping to change at page 29, line 7 ¶ | |||
| for a string whose form matches that of a fully-qualified DNS domain | for a string whose form matches that of a fully-qualified DNS domain | |||
| name in a Common Name field of the subject field (i.e., a CN-ID). If | name in a Common Name field of the subject field (i.e., a CN-ID). If | |||
| the client chooses to compare a reference identifier of type CN-ID | the client chooses to compare a reference identifier of type CN-ID | |||
| against that string, it MUST follow the comparison rules for the DNS | against that string, it MUST follow the comparison rules for the DNS | |||
| domain name portion of an identifier of type DNS-ID, SRV-ID, or | domain name portion of an identifier of type DNS-ID, SRV-ID, or | |||
| URI-ID, as described under Section 6.4.1, Section 6.4.2, and | URI-ID, as described under Section 6.4.1, Section 6.4.2, and | |||
| Section 6.4.3. | Section 6.4.3. | |||
| 6.5. Matching the Application Type Portion | 6.5. Matching the Application Type Portion | |||
| When checking identifiers of type SRV-ID and URI-ID, a client SHOULD | If a client supports checking of identifiers of type SRV-ID and | |||
| also check the service type of the application service with which it | URI-ID, it MUST also check the service type of the application | |||
| communicates (in addition to checking the domain name as described | service with which it communicates (in addition to checking the | |||
| above). This is a best practice because typically a client is not | domain name as described above). This is a best practice because | |||
| designed to communicate with all kinds of services using all possible | typically a client is not designed to communicate with all kinds of | |||
| application protocols, but instead is designed to communicate with | services using all possible application protocols, but instead is | |||
| one kind of service, such as websites, email services, VoIP services, | designed to communicate with one kind of service, such as websites, | |||
| or IM services. | email services, VoIP services, or IM services. | |||
| The service type is verified by means of an SRV-ID or a URI-ID. | The service type is verified by means of an SRV-ID or a URI-ID. | |||
| 6.5.1. SRV-ID | 6.5.1. SRV-ID | |||
| The service name portion of an SRV-ID (e.g., "imaps") MUST be matched | The service name portion of an SRV-ID (e.g., "imaps") MUST be matched | |||
| in a case-insensitive manner, in accordance with [DNS-SRV]. Note | in a case-insensitive manner, in accordance with [DNS-SRV]. Note | |||
| that the "_" character is prepended to the service identifier in DNS | that the "_" character is prepended to the service identifier in DNS | |||
| SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to | SRV records and in SRV-IDs (per [SRVNAME]), and thus does not need to | |||
| be included in any comparison. | be included in any comparison. | |||
| skipping to change at page 31, line 38 ¶ | skipping to change at page 32, line 9 ¶ | |||
| * included as all or part of more than one label (e.g., | * included as all or part of more than one label (e.g., | |||
| *.*.example.com) | *.*.example.com) | |||
| These ambiguities might introduce exploitable differences in | These ambiguities might introduce exploitable differences in | |||
| identity checking behavior among client implementations and | identity checking behavior among client implementations and | |||
| necessitate overly complex and inefficient identity checking | necessitate overly complex and inefficient identity checking | |||
| algorithms. | algorithms. | |||
| o There is no specification that defines how the wildcard character | o There is no specification that defines how the wildcard character | |||
| may be embedded within the NR-LDH labels, A-labels, or U-labels | may be embedded within the A-labels or U-labels [IDNA-DEFS] of an | |||
| [IDNA-DEFS] of an internationalized domain name [IDNA-PROTO]; as a | internationalized domain name [IDNA-PROTO]; as a result, | |||
| result, implementations are strongly discouraged from including or | implementations are strongly discouraged from including or | |||
| attempting to check for the wildcard character emdedded within NR- | attempting to check for the wildcard character embedded within the | |||
| LDH labels, A-labels, or U-labels of an internationalized domain | A-labels or U-labels of an internationalized domain name (e.g., | |||
| name (e.g., "xn--kcry6tjko*.example.org"). Note, however, that a | "xn--kcry6tjko*.example.org"). Note, however, that a presented | |||
| presented domain name identifier MAY contain the wildcard | domain name identifier MAY contain the wildcard character as long | |||
| character as long as that character occupies the entire left-most | as that character occupies the entire left-most label position, | |||
| label position, where some or all of the remaining labels are NR- | where all of the remaining labels are valid NR-LDH labels, | |||
| LDH labels, A-labels, or U-labels (e.g., "*.xn-- | A-labels, or U-labels (e.g., "*.xn--kcry6tjko.example.org"). | |||
| kcry6tjko.example.org"). | ||||
| Notwithstanding the foregoing security considerations, specifications | Notwithstanding the foregoing security considerations, specifications | |||
| that re-use this one can legitimately encourage continued support for | that re-use this one can legitimately encourage continued support for | |||
| the wildcard character if they have good reasons to do so, such as | the wildcard character if they have good reasons to do so, such as | |||
| backward compatibility with deployed infrastructure (see, for | backward compatibility with deployed infrastructure (see, for | |||
| example, [EV-CERTS]). | example, [EV-CERTS]). | |||
| 7.3. Internationalized Domain Names | 7.3. Internationalized Domain Names | |||
| Allowing internationalized domain names can lead to the inclusion of | Allowing internationalized domain names can lead to the inclusion of | |||
| End of changes. 17 change blocks. | ||||
| 55 lines changed or deleted | 70 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||