draft-saintandre-tls-server-id-check-04.txt		draft-saintandre-tls-server-id-check-05.txt
	Network Working Group P. Saint-Andre, Ed.		Network Working Group P. Saint-Andre, Ed.
	Internet-Draft Cisco		Internet-Draft Cisco
	Intended status: BCP J. Hodges, Ed.		Intended status: BCP J. Hodges, Ed.
	Expires: November 1, 2010 PayPal		Expires: November 13, 2010 PayPal
	April 30, 2010		May 12, 2010
	Representation and Verification of Application Server Identity in		Representation and Verification of Domain-Based Application Server
	Certificates Used with Transport Layer Security (TLS)		Identity in Certificates Used with Transport Layer Security
	draft-saintandre-tls-server-id-check-04		draft-saintandre-tls-server-id-check-05
	Abstract		Abstract
	Many application technologies enable a secure connection between two		Many application technologies enable a secure connection between two
	entities using certificates in the context of Transport Layer		entities using certificates in the context of Transport Layer
	Security (TLS). This document specifies best current practices for		Security (TLS). This document specifies best current practices for
	representing and verifying the identity of application servers in		representing and verifying the identity of application servers in
	such interactions.		such interactions.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 36		skipping to change at page 1, line 36
	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 November 1, 2010.		This Internet-Draft will expire on November 13, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5		1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5		1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
	1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 7		1.4. Discussion Venue . . . . . . . . . . . . . . . . . . . . . 8
	1.5. Contributors . . . . . . . . . . . . . . . . . . . . . . . 7		1.5. Contributors . . . . . . . . . . . . . . . . . . . . . . . 8
	1.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 7		1.6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 8
	2. Representation of Server Identity . . . . . . . . . . . . . . 8		2. Representation of Server Identity . . . . . . . . . . . . . . 8
	2.1. Subject Naming in PKIX Certificates . . . . . . . . . . . 8		2.1. Subject Naming in PKIX Certificates . . . . . . . . . . . 8
	2.2. PKIX Certificate Name Rules . . . . . . . . . . . . . . . 9		2.2. PKIX Certificate Name Rules . . . . . . . . . . . . . . . 9
	3. Verification of Server Identity . . . . . . . . . . . . . . . 10		3. Verification of Server Identity . . . . . . . . . . . . . . . 11
	3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 10		3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 11
	3.2. Constructing an Ordered List of Reference Identifiers . . 10		3.2. Constructing an Ordered List of Reference Identifiers . . 11
	3.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 12		3.3. Seeking a Match . . . . . . . . . . . . . . . . . . . . . 13
	3.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 13		3.4. Verifying a Domain Name . . . . . . . . . . . . . . . . . 13
	3.4.1. Checking of Traditional Domain Names . . . . . . . . . 13		3.4.1. Checking of Traditional Domain Names . . . . . . . . . 14
	3.4.2. Checking of Internationalized Domain Names . . . . . . 13		3.4.2. Checking of Internationalized Domain Names . . . . . . 14
	3.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 14		3.4.3. Checking of Wildcard Labels . . . . . . . . . . . . . 15
	3.4.4. Checking of DNS Domain Names in Common Names . . . . . 14		3.4.4. Checking of DNS Domain Names in Common Names . . . . . 15
	3.5. Verifying an Application Type . . . . . . . . . . . . . . 15		3.5. Verifying an Application Type . . . . . . . . . . . . . . 16
	3.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 15		3.5.1. SRV-ID . . . . . . . . . . . . . . . . . . . . . . . . 16
	3.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 15		3.5.2. URI-ID . . . . . . . . . . . . . . . . . . . . . . . . 16
	3.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 16		3.6. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 16
	3.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 16		3.6.1. Case #1: Match Found . . . . . . . . . . . . . . . . . 16
	3.6.2. Case #2: No Match Found, Cached Certificate . . . . . 16		3.6.2. Case #2: No Match Found, Cached Certificate . . . . . 17
	3.6.3. Case #3: No Match Found, Uncached Certificate . . . . 16		3.6.3. Case #3: No Match Found, Uncached Certificate . . . . 17
	3.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 16		3.6.3.1. Interactive User Agent . . . . . . . . . . . . . . 17
	3.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 17		3.6.3.2. Automated Client . . . . . . . . . . . . . . . . . 18
	4. Security Considerations . . . . . . . . . . . . . . . . . . . 17		4. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	4.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 17		4.1. Service Delegation . . . . . . . . . . . . . . . . . . . . 18
	4.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 17		4.2. Wildcard Certificates . . . . . . . . . . . . . . . . . . 18
	4.3. Internationalized Doman Names . . . . . . . . . . . . . . 18		4.3. Internationalized Doman Names . . . . . . . . . . . . . . 18
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	6.1. Normative References . . . . . . . . . . . . . . . . . . . 18		6.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	6.2. Informative References . . . . . . . . . . . . . . . . . . 19		6.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 22		Appendix A. Prior Art . . . . . . . . . . . . . . . . . . . . . . 23
	A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 22		A.1. IMAP, POP3, and ACAP (1999) . . . . . . . . . . . . . . . 24
	A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 23		A.2. HTTP (2000) . . . . . . . . . . . . . . . . . . . . . . . 24
	A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 25		A.3. LDAP (2000/2006) . . . . . . . . . . . . . . . . . . . . . 26
	A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 28		A.4. SMTP (2002/2007) . . . . . . . . . . . . . . . . . . . . . 29
	A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 29		A.5. XMPP (2004) . . . . . . . . . . . . . . . . . . . . . . . 30
	A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 30		A.6. NNTP (2006) . . . . . . . . . . . . . . . . . . . . . . . 31
	A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 31		A.7. NETCONF (2006/2009) . . . . . . . . . . . . . . . . . . . 32
	A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 32		A.8. Syslog (2009) . . . . . . . . . . . . . . . . . . . . . . 34
	A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 33		A.9. SIP (2010) . . . . . . . . . . . . . . . . . . . . . . . . 35
	A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 34		A.10. GIST (2010) . . . . . . . . . . . . . . . . . . . . . . . 35
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36
	1. Introduction		1. Introduction
	1.1. Motivation		1.1. Motivation
	The visible face of the Internet consists of services that employ a		The visible face of the Internet consists of services that employ a
	client-server architecture in which an interactive or automated		client-server architecture in which an interactive or automated
	client connects to an application server in order to retrieve or		client connects to an application server in order to retrieve or
	upload information, communicate with other entities, or access a		upload information, communicate with other entities, or access a
	broader network of services. When a client connects to an		broader network of services. When a client connects to an
	application server using Transport Layer Security [TLS], it		application server using Transport Layer Security [TLS] (or, less
	references some conception of the server's identity while attempting		commonly, [DTLS]), it references some conception of the server's
	to establish a secure connection (e.g., "the web site at		identity while attempting to establish a secure connection (e.g.,
	example.com"). Likewise, during TLS negotiation the server presents		"the web site at example.com"). Likewise, during TLS negotiation the
	its conception of the server's identity in the form of a public-key		server presents its conception of the server's identity in the form
	certificate that was issued by a certification authority in the		of a public-key certificate that was issued by a certification
	context of the Internet Public Key Infrastructure using X.509 [PKIX].		authority in the context of the Internet Public Key Infrastructure
	Only a match between the client's reference identity and the server's		using X.509 [PKIX]. Only a match between the client's reference
	presented identity enables the client to be sure that the certificate		identity and the server's presented identity enables the client to be
	can legitimately be used to secure the connection.		sure that the certificate can legitimately be used to secure the
			connection.
	Many application technologies adhere to the pattern outlined here,		Many application technologies adhere to the pattern outlined here,
	including but not limited to the following:		including but not limited to the following:
	o The Internet Message Access Protocol [IMAP] and the Post Office		o The Internet Message Access Protocol [IMAP] and the Post Office
	Protocol [POP3], for which see also [USINGTLS]		Protocol [POP3], for which see also [USINGTLS]
	o The Hypertext Transfer Protocol [HTTP], for which see also		o The Hypertext Transfer Protocol [HTTP], for which see also
	[HTTP-TLS]		[HTTP-TLS]
	skipping to change at page 5, line 24		skipping to change at page 5, line 24
	To codify best current practices regarding the implementation and		To codify best current practices regarding the implementation and
	deployment of secure PKIX-based authentication, this document		deployment of secure PKIX-based authentication, this document
	specifies recommended procedures for representing and verifying		specifies recommended procedures for representing and verifying
	server identities in certificates intended for use in applications		server identities in certificates intended for use in applications
	employing TLS.		employing TLS.
	1.2. Scope		1.2. Scope
	This document applies only to server identities associated with DNS		This document applies only to server identities associated with DNS
	domain names, only to TLS, and only to PKIX-based systems. Similar		domain names, only to TLS, and only to PKIX-based systems. As a
	considerations might apply to client identities (e.g., for mutual		result, the following scenarios are out of scope for this document:
	authentication), to identifiers other than DNS domain names (e.g., IP
	addresses), to security protocols other than TLS (e.g., [IPSEC] and		o Client or end-user identities. It is true that certificates
	[DTLS]), and to keys or certificates created outside the context of		containing such identities can be used for mutual authentication
	PKIX-based systems (e.g., on networks that use a web of trust model		between a client and server or between two clients, thus enabling
	based on [OPENPGP] or that are not directly connected to the public		stronger client-server security or end-to-end security. However,
	Internet and therefore cannot depend on Certificate Revocation Lists		certification authorities, application developers, and service
	(CRLs) or the Online Certificate Status Protocol (OCSP)). Although		operators have less experience with client certificates than with
	those scenarios might be able to re-use some aspects of the		server certificates, thus gives us fewer models from which to
	representation and verification rules provided here, they are outside		generalize.
	the scope of this document and need to be addressed by separate
	specifications.		o Identifiers other than DNS domain names. It is true that some
			certification authorities issue server certificates based on
			identifiers such as IP addresses. However, most users find DNS
			domain names much easier to work with than IP addresses, which is
			why the domain name system was designed in the first place.
			o Security protocols other than [TLS] or [DTLS]. It is true that
			some application technologies are built upon security foundations
			such as [IPSEC]. However, here again the Internet community has
			less experience with such technologies.
			o Keys or certificates employed outside the context of PKIX-based
			systems. It is true that some application technologies use a web
			of trust model based on [OPENPGP], that some application
			technologies (mostly) use self-signed certificates, and that some
			networks are not directly connected to the public Internet and
			therefore cannot depend on Certificate Revocation Lists (CRLs) or
			the Online Certificate Status Protocol [OCSP] to check CA-issued
			certificates. However, the syntax of OpenPGP keys differs
			significantly from X.509 certificates, the data in self-signed
			certificates has not been certified in any way, and checking of
			CA-issued certificates via CRLs or OSCP is critically important to
			maintaining the security of PKIX-based systems.
			Therefore, although the foregoing scenarios are of inherent interest
			and might be able to re-use many aspects of the representation and
			verification rules provided here, they are outside the scope of this
			document and need to be addressed by separate specifications.
			Furthermore, this document also does not address various
			certification authority policies, such as:
			o Whether to issue certificates based on IP addresses instead of or
			in addition to DNS domain names.
			o What information will and will not be represented in a certificate
			(e.g., whether to support the SRVName and
			uniformResourceIdentifier extensions).
			o How to certify or validate the information contained in a
			certificate.
	1.3. Terminology		1.3. Terminology
	Because the concept of "identity" is too vague to be actionable in		Because the concept of "identity" is too vague to be actionable in
	application protocols, we define a set of more concrete terms:		application protocols, we define a set of more concrete terms:
	application server: A service on the Internet that enables		application server: A service on the Internet that enables
	interactive clients and automated clients to connect for the		interactive clients and automated clients to connect for the
	purpose of retrieving or uploading information, communicate with		purpose of retrieving or uploading information, communicate with
	other entities, or connect to a broader network of services.		other entities, or connect to a broader network of services.
	skipping to change at page 6, line 28		skipping to change at page 7, line 17
	* DNS-ID = a subjectAltName identifier of type dNSName		* DNS-ID = a subjectAltName identifier of type dNSName
	* SRV-ID = the SRVName form of otherName from the GeneralName		* SRV-ID = the SRVName form of otherName from the GeneralName
	structure in SubjectAltName		structure in SubjectAltName
	* URI-ID = a subjectAltName identifier of type		* URI-ID = a subjectAltName identifier of type
	uniformResourceName		uniformResourceName
	interactive client: A software agent or device that is directly		interactive client: A software agent or device that is directly
	controlled by a natural person.		controlled by a natural person. (Other specifications related to
			security and application protocols often refer to this as a "user
			agent", e.g., [WSC-UI].)
	PKIX certificate: An X.509v3 certificate generated and employed in		PKIX certificate: An X.509v3 certificate generated and employed in
	the context of the Internet Public Key Infrastructure using X.509		the context of the Internet Public Key Infrastructure using X.509
	[PKIX].		[PKIX].
	presented identifier: An identifier that is presented by a server to		presented identifier: An identifier that is presented by a server to
	a client within the server's PKIX certificate when the client		a client within the server's PKIX certificate when the client
	attempts to establish a secure connection with the server; the		attempts to establish a secure connection with the server; the
	certificate can include one or more presented identifiers of		certificate can include one or more presented identifiers of
	different types.		different types.
	skipping to change at page 7, line 32		skipping to change at page 8, line 21
	in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT";		in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT";
	"SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY",		"SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY",
	"OPTIONAL".		"OPTIONAL".
	1.4. Discussion Venue		1.4. Discussion Venue
	[[ RFC Editor: please remove this section. ]]		[[ RFC Editor: please remove this section. ]]
	The editors are actively seeking input from certification		The editors are actively seeking input from certification
	authorities, application developers, and protocol designers regarding		authorities, application developers, and protocol designers regarding
	the recommendations in this document. Please direct feedback to the		the recommendations in this document. Please send feedback to the
	editors directly or post to the <certid@ietf.org> mailing list, for		editors directly or post to the <certid@ietf.org> mailing list, for
	which archives and subscription information are available at		which archives and subscription information are available at
	<https://www.ietf.org/mailman/listinfo/certid>.		<https://www.ietf.org/mailman/listinfo/certid>.
	1.5. Contributors		1.5. Contributors
	The following individuals made significant contributions to the text		The following individuals made significant contributions to the text
	of this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga.		of this document: Shumon Huque, RL 'Bob' Morgan, and Kurt Zeilenga.
	1.6. Acknowledgements		1.6. Acknowledgements
	The editors and contributors wish to thank the following individuals		The editors and contributors wish to thank the following individuals
	for their feedback and suggestions: Nelson Bolyard, Scott Cantor,		for their feedback and suggestions: Nelson Bolyard, Scott Cantor,
	Dave Crocker, Cyrus Daboo, Philip Guenther, Bruno Harbulot, David		Dave Crocker, Cyrus Daboo, Charles Gardiner, Philip Guenther, Bruno
	Harrington, Paul Hoffman, Scott Lawrence, Alexey Melnikov, Ludwig		Harbulot, David Harrington, Paul Hoffman, Geoff Keating, Scott
	Nussel, Joe Orton, Tom Petch, Tim Polk, Pete Resnick, Joe Salowey,		Lawrence, Alexey Melnikov, Eddy Nigg, Ludwig Nussel, Joe Orton, Tom
	and Dan Wing.		Petch, Yngven Pettersen, Tim Polk, Pete Resnick, Martin Rex, Joe
			Salowey, Rob Stradling, Dan Wing, and Dan Winship.
	2. Representation of Server Identity		2. Representation of Server Identity
	This section enumerates the rules for representing application server		This section enumerates the rules for representing application server
	identity in PKIX certificates. First we provide a brief tutorial		identity in PKIX certificates. First we provide a brief tutorial
	about subject naming, then we provide the rules.		about subject naming, then we provide the rules.
	2.1. Subject Naming in PKIX Certificates		2.1. Subject Naming in PKIX Certificates
	The application server is the subject of a server certificate. As		The application server is the subject of a server certificate. As
	skipping to change at page 8, line 25		skipping to change at page 9, line 14
	with the public key stored in the subject public key field."		with the public key stored in the subject public key field."
	The application server is identified by a name or names carried in		The application server is identified by a name or names carried in
	the subject field and/or the subjectAltName extension of the		the subject field and/or the subjectAltName extension of the
	certificate. See sections 4.1.2.6 and 4.2.1.6 of [PKIX] for details.		certificate. See sections 4.1.2.6 and 4.2.1.6 of [PKIX] for details.
	This section only briefly introduces distinguished names and their		This section only briefly introduces distinguished names and their
	components, as well as subjectAltNames and the particular		components, as well as subjectAltNames and the particular
	subjectAltName extension types explicitly mentioned in this		subjectAltName extension types explicitly mentioned in this
	specification.		specification.
	The subject field of a PKIX Certificate is defined as a X.501 type		The subject field of a PKIX certificate is defined as an X.501 type
	Name [PKIX] and known as a Distinguished Name (DN). See also [X.501]		Name and known as a Distinguished Name (DN) -- see [X.501] and
	A DN is an ordered sequence of attribute type and attribute value		[PKIX]. A DN is an ordered sequence of Relative Distinguished Name
	pairs (termed "attribute value assertions (AVAs)"), where the		(RDNs), where an RDN is a set (i.e., an unordered group) of type-and-
	attributes are to be those of the subject. Each AVA is also termed a		value pairs [LDAP-DN], each of which asserts some attribute about the
	"Relative Distinguished Name (RDN)". The RDNs are ordered in the DN		subject of the certificate. The RDNs are ordered in the DN sequence
	sequence from most general to most specific.		from most general to most specific.
	Note that certificates are binary objects -- they are encoded using		Note that certificates are binary objects -- they are encoded using
	distinguished encoding rules (DER). Thus, displayable (aka		distinguished encoding rules (DER). Thus, displayable (a.k.a.
	printable) renderings of certificate subject (and issuer) names means		printable) renderings of certificate subject (and issuer) names means
	that the DER-encoded sequences are decoded and converted into a		that the DER-encoded sequences are decoded and converted into a
	"string representation" of a DN before being rendered. Often such a		"string representation" of a DN before being rendered. Often such a
	DN string representation is ordered from left-to-right, most specific		DN string representation is ordered from left-to-right, most specific
	to most general. See [LDAP-AUTH] for details.		to most general. See [LDAP-AUTH] for details.
	Certificate subjects may also have "alternative" names. These are		Certificate subjects may also have "alternative" names. These are
	represented within certificates using the SubjectAltName field. This		represented within certificates using the SubjectAltName field. This
	field is a sequence of typed fields, where each type is a distinct		field is a sequence of typed fields, where each type is a distinct
	type of identifier. For example, the SubjectAltName identifier types		type of identifier. For example, the subjectAltName identifier types
	noted in this specification are:		noted in this specification are:
	o dNSName -- a DNS domain name [PKIX]		o dNSName -- a DNS domain name [PKIX]
	o SRVName -- a service name [SRVNAME]		o SRVName -- a DNS SRV service name [DNS-SRV] [SRVNAME]
	o uniformResourceIdentifier -- a URI [URI] [PKIX]		o uniformResourceIdentifier -- a Uniform Resource Identifier [URI]
			[PKIX]
	2.2. PKIX Certificate Name Rules		2.2. PKIX Certificate Name Rules
	The following rules apply to the representation of application server		When a certification authority issues a certificate based on the DNS
	identities in PKIX certificates issued by certification authorities.		domain name at which the server will provide the relevant service,
			the following rules apply to the representation of application server
	1. The certification authority MUST issue the certificate based on		identities.
	the DNS domain name (not an IP address) at which the server will
	provide the relevant service.
	2. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName		1. The certificate MUST include a "DNS-ID" (i.e., a subjectAltName
	identifier of type dNSName).		identifier of type dNSName).
	3. If the service using the certificate deploys a technology in		2. If the service using the certificate deploys a technology in
	which a server is discovered by means of DNS SRV records		which a server is discovered by means of DNS SRV records
	[DNS-SRV] (e.g., this is true of [XMPP]), then the certificate		[DNS-SRV] (e.g., this is true of [XMPP]), then the certificate
	SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form		SHOULD include an "SRV-ID" (i.e., an instance of the SRVName form
	of otherName from the GeneralName structure in the subjectAltName		of otherName from the GeneralName structure in the subjectAltName
	as specified in [SRVNAME]).		as specified in [SRVNAME]).
	4. If the service using the certificate deploys a technology in		3. If the service using the certificate deploys a technology in
	which a server is typically associated with a URI (e.g., this is		which a server is typically associated with a URI (e.g., this is
	true of [SIP]), then the certificate SHOULD include an URI-ID		true of [SIP]), then the certificate SHOULD include an URI-ID
	(i.e., a subjectAltName identifier of type		(i.e., a subjectAltName identifier of type
	uniformResourceIdentifier); the scheme SHALL be that of the		uniformResourceIdentifier); the scheme SHALL be that of the
	protocol associated with the application type and the authority		protocol associated with the application type and the authority
	component SHALL be the DNS domain name of the service.		component SHALL be the DNS domain name of the service.
	5. The certificate MAY include other application-specific		4. The certificate MAY include other application-specific
	identifiers for types that were defined before specification of		identifiers for types that were defined before specification of
	the SRVName extension (e.g., XmppAddr for [XMPP]) or for which		the SRVName extension (e.g., XmppAddr for [XMPP]) or for which
	service names or URI schemes do not exist; however, such		service names or URI schemes do not exist; however, such
	application-specific identifiers are not generally applicable and		application-specific identifiers are not generally applicable and
	therefore are out of scope for this specification.		therefore are out of scope for this specification.
	6. The DNS domain name portion of any identifier type MAY contain		5. The DNS domain name portion of any identifier type MAY contain
	one instance of the wildcard character '*' (see [DNS-WILD]) but		one instance of the wildcard character '*' (see [DNS-WILD]) but
	only as the left-most label of the DNS domain name component of		only as the left-most label of the DNS domain name component of
	the identifier (following the definition of "label" from		the identifier (following the definition of "label" from
	[RFC1035]). An application protocol that employs the rules		[RFC1035]). An application protocol that employs the rules
	defined in this document MUST specify whether the wildcard		defined in this document MUST specify whether the wildcard
	character is or is not allowed in certificates issued for use		character is or is not allowed in certificates issued for use
	with that protocol; by default wildcard certificates SHOULD be		with that protocol; by default wildcard certificates SHOULD be
	disallowed.		disallowed.
	7. The certificate SHOULD NOT represent the server's DNS domain name		6. The certificate SHOULD NOT represent the server's DNS domain name
	in a Relative Distinguished Name (RDN) of type Common Name (CN)		in a Relative Distinguished Name (RDN) of type Common Name (CN)
	(see [LDAP-SCHEMA]) within the subjectName field, even though it		(see [LDAP-SCHEMA]) within the subjectName field, even though it
	is recognized that many deployed clients still check for this		is recognized that many deployed clients still check for this
	legacy identifier configuration within certificate subjectName.		legacy identifier configuration within certificate subjectName.
	However, if this legacy identifer configuration is employed, then		However, if this legacy identifer configuration is employed, then
	the server's DNS domain name MUST be placed in the last (most		the server's DNS domain name MUST be placed in the last (most
	specific) RDN within the RDN sequence making up the certificate's		specific) RDN within the RDN sequence making up the certificate's
	subjectName, as the order of RDNs is determined by the DER-		subjectName, as the order of RDNs is determined by the DER-
	encoded Name within the server's PKIX certificate.		encoded Name within the server's PKIX certificate.
	8. The certificate MUST NOT represent the server's DNS domain name		7. The certificate MUST NOT represent the server's DNS domain name
	by means of a series of Domain Component (DC) attributes (because		by means of a series of Domain Component (DC) attributes (because
	the order of Domain Components is not guaranteed, certain attacks		the order of Domain Components is not guaranteed, certain attacks
	are possible if DC attributes are included).		are possible if DC attributes are included).
	3. Verification of Server Identity		3. Verification of Server Identity
	3.1. Overview		3.1. Overview
	At a high level, the client verifies the server's identity by		At a high level, the client verifies the server's identity by
	performing the following actions:		performing the following actions:
	1. Before connecting to the server, the client constructs an ordered		1. Before connecting to the server, the client constructs an ordered
	list of reference identifiers against which to check the		list of reference identifiers against which to check the
	presented identifiers.		presented identifiers.
	2. After the server provides its presented identifiers in the form		2. After the server provides its presented identifiers in the form
	of an PKIX certificate, the client checks each of its reference		of a PKIX certificate, the client checks each of its reference
	identifiers against the presented identifiers for the purpose of		identifiers against the presented identifiers for the purpose of
	finding a match.		finding a match.
	3. When checking a reference identifier against a presented		3. When checking a reference identifier against a presented
	identifier, the client (a) MUST match the source domain of the		identifier, the client (a) MUST match the source domain of the
	identifiers and (b) MAY also match the service type of the		identifiers and (b) MAY also match the service type of the
	identifiers.		identifiers.
	In addition to checking identifiers, a client MAY complete further		In addition to checking identifiers, a client MAY complete further
	checks to ensure that the server is authorized to provide the		checks to ensure that the server is authorized to provide the
	skipping to change at page 11, line 46		skipping to change at page 12, line 32
	o If a server for the application type is typically discovered by		o If a server for the application type is typically discovered by
	means of DNS SRV records, then the list SHOULD include an SRV-ID.		means of DNS SRV records, then the list SHOULD include an SRV-ID.
	o If a server for the application type is typically associated with		o If a server for the application type is typically associated with
	a URI, then the list SHOULD include a URI-ID		a URI, then the list SHOULD include a URI-ID
	o The list SHOULD NOT include a CN-ID; however, the CN-ID (if		o The list SHOULD NOT include a CN-ID; however, the CN-ID (if
	included) MUST be constructed only from the source domain and		included) MUST be constructed only from the source domain and
	never from a target domain.		never from a target domain.
	Note: A client MUST NOT construct a reference identifier		Security Note: A client MUST NOT construct a reference identifier
	corresponding to Relative Distinguished Names (RDNs) other than		corresponding to Relative Distinguished Names (RDNs) other than
	the Common Name and MUST NOT check for such RDNs in the presented		the Common Name and MUST NOT check for such RDNs in the presented
	identifiers. In particular, this means that a client MUST NOT		identifiers. In particular, this means that a client MUST NOT
	check a series of Domain Component (DC) attributes if included in		check a series of Domain Component (DC) attributes if included in
	the certificate (because the order of Domain Components is not		the certificate (because the order of Domain Components is not
	guaranteed, certain attacks are possible if DC attributes are		guaranteed, certain attacks are possible if DC attributes are
	checked).		checked).
	The client then orders the list in accordance with the following		The client then orders the list in accordance with the following
	rules:		rules:
	o Reference identifiers that include the source domain MUST be		o Reference identifiers that include the source domain MUST be
	preferred over reference identifiers that include a target domain		preferred over reference identifiers that include a target domain
	(if any).		(if any).
	o Reference identifiers that include both a DNS domain name and an		o Reference identifiers that include both a DNS domain name and an
	application type MUST be preferred over reference identifiers that		application type MUST be preferred over reference identifiers that
	include only a DNS domain name. Therefore an SRV-ID or URI-ID is		include only a DNS domain name. Therefore an SRV-ID or URI-ID is
	to be preferred over a DNS-ID.		to be preferred over a DNS-ID.
	o A reference identifier of type CN-ID (if included) MUST always be		o Notwithstanding any of the foregoing rules, reference identifiers
	the lowest-priority reference identifier in the list.		of type CN-ID (if included) MUST always be the lowest-priority
			reference identifiers in the list.
	To illustrate the ordering rules, consider the case where the inputs		To illustrate the ordering rules, consider the case where the inputs
	are a source domain of "im.example.com" and an application type of		are a source domain of "im.example.com" and an application type of
	"XMPP" (for which application servers are discovered via DNS SRV		"XMPP" (for which application servers are discovered via DNS SRV
	records) and the user of the client has also explicitly configured a		records) and the user of the client has also explicitly configured a
	target domain of "hosting.example.net". In this case, the ordered		target domain of "hosting.example.net". In this case, the ordered
	list would be:		list would be:
	1. An SRV-ID of "_xmpp.im.example.com"		1. An SRV-ID of "_xmpp.im.example.com"
	2. A DNS-ID of "im.example.com"		2. A DNS-ID of "im.example.com"
	skipping to change at page 13, line 5		skipping to change at page 13, line 36
	identifiers and has received the server's presented identifiers in		identifiers and has received the server's presented identifiers in
	the form of an PKIX certificate, the client checks its reference		the form of an PKIX certificate, the client checks its reference
	identifiers against the presented identifiers for the purpose of		identifiers against the presented identifiers for the purpose of
	finding a match. It does so by seeking a match in preference order		finding a match. It does so by seeking a match in preference order
	and aborting the search if any presented identifier matches one of		and aborting the search if any presented identifier matches one of
	its reference identifiers. The search fails if the client exhausts		its reference identifiers. The search fails if the client exhausts
	its list of reference identifiers without finding a match. Detailed		its list of reference identifiers without finding a match. Detailed
	comparison rules for finding a match are provided in the following		comparison rules for finding a match are provided in the following
	sections.		sections.
	Note: A client MUST NOT seek a match for a reference identifier of		Security Note: A client MUST NOT seek a match for a reference
	CN-ID if the presented identifiers include an SRV-ID, URI-ID,		identifier of CN-ID if the presented identifiers include an
	DNS-ID, or any application-specific subjectAltName extensions, and		SRV-ID, URI-ID, DNS-ID, or any application-specific subjectAltName
	MUST NOT check a Common Name in the certificate if it is other		extensions, and MUST NOT check a Common Name in the certificate if
	than the last Relative Distinguished Name (RDN) in within the		it is other than the last Relative Distinguished Name (RDN) in
	sequence of RDNs making up the Distinguished Name within the		within the sequence of RDNs making up the Distinguished Name
	certificate's subjectName. (Note: The term "last" refers to the		within the certificate's subjectName. (The term "last" refers to
	DER order, which is often not the string order presented to a		the DER order, which is often not the string order presented to a
	user; the order that is applied here MUST be the DER order.)		user; the order that is applied here MUST be the DER order.)
	3.4. Verifying a Domain Name		3.4. Verifying a Domain Name
	This document assumes that each reference identifier contains a DNS		This document assumes that each reference identifier contains a DNS
	domain name that is a "traditional domain name" or an		domain name that is a "traditional domain name" or an
	"internationalized domain name". The client MUST match the source		"internationalized domain name". The client MUST match the source
	domain of a reference identifier according to the following rules.		domain of a reference identifier according to the following rules.
	3.4.1. Checking of Traditional Domain Names		3.4.1. Checking of Traditional Domain Names
	skipping to change at page 15, line 6		skipping to change at page 15, line 39
	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 an SRV-ID, URI-ID,		of CN-ID if the presented identifiers include an SRV-ID, URI-ID,
	DNS-ID, or any application-specific subjectAltName extensions.		DNS-ID, or any application-specific subjectAltName extensions.
	Therefore, if and only if the identity set does not include		Therefore, if and only if the identity set does not include
	subjectAltName extensions of type dNSName, SRVName, or		subjectAltName extensions of type dNSName, SRVName, or
	uniformResourceIdentifier (or any application-specific subjectAltName		uniformResourceIdentifier (or any application-specific subjectAltName
	extensions), the client MAY as a fallback check for a DNS domain name		extensions), the client MAY as a fallback check for a DNS domain name
	in the value of the last Relative Distinguished Name (RDN), if it is		in the value of the last Relative Distinguished Name (RDN), if it is
	of type Common Name (CN), within the sequence of RDNs making up the		of type Common Name (CN), within the sequence of RDNs making up the
	Distinguished Name within the certificate's subjectName. (Note: The		Distinguished Name within the certificate's subjectName. (The term
	term "last" refers to the DER order, which is often not the string		"last" refers to the DER order, which is often not the string order
	order presented to a user; the order that is applied here MUST be the		presented to a user; the order that is applied here MUST be the DER
	DER order.)		order.)
	In existing certificates, the CN is often used for representing a DNS		In existing certificates, the CN is often used for representing a DNS
	domain name; for example, consider the following subjectName, where		domain name; for example, consider the following subjectName, where
	the last RDN is a Common Name that is intended to represent a DNS		the last RDN is a Common Name that is intended to represent a DNS
	domain name:		domain name:
	ou=Web Services, c=GB, cn=www.example.com		ou=Web Services, c=GB, cn=www.example.com
	Here the Common Name is "www.example.com" (a string whose form		Here the Common Name is "www.example.com" (a string whose form
	matches that of a DNS domain name) and the client could choose to		matches that of a DNS domain name) and the client could choose to
	skipping to change at page 16, line 52		skipping to change at page 17, line 41
	error; or		error; or
	2. Actively warn the user that the certificate is untrusted and		2. Actively warn the user that the certificate is untrusted and
	encourage the user to terminate the connection, but give advanced		encourage the user to terminate the connection, but give advanced
	users the option to (a) view the entire certificate chain, (b)		users the option to (a) view the entire certificate chain, (b)
	accept the certificate either temporarily (i.e., for this		accept the certificate either temporarily (i.e., for this
	connection attempt only) or permanently (i.e., for all future		connection attempt only) or permanently (i.e., for all future
	connection attempts), and then (c) continue with the connection		connection attempts), and then (c) continue with the connection
	attempt.		attempt.
	If a user permanently accepts a certificate, the client MUST cache		If a user permanently accepts a certificate (an action referred to in
	the certificate (or some non-forgeable representation such as a hash		[WSC-UI] as "pinning"), the client MUST cache the certificate (or
	value) and in future connection attempts MUST behave as in "Case #2:		some non-forgeable representation such as a hash value) and in future
	No Match Found, Cached Certificate".		connection attempts MUST behave as in "Case #2: No Match Found,
			Cached Certificate".
	Note: It is the responsibility of the human user to verify the		Security Note: It is the responsibility of the human user to
	hash value or fingerprint of the certificate with the server over		verify the hash value or fingerprint of the certificate with the
	a trusted communication layer.		server over a trusted communication layer.
			Informational Note: The guidelines provided here are roughly
			consistent with those provided for web browsers and other HTTP-
			aware interactive clients in [WSC-UI].
	3.6.3.2. Automated Client		3.6.3.2. Automated Client
	If the client is an automated application that is not directly		If the client is an automated application that is not directly
	controlled by a natural person, then it SHOULD terminate the		controlled by a natural person, then it SHOULD terminate the
	connection with a bad certificate error and log the error to an		connection with a bad certificate error and log the error to an
	appropriate audit log. An automated application MAY provide a		appropriate audit log. An automated application MAY provide a
	configuration setting that disables this check, but MUST enable the		configuration setting that disables this check, but MUST enable the
	check by default.		check by default.
	skipping to change at page 18, line 31		skipping to change at page 19, line 24
	Faltstrom, P., Hoffman, P., and A. Costello,		Faltstrom, P., Hoffman, P., and A. Costello,
	"Internationalizing Domain Names in Applications (IDNA)",		"Internationalizing Domain Names in Applications (IDNA)",
	RFC 3490, March 2003.		RFC 3490, March 2003.
	[IDNA2008]		[IDNA2008]
	Klensin, J., "Internationalized Domain Names in		Klensin, J., "Internationalized Domain Names in
	Applications (IDNA): Protocol",		Applications (IDNA): Protocol",
	draft-ietf-idnabis-protocol-18 (work in progress),		draft-ietf-idnabis-protocol-18 (work in progress),
	January 2010.		January 2010.
			[LDAP-DN] Zeilenga, K., "Lightweight Directory Access Protocol
			(LDAP): String Representation of Distinguished Names",
			RFC 4514, June 2006.
	[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,		[PKIX] 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, May 2008.		(CRL) Profile", RFC 5280, May 2008.
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, November 1987.		STD 13, RFC 1034, November 1987.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, November 1987.		specification", STD 13, RFC 1035, November 1987.
	skipping to change at page 20, line 50		skipping to change at page 21, line 44
	RFC 5539, May 2009.		RFC 5539, May 2009.
	[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)",		[NNTP] Feather, C., "Network News Transfer Protocol (NNTP)",
	RFC 3977, October 2006.		RFC 3977, October 2006.
	[NNTP-TLS]		[NNTP-TLS]
	Murchison, K., Vinocur, J., and C. Newman, "Using		Murchison, K., Vinocur, J., and C. Newman, "Using
	Transport Layer Security (TLS) with Network News Transfer		Transport Layer Security (TLS) with Network News Transfer
	Protocol (NNTP)", RFC 4642, October 2006.		Protocol (NNTP)", RFC 4642, October 2006.
			[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
			Adams, "X.509 Internet Public Key Infrastructure Online
			Certificate Status Protocol - OCSP", RFC 2560, June 1999.
	[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.		[OPENPGP] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R.
	Thayer, "OpenPGP Message Format", RFC 4880, November 2007.		Thayer, "OpenPGP Message Format", RFC 4880, November 2007.
	[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",		[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
	STD 53, RFC 1939, May 1996.		STD 53, RFC 1939, May 1996.
	[RFC1123] Braden, R., "Requirements for Internet Hosts - Application		[RFC1123] Braden, R., "Requirements for Internet Hosts - Application
	and Support", STD 3, RFC 1123, October 1989.		and Support", STD 3, RFC 1123, October 1989.
	[RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet		[RFC2459] Housley, R., Ford, W., Polk, T., and D. Solo, "Internet
	skipping to change at page 22, line 19		skipping to change at page 23, line 18
	[US-ASCII]		[US-ASCII]
	American National Standards Institute, "Coded Character		American National Standards Institute, "Coded Character
	Set - 7-bit American Standard Code for Information		Set - 7-bit American Standard Code for Information
	Interchange", ANSI X3.4, 1986.		Interchange", ANSI X3.4, 1986.
	[USINGTLS]		[USINGTLS]
	Newman, C., "Using TLS with IMAP, POP3 and ACAP",		Newman, C., "Using TLS with IMAP, POP3 and ACAP",
	RFC 2595, June 1999.		RFC 2595, June 1999.
			[WSC-UI] Saldhana, A. and T. Roessler, "Web Security Context: User
			Interface Guidelines", World Wide Web Consortium
			LastCall WD-wsc-ui-20100309, March 2010,
			<http://www.w3.org/TR/2010/WD-wsc-ui-20100309>.
	[X.501] International Telecommunications Union, "Information		[X.501] International Telecommunications Union, "Information
	Technology - Open Systems Interconnection - The Directory:		Technology - Open Systems Interconnection - The Directory:
	Models", ITU-T Recommendation X.501, ISO Standard 9594-2,		Models", ITU-T Recommendation X.501, ISO Standard 9594-2,
	February 2001.		February 2001.
	[XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence		[XMPP] Saint-Andre, P., Ed., "Extensible Messaging and Presence
	Protocol (XMPP): Core", RFC 3920, October 2004.		Protocol (XMPP): Core", RFC 3920, October 2004.
	[XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence		[XMPPBIS] Saint-Andre, P., "Extensible Messaging and Presence
	Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-07 (work		Protocol (XMPP): Core", draft-ietf-xmpp-3920bis-07 (work
End of changes. 36 change blocks.
	119 lines changed or deleted		179 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/