draft-ietf-uta-rfc6125bis-03.txt   draft-ietf-uta-rfc6125bis-04.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Mozilla Internet-Draft Mozilla
Obsoletes: 6125 (if approved) J. Hodges Obsoletes: 6125 (if approved) J. Hodges
Intended status: Standards Track Google Intended status: Standards Track Google
Expires: 16 April 2022 R. Salz Expires: 22 May 2022 R. Salz
Akamai Technologies Akamai Technologies
13 October 2021 18 November 2021
Representation and Verification of Domain-Based Application Service Service Names in TLS
Identity within Internet Public Key Infrastructure Using X.509 (PKIX) draft-ietf-uta-rfc6125bis-04
Certificates in the Context of Transport Layer Security (TLS)
draft-ietf-uta-rfc6125bis-03
Abstract Abstract
Many application technologies enable secure communication between two Many application technologies enable secure communication between two
entities by means of Transport Layer Security (TLS) with Internet entities by means of Transport Layer Security (TLS) with Internet
Public Key Infrastructure Using X.509 (PKIX) certificates. This Public Key Infrastructure Using X.509 (PKIX) certificates. This
document specifies procedures for representing and verifying the document specifies procedures for representing and verifying the
identity of application services in such interactions. identity of application services in such interactions.
This document obsoletes RFC 6125. This document obsoletes RFC 6125.
skipping to change at page 2, line 9 skipping to change at page 2, line 4
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 22 May 2022.
This Internet-Draft will expire on 16 April 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Simplified BSD License text extracted from this document must include Revised BSD License text as
as described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Changes since RFC 6125 . . . . . . . . . . . . . . . . . 3 1.2. Changes since RFC 6125 . . . . . . . . . . . . . . . . . 3
1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Applicability . . . . . . . . . . . . . . . . . . . . . . 4
1.4. Overview of Recommendations . . . . . . . . . . . . . . . 4 1.4. Overview of Recommendations . . . . . . . . . . . . . . . 4
1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 5 1.5.1. In Scope . . . . . . . . . . . . . . . . . . . . . . 5
1.5.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 5 1.5.2. Out of Scope . . . . . . . . . . . . . . . . . . . . 5
1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6 1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 6
2. Naming of Application Services . . . . . . . . . . . . . . . 9 2. Naming of Application Services . . . . . . . . . . . . . . . 8
3. Designing Application Protocols . . . . . . . . . . . . . . . 10 3. Designing Application Protocols . . . . . . . . . . . . . . . 10
4. Representing Server Identity . . . . . . . . . . . . . . . . 11 4. Representing Server Identity . . . . . . . . . . . . . . . . 10
4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Examples . . . . . . . . . . . . . . . . . . . . . . . . 11
5. Requesting Server Certificates . . . . . . . . . . . . . . . 12 5. Requesting Server Certificates . . . . . . . . . . . . . . . 12
6. Verifying Service Identity . . . . . . . . . . . . . . . . . 13 6. Verifying Service Identity . . . . . . . . . . . . . . . . . 12
6.1. Constructing a List of Reference Identifiers . . . . . . 13 6.1. Constructing a List of Reference Identifiers . . . . . . 13
6.1.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 13 6.1.1. Rules . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . 15 6.1.2. Examples . . . . . . . . . . . . . . . . . . . . . . 14
6.2. Preparing to Seek a Match . . . . . . . . . . . . . . . . 15 6.2. Preparing to Seek a Match . . . . . . . . . . . . . . . . 15
6.3. Matching the DNS Domain Name Portion . . . . . . . . . . 16 6.3. Matching the DNS Domain Name Portion . . . . . . . . . . 16
6.4. Matching the Application Service Type Portion . . . . . . 17 6.4. Matching the Application Service Type Portion . . . . . . 17
6.5. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.5. Outcome . . . . . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 19 7.1. Wildcard Certificates . . . . . . . . . . . . . . . . . . 19
7.2. Internationalized Domain Names . . . . . . . . . . . . . 19 7.2. Internationalized Domain Names . . . . . . . . . . . . . 19
7.3. Multiple Presented Identifiers . . . . . . . . . . . . . 20 7.3. Multiple Presented Identifiers . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . 20 9.1. Normative References . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . 21
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 23
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
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 a client communicates
automated client communicates with an application service. When a with an application service. When a client communicates with an
client communicates with an application service using Transport Layer application service using [TLS], [DTLS], or a protocol built on
Security [TLS] or Datagram Transport Layer Security [DTLS], it has those, it has some notion of the server's identity (e.g., "the
some notion of the server's identity (e.g., "the website at website at example.com") while attempting to establish secure
example.com") while attempting to establish secure communication. communication. Likewise, during TLS negotiation, the server presents
Likewise, during TLS negotiation, the server presents its notion of its notion of the service's identity in the form of a public-key
the service's identity in the form of a public-key certificate that certificate that was issued by a CA in the context of the Internet
was issued by a certification authority (CA) in the context of the Public Key Infrastructure using X.509 [PKIX]. Informally, we can
Internet Public Key Infrastructure using X.509 [PKIX]. Informally, think of these identities as the client's "reference identity" and
we can think of these identities as the client's "reference identity" the server's "presented identity"; more formal definitions are given
and the server's "presented identity" (more formal definitions are later. A client needs to verify that the server's presented identity
given later). A client needs to verify that the server's presented matches its reference identity so it can deterministically and
identity matches its reference identity so it can authenticate the automatically authenticate the communication.
communication.
This document defines procedures for how clients do this This document defines procedures for how clients do this
verification. It therefore implicitly defines requirements on other verification. It therefore also defines requirements on other
parties, such as the CA's that issue certificates, the service parties, such as the CA's that issue certificates, the service
administrators requesting them, and the protocol designers defining administrators requesting them, and the protocol designers defining
how things are named. how things are named.
1.2. Changes since RFC 6125 1.2. Changes since RFC 6125
This document revises and obsoletes [VERIFY] based on the decade of This document revises and obsoletes [VERIFY] based on the decade of
experience and changes since it was first published. The major experience and changes since it was published. The major changes, in
changes, in no particular order, include: no particular order, include:
* All references have been updated to the current latest version. * All references have been updated to the current latest version.
* The TLS SNI extension is no longer new, it is commonplace. * The TLS SNI extension is no longer new, it is commonplace.
* The only legal place for a certificate wildcard name is as the * The only legal place for a certificate wildcard name is as the
left-most component in a domain name. left-most component in a domain name.
* It is no longer allowed to use the commonName RDN, known as CN-ID, * The server identity can only be expressed in the subjectAltNames
to represent the server identity; only the subjectAltNames extension; it is no longer valid to use the commonName RDN, known
extension is used. as CN-ID in [VERIFY].
* References to the X.500 directory, the survey of prior art, and * References to the X.500 directory, the survey of prior art, and
the sample text in Appendix A have been removed. the sample text in Appendix A have been removed.
* Detailed discussion of pinning (configuring use of a certificate * Detailed discussion of pinning (configuring use of a certificate
that doesn't match the criteria in this document) has been that doesn't match the criteria in this document) has been removed
removed. and replaced with two paragraphs in Section 6.5.
* The sections detailing different target audiences and which * The sections detailing different target audiences and which
sections to read (first) have been removed. sections to read (first) have been removed.
1.3. Applicability 1.3. Applicability
This document does not supersede the rules for certificate issuance This document does not supersede the rules for certificate issuance
or validation specified by [PKIX]. That document also governs any or validation specified by [PKIX]. That document also governs any
certificate-related topic on which this document is silent. This certificate-related topic on which this document is silent. This
includes certificate syntax, certificate extensions such as name includes certificate syntax, extensions such as name constraints or
constraints or extended key usage, and handling of certification extended key usage, and handling of certification paths.
paths.
This document addresses only name forms in the leaf "end entity" This document addresses only name forms in the leaf "end entity"
server certificate. It does not address the name forms in the chain server certificate. It does not address the name forms in the chain
of certificates used to validate a cetrificate, let alone creating or of certificates used to validate a cetrificate, let alone creating or
checking the validity of such a chain. In order to ensure proper checking the validity of such a chain. In order to ensure proper
authentication, applications need to verify the entire certification authentication, applications need to verify the entire certification
path as per [PKIX]. path as per [PKIX].
1.4. Overview of Recommendations 1.4. Overview of Recommendations
The previous version of this specification, [VERIFY], surveyed the The previous version of this specification, [VERIFY], surveyed the
current practice from many IETF standards and tried to generalize current practice from many IETF standards and tried to generalize
best practices. This document takes the lessons learned in the past best practices. This document takes the lessons learned since then
decade and codifies them. he rules are brief: and codifies them. The rules are brief:
* Only check DNS domain names via the subjectAlternativeName * Only check DNS domain names via the subjectAlternativeName
extension designed for that purpose: dNSName. extension designed for that purpose: dNSName.
* Allow use of even more specific subjectAlternativeName extensions * Allow use of even more specific subjectAlternativeName extensions
where appropriate such as uniformResourceIdentifier and the where appropriate such as uniformResourceIdentifier and the
otherName form SRVName. otherName form SRVName.
* Constrain wildcard certificates so that the wildcard can only be * Constrain wildcard certificates so that the wildcard can only be
the left-most component of a domain name. the left-most component of a domain name.
skipping to change at page 5, line 27 skipping to change at page 5, line 24
practice, such as a browser connecting to a Web origin. For the sake practice, such as a browser connecting to a Web origin. For the sake
of clarity, and to follow the usage in [TLS] and related of clarity, and to follow the usage in [TLS] and related
specifications, we will continue to use to use the terms client and specifications, we will continue to use to use the terms client and
server in this document. Note that these are TLS-layer roles, and server in this document. Note that these are TLS-layer roles, and
that the application protocol could support the TLS server making that the application protocol could support the TLS server making
requests to the TLS client after the TLS handshake; these is no requests to the TLS client after the TLS handshake; these is no
requirement that the roles at the application layer match the TLS- requirement that the roles at the application layer match the TLS-
layer. layer.
At the time of this writing, other protocols such as [QUIC] and At the time of this writing, other protocols such as [QUIC] and
Network Time Security ([NTS]) use TLS as a service to do the initial Network Time Security ([NTS]) use DTLS or TLS to do the initial
establishment of cryptographic key material. Such services MUST also establishment of cryptographic key material. Such services MUST also
follow the rules specified here. follow the rules specified here.
1.5.2. Out of Scope 1.5.2. Out of Scope
The following topics are out of scope for this specification: The following topics are out of scope for this specification:
* Security protocols other than [TLS] or [DTLS] except as described * Security protocols other than [TLS] or [DTLS] except as described
above. above.
skipping to change at page 6, line 5 skipping to change at page 5, line 51
* Identifiers other than FQDNs. Identifiers such as IP address are * Identifiers other than FQDNs. Identifiers such as IP address are
not discussed. In addition, the focus of this document is on not discussed. In addition, the focus of this document is on
application service identities, not specific resources located at application service identities, not specific resources located at
such services. Therefore this document discusses Uniform Resource such services. Therefore this document discusses Uniform Resource
Identifiers [URI] only as a way to communicate a DNS domain name Identifiers [URI] only as a way to communicate a DNS domain name
(via the URI "host" component or its equivalent), not other (via the URI "host" component or its equivalent), not other
aspects of a service such as a specific resource (via the URI aspects of a service such as a specific resource (via the URI
"path" component) or parameters (via the URI "query" component). "path" component) or parameters (via the URI "query" component).
* Certification authority policies. This includes items such as the * CA policies. This includes items such as the following:
following:
- How to certify or validate FQDNs and application service types - How to certify or validate FQDNs and application service types
(see [ACME] for some definition of this). (see [ACME] for some definition of this).
- Issuing certificates with additional identifiers such as IP - Issuing certificates with additional identifiers such as IP
address or relative domain name, in addition to FQDNs. address or other, in addition to FQDNs.
- Types or "classes" of certificates to issue and whether to - Types or "classes" of certificates to issue and whether to
apply different policies for them. apply different policies for them.
- How to certify or validate other kinds of information that - How to certify or validate other kinds of information that
might be included in a certificate (e.g., organization name). might be included in a certificate (e.g., organization name).
* Resolution of DNS domain names. Although the process whereby a * Resolution of DNS domain names. Although the process whereby a
client resolves the DNS domain name of an application service can client resolves the DNS domain name of an application service can
involve several steps, for our purposes we care only about the involve several steps, for our purposes we care only about the
skipping to change at page 6, line 39 skipping to change at page 6, line 36
responsibility of client software developers and standards responsibility of client software developers and standards
development organizations dedicated to particular application development organizations dedicated to particular application
technologies (see, for example, [WSC-UI]). technologies (see, for example, [WSC-UI]).
1.6. Terminology 1.6. Terminology
Because many concepts related to "identity" are often too vague to be Because many concepts related to "identity" are often too vague to be
actionable in application protocols, we define a set of more concrete actionable in application protocols, we define a set of more concrete
terms for use in this specification. terms for use in this specification.
application service: A service on the Internet that enables application service: A service on the Internet that enables clients
interactive and automated clients to connect for the purpose of to connect for the purpose of retrieving or uploading information,
retrieving or uploading information, communicating with other communicating with other entities, or connecting to a broader
entities, or connecting to a broader network of services. network of services.
application service provider: An organization or individual that application service provider: An entity that hosts or deploys an
hosts or deploys an application service. application service.
application service type: A formal identifier for the application application service type: A formal identifier for the application
protocol used to provide a particular kind of application service protocol used to provide a particular kind of application service
at a domain. This often apepars as a URI scheme [URI] or a DNS at a domain. This often appears as a URI scheme [URI], DNS SRV
SRV Service [DNS-SRV]. Service [DNS-SRV], or an ALPN [ALPN] identifier.
automated client: A software agent or device that is not directly
controlled by a human user.
delegated domain: A domain name or host name that is explicitly delegated domain: A domain name or host name that is explicitly
configured for communicating with the source domain, by either the configured for communicating with the source domain, by either the
human user controlling an interactive client or a trusted human user controlling the client or a trusted administrator. For
administrator. For example, a server at mailhost.example.com for example, a server at mailhost.example.com for connecting to an
connecting to an IMAP server hosting an email address of IMAP server hosting an email address of user@example.com.
user@example.com.
derived domain: A domain name or host name that a client has derived derived domain: A domain name or host name that a client has derived
from the source domain in an automated fashion (e.g., by means of from the source domain in an automated fashion (e.g., by means of
a [DNS-SRV] lookup). a [DNS-SRV] lookup).
identifier: A particular instance of an identifier type that is identifier: A particular instance of an identifier type that is
either presented by a server in a certificate or referenced by a either presented by a server in a certificate or referenced by a
client for matching purposes. client for matching purposes.
identifier type: A formally defined category of identifier that can identifier type: A formally-defined category of identifier that can
be included in a certificate and therefore that can also be used be included in a certificate and therefore that can also be used
for matching purposes. For conciseness and convenience, we define for matching purposes. For conciseness and convenience, we define
the following identifier types of interest, which are based on the following identifier types of interest:
those found in the PKIX specification [PKIX] and various PKIX
extensions:
* DNS-ID: a subjectAltName entry of type dNSName * DNS-ID: a subjectAltName entry of type dNSName as defined in
[PKIX].
* SRV-ID: a subjectAltName entry of type otherName whose name * SRV-ID: a subjectAltName entry of type otherName whose name
form is SRVName; see [SRVNAME] form is SRVName, as defined in [SRVNAME].
* URI-ID: a subjectAltName entry of type * URI-ID: a subjectAltName entry of type
uniformResourceIdentifier whose value includes both (i) a uniformResourceIdentifier as defined in [PKIX]. This entry
"scheme" and (ii) a "host" component (or its equivalent) that MUST include both a "scheme" and a "host" component (or its
matches the "reg-name" rule (where the quoted terms represent equivalent) that matches the "reg-name" rule (where the quoted
the associated [ABNF] productions from [URI]) An entry which terms represent the associated [ABNF] productions from [URI]).
does not have both the scheme and host is not a valid URI-ID If the entry does not have both, it is not a valid URI-ID and
and MUST be ignored. MUST be ignored.
interactive client: A software agent or device that is directly
controlled by a human user, commonly known as a "user agent."
PKIX: PKIX is a short name for the Internet Public Key PKIX: The short name for the Internet Public Key Infrastructure
Infrastructure using X.509 defined in [PKIX]. That document using X.509 defined in [PKIX]. That document provides a profile
provides a profile of the X.509v3 certificate specifications and of the X.509v3 certificate specifications and X.509v2 certificate
X.509v2 certificate revocation list (CRL) specifications for use revocation list (CRL) specifications for use in the Internet.
in the Internet.
presented identifier: An identifier presented by a server to a presented identifier: An identifier presented by a server to a
client within a PKIX certificate when the client attempts to client within a PKIX certificate when the client attempts to
establish secure communication with the server. The certificate establish secure communication with the server. The certificate
can include one or more presented identifiers of different types, can include one or more presented identifiers of different types,
and if the server hosts more than one domain then the certificate and if the server hosts more than one domain then the certificate
might present distinct identifiers for each domain. might present distinct identifiers for each domain.
reference identifier: An identifier used by the client when reference identifier: An identifier used by the client when
examining presented identifiers. It is constructed from the examining presented identifiers. It is constructed from the
source domain, and optionally an application service type. source domain, and optionally an application service type.
Relative Distinguished Name (RDN): The ASN.1-based construction Relative Distinguished Name (RDN): An ASN.1-based construction which
comprising a Relative Distinguished Name (RDN), which itself is a itself is a building-block component of Distinguished Names. See
building-block component of Distinguished Names. See [LDAP-DN], [LDAP-DN], Section 2.
Section 2.
source domain: The FQDN that a client expects an application service source domain: The FQDN that a client expects an application service
to present in the certificate. This is typically input by a human to present in the certificate. This is typically input by a human
user, configured into a client, or provided by reference such as user, configured into a client, or provided by reference such as a
URL. The combination of a source domain and, optionally, an URL. The combination of a source domain and, optionally, an
application service type enables a client to construct one or more application service type enables a client to construct one or more
reference identifiers. reference identifiers.
subjectAltName entry: An identifier placed in a subjectAltName subjectAltName entry: An identifier placed in a subjectAltName
extension. extension.
subjectAltName extension: A standard PKIX certificate extension subjectAltName extension: A standard PKIX extension enabling
[PKIX] enabling identifiers of various types to be bound to the identifiers of various types to be bound to the certificate
certificate subject. subject.
subject name: In this specification, the term refers to the name of subjectName: The name of a PKIX certificate's subject, encoded in a
a PKIX certificate's subject, encoded in a certificate's subject certificate's subject field (see [PKIX], Section 4.1.2.6).
field (see [PKIX], Section 4.1.2.6).
Security-related terms used in this document, but not defined here or Security-related terms used in this document, but not defined here or
in [PKIX] should be understood in the the sense defined in in [PKIX] should be understood in the the sense defined in
[SECTERMS]. Such terms include "attack", "authentication", [SECTERMS]. Such terms include "attack", "authentication",
"identity", "trust", "validate", and "verify". "identity", "trust", "validate", and "verify".
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
2. Naming of Application Services 2. Naming of Application Services
This document assumes that the name of an application service is This document assumes that the name of an application service is
based on a DNS domain name (e.g., example.com) -- supplemented in based on a DNS domain name (e.g., example.com) -- supplemented in
some circumstances by an application service type (e.g., "the IMAP some circumstances by an application service type (e.g., "the IMAP
server at example.com"). The DNS name conforms to one of the server at example.com"). The DNS name conforms to one of the
following forms: following forms:
1. A "traditional domain name", i.e., a FQDN (see [DNS-CONCEPTS]) 1. A "traditional domain name", a FQDN (see [DNS-CONCEPTS]) all of
all of whose labels are "LDH labels" as described in [IDNA-DEFS]. whose labels are "LDH labels" as described in [IDNA-DEFS].
Informally, such labels are constrained to [US-ASCII] letters, Informally, such labels are constrained to [US-ASCII] letters,
digits, and the hyphen, with the hyphen prohibited in the first digits, and the hyphen, with the hyphen prohibited in the first
character position. Additional qualifications apply (refer to character position. Additional qualifications apply (refer to
the above-referenced specifications for details), but they are the above-referenced specifications for details), but they are
not relevant here. not relevant here.
2. An "internationalized domain name", a DNS domain name that 2. An "internationalized domain name", a DNS domain name that
includes at least one label containing appropriately encoded includes at least one label containing appropriately encoded
Unicode code points outside the traditional US-ASCII range. That Unicode code points outside the traditional US-ASCII range. That
is, it contains at least one U-label or A-label, but otherwise is, it contains at least one U-label or A-label, but otherwise
may contain any mixture of NR-LDH labels, A-labels, or U-labels, may contain any mixture of NR-LDH labels, A-labels, or U-labels,
as described in [IDNA-DEFS] and the associated documents. as described in [IDNA-DEFS] and the associated documents.
From the perspective of the application client or user, some names From the perspective of the application client or user, some names
are _direct_ because they are provided directly by a human user. are _direct_ because they are provided directly by a human user.
This includes runtime input, prior configuration, or explicit This includes runtime input, prior configuration, or explicit
acceptance of a client communication attempt. Other names are acceptance of a client communication attempt. Other names are
_indirect_ because they are automatically resolved by the application _indirect_ because they are automatically resolved by the application
based on user input, such as a target name resolved from a source based on user input, such as a target name resolved from a source
name using DNS SRV or [NAPTR] records). The distinction matters most name using DNS SRV or [NAPTR] records. The distinction matters most
for certificate consumption, specifically verification as discussed for certificate consumption, specifically verification as discussed
in this document. in this document.
From the perspective of the application service, some names are From the perspective of the application service, some names are
_unrestricted_ because they can be used in any type of service, such _unrestricted_ because they can be used in any type of service, such
as a single certificate being used for both the HTTP and IMAP as a single certificate being used for both the HTTP and IMAP
services at the host example.com. Other names are _restricted_ services at the host example.com. Other names are _restricted_
because they can only be used for one type of service, such as a because they can only be used for one type of service, such as a
special-purpose certificate that can only be used for an IMAP special-purpose certificate that can only be used for an IMAP
service. This distinction matters most for certificate issuance. service. This distinction matters most for certificate issuance.
We can categorize the supported identifier types as follows: We can categorize the three identifier types as follows:
* A DNS-ID is direct and unrestricted. * A DNS-ID is direct and unrestricted.
* An SRV-ID is typically indirect but can be direct, and is * An SRV-ID is typically indirect but can be direct, and is
restricted. restricted.
* A URI-ID is direct and restricted. * A URI-ID is direct and restricted.
It is important to keep these distinctions in mind, as best practices It is important to keep these distinctions in mind, as best practices
for the deployment and use of the identifiers differ. As a further for the deployment and use of the identifiers differ. Note that
example, cross-protocol attacks such as [ALPACA] are possibile when cross-protocol attacks such as [ALPACA] are possibile when two
two different protocol services use the same certificate. This can different protocol services use the same certificate. This can be
be addressed by using restricted identifiers, or telling services to addressed by using restricted identifiers, or telling services to not
not share certificates. Protocol specifications MUST specify which share certificates. Protocol specifications MUST specify which
identifiers are mandatory-to-implement and SHOULD provide operational identifiers are mandatory-to-implement and SHOULD provide operational
guidance when necessary. guidance when necessary.
The Common Name RDN MUST NOT be used to identify a service. Reasons The Common Name RDN MUST NOT be used to identify a service. Reasons
for this include: for this include:
* It is not strongly typed and therefore suffers from ambiguities in * It is not strongly typed and therefore suffers from ambiguities in
interpretation. interpretation.
* It can appear more than once in the Subject Name. * It can appear more than once in the subjectName.
For similar reasons, other RDN's within the Subject Name MUST NOT be For similar reasons, other RDN's within the subjectName MUST NOT be
used to identify a service. used to identify a service.
3. Designing Application Protocols 3. Designing Application Protocols
This section defines how protocol designers should reference this This section defines how protocol designers should reference this
document, which MUST be a normative reference in their specification. document, which MUST be a normative reference in their specification.
The technology MUST only use the identifiers defined in this The technology MUST only use the identifiers defined in this
document. Its specification MAY choose to allow only one of them. document. Its specification MAY choose to allow only one of them.
If the technology does not use DNS SRV records to resolve the DNS If the technology does not use DNS SRV records to resolve the DNS
skipping to change at page 11, line 11 skipping to change at page 10, line 42
A technology MAY disallow the use of the wildcard character in DNS A technology MAY disallow the use of the wildcard character in DNS
names. If it does so, then the specification MUST state that names. If it does so, then the specification MUST state that
wildcard certificates as defined in this document are not supported. wildcard certificates as defined in this document are not supported.
4. Representing Server Identity 4. Representing Server Identity
This section provides instructions for issuers of certificates. This section provides instructions for issuers of certificates.
4.1. Rules 4.1. Rules
When a certification authority issues a certificate based on the FQDN When a CA issues a certificate based on the FQDN at which the
at which the application service provider will provide the relevant application service provider will provide the relevant application,
application, the following rules apply to the representation of the following rules apply to the representation of application
application service identities. Note that some of these rules are service identities. Note that some of these rules are cumulative and
cumulative and can interact in important ways that are illustrated can interact in important ways that are illustrated later in this
later in this document. document.
1. The certificate MUST include a "DNS-ID" as a baseline for 1. The certificate MUST include a "DNS-ID" as a baseline for
interoperability. interoperability.
2. If the service using the certificate deploys a technology for 2. If the service using the certificate deploys a technology for
which the relevant specification stipulates that certificates which the relevant specification stipulates that certificates
ought to include identifiers of type SRV-ID (e.g., this is true ought to include identifiers of type SRV-ID (e.g., [XMPP]), then
of [XMPP]), then the certificate SHOULD include an SRV-ID. the certificate SHOULD include an SRV-ID.
3. If the service using the certificate deploys a technology for 3. If the service using the certificate deploys a technology for
which the relevant specification stipulates that certificates which the relevant specification stipulates that certificates
ought to include identifiers of type URI-ID (e.g., this is true ought to include identifiers of type URI-ID (e.g., [SIP] as
of [SIP] as specified by [SIP-CERTS]), then the certificate specified by [SIP-CERTS]), then the certificate SHOULD include a
SHOULD include a URI-ID. The scheme MUST be that of the protocol URI-ID. The scheme MUST be that of the protocol associated with
associated with the application service type and the "host" the application service type and the "host" component (or its
component (or its equivalent) MUST be the FQDN of the service. equivalent) MUST be the FQDN of the service. The application
The application protocol specification MUST specify which URI protocol specification MUST specify which URI schemes are
schemes are acceptable in URI-IDs contained in PKIX certificates acceptable in URI-IDs contained in PKIX certificates used for the
used for the application protocol (e.g., sip but not sips or tel application protocol (e.g., sip but not sips or tel for SIP as
for SIP as described in [SIP-SIPS]). described in [SIP-SIPS]).
4. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI- 4. The certificate MAY contain more than one DNS-ID, SRV-ID, or URI-
ID as further explained under Section 7.3. ID as further explained under Section 7.3.
5. The certificate MAY include other application-specific 5. The certificate MAY include other application-specific
identifiers for compatibility with a deployed base. Such identifiers for compatibility with a deployed base. Such
identifiers are out of scope for this specification. identifiers are out of scope for this specification.
4.2. Examples 4.2. Examples
skipping to change at page 12, line 43 skipping to change at page 12, line 25
for the application service type that will be secured using the for the application service type that will be secured using the
certificate to be issued. certificate to be issued.
If the certificate will be used for only a single type of application If the certificate will be used for only a single type of application
service, the service provider SHOULD request a certificate that service, the service provider SHOULD request a certificate that
includes a DNS-ID and, if appropriate for the application service includes a DNS-ID and, if appropriate for the application service
type, an SRV-ID or URI-ID that limits the deployment scope of the type, an SRV-ID or URI-ID that limits the deployment scope of the
certificate to only the defined application service type. certificate to only the defined application service type.
If the certificate might be used for any type of application service, If the certificate might be used for any type of application service,
then the service provider SHOULD to request a certificate that then the service provider SHOULD request a certificate that includes
includes only a DNS-ID. Again, because of multi-protocol attacks only a DNS-ID. Again, because of multi-protocol attacks this
this practice is discouraged; this can be mitigated by providing only practice is discouraged; this can be mitigated by deploying only one
one service on a host. service on a host.
If a service provider offersmultiple application service types and If a service provider offers multiple application service types and
wishes to limit the applicability of certificates using SRV-IDs or wishes to limit the applicability of certificates using SRV-IDs or
URI-IDs, they SHOULD request multiple certificates, rather than a URI-IDs, they SHOULD request multiple certificates, rather than a
single certificate containing multiple SRV-IDs or URI-IDs each single certificate containing multiple SRV-IDs or URI-IDs each
identifying ia different application service type. This rule does identifying ia different application service type. This rule does
not apply to application service type "bundles" that identify not apply to application service type "bundles" that identify
distinct access methods to the same underlying application such as an distinct access methods to the same underlying application such as an
email application with access methods denoted by the application email application with access methods denoted by the application
service types of imap, imaps, pop3, pop3s, and submission as service types of imap, imaps, pop3, pop3s, and submission as
described in [EMAIL-SRV]. described in [EMAIL-SRV].
skipping to change at page 14, line 32 skipping to change at page 14, line 15
For example, given an input URI of <sips:alice@example.net>, a client For example, given an input URI of <sips:alice@example.net>, a client
would derive the application service type sip from the scheme and would derive the application service type sip from the scheme and
parse the domain name example.net from the host component. parse the domain name example.net from the host component.
Each reference identifier in the list MUST be based on the source Each reference identifier in the list MUST be based on the source
domain and MUST NOT be based on a derived domain such as a domain domain and MUST NOT be based on a derived domain such as a domain
name discovered through DNS resolution of the source domain. This name discovered through DNS resolution of the source domain. This
rule is important because only a match between the user inputs and a rule is important because only a match between the user inputs and a
presented identifier enables the client to be sure that the presented identifier enables the client to be sure that the
certificate can legitimately be used to secure the client's certificate can legitimately be used to secure the client's
communication with the server. communication with the server. This removes DNS and DNS resolution
from the attack surface.
Using the combination of FQDN(s) and application service type, the Using the combination of FQDN(s) and application service type, the
client MUST construct its list of reference identifiers in accordance client MUST construct its list of reference identifiers in accordance
with the following rules: with the following rules:
* The list SHOULD include a DNS-ID. A reference identifier of type * The list SHOULD include a DNS-ID. A reference identifier of type
DNS-ID can be directly constructed from a FQDN that is (a) DNS-ID can be directly constructed from a FQDN that is (a)
contained in or securely derived from the inputs, or (b) contained in or securely derived from the inputs, or (b)
explicitly associated with the source domain by means of user explicitly associated with the source domain by means of user
configuration. configuration.
skipping to change at page 15, line 43 skipping to change at page 15, line 28
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 identifiers: IM service at im.example.org might have three reference identifiers:
an SRV-ID of _xmpp-client.im.example.org (see [XMPP]), a DNS-ID of an SRV-ID of _xmpp-client.im.example.org (see [XMPP]), a DNS-ID of
im.example.org, and an XMPP-specific XmppAddr of im.example.org (see im.example.org, and an XMPP-specific XmppAddr of im.example.org (see
[XMPP]). [XMPP]).
6.2. Preparing to Seek a Match 6.2. Preparing to Seek a Match
Once the client has constructed its list of reference identifiers and Once the client has constructed its list of reference identifiers and
has received the server's presented identifiers in the form of a PKIX has received the server's presented identifiers, the client checks
certificate, the client checks its reference identifiers against the its reference identifiers against the presented identifiers for the
presented identifiers for the purpose of finding a match. The search purpose of finding a match. The search fails if the client exhausts
fails if the client exhausts its list of reference identifiers its list of reference identifiers without finding a match. The
without finding a match. The search succeeds if any presented search succeeds if any presented identifier matches one of the
identifier matches one of the reference identifiers, at which point reference identifiers, at which point the client SHOULD stop the
the client SHOULD stop the search. search.
Before applying the comparison rules provided in the following Before applying the comparison rules provided in the following
sections, the client might need to split the reference identifier sections, the client might need to split the reference identifier
into its DNS domain name portion and its application service type into its DNS domain name portion and its application service type
portion, as follows: portion, as follows:
* A DNS-ID reference identifier MUST be used directly as the DNS * A DNS-ID reference identifier MUST be used directly as the DNS
domain name and there is no application service type. domain name and there is no application service type.
* For an SRV-ID reference identifier, the DNS domain name portion is * For an SRV-ID reference identifier, the DNS domain name portion is
skipping to change at page 16, line 42 skipping to change at page 16, line 27
SIP as explained in [SIP-CERTS]). SIP as explained in [SIP-CERTS]).
A client MUST match the DNS name, and if an application service type A client MUST match the DNS name, and if an application service type
is present it MUST also match the service type as well. These are is present it MUST also match the service type as well. These are
described below. described below.
6.3. Matching the DNS Domain Name Portion 6.3. Matching the DNS Domain Name Portion
This section describes how the client must determine if the the This section describes how the client must determine if the the
presented DNS name matches the reference DNS name. The rules differ presented DNS name matches the reference DNS name. The rules differ
depending on whether the domain to be checked is a "traditional depending on whether the domain to be checked is a traditional domain
domain name" or an "internationalized domain name" (as defined under name or an internationalized domain name, as defined in Section 2.
Section 2). For clients that support names containing the wildcard For clients that support names containing the wildcard character "*",
character "*", this section also specifies a supplemental rule for this section also specifies a supplemental rule for such "wildcard
such "wildcard certificates". This section uses the description of certificates". This section uses the description of labels and
labels and domain names in [DNS-CONCEPTS]. domain names in [DNS-CONCEPTS].
If the DNS domain name portion of a reference identifier is a If the DNS domain name portion of a reference identifier is a
"traditional domain name", then matching of the reference identifier traditional domain name, then matching of the reference identifier
against the presented identifier MUST be performed by comparing the against the presented identifier MUST be performed by comparing the
set of domain name labels using a case-insensitive ASCII comparison, set of domain name labels using a case-insensitive ASCII comparison,
as clarified by [DNS-CASE]. For example, WWW.Example.Com would be as clarified by [DNS-CASE]. For example, WWW.Example.Com would be
lower-cased to www.example.com for comparison purposes. Each label lower-cased to www.example.com for comparison purposes. Each label
MUST match in order for the names to be considered to match, except MUST match in order for the names to be considered to match, except
as supplemented by the rule about checking of wildcard labels given as supplemented by the rule about checking of wildcard labels given
below. below.
If the DNS domain name portion of a reference identifier is an If the DNS domain name portion of a reference identifier is an
internationalized domain name, then the client MUST convert any internationalized domain name, then the client MUST convert any
skipping to change at page 17, line 43 skipping to change at page 17, line 29
in a reference identifier. Note that this is not the same as DNS in a reference identifier. Note that this is not the same as DNS
wildcard matching, where the "*" label always matches at least one wildcard matching, where the "*" label always matches at least one
whole label and sometimes more. See [DNS-CONCEPTS], Section 4.3.3 whole label and sometimes more. See [DNS-CONCEPTS], Section 4.3.3
and [DNS-WILDCARDS]. and [DNS-WILDCARDS].
For information regarding the security characteristics of wildcard For information regarding the security characteristics of wildcard
certificates, see Section 7.1. certificates, see Section 7.1.
6.4. Matching the Application Service Type Portion 6.4. Matching the Application Service Type Portion
The rules for matching the application service type deopend on The rules for matching the application service type depend on whether
whether the identifier is an SRV-ID or a URI-ID. the identifier is an SRV-ID or a URI-ID.
These identifiers provide an application service type portion to be These identifiers provide an application service type portion to be
checked, but that portion is combined only with the DNS domain name checked, but that portion is combined only with the DNS domain name
portion of the SRV-ID or URI-ID itself. For example, if a client's portion of the SRV-ID or URI-ID itself. For example, if a client's
list of reference identifiers includes an SRV-ID of _xmpp- list of reference identifiers includes an SRV-ID of _xmpp-
client.im.example.org and a DNS-ID of apps.example.net, the client client.im.example.org and a DNS-ID of apps.example.net, the client
would check both the combination of an application service type of MUST check both the combination of an application service type of
xmpp-client and a DNS domain name of im.example.org and a DNS domain xmpp-client and a DNS domain name of im.example.org and a DNS domain
name of apps.example.net. However, the client would not check the name of apps.example.net. However, the client MUST NOT check the
combination of an application service type of xmpp-client and a DNS combination of an application service type of xmpp-client and a DNS
domain name of apps.example.net because it does not have an SRV-ID of domain name of apps.example.net because it does not have an SRV-ID of
_xmpp-client.apps.example.net in its list of reference identifiers. _xmpp-client.apps.example.net in its list of reference identifiers.
If the identifier is an SRV-ID, then the application service name If the identifier is an SRV-ID, then the application service name
MUST be matched in a case-insensitive manner, in accordance with MUST be matched in a case-insensitive manner, in accordance with
[DNS-SRV]. Note that the _ character is prepended to the service [DNS-SRV]. Note that the _ character is prepended to the service
identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and identifier in DNS SRV records and in SRV-IDs (per [SRVNAME]), and
thus does not need to be included in any comparison. thus does not need to be included in any comparison.
skipping to change at page 18, line 33 skipping to change at page 18, line 22
If the client has found a presented identifier that matches a If the client has found a presented identifier that matches a
reference identifier, then the service identity check has succeeded. reference identifier, then the service identity check has succeeded.
In this case, the client MUST use the matched reference identifier as In this case, the client MUST use the matched reference identifier as
the validated identity of the application service. the validated identity of the application service.
If the client does not find a presented identifier matching any of If the client does not find a presented identifier matching any of
the reference identifiers then the client MUST proceed as described the reference identifiers then the client MUST proceed as described
as follows. as follows.
If the client is an automated application not directly controlled by If the client is an automated application, then it SHOULD terminate
a human user, then it SHOULD terminate the communication attempt with the communication attempt with a bad certificate error and log the
a bad certificate error and log the error appropriately. The error appropriately. The application MAY provide a configuration
application MAY provide a configuration setting to disable this setting to disable this behavior, but it MUST enable it by default.
behavior, but it MUST enable it by default.
If the client is an interactive client that is directly controlled by If the client is one that is directly controlled by a human user,
a human user, then it SHOULD inform the user of the identity mismatch then it SHOULD inform the user of the identity mismatch and
and automatically terminate the communication attempt with a bad automatically terminate the communication attempt with a bad
certificate error in order to prevent users from inadvertently certificate error in order to prevent users from inadvertently
bypassing security protections in hostile situations. bypassing security protections in hostile situations. Such clients
MAY give advanced users the option of proceeding with acceptance
Some interactive clients MAY give advanced users the option of despite the identity mismatch. Although this behavior can be
proceeding with acceptance despite the identity mismatch. Although appropriate in certain specialized circumstances, it needs to be
this behavior can be appropriate in certain specialized handled with extreme caution, for example by first encouraging even
circumstances, it needs to be handled with extreme caution, for an advanced user to terminate the communication attempt and, if they
example by first encouraging even an advanced user to terminate the choose to proceed anyway, by forcing the user to view the entire
communication attempt and, if they choose to proceed anyway, by certification path before proceeding.
forcing the user to view the entire certification path before
proceeding.
The application MAY also present the user with the ability to accept The application MAY also present the user with the ability to accept
the presented certificate as valid for subsequent connections. Such the presented certificate as valid for subsequent connections. Such
ad-hoc "pinning" SHOULD NOT restrict future connections to just the ad-hoc "pinning" SHOULD NOT restrict future connections to just the
pinned certificate. Local policy that statically enforces a given pinned certificate. Local policy that statically enforces a given
certificate for a given peer is best made available only as prior certificate for a given peer is SHOULD made available only as prior
configuration, rather than a just-in-time override for a failed configuration, rather than a just-in-time override for a failed
connection. connection.
7. Security Considerations 7. Security Considerations
7.1. Wildcard Certificates 7.1. Wildcard Certificates
Wildcard certificates, those that have an identifier with "*" as the Wildcard certificates automatically vouch for any single-label host
left-most DNS label, automatically vouch for any single-label host
names within their domain, but not multiple levels of domains. This names within their domain, but not multiple levels of domains. This
can be convenient for administrators but also poses the risk of can be convenient for administrators but also poses the risk of
vouching for rogue or buggy hosts. See for example [Defeating-SSL] vouching for rogue or buggy hosts. See for example [Defeating-SSL]
(beginning at slide 91) and [HTTPSbytes] (slides 38-40). (beginning at slide 91) and [HTTPSbytes] (slides 38-40).
Protection against a wildcard that identifies a public suffix Protection against a wildcard that identifies a public suffix
[Public-Suffix], such as *.co.uk or *.com, is beyond the scope of [Public-Suffix], such as *.co.uk or *.com, is beyond the scope of
this document. this document.
7.2. Internationalized Domain Names 7.2. Internationalized Domain Names
skipping to change at page 20, line 12 skipping to change at page 19, line 30
certificates. For discussion, see for example [IDNA-DEFS], certificates. For discussion, see for example [IDNA-DEFS],
Section 4.4 and [UTS-39]. Section 4.4 and [UTS-39].
7.3. Multiple Presented Identifiers 7.3. Multiple Presented Identifiers
A given application service might be addressed by multiple DNS domain A given application service might be addressed by multiple DNS domain
names for a variety of reasons, and a given deployment might service names for a variety of reasons, and a given deployment might service
multiple domains or protocols. TLS Extensions such as TLS Server multiple domains or protocols. TLS Extensions such as TLS Server
Name Identification (SNI), discussed in [TLS], Section 4.4.2.2, and Name Identification (SNI), discussed in [TLS], Section 4.4.2.2, and
Application Layer Protocol Negotiation (ALPN), discussed in [ALPN], Application Layer Protocol Negotiation (ALPN), discussed in [ALPN],
provide a way for the application to indicate the desired identifier provide a way for the client to indicate the desired identifier and
and protocol to the server, which can be used to select the most protocol to the server, which can then select the most appropriate
appropriate certificate. certificate.
To accommodate the workaround that was needed before the development To accommodate the workaround that was needed before the development
of the SNI extension, this specification allows multiple DNS-IDs, of the SNI extension, this specification allows multiple DNS-IDs,
SRV-IDs, or URI-IDs in a certificate. SRV-IDs, or URI-IDs in a certificate.
8. IANA Considerations 8. IANA Considerations
This document has no actions for IANA. This document has no actions for IANA.
9. References 9. References
skipping to change at page 24, line 27 skipping to change at page 23, line 43
Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120, Protocol (XMPP): Core", RFC 6120, DOI 10.17487/RFC6120,
March 2011, <https://www.rfc-editor.org/rfc/rfc6120>. March 2011, <https://www.rfc-editor.org/rfc/rfc6120>.
Acknowledgements Acknowledgements
We gratefully acknowledge everyone who contributed to the previous We gratefully acknowledge everyone who contributed to the previous
version of this document, [VERIFY]. Thanks also to Carsten Bormann version of this document, [VERIFY]. Thanks also to Carsten Bormann
for converting the previous document to Markdown so that we could for converting the previous document to Markdown so that we could
more easily use Martin Thomson's i-d-template software. more easily use Martin Thomson's i-d-template software.
In addition to discussion on the mailing list, the following people
contributed significant changes: Viktor Dukhovni, Jim Fenton, Olle
Johansson, and Ryan Sleevi.
Authors' Addresses Authors' Addresses
Peter Saint-Andre Peter Saint-Andre
Mozilla Mozilla
United States of America United States of America
Email: stpeter@mozilla.com Email: stpeter@mozilla.com
Jeff Hodges Jeff Hodges
Google Google
United States of America United States of America
Email: jdhodges@google.com Email: jdhodges@google.com
Rich Salz Rich Salz
Akamai Technologies Akamai Technologies
 End of changes. 63 change blocks. 
179 lines changed or deleted 161 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/