rfc8657xml2.original.xml   rfc8657.xml 
<?xml version="1.0" encoding="UTF-8"?> <?xml version='1.0' encoding='utf-8'?>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?> <!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>
<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>
<rfc ipr="trust200902" docName="draft-ietf-acme-caa-10" category="std">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
category="std" consensus="true" number="8657" ipr="trust200902"
docName="draft-ietf-acme-caa-10" obsoletes="" updates=""
xml:lang="en" tocInclude="true" symRefs="true"
sortRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 2.28.0 -->
<front> <front>
<title abbrev="ACME-CAA">CAA Record Extensions for Account URI and ACME Meth <title abbrev="ACME-CAA">Certification Authority Authorization (CAA)
od Binding</title> Record Extensions for Account URI and Automatic Certificate Management
Environment (ACME) Method Binding</title>
<seriesInfo name="RFC" value="8657"/>
<author initials="H." surname="Landau" fullname="Hugo Landau"> <author initials="H." surname="Landau" fullname="Hugo Landau">
<organization></organization> <organization/>
<address> <address>
<email>hlandau@devever.net</email> <email>hlandau@devever.net</email>
</address> </address>
</author> </author>
<date year="2019" month="November"/>
<date year="2019" month="June" day="20"/>
<area>General</area>
<workgroup>ACME Working Group</workgroup>
<keyword>Internet-Draft</keyword>
<abstract> <abstract>
<t>The Certification Authority Authorization (CAA) DNS record allows a dom
<t>The Certification Authority Authorization (CAA) DNS record allows a domain to ain to
communicate issuance policy to Certification Authorities (CAs), but only allows communicate an issuance policy to Certification Authorities (CAs) but only allow
a domain to define policy with CA-level granularity. However, the CAA s
specification also provides facilities for extension to admit more granular, a domain to define a policy with CA-level granularity. However, the CAA
CA-specific policy. This specification defines two such parameters, one specification (RFC 8659) also provides facilities for an extension to admit a
allowing specific accounts of a CA to be identified by URI and one allowing more granular, CA-specific policy. This specification defines two such
specific methods of domain control validation as defined by the ACME protocol parameters: one allowing specific accounts of a CA to be identified by URIs
to be required.</t> and one allowing specific methods of domain control validation as defined by
the Automatic Certificate Management Environment (ACME) protocol to be
required.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" numbered="true" toc="default">
<section anchor="introduction" title="Introduction"> <name>Introduction</name>
<t>This specification defines two parameters for the "issue" and "issuewil
<t>This specification defines two parameters for the “issue” and “issuewild” d"
properties of the Certification Authority Authorization (CAA) DNS resource Properties of the Certification Authority Authorization (CAA) DNS resource
record <xref target="I-D.ietf-lamps-rfc6844bis"/>. The first, “accounturi”, allo record <xref target="RFC8659" format="default"/>. The first, "accounturi", allow
ws s
authorization conferred by a CAA policy to be restricted to specific accounts authorization conferred by a CAA policy to be restricted to specific accounts
of a CA, which are identified by URIs. The second, “validationmethods”, allows of a Certification Authority (CA), which are identified by URIs. The second, "va lidationmethods", allows
the set of validation methods supported by a CA to validate domain control to the set of validation methods supported by a CA to validate domain control to
be limited to a subset of the full set of methods which it supports.</t> be limited to a subset of the full set of methods that it supports.</t>
</section>
</section> <section anchor="terminology" numbered="true" toc="default">
<section anchor="terminology" title="Terminology"> <name>Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14
<t>In this document, the key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHA >REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
LL "<bcp14>SHALL&nbsp;NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD&nbsp;NO
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and T</bcp14>", "<bcp14>RECOMMENDED</bcp14>",
“OPTIONAL” are to be interpreted as described in BCP 14 <xref target="RFC2119"/> "<bcp14>NOT&nbsp;RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONA
<xref target="RFC8174"/> L</bcp14>" in this document
when, and only when, they appear in all capitals, as shown here.</t> are to be interpreted as described in BCP&nbsp;14
<xref target="RFC2119" format="default"/> <xref target="RFC8174" format="default
</section> "/> when,
<section anchor="extensions-to-the-caa-record-accounturi-parameter" title="Exten and only when, they appear in all capitals, as shown here.</t>
sions to the CAA Record: accounturi Parameter"> </section>
<section anchor="extensions-to-the-caa-record-accounturi-parameter" numbered
<t>A CAA parameter “accounturi” is defined for the “issue” and “issuewild” ="true" toc="default">
properties defined by <xref target="I-D.ietf-lamps-rfc6844bis"/>. The value of t <name>Extensions to the CAA Record: The "accounturi" Parameter</name>
his <t>This document defines the "accounturi" CAA parameter for the "issue" an
parameter, if specified, MUST be a URI <xref target="RFC3986"/> identifying a sp d
ecific CA "issuewild" Properties defined by <xref target="RFC8659" format="default"/>. The
account.</t> value of this
parameter, if specified, <bcp14>MUST</bcp14> be a URI <xref target="RFC3986" for
<t>“CA account” means an object, maintained by a specific CA and which may reque mat="default"/> identifying a
st specific CA account.</t>
the issuance of certificates, which represents a specific entity or group of <t>"CA account" means an object that is maintained by a specific CA, that
may request
the issuance of certificates, and that represents a specific entity or group of
related entities.</t> related entities.</t>
<t>The presence of this parameter constrains the Property to which it is a
<t>The presence of this parameter constrains the property to which it is attache ttached.
d. Where a CAA Property has an "accounturi" parameter, a CA <bcp14>MUST</bcp14> onl
Where a CAA property has an “accounturi” parameter, a CA MUST only consider y consider
that property to authorize issuance in the context of a given certificate that Property to authorize issuance in the context of a given certificate
issuance request if the CA recognises the URI specified in the value portion of issuance request if the CA recognizes the URI specified in the value portion of
that parameter as identifying the account making that request.</t> that parameter as identifying the account making that request.</t>
<t>A Property without an "accounturi" parameter matches any account. A Pro
<t>A property without an “accounturi” parameter matches any account. A property perty
with an invalid or unrecognised “accounturi” parameter is unsatisfiable. A with an invalid or unrecognized "accounturi" parameter is unsatisfiable. A
property with multiple “accounturi” parameters is unsatisfiable.</t> Property with multiple "accounturi" parameters is unsatisfiable.</t>
<t>The presence of an "accounturi" parameter does not replace or supersede
<t>The presence of an “accounturi” parameter does not replace or supercede the the
need to validate the domain name specified in an “issue” or “issuewild” record need to validate the domain name specified in an "issue" or "issuewild" record
in the manner described in the CAA specification. CAs MUST still perform such in the manner described in the CAA
validation. For example, a CAA “issue” property which specifies a domain name specification <xref target="RFC8659" format="default"/>. CAs <bcp14>MUST</bcp
belonging to CA A and an “accounturi” parameter identifying an account at CA B 14> still perform such
validation. For example, a CAA "issue" Property that specifies a domain name
belonging to CA A and an "accounturi" parameter identifying an account at CA B
is unsatisfiable.</t> is unsatisfiable.</t>
<section anchor="use-with-acme" numbered="true" toc="default">
<section anchor="use-with-acme" title="Use with ACME"> <name>Use with ACME</name>
<t>An Automatic Certificate Management Environment (ACME) <xref target="
<t>An ACME <xref target="RFC8555"/> account object MAY be identified by setting RFC8555" format="default"/> account object <bcp14>MAY</bcp14> be identified by s
the etting the
“accounturi” parameter to the URI of the ACME account object.</t> "accounturi" parameter to the URI of the ACME account object.</t>
<t>Implementations of this specification that also implement ACME <bcp14
<t>Implementations of this specification which also implement ACME MUST recognis >MUST</bcp14> recognize
e
such URIs.</t> such URIs.</t>
</section>
</section> <section anchor="use-without-acme" numbered="true" toc="default">
<section anchor="use-without-acme" title="Use without ACME"> <name>Use without ACME</name>
<t>The "accounturi" specification provides a general mechanism to identi
<t>The “accounturi” specification provides a general mechanism to identify fy
entities which may request certificate issuance via URIs. The use of specific entities that may request certificate issuance via URIs. The use of specific
kinds of URI may be specified in future RFCs, and CAs not implementing ACME MAY kinds of URIs may be specified in future RFCs, and CAs not implementing ACME <bc
assign and recognise their own URIs arbitrarily.</t> p14>MAY</bcp14>
assign and recognize their own URIs arbitrarily.</t>
</section> </section>
</section> </section>
<section anchor="extensions-to-the-caa-record-validationmethods-parameter" title <section anchor="extensions-to-the-caa-record-validationmethods-parameter" n
="Extensions to the CAA Record: validationmethods Parameter"> umbered="true" toc="default">
<name>Extensions to the CAA Record: The "validationmethods" Parameter</nam
<t>A CAA parameter “validationmethods” is also defined for the “issue” and e>
“issuewild” properties. The value of this parameter, if specified, MUST be a <t>This document also defines the "validationmethods" CAA parameter for th
e "issue" and
"issuewild" Properties. The value of this parameter, if specified, <bcp14>MUST</
bcp14> be a
comma-separated string of zero or more validation method labels.</t> comma-separated string of zero or more validation method labels.</t>
<t>A validation method label identifies a validation method. A validation
<t>A validation method label identifies a validation method. A validation method method
is a particular way in which a CA can validate control over a domain.</t> is a particular way in which a CA can validate control over a domain.</t>
<t>The presence of this parameter constrains the Property to which it is a
<t>The presence of this parameter constrains the property to which it is attache ttached.
d. A CA <bcp14>MUST</bcp14> only consider a Property with the "validationmethods" p
A CA MUST only consider a property with the “validationmethods” parameter to arameter to
authorize issuance where the validation method being used is identified by one authorize issuance where the validation method being used is identified by one
of the validation method labels listed in the comma-separated list.</t> of the validation method labels listed in the comma-separated list.</t>
<t>Each validation method label <bcp14>MUST</bcp14> be either the label of
<t>Each validation method label MUST be either the label of a method defined in a method defined in
the ACME Validation Methods IANA registry, or a CA-specific non-ACME validation the "ACME Validation Methods" IANA registry
<xref target="RFC8555" format="default"/> or a CA&#8209;specific non-ACME valida
tion
method label as defined below.</t> method label as defined below.</t>
<t>Where a CA supports both the "validationmethods" parameter and one or m
<t>Where a CA supports both the “validationmethods” parameter and one or more ore
non-ACME validation methods, it MUST assign labels to those methods. If non-ACME validation methods, it <bcp14>MUST</bcp14> assign labels to those metho
appropriate non-ACME labels are not present in the ACME Validation Methods IANA ds. If
registry, the CA MUST use labels beginning with the string “ca-“, which are appropriate non-ACME labels are not present in the "ACME Validation Methods" IAN
A
registry, the CA <bcp14>MUST</bcp14> use labels beginning with the string "ca-",
which are
defined to have CA-specific meaning.</t> defined to have CA-specific meaning.</t>
<t>The value of the "validationmethods" parameter <bcp14>MUST</bcp14> comp
ly with the following
ABNF <xref target="RFC5234" format="default"/>:</t>
<t>The value of the “validationmethods” parameter MUST comply with the following <sourcecode name="abnf-for-validationmethods" type="abnf" ><![CDATA[
ABNF <xref target="RFC5234"/>:</t> value = [*(label ",") label]
label = 1*(ALPHA / DIGIT / "-") ]]></sourcecode>
<figure><artwork><![CDATA[ </section>
value = [*(label ",") label] <section anchor="security-considerations" numbered="true" toc="default">
label = 1*(ALPHA / DIGIT / "-") <name>Security Considerations</name>
]]></artwork></figure> <t>This specification describes an extension to the CAA record specificati
on,
</section> increasing the granularity at which a CAA policy can be expressed. This allows
<section anchor="security-considerations" title="Security Considerations">
<t>This specification describes an extension to the CAA record specification
increasing the granularity at which CAA policy can be expressed. This allows
the set of entities capable of successfully requesting issuance of certificates the set of entities capable of successfully requesting issuance of certificates
for a given domain to be restricted beyond that which would otherwise be for a given domain to be restricted beyond the set of entities would otherwise
possible, while still allowing issuance for specific accounts of a CA. This be possible, while still allowing issuance for specific accounts of a CA. This
improves the security of issuance for domains which choose to employ it, when improves the security of issuance for domains that choose to employ it, when
combined with a CA which implements this specification.</t> combined with a CA that implements this specification.</t>
<section anchor="limited-to-cas-processing-caa-records" numbered="true" to
<section anchor="limited-to-cas-processing-caa-records" title="Limited to CAs Pr c="default">
ocessing CAA Records"> <name>Limited to CAs Processing CAA Records</name>
<t>All of the security considerations listed in <xref target="RFC8659" f
<t>All of the security considerations of the CAA specification are inherited by ormat="default"/> are inherited by
this document. This specification merely enables a domain with an existing this document. This specification merely enables a domain with an existing
relationship with a CA to further constrain that CA in its issuance practices, relationship with a CA to further constrain that CA in its issuance practices,
where that CA implements this specification. In particular, it provides no where that CA implements this specification. In particular, it provides no
additional security above that provided by use of the unextended CAA additional security above that provided by using the unextended CAA
specification alone as concerns matters relating to any other CA. The capacity specification alone as concerns matters relating to any other CA. The capacity
of any other CA to issue certificates for the given domain is completely of any other CA to issue certificates for the given domain is completely
unchanged.</t> unchanged.</t>
<t>As such, a domain that, via CAA records, authorizes only CAs adopting
<t>As such, a domain which via CAA records authorizes only CAs adopting this this
specification, and which constrains its policy by means of this specification, specification and that constrains its policy by means of this specification,
remains vulnerable to unauthorized issuance by CAs which do not honour CAA remains vulnerable to unauthorized issuance by CAs that do not honor CAA
records, or which honour them only on an advisory basis. Where a domain uses records or that honor them only on an advisory basis. Where a domain uses
DNSSEC, it also remains vulnerable to CAs which honour CAA records but which do DNSSEC, it also remains vulnerable to CAs that honor CAA records but that do
not validate CAA records by means of a trusted DNSSEC-validating resolver.</t> not validate CAA records by means of a trusted DNSSEC-validating resolver.</t>
</section>
</section> <section anchor="restrictions-ineffective-without-ca-recognition" numbered
<section anchor="restrictions-ineffective-without-ca-recognition" title="Restric ="true" toc="default">
tions Ineffective without CA Recognition"> <name>Restrictions Ineffective without CA Recognition</name>
<t>Because the parameters of "issue" or "issuewild" CAA Properties const
<t>Because the parameters of “issue” or “issuewild” CAA properties constitute a itute a
CA-specific namespace, the CA identified by an “issue” or “issuewild” property CA-specific namespace, the CA identified by an "issue" or "issuewild" Property
decides what parameters to recognise and their semantics. Accordingly, the CAA decides what parameters to recognize and their semantics. Accordingly, the CAA
parameters defined in this specification rely on their being recognised by the parameters defined in this specification rely on their being recognized by the
CA named by an “issue” or “issuewild” CAA property, and are not an effective CA named by an "issue" or "issuewild" CAA Property and are not an effective
means of control over issuance unless a CA’s support for the parameters is means of control over issuance unless a CA's support for the parameters is
established beforehand.</t> established beforehand.</t>
<t>CAs that implement this specification <bcp14>SHOULD</bcp14> make avai
<t>CAs which implement this specification SHOULD make available documentation lable documentation
indicating as such, including explicit statements as to which parameters are indicating as such, including explicit statements as to which parameters are
supported. Domains configuring CAA records for a CA MUST NOT assume that the supported. Domains configuring CAA records for a CA <bcp14>MUST NOT</bcp14> assu
restrictions implied by the “accounturi” and “validationmethods” parameters are me that the
restrictions implied by the "accounturi" and "validationmethods" parameters are
effective in the absence of explicit indication as such from that CA.</t> effective in the absence of explicit indication as such from that CA.</t>
<t>CAs <bcp14>SHOULD</bcp14> also document whether they implement DNSSEC
<t>CAs SHOULD also document whether they implement DNSSEC validation for DNS validation for DNS
lookups done for validation purposes, as this affects the security of the lookups done for validation purposes, as this affects the security of the
“accounturi” and “validationmethods” parameters.</t> "accounturi" and "validationmethods" parameters.</t>
</section>
</section> <section anchor="mandatory-consistency-in-ca-recognition" numbered="true"
<section anchor="mandatory-consistency-in-ca-recognition" title="Mandatory Consi toc="default">
stency in CA Recognition"> <name>Mandatory Consistency in CA Recognition</name>
<t>A CA <bcp14>MUST</bcp14> ensure that its support for the "accounturi"
<t>A CA MUST ensure that its support for the “accounturi” and “validationmethods and "validationmethods"
” parameters is fully consistent for a given domain name that a CA recognizes as
parameters is fully consistent for a given domain name which a CA recognises as identifying itself in a CAA "issue" or "issuewild" Property. If a CA has
identifying itself in a CAA “issue” or “issuewild” property. If a CA has
multiple issuance systems (for example, an ACME-based issuance system and a multiple issuance systems (for example, an ACME-based issuance system and a
non-ACME based issuance system, or two different issuance systems resulting non-ACME-based issuance system, or two different issuance systems resulting
from a corporate merger), it MUST ensure that all issuance systems recognise from a corporate merger), it <bcp14>MUST</bcp14> ensure that all issuance system
s recognize
the same parameters.</t> the same parameters.</t>
<t>A CA that is unable to do this <bcp14>MAY</bcp14> still implement the
<t>A CA which is unable to do this MAY still implement the parameters by splitti parameters by splitting
ng
the CA into two domain names for the purposes of CAA processing. For example, a the CA into two domain names for the purposes of CAA processing. For example, a
CA “example.com” with an ACME-based issuance system and a non-ACME-based CA "example.com" with an ACME-based issuance system and a non-ACME-based
issuance system could recognise only “acme.example.com” for the former and issuance system could recognize only "acme.example.com" for the former and
“example.com” for the latter, and then implement support for the “accounturi” "example.com" for the latter, and then implement support for the "accounturi"
and “validationmethods” parameters for “acme.example.com” only.</t> and "validationmethods" parameters for "acme.example.com" only.</t>
<t>A CA that is unable to ensure consistent processing of the "accountur
<t>A CA which is unable to ensure consistent processing of the “accounturi” or i"
“validationmethods” parameters for a given CA domain name as specifiable in CAA parameter or the
“issue” or “issuewild” properties MUST NOT implement support for these "validationmethods" parameter for a given CA domain name as specifiable in CAA
"issue" or "issuewild" Properties <bcp14>MUST NOT</bcp14> implement support for
these
parameters. Failure to do so would result in an implementation of these parameters. Failure to do so would result in an implementation of these
parameters which does not provide effective security.</t> parameters that does not provide effective security.</t>
</section>
</section> <section anchor="uri-ambiguity" numbered="true" toc="default">
<section anchor="uri-ambiguity" title="URI Ambiguity"> <name>URI Ambiguity</name>
<t>Suppose that CA A recognizes "a.example.com" as identifying itself an
<t>Suppose that CA A recognises “a.example.com” as identifying itself, CA B is a d
subsidiary of CA A which recognises both “a.example.com” and “b.example.com” as CA B is a subsidiary of CA A that recognizes both "a.example.com" and "b.example
.com" as
identifying itself.</t> identifying itself.</t>
<t>Suppose that both CA A and CA B issue account URIs of the form:</t>
<t>Suppose that both CA A and CA B issue account URIs of the form</t> <artwork name="" type="" align="left" alt=""><![CDATA[
"urn:example:account-id:1234" ]]></artwork>
<t>“urn:example:account-id:1234”</t> <t>If the CA domain name in a CAA record is specified as "a.example.com"
, then this
<t>If the CA domain name in a CAA record is specified as “a.example.com” then th could be construed as identifying account number 1234 at CA&nbsp;A or at CA B. T
is hese
could be construed as identifying account number 1234 at CA A or at CA B. These
may be different accounts, creating ambiguity.</t> may be different accounts, creating ambiguity.</t>
<t>Thus, CAs <bcp14>MUST</bcp14> ensure that the URIs they recognize as
<t>Thus, CAs MUST ensure that the URIs they recognise as pertaining to a specifi pertaining to a specific
c account of that CA are unique within the scope of all domain names that they
account of that CA are unique within the scope of all domain names which they recognize as identifying that CA for the purpose of CAA record validation.</t>
recognise as identifying that CA for the purpose of CAA record validation.</t> <t>CAs <bcp14>SHOULD</bcp14> satisfy this requirement by using URIs that
include an authority
<t>CAs SHOULD satisfy this requirement by using URIs which include an authority (see <xref target="RFC3986" sectionFormat="of" section="3.2"/>):</t>
(see Section 3.2 of <xref target="RFC3986"/>):</t> <artwork name="" type="" align="left" alt=""><![CDATA[
"https://a.example.com/account/1234" ]]></artwork>
<t>“https://a.example.com/account/1234”</t> </section>
<section anchor="authorization-freshness" numbered="true" toc="default">
</section> <name>Authorization Freshness</name>
<section anchor="authorization-freshness" title="Authorization Freshness"> <t>The CAA specification <xref target="RFC8659" format="default"/> gover
ns the act of issuance by a CA. In some cases, a CA
<t>The CAA specification governs the act of issuance by a CA. In some cases, a C
A
may establish authorization for an account to request certificate issuance for may establish authorization for an account to request certificate issuance for
a specific domain separately to the act of issuance itself. Such authorization a specific domain separately from the act of issuance itself. Such authorization
may occur substantially prior to a certificate issuance request. The CAA policy may occur substantially prior to a certificate issuance request. The CAA policy
expressed by a domain may have changed in the meantime, creating the risk that expressed by a domain may have changed in the meantime, creating the risk that
a CA will issue certificates in a manner inconsistent with the presently a CA will issue certificates in a manner inconsistent with the presently
published CAA policy.</t> published CAA policy.</t>
<t>CAs <bcp14>SHOULD</bcp14> adopt practices to reduce the risk of such
<t>CAs SHOULD adopt practices to reduce the risk of such circumstances. Possible circumstances. Possible
countermeasures include issuing authorizations with very limited validity countermeasures include issuing authorizations with very limited validity
periods, such as an hour, or revalidating the CAA policy for a domain at periods, such as an hour, or revalidating the CAA policy for a domain at
certificate issuance time.</t> certificate issuance time.</t>
</section>
</section> <section anchor="use-with-and-without-dnssec" numbered="true" toc="default
<section anchor="use-with-and-without-dnssec" title="Use with and without DNSSEC ">
"> <name>Use with and without DNSSEC</name>
<t>The "domain validation" model of validation commonly used for certifi
<t>The “domain validation” model of validation commonly used for certificate cate
issuance cannot ordinarily protect against adversaries who can conduct global issuance cannot ordinarily protect against adversaries who can conduct global
man-in-the-middle attacks against a particular domain. A global man-in-the-middle attacks against a particular domain. A global
man-in-the-middle attack is an attack which can intercept traffic to or from a man-in-the-middle attack is an attack that can intercept traffic to or from a
given domain, regardless of the origin or destination of that traffic. Such an given domain, regardless of the origin or destination of that traffic. Such an
adversary can intercept all validation traffic initiated by a CA and thus adversary can intercept all validation traffic initiated by a CA and thus
appear to have control of the given domain.</t> appear to have control of the given domain.</t>
<t>Where a domain is signed using DNSSEC, the authenticity of its DNS da
<t>Where a domain is signed using DNSSEC, the authenticity of its DNS data can b ta can be
e
assured, providing that a given CA makes all DNS resolutions via a trusted assured, providing that a given CA makes all DNS resolutions via a trusted
DNSSEC-validating resolver. A domain can use this property to protect itself DNSSEC-validating resolver. A domain can use this Property to protect itself
from the threat posed by an adversary capable of performing a global from the threat posed by an adversary capable of performing a global
man-in-the-middle attack against that domain.</t> man-in-the-middle attack against that domain.</t>
<t>In order to facilitate this, a CA validation process must either rely
<t>In order to facilitate this, a CA validation process must either rely solely solely on
on information obtained via DNSSEC or meaningfully bind the other parts of the
information obtained via DNSSEC, or meaningfully bind the other parts of the
validation transaction using material obtained via DNSSEC.</t> validation transaction using material obtained via DNSSEC.</t>
<t>The CAA parameters described in this specification can be used to ens
<t>The CAA parameters described in this specification can be used to ensure that ure that
only validation methods meeting these criteria are used. In particular, a only validation methods meeting these criteria are used. In particular, a
domain secured via DNSSEC SHOULD either:</t> domain secured via DNSSEC <bcp14>SHOULD</bcp14> either:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>Use the "accounturi" parameter to ensure that only accounts that i
<t>Use the “accounturi” parameter to ensure that only accounts which it t
controls are authorized to obtain certificates, or</t> controls are authorized to obtain certificates, or</li>
<t>Exclusively use validation methods which rely solely on information <li>Exclusively use validation methods that rely solely on information
obtained via DNSSEC, and use the “validationmethods” parameter to ensure obtained via DNSSEC and use the "validationmethods" parameter to ensure
that only such methods are used.</t> that only such methods are used.</li>
</list></t> </ol>
<t>A CA supporting the "accounturi" parameter or the "validationmethods"
<t>A CA supporting the “accounturi” or “validationmethods” parameters MUST perfo parameter <bcp14>MUST</bcp14> perform
rm CAA validation using a trusted DNSSEC&#8209;validating resolver.</t>
CAA validation using a trusted, DNSSEC-validating resolver.</t> <t>"Trusted" in this context means that the CA both trusts the resolver
itself and
<t>“Trusted” in this context means that the CA both trusts the resolver itself a
nd
ensures that the communications path between the resolver and the system ensures that the communications path between the resolver and the system
performing CAA validation are secure. It is RECOMMENDED that a CA ensure this performing CAA validation is secure. It is <bcp14>RECOMMENDED</bcp14> that a CA ensure this
by using a DNSSEC-validating resolver running on the same machine as the system by using a DNSSEC-validating resolver running on the same machine as the system
performing CAA validation.</t> performing CAA validation.</t>
<t>The use of the "accounturi" parameter or the "validationmethods" para
<t>Use of the “accounturi” or “validationmethods” parameters does not confer meter does not confer
additional security against an attacker capable of performing a additional security against an attacker capable of performing a
man-in-the-middle attack against all validation attempts made by a given CA man-in-the-middle attack against all validation attempts made by a given CA
which is authorized by CAA where:</t> that is authorized by CAA where:</t>
<ol spacing="normal" type="1">
<t><list style="numbers"> <li>A domain does not secure its nameservers using DNSSEC, or</li>
<t>A domain does not secure its nameservers using DNSSEC, or</t> <li>That CA does not perform CAA validation using a trusted DNSSEC&#82
<t>That CA does not perform CAA validation using a trusted DNSSEC-validating 09;validating
resolver.</t> resolver.</li>
</list></t> </ol>
<t>Moreover, the use of the "accounturi" parameter or the "validationmet
<t>Moreover, use of the “accounturi” or “validationmethods” parameters does not hods" parameter does not
mitigate against man-in-the-middle attacks against CAs which do not validate mitigate man-in-the-middle attacks against CAs that do not validate
CAA records, or which do not do so using a trusted DNSSEC-validating resolver, CAA records or that do not do so using a trusted DNSSEC-validating resolver,
regardless of whether those CAs are authorized by CAA or not; see regardless of whether or not those CAs are authorized by CAA; see
<xref target="limited-to-cas-processing-caa-records"/>.</t> <xref target="limited-to-cas-processing-caa-records" format="default"/>.</t>
<t>In these cases, the "accounturi" and "validationmethods" parameters s
<t>In these cases, the “accounturi” and “validationmethods” parameters still till
provide an effective means of administrative control over issuance, except provide an effective means of administrative control over issuance, except
where control over DNS is subdelegated (see below).</t> where control over DNS is subdelegated (see below).</t>
</section>
</section> <section anchor="restrictions-supersedable-by-dns-delegation" numbered="tr
<section anchor="restrictions-supercedable-by-dns-delegation" title="Restriction ue" toc="default">
s Supercedable by DNS Delegation"> <name>Restrictions Supersedable by DNS Delegation</name>
<t>CAA records are located during validation by walking up the DNS hiera
<t>CAA records are located during validation by walking up the DNS hierarchy unt rchy until
il
one or more records are found. CAA records are therefore not an effective way one or more records are found. CAA records are therefore not an effective way
of restricting or controlling issuance for subdomains of a domain, where of restricting or controlling issuance for subdomains of a domain, where
control over those subdomains is delegated to another party (such as via DNS control over those subdomains is delegated to another party (such as via DNS
delegation or by providing limited access to manage subdomain DNS records).</t> delegation or by providing limited access to manage subdomain DNS records).</t>
</section>
</section> <section anchor="misconfiguration-hazards" numbered="true" toc="default">
<section anchor="misconfiguration-hazards" title="Misconfiguration Hazards"> <name>Misconfiguration Hazards</name>
<t>Because the "accounturi" and "validationmethods" parameters express r
<t>Because the “accounturi” and “validationmethods” parameters express restricti estrictive
ve
security policies, misconfiguration of said parameters may result in legitimate security policies, misconfiguration of said parameters may result in legitimate
issuance requests being refused.</t> issuance requests being refused.</t>
</section>
</section> <section anchor="revelation-of-account-uris" numbered="true" toc="default"
<section anchor="revelation-of-account-uris" title="Revelation of Account URIs"> >
<name>Revelation of Account URIs</name>
<t>Because CAA records are publically accessible, use of the “accounturi” <t>Because CAA records are publicly accessible, the use of the "accountu
ri"
parameter enables third parties to observe the authorized account URIs for a parameter enables third parties to observe the authorized account URIs for a
domain. This may allow third parties to identify a correlation between domains domain. This may allow third parties to identify a correlation between domains
if those domains use the same account URIs.</t> if those domains use the same account URIs.</t>
<t>CAs are encouraged to select and process account URIs under the assum
<t>CAs are encouraged to select and process account URIs under the assumption th ption that
at
untrusted third parties may learn of them.</t> untrusted third parties may learn of them.</t>
</section>
</section> </section>
</section> <section anchor="iana-considerations" numbered="true" toc="default">
<section anchor="iana-considerations" title="IANA Considerations"> <name>IANA Considerations</name>
<t>This document has no IANA actions. As per <xref target="RFC8659" format
<t>None. As per the CAA specification, the parameter namespace for the CAA “issu ="default"/>, the parameter namespace for the CAA "issue"
e” and "issuewild" Properties has CA-defined semantics, and the identifiers within
and “issuewild” properties has CA-defined semantics and the identifiers within
that namespace may be freely and arbitrarily assigned by a CA. This document that namespace may be freely and arbitrarily assigned by a CA. This document
merely specifies recommended semantics for parameters of the names “accounturi” merely specifies recommended semantics for parameters of the names "accounturi"
and “validationmethods”, which CAs may choose to adopt.</t> and "validationmethods", which CAs may choose to adopt.</t>
</section>
</section>
</middle> </middle>
<back> <back>
<references>
<name>Normative References</name>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3986.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5234.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.
xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8555.
xml"/>
<references title='Normative References'> <!-- draft-ietf-lamps-rfc6844bis (was RFC 8644; now RFC 8659) -->
<reference anchor="RFC8659" target="https://www.rfc-editor.org/info/rfc865
<reference anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> 9">
<front> <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title> <title>DNS Certification Authority Authorization (CAA) Resource Record
<author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></ </title>
author> <seriesInfo name="DOI" value="10.17487/RFC8659"/>
<date year='1997' month='March' /> <seriesInfo name="RFC" value="8659"/>
<abstract><t>In many standards track documents several words are used to signify <author initials="P" surname="Hallam-Baker" fullname="Phillip Hallam-B
the requirements in the specification. These words are often capitalized. This aker">
document defines these words as they should be interpreted in IETF documents. <organization/>
This document specifies an Internet Best Current Practices for the Internet Comm </author>
unity, and requests discussion and suggestions for improvements.</t></abstract> <author initials="R" surname="Stradling" fullname="Rob Stradling">
</front> <organization/>
<seriesInfo name='BCP' value='14'/> </author>
<seriesInfo name='RFC' value='2119'/> <author initials="J" surname="Hoffman-Andrews" fullname="Jacob Hoffman
<seriesInfo name='DOI' value='10.17487/RFC2119'/> -Andrews">
</reference> <organization/>
</author>
<reference anchor="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'> <date month="November" year="2019"/>
<front> </front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title> </reference>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organizat
ion /></author>
<author initials='R.' surname='Fielding' fullname='R. Fielding'><organization />
</author>
<author initials='L.' surname='Masinter' fullname='L. Masinter'><organization />
</author>
<date year='2005' month='January' />
<abstract><t>A Uniform Resource Identifier (URI) is a compact sequence of charac
ters that identifies an abstract or physical resource. This specification defin
es the generic URI syntax and a process for resolving URI references that might
be in relative form, along with guidelines and security considerations for the u
se of URIs on the Internet. The URI syntax defines a grammar that is a superset
of all valid URIs, allowing an implementation to parse the common components of
a URI reference without knowing the scheme-specific requirements of every possi
ble identifier. This specification does not define a generative grammar for URI
s; that task is performed by the individual specifications of each URI scheme.
[STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='66'/>
<seriesInfo name='RFC' value='3986'/>
<seriesInfo name='DOI' value='10.17487/RFC3986'/>
</reference>
<reference anchor="RFC5234" target='https://www.rfc-editor.org/info/rfc5234'>
<front>
<title>Augmented BNF for Syntax Specifications: ABNF</title>
<author initials='D.' surname='Crocker' fullname='D. Crocker' role='editor'><org
anization /></author>
<author initials='P.' surname='Overell' fullname='P. Overell'><organization /></
author>
<date year='2008' month='January' />
<abstract><t>Internet technical specifications often need to define a formal syn
tax. Over the years, a modified version of Backus-Naur Form (BNF), called Augme
nted BNF (ABNF), has been popular among many Internet specifications. The curre
nt specification documents ABNF. It balances compactness and simplicity with rea
sonable representational power. The differences between standard BNF and ABNF i
nvolve naming rules, repetition, alternatives, order-independence, and value ran
ges. This specification also supplies additional rule definitions and encoding
for a core lexical analyzer of the type common to several Internet specification
s. [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='STD' value='68'/>
<seriesInfo name='RFC' value='5234'/>
<seriesInfo name='DOI' value='10.17487/RFC5234'/>
</reference>
<reference anchor="I-D.ietf-lamps-rfc6844bis">
<front>
<title>DNS Certification Authority Authorization (CAA) Resource Record</title>
<author initials='P' surname='Hallam-Baker' fullname='Phillip Hallam-Baker'>
<organization />
</author>
<author initials='R' surname='Stradling' fullname='Rob Stradling'>
<organization />
</author>
<author initials='J' surname='Hoffman-Andrews' fullname='Jacob Hoffman-Andrews'>
<organization />
</author>
<date month='May' day='30' year='2019' />
<abstract><t>The Certification Authority Authorization (CAA) DNS Resource Record
allows a DNS domain name holder to specify one or more Certification Authoritie
s (CAs) authorized to issue certificates for that domain name. CAA Resource Rec
ords allow a public Certification Authority to implement additional controls to
reduce the risk of unintended certificate mis-issue. This document defines the
syntax of the CAA record and rules for processing CAA records by certificate iss
uers. This document obsoletes RFC 6844.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-lamps-rfc6844bis-07' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-lamps-rfc6844bis-
07.txt' />
</reference>
<reference anchor="RFC8174" target='https://www.rfc-editor.org/info/rfc8174'>
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
<author initials='B.' surname='Leiba' fullname='B. Leiba'><organization /></auth
or>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol s
pecifications. This document aims to reduce the ambiguity by clarifying that on
ly UPPERCASE usage of the key words have the defined special meanings.</t></abs
tract>
</front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='8174'/>
<seriesInfo name='DOI' value='10.17487/RFC8174'/>
</reference>
<reference anchor="RFC8555" target='https://www.rfc-editor.org/info/rfc8555'>
<front>
<title>Automatic Certificate Management Environment (ACME)</title>
<author initials='R.' surname='Barnes' fullname='R. Barnes'><organization /></au
thor>
<author initials='J.' surname='Hoffman-Andrews' fullname='J. Hoffman-Andrews'><o
rganization /></author>
<author initials='D.' surname='McCarney' fullname='D. McCarney'><organization />
</author>
<author initials='J.' surname='Kasten' fullname='J. Kasten'><organization /></au
thor>
<date year='2019' month='March' />
<abstract><t>Public Key Infrastructure using X.509 (PKIX) certificates are used
for a number of purposes, the most significant of which is the authentication of
domain names. Thus, certification authorities (CAs) in the Web PKI are trusted
to verify that an applicant for a certificate legitimately represents the domai
n name(s) in the certificate. As of this writing, this verification is done thr
ough a collection of ad hoc mechanisms. This document describes a protocol that
a CA and an applicant can use to automate the process of verification and certi
ficate issuance. The protocol also provides facilities for other certificate ma
nagement functions, such as certificate revocation.</t></abstract>
</front>
<seriesInfo name='RFC' value='8555'/>
<seriesInfo name='DOI' value='10.17487/RFC8555'/>
</reference>
</references> </references>
<section anchor="examples" numbered="true" toc="default">
<section anchor="examples" title="Examples"> <name>Examples</name>
<t>The following shows an example DNS zone file fragment that nominates tw
<t>The following shows an example DNS zone file fragment which nominates two o
account URIs as authorized to issue certificates for the domain “example.com”. account URIs as authorized to issue certificates for the domain "example.com".
Issuance is restricted to the CA “example.net”.</t> Issuance is restricted to the CA "example.net".</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
example.com. IN CAA 0 issue "example.net; \ example.com. IN CAA 0 issue "example.net; \
accounturi=https://example.net/account/1234" accounturi=https://example.net/account/1234"
example.com. IN CAA 0 issue "example.net; \ example.com. IN CAA 0 issue "example.net; \
accounturi=https://example.net/account/2345" accounturi=https://example.net/account/2345" ]]></artwork>
]]></artwork></figure> <t>The following shows a zone file fragment that restricts the ACME method
s that
<t>The following shows a zone file fragment which restricts the ACME methods whi can be used; only ACME methods "dns-01" and "xyz-01" can be used.</t>
ch <artwork name="" type="" align="left" alt=""><![CDATA[
can be used; only ACME methods “dns-01” and “xyz-01” can be used.</t>
<figure><artwork><![CDATA[
example.com. IN CAA 0 issue "example.net; \ example.com. IN CAA 0 issue "example.net; \
validationmethods=dns-01,xyz-01" validationmethods=dns-01,xyz-01" ]]></artwork>
]]></artwork></figure> <t>The following shows an equivalent way of expressing the same restrictio
n:</t>
<t>The following shows an equivalent way of expressing the same restriction:</t> <artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
example.com. IN CAA 0 issue "example.net; validationmethods=dns-01" example.com. IN CAA 0 issue "example.net; validationmethods=dns-01"
example.com. IN CAA 0 issue "example.net; validationmethods=xyz-01" example.com. IN CAA 0 issue "example.net; validationmethods=xyz-01" ]]></artwork
]]></artwork></figure> >
<t>The following shows a zone file fragment in which one account can be us
<t>The following shows a zone file fragment in which one account can be used to ed to
issue with the “dns-01” method and one account can be used to issue with the issue with the "dns-01" method and one account can be used to issue with the
“http-01” method.</t> "http-01" method.</t>
<artwork name="" type="" align="left" alt=""><![CDATA[
<figure><artwork><![CDATA[
example.com. IN CAA 0 issue "example.net; \ example.com. IN CAA 0 issue "example.net; \
accounturi=https://example.net/account/1234; \ accounturi=https://example.net/account/1234; \
validationmethods=dns-01" validationmethods=dns-01"
example.com. IN CAA 0 issue "example.net; \ example.com. IN CAA 0 issue "example.net; \
accounturi=https://example.net/account/2345; \ accounturi=https://example.net/account/2345; \
validationmethods=http-01" validationmethods=http-01" ]]></artwork>
]]></artwork></figure> <t>The following shows a zone file fragment in which only ACME method "dns
-01" or
<t>The following shows a zone file fragment in which only ACME method “dns-01” o a CA-specific method "ca-foo" can be used.</t>
r <artwork name="" type="" align="left" alt=""><![CDATA[
a CA-specific method “ca-foo” can be used.</t>
<figure><artwork><![CDATA[
example.com. IN CAA 0 issue "example.net; \ example.com. IN CAA 0 issue "example.net; \
validationmethods=dns-01,ca-foo" validationmethods=dns-01,ca-foo" ]]></artwork>
]]></artwork></figure> </section>
</section>
</back> </back>
<!-- ##markdown-source:
H4sIAIkNDF0AA71bW48bN5Z+568g9LLxQFJsx84kHQRYpe3EDdiO123vYDA7
WFBVlMR1qUohq7qtBP7ve268lC7dTgYZDwZRSyzy8Fy/c6nZbKZ61zf2Ql8u
FvqtrTpf6+cfe9sG17VBrzqvF1XVDW2v37+90qat9eLy1XP9yvabrtY/uLZ2
7VqZ5dLbmwv6bQZbqbqrWrOFfWtvVv3M2X41M9XWzipjZo8eqtr08OPjh4++
nT38evb4oargi3Xn9xc69LVSbucvdO+H0D9++PDbh4+V8dZc6J9sa71p1G3n
P6x9N+z4SP03+Bvo0D/hd+qD3cOC+kJftb31re1nz5AKpUIPF/hf03QtHL63
Qe3chf5H31VTHTrfe7sK8Gm/xQ//VMoMcEl/obSewf+1dm240C/m+iXsYgb6
ii/5Ylh35bd2a1xzoTcNffWftb2B//k5UKJU2/mt6d2NxX3f/nj5+NGjb+Xj
V99+87V8fPr4qyf48Wr2bE7Ma8x2F2Z+VX39zZMnSxdk3TeP/vokfnz69OmF
UrPZTJtl6L2p4LR3G6svre/dygGHQaZ6QZdy/T5++pW//wLE9kA/e32tPauB
aZruNmij6w6u0+q+U1W33Q4t7mS1C2EwbWX1rmtctYefzxzkbMDNw4OpXg69
7tpmL3urYm9d25Vr0263rt+ATs4aYFyj1960Q2OQ6rl+0d0iN6e6x7uBroWd
rfKxpgmd3vnuxtVw8MpUrmEaUJdtVG080dRb1+tt5206YKrgzLif0DLX7zYu
6PEpTG3Q/W2nw1Bt9M54UAVQN9AgUC9FN0SVTLsZtqOguxUw9XKBJCyBj7Vt
kWu21st9MjLYQsct0gX1lqyOdhDGVV3b+67RN6ZxtTAgCHW0ITKJTARYAore
NYqP9faXwXlbz1ljtq6uG6vUFW5XDxXupL4v/qEq3cmFzADiNJ47QR2xE7oQ
f751TT1RQMoOVcXSTfo/pKKhG3xllejqb7+dNZRPn1CAVq+cD/1UT0QMg3eT
adLD0THA05X1nvlnyDNmHSfWgXW5qocF8MWRfJXId6pvNw40AzzXsZADExWA
/LYGqrL8RMaZuJ7W9ciqQspRFcKw24HrysQiTbLOHmoJmDDQ3zjQeybewPNL
2RzPWQ1NEw+LJ/AtwFLkqAAq8876rWu7plvv1UhJrsCyUE/A/w9buDNbKThk
jR456Mmr99fv4G70X/36Z/r89vl/vb96+/wZfr5+sXj5Mn1QsuL6xc/vXz7L
n/KTlz+/evX89TN+GL7VB1+9WvwdWdnWavLzm3dXP79evJyQSMT6MELsvEV+
kOGEyrsl/AFc++HyjX70BHRLvPSnT/wZfe6nT+p2Y9upGCu4NP4Tbgti2O2s
8bgFiFBXZud68EpTPCBsuttWb6y3wMUi0AI14s4kCl/orKj6TbStkUl+3j+l
FqzCcY+RCWiXvcXvMNvCwXyG6YE6DpZVzEHMjYRMtVtF87FgBKQSIBNDXpBY
jRER2C7ms0d/arLFXS6UXAWYOQHVl78moLsGmGpa3S3/z1aghWgGvYk0j/ag
e7KSb82eHCMYOJldinFAe5VclA3RtL0F1QkWnXqxJdIKvgu4SRAFHgY31RhU
MfoJGDjnyMxPV4k3hZDAZDGGO9QNWkm8JxeUDBIeMH1vqg268b+hUkV3FVdv
DHFhJPGC/+QviO2kwngmsNrD3U0/OjI6yIIlGLWBMHQtEFU5qK0B1rQlp1Ra
LmxFkbOiE8xYty5YviHKPClD3J01B70O+jxgJFOWuATXK3UDH5Grgiw/8Ffw
gBw+R1tI10KI0QEgOcsf2KIH3iIH93Hbuc47KAIp8LhryeGixIc2Xas+ty2I
bWgDuPGwcmbZWNhTjajS26Hp3a6xZ3YIx1sc69P5a9Ud3KntkC27xuBqj77d
QjytLfJQtZbDQ4ojyFiJJYh4x4LCk8RlwE6FxxAkqUSYW9O2eHzpY6PTG+GK
OXwVWC9D78CFAm3gnLaEtFQOgnP9I2E6cDuNnYruR1IyR8lcIsUFoMWbQDyE
bGBNmtKhVrI7OM+8kStqk7aBksHDP6gTgnkfLEsVYRiCrfwP9LFldMaBBRA8
eLu4J/suDRHsGCdCjO5F49UZSiWkoF1JdKeTxrsDfVfIPYzVxNOQfNEY6gmW
QXDt4gOSCqKcktYrQsOEcPLV0cyOb08MQLUdXWB8bALy4Fw49wPfXm0MHLXF
G0ZxqOhZjz156Y+y+7pxpsBhQyCbiWcrcB0Ms5F7uNfyQOdXA1BrMe0KjAFQ
Y9GmEnNQOsyfxd+VCcGtW1qYOIUicV4jHkBCAJQsHXh875r9vdjgCC7+SxDh
PFI4hqUUdFAL7kANqvQBGTWcAAP6fjBASaeZBYtLMYYi+Abewg6/Wt+hy6EU
7ggb68aAcQdy+md+zEaFCna0CJ390Zdo4gbp7l2FKaO+BfVwyUDQDVTgGJLr
jNi7u8F4Jb7nT4j/i9OxHGkdxRaS1Qm5lo5DnYj3t4QvJCgfMHNpUSIDxjwX
DjwVJsPif86JCDKS0Od4cChw/BUtAi56VpBRXSxc0bJC8g+ES2RpVFnXquQO
/ztv+EpM6WrxGtHJGo71+ykqGEo1lwXarp3Rs5kYNSKmzMAhvNwC8RmdpTRK
L7vPEkcsB4iiqxPHx1xtilpBrBCHI/wlD9KBy5F1c321UpClgGJ4h0qa9pQH
MEFCbybwNkrmLo6pzDEBeEQIelbZdAkL2hY1JSmi2PKkMrNJkS+ryD4gfGNu
7Ij9iO3hITGhwp3cx0iiB5Rr1xSmsOpilWXxw+sfOQ5j8e3TpwtFtTw+4Hv9
j798wdKdTCcP+Er/pAX87ff60V++WLx882Khv9TPrn66egf/ncwmD5S6ttVA
1YxLsUkOtOcc9ZlKC4MmgvOjKlYMDVIJGT0GyKvy1oSIjYs6GiIW5ndR30DH
hUb0EeUO1iylr+NCRIq2kNwizKHgOVQVPIUlhBR78eBzSZRakWVxzpDrgOMC
y9LuO9B/QvFM7m03NGAQaOa3GEWXVu060PYlQkBY0lgBjakClwjAA8+W4/iu
CuI3QA7JSUKUHKwZ7cLkRrBRbTo0LiDegnJ1EA76KdUDMHYtSZE5VUCrEO8d
YUI4AbZAtV/mGg0iize+Q97ibTIMCEdw6uQ/iH9NEy0k3aga6WKqwx1Cca5e
tcBsxzUmNSrvnKyNbsHVgQrYFjWjwNsxXbIfHWkGZ8V4/MbtCg7BnVeDJz+e
oiBrAPwIH10fiuoz1rkdMGeqYoSShXdyWF+1RQwnv5mgZgvxr64drjNN5phZ
gl7omBrjUopvAh2Re0NLlok/nKpLU0034J3ADIDnkF5SMsds4AwEU03SbdFI
SxZWwflUVix+JfSLMGtkVAmOjczKBfZ74AabvRpaBNBrqv0uAiVV00JKpJ8I
j7NXCbkAEBheoFKauttJEgKGM7rttCiqFEgGJSeuBjjHRZqT6cYUdIMt7GZo
EPajj4ELD20ipM46sGR6+Li6o8i16dpu8CQHuQNFcl4jPwKftnydjrJYU9+4
0HkgDlwmBMkYtIUzIOmgnr2+vn5+SQpDMPg0nZmcTEfiJXZBIq0KaU1YcbSq
YJDhVhjcmY+fxTgHzMdSeIPdJaXeit8ki75q7WoFGR7oQcrBLtl1QPpB0eGz
3EfpSH6wlRk4cymrEUDhmQJAUYyiaIGq4PqhR1w/glSwVQA9twk8jEHk+RJD
KsbUsFVN+V9ZISLsk1MuQ7EE064AcoMDKhAzNjg9tjGbfW4qFTtk2HgqMSZf
17WyLSPhogbELRi4LN3xnsuUtTs2oQjE0G1GcaqkF6PcIpnD0ILbDeRL/yM1
CJJjGFWRFGgM6KwLG4q1sMaCa0DHkDU4p/snbi/l+K35AMy9Ma4hC4jhIYKQ
mpZjxSS6GwAmzYA8R7ABDgHbC7BcHLYJOc8p6EVkmPodc/1MgjD2a9x68DE6
RgtaCXLXsdeAqBjoYh+OUvGlweA9XW6ajYoSVAq/C1wycdniBDCbZcrv0j0j
O7hVR+WSle+2MXAJ74WxnGoLOxFTxPRmX8iFnUKZD+DV4VvVdN2HYYfxumXg
UqzZDR6Ak+W+BInWEPnH0OeoyHQ/O+AWr7D53aM7JdwL7qutKFP+Y15IFRku
oN8hhnqMKYc6/jnEqnE5lWFrFSnt9Ql0SqXPIs8vKtgGkGNRGQSibLOi4uio
KHnGeWE+xltuYKNU/U0WHfZA0zboL1ajeifXDmcQrcpoyIvZe+Rk8eQiConY
vK0diN5Tpnd4JtgI0gNwjbTUAI9AbzAzR6C3tv5BzjpLuWDr68RmsUxIOob8
HOnMokDIWEmN8bTuWEOxFsrovvRKI6eGxVGwNCqPqhhMWkyU8J5ZkBkqRUNA
VRcPLGD7sMCMbnwif84BUU0Spr1PECnD5kXqcFFFWU0OVIRKJjgxMx+dF2nG
cjjXBtTk5IKGwOU0Rry2YNhd1qI+w9PhcydIQ5LvEKHoRmFhmc8pfy/ttvPq
MwiJJgqHllZqUqCi88nrLNTdZogIJYWKs+wC3S1UVv8IMW/wUUnBWd+KJNFq
pDviRhV2uexon4QHpTMjCUaO+ckfY1X97ZVeQF65HjAtOHCS10htyGnQyEtN
zFhkB+0z9lpT6mRQcVHhdICrnfF7Ng69SJ3PtCmVsY52RjVaHp52wkfOD0im
3VIfRijBLMfkMbSUrqIVYJVmMvj2Qs66kIUzV188evzVk4lSV6nnWKpIcs5S
OcnYhmcBDq9EVkSpDhvr0kpqM/D6UWdIiG2H7RLMFOnQUR6otNwtogQP9EAa
DNkJx9rEVGP5hpFTFDjVvYYwzT2y0utKxycwRCiAb8AmGnbAY6KZmx2pI7RK
WoOwc2jdLwPnDoJmQgV2QvkIOOCRK2WlwDPV6Mxxc5b3PnC70euKFIru3ggI
cU9tz2FAhpfIPCkFx/3p2uJ4CF1ayuniLJH6Ilirry2hPf3V/DEeXAwZPKB6
32TT97tw8eWXI+F/KSz6UhRqPJb0Ixj7pgVPdg7KyBjeUW1ljbhdCvym6kdV
JpnmoUJF6LZYB2CshlMPqDAJuevx9BI5xdyYpPTnjj4YLFfF7IJINRbfm30s
MR7SJ9arrxG/jigg6roK3BUNF/WYZhkEVzvvOs+6d5KU2KXXkVtcKlCpHMlM
ERLxFKoNSzEjQm5Mjnq3tYXt4NfehQ+kgoqrcE7gyUH5hJyCNKpBi3KwSgVj
KYk3e7UbYuaUiT1A71ghySUqFkY9VDaTxIXTja6cB5CP3KqwU/ZGSpqKpGgh
2Bs08pBUG2knv1CyPjCZoFX7NOVFBoX6D/bvqEdA5/FgyKYbPIFAb4uSQj/i
v4RZYTsw8KTwkOVls5vqP1J24PzkLqAvfWA5I/uAid52NXdxiswFG0QEkKjj
hOSdHDmpQIwQSym3p7YqzUBiS92sMXHsseADwRd+IxfWUf0bB/IGWLNuuqVp
QJnbmWtnwJIZz0hyy+1DyJuUzUBp74Gbv+d5iq9t/EMqZTRL0uMgBqhN7yEf
A5PsqcfJ4FuV+cgUm1TG15TtS0QEVVgDBzsaswBhFojDpC2j1bYqMmB/cDY6
+ILhkRSHKZsphw0ZXg5BycxbbNikysTqqBpZdMNyeRK7VbAte/JYYyO/M2Dc
7TFz5jI8pHs4AQqUGelXYHcdbKOeCmxKwabAhligoEZGGh9tBrYYrHSm+pq6
o76mE3zAY7kMhi3bojMb9Yudo5K0HheiK9IY7mIFqOR8aqHInAuPud2nQFH/
6KqJtVco/JrHP2T4mQd4nASPUQmAEbjewuVj65TqWXBlLmsp1654YB3VaCkj
dMizKCRsS3JHjlPopeOMQwrVaBtRO9VYpdpgOBiz1OEQ8FCmOXXMPIfQUWFu
NEl0VJySdhZ5iZyBUBAg93FinHZrbXSBIOAKux4eFcTzNkd9A6NSxKxQBwua
YxBgvhK6eDTX76V8en5op4RzPCwfO1Wx8U9tx2hi3KwtyuLoL4iDByOLEOjh
wcdz/fwjhJAAlsEe9BQbIsgvVUEXqsAUnNQH9AixRnzfnIHclXfLF6YAFUlJ
rJfUUtKxGKcOUsb7clcCzGJmCtWpuDyrYfIF07uL7ZN3vGySlC+OQnJ5NsFx
oJk7/biewV7cJtaJMI1nVhTP5ZctyE/tDOyxtP2tte14E0nxpZSgCidycEFk
Jesp6DGNjxTD0tFlArlJAyHXSfDa3MEO7Qdu7HeSKGB+tTXVxnHL63OoE/Bw
uhJwn1hT4syz+6f7dzFex6iL/cXTvvd+p3sQILHYst312NOrBbvH0KNSLaSw
UepYLXimJnqGFF7SZVhWFPIozbIeY8ZBkExm/U7yq1xEkKnJu9X8WKxsjoWq
v+q87eiVm+FflpACVOrWGJIiK+9HWEfNvdgwU0W5v2jvySqux9x73XRTbDqW
eCpX2zFNpY7n2NOKFOFcOO47EJdVv/0muHvWdzNI2Wa5yEWvvgmxnz7N5V0J
CjOc2v2RrgMVQ1UsF5VdoqJ7WINW42gOvXZ2umk01fYjIj9poo/WIGLC2Dos
AYrbNeE/SqZpuOkB3GTcebyWWWKyLOARPv+Mn/ydXUelRj1oIKzpKjq/5nZP
odZw0K1paOZ72BEv8dyNs974agNeDEBko4pBqtG+K2B6PdeHx6H8qSt21ITD
sT9syacWEno/HxnXHM+dAPekX0UN3Qjhid9qxG/Wt+IBekcjcp6GBDK22oMo
JJ+TKKzqxGukaLkvYHFMCg2N6uBeYH1mXZxWvAEYSLSvXIgNNt7zhfnV3DV8
Mm4T/16FlmQ/8/XGquTCKSF1aCvbQ6owjzauLrfiGeBYhwWegOfZnnopIaS2
7UqQBij0jQyn4M7FK7B3Dd3kmx/qEZUKKqqCMOt5XOmMO82F4TREA7HY14w8
uY7QLSkcpBxJXNKoSkqJu4opKU3qIE9oMOp4x1ir4xZPnM1JkEOUUdELHKig
UTujpCnol+dLLQTvb1v42pu1vDIHCopZOGhDzEBGdIMpygwnNWx3nDAgbIcl
4sbH5OO1Gsg/Y3F9izKkOc77Z+6Ueg1eAeIvlUhPj0FNx12mPK+QqplFl08d
vDhV9hfwhZzLxSyOFKQphATi0tyDD1J65Xde8olSLV55i7ichwTS5LgMfuYM
XeQeW8hKhrPy6xCoptstTy1lcvBa4wkPJI6LvZ/TL5qm4UIWTh6Ro5oYigcM
Ri8hzuOsO1Vas3Q420ujmfTWnEw+0kpyUr9STxvn/VagWdIfxzPbbouFD34v
VY00y4SDTOmOCSrxh6P22lxdpQJo9lG8lWD9tL61Pazn98HzFoC8X5OyPJSz
y/Xf6f9h8FW8/Pd9rEgX6w7q0X/qEXDC08kZgZyXQWQNY3/qQI9yS1Xk5t9x
1jdaNKnbMHv4SELGx/2v9Efx0B/m7JGufs9HTeWQ87r3y+DgYbqj2ctIh5cG
ZnKAxUjJxe8l8Rxpv1fCx/vcfbdTYkyTgDS1KDY0LqgoPju/VRBlJsPw6T32
k0/r8dOKOi/F4/8O07lfK/4NxnUXEZEnf0xwY6PK8qGWz3iknhdUZrbquj/Z
zuQQpf4fVCQYd35EAAA=
</rfc> </rfc>
 End of changes. 63 change blocks. 
631 lines changed or deleted 367 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/