<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.12 --> version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?> "rfc2629-xhtml.ent">

<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" category="std"> obsoletes="" updates=""
     xml:lang="en" tocInclude="true" symRefs="true"
     sortRefs="true" version="3">
  <!-- xml2rfc v2v3 conversion 2.28.0 -->
  <front>
    <title abbrev="ACME-CAA">CAA abbrev="ACME-CAA">Certification Authority Authorization (CAA)
 Record Extensions for Account URI and ACME Automatic Certificate Management
 Environment (ACME) Method Binding</title>
    <seriesInfo name="RFC" value="8657"/>
    <author initials="H." surname="Landau" fullname="Hugo Landau">
      <organization></organization>
      <organization/>
      <address>
        <email>hlandau@devever.net</email>
      </address>
    </author>
    <date year="2019" month="June" day="20"/>

    <area>General</area>
    <workgroup>ACME Working Group</workgroup>
    <keyword>Internet-Draft</keyword> month="November"/>
    <abstract>
      <t>The Certification Authority Authorization (CAA) DNS record allows a domain to
communicate an issuance policy to Certification Authorities (CAs), (CAs) but only allows
a domain to define a policy with CA-level granularity. However, the CAA
specification (RFC 8659) also provides facilities for an extension to admit a
more granular, CA-specific policy. This specification defines two such parameters,
parameters: one allowing specific accounts of a CA to be identified by URI URIs
and one allowing specific methods of domain control validation as defined by
the ACME Automatic Certificate Management Environment (ACME) protocol to be
required.</t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>This specification defines two parameters for the “issue” "issue" and “issuewild”
properties "issuewild"
Properties of the Certification Authority Authorization (CAA) DNS resource
record <xref target="I-D.ietf-lamps-rfc6844bis"/>. target="RFC8659" format="default"/>. The first, “accounturi”, "accounturi", allows
authorization conferred by a CAA policy to be restricted to specific accounts
of a CA, Certification Authority (CA), which are identified by URIs. The second, “validationmethods”, "validationmethods", allows
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 that it supports.</t>
    </section>
    <section anchor="terminology" title="Terminology">

<t>In this document, the numbered="true" toc="default">
      <name>Terminology</name>
      <t>The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>",
"<bcp14>SHALL&nbsp;NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD&nbsp;NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>",
"<bcp14>NOT&nbsp;RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and
“OPTIONAL” "<bcp14>OPTIONAL</bcp14>" in this document
are to be interpreted as described in BCP 14 BCP&nbsp;14
<xref target="RFC2119"/> target="RFC2119" format="default"/> <xref target="RFC8174"/> target="RFC8174" format="default"/> when,
and only when, they appear in all capitals, as shown here.</t>
    </section>
    <section anchor="extensions-to-the-caa-record-accounturi-parameter" title="Extensions numbered="true" toc="default">
      <name>Extensions to the CAA Record: accounturi Parameter">

<t>A The "accounturi" Parameter</name>
      <t>This document defines the "accounturi" CAA parameter “accounturi” is defined for the “issue” "issue" and “issuewild”
properties
"issuewild" Properties defined by <xref target="I-D.ietf-lamps-rfc6844bis"/>. target="RFC8659" format="default"/>. The value of this
parameter, if specified, MUST <bcp14>MUST</bcp14> be a URI <xref target="RFC3986"/> target="RFC3986" format="default"/> identifying a
specific CA account.</t>

<t>“CA account”
      <t>"CA account" means an object, object that is maintained by a specific CA and which CA, that may request
the issuance of certificates, which and that represents a specific entity or group of
related entities.</t>
      <t>The presence of this parameter constrains the property Property to which it is attached.
Where a CAA property Property has an “accounturi” "accounturi" parameter, a CA MUST <bcp14>MUST</bcp14> only consider
that property Property to authorize issuance in the context of a given certificate
issuance request if the CA recognises recognizes the URI specified in the value portion of
that parameter as identifying the account making that request.</t>
      <t>A property Property without an “accounturi” "accounturi" parameter matches any account. A property Property
with an invalid or unrecognised “accounturi” unrecognized "accounturi" parameter is unsatisfiable. A
property
Property with multiple “accounturi” "accounturi" parameters is unsatisfiable.</t>
      <t>The presence of an “accounturi” "accounturi" parameter does not replace or supercede supersede the
need to validate the domain name specified in an “issue” "issue" or “issuewild” "issuewild" record
in the manner described in the CAA specification.
   specification <xref target="RFC8659" format="default"/>. CAs MUST <bcp14>MUST</bcp14> still perform such
validation. For example, a CAA “issue” property which "issue" Property that specifies a domain name
belonging to CA A and an “accounturi” "accounturi" parameter identifying an account at CA B
is unsatisfiable.</t>
      <section anchor="use-with-acme" title="Use numbered="true" toc="default">
        <name>Use with ACME"> ACME</name>
        <t>An ACME Automatic Certificate Management Environment (ACME) <xref target="RFC8555"/> target="RFC8555" format="default"/> account object MAY <bcp14>MAY</bcp14> be identified by setting the
“accounturi”
"accounturi" parameter to the URI of the ACME account object.</t>
        <t>Implementations of this specification which that also implement ACME MUST recognise <bcp14>MUST</bcp14> recognize
such URIs.</t>
      </section>
      <section anchor="use-without-acme" title="Use numbered="true" toc="default">
        <name>Use without ACME"> ACME</name>
        <t>The “accounturi” "accounturi" specification provides a general mechanism to identify
entities which that may request certificate issuance via URIs. The use of specific
kinds of URI URIs may be specified in future RFCs, and CAs not implementing ACME MAY <bcp14>MAY</bcp14>
assign and recognise recognize their own URIs arbitrarily.</t>
      </section>
    </section>
    <section anchor="extensions-to-the-caa-record-validationmethods-parameter" title="Extensions numbered="true" toc="default">
      <name>Extensions to the CAA Record: validationmethods Parameter">

<t>A The "validationmethods" Parameter</name>
      <t>This document also defines the "validationmethods" CAA parameter “validationmethods” is also defined for the “issue” "issue" and
“issuewild” properties.
"issuewild" Properties. The value of this parameter, if specified, MUST <bcp14>MUST</bcp14> be a
comma-separated string of zero or more validation method labels.</t>
      <t>A validation method label identifies a validation method. A validation method
is a particular way in which a CA can validate control over a domain.</t>
      <t>The presence of this parameter constrains the property Property to which it is attached.
A CA MUST <bcp14>MUST</bcp14> only consider a property Property with the “validationmethods” "validationmethods" parameter to
authorize issuance where the validation method being used is identified by one
of the validation method labels listed in the comma-separated list.</t>
      <t>Each validation method label MUST <bcp14>MUST</bcp14> be either the label of a method defined in
the ACME "ACME Validation Methods Methods" IANA registry, registry
<xref target="RFC8555" format="default"/> or a CA-specific CA&#8209;specific non-ACME validation
method label as defined below.</t>
      <t>Where a CA supports both the “validationmethods” "validationmethods" parameter and one or more
non-ACME validation methods, it MUST <bcp14>MUST</bcp14> assign labels to those methods. If
appropriate non-ACME labels are not present in the ACME "ACME Validation Methods Methods" IANA
registry, the CA MUST <bcp14>MUST</bcp14> use labels beginning with the string “ca-“, "ca-", which are
defined to have CA-specific meaning.</t>
      <t>The value of the “validationmethods” "validationmethods" parameter MUST <bcp14>MUST</bcp14> comply with the following
ABNF <xref target="RFC5234"/>:</t>

<figure><artwork><![CDATA[ target="RFC5234" format="default"/>:</t>

      <sourcecode name="abnf-for-validationmethods" type="abnf" ><![CDATA[
   value = [*(label ",") label]
   label = 1*(ALPHA / DIGIT / "-")
]]></artwork></figure> ]]></sourcecode>
    </section>
    <section anchor="security-considerations" title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>This specification describes an extension to the CAA record specification specification,
increasing the granularity at which a CAA policy can be expressed. This allows
the set of entities capable of successfully requesting issuance of certificates
for a given domain to be restricted beyond that which the set of entities would otherwise
be possible, while still allowing issuance for specific accounts of a CA. This
improves the security of issuance for domains which that choose to employ it, when
combined with a CA which that implements this specification.</t>
      <section anchor="limited-to-cas-processing-caa-records" title="Limited numbered="true" toc="default">
        <name>Limited to CAs Processing CAA Records"> Records</name>
        <t>All of the security considerations of the CAA specification listed in <xref target="RFC8659" format="default"/> are inherited by
this document. This specification merely enables a domain with an existing
relationship with a CA to further constrain that CA in its issuance practices,
where that CA implements this specification. In particular, it provides no
additional security above that provided by use of using the unextended CAA
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
unchanged.</t>
        <t>As such, a domain which that, via CAA records records, authorizes only CAs adopting this
specification,
specification and which that constrains its policy by means of this specification,
remains vulnerable to unauthorized issuance by CAs which that do not honour honor CAA
records,
records or which honour that honor them only on an advisory basis. Where a domain uses
DNSSEC, it also remains vulnerable to CAs which honour that honor CAA records but which that do
not validate CAA records by means of a trusted DNSSEC-validating resolver.</t>
      </section>
      <section anchor="restrictions-ineffective-without-ca-recognition" title="Restrictions numbered="true" toc="default">
        <name>Restrictions Ineffective without CA Recognition"> Recognition</name>
        <t>Because the parameters of “issue” "issue" or “issuewild” "issuewild" CAA properties Properties constitute a
CA-specific namespace, the CA identified by an “issue” "issue" or “issuewild” property "issuewild" Property
decides what parameters to recognise recognize and their semantics. Accordingly, the CAA
parameters defined in this specification rely on their being recognised recognized by the
CA named by an “issue” "issue" or “issuewild” "issuewild" CAA property, Property and are not an effective
means of control over issuance unless a CA’s CA's support for the parameters is
established beforehand.</t>
        <t>CAs which that implement this specification SHOULD <bcp14>SHOULD</bcp14> make available documentation
indicating as such, including explicit statements as to which parameters are
supported. Domains configuring CAA records for a CA MUST NOT <bcp14>MUST NOT</bcp14> assume that the
restrictions implied by the “accounturi” "accounturi" and “validationmethods” "validationmethods" parameters are
effective in the absence of explicit indication as such from that CA.</t>
        <t>CAs SHOULD <bcp14>SHOULD</bcp14> also document whether they implement DNSSEC validation for DNS
lookups done for validation purposes, as this affects the security of the
“accounturi”
"accounturi" and “validationmethods” "validationmethods" parameters.</t>
      </section>
      <section anchor="mandatory-consistency-in-ca-recognition" title="Mandatory numbered="true" toc="default">
        <name>Mandatory Consistency in CA Recognition"> Recognition</name>
        <t>A CA MUST <bcp14>MUST</bcp14> ensure that its support for the “accounturi” "accounturi" and “validationmethods” "validationmethods"
parameters is fully consistent for a given domain name which that a CA recognises recognizes as
identifying itself in a CAA “issue” "issue" or “issuewild” property. "issuewild" Property. If a CA has
multiple issuance systems (for example, an ACME-based issuance system and a
non-ACME based
non-ACME-based issuance system, or two different issuance systems resulting
from a corporate merger), it MUST <bcp14>MUST</bcp14> ensure that all issuance systems recognise recognize
the same parameters.</t>
        <t>A CA which that is unable to do this MAY <bcp14>MAY</bcp14> still implement the parameters by splitting
the CA into two domain names for the purposes of CAA processing. For example, a
CA “example.com” "example.com" with an ACME-based issuance system and a non-ACME-based
issuance system could recognise recognize only “acme.example.com” "acme.example.com" for the former and
“example.com”
"example.com" for the latter, and then implement support for the “accounturi” "accounturi"
and “validationmethods” "validationmethods" parameters for “acme.example.com” "acme.example.com" only.</t>
        <t>A CA which that is unable to ensure consistent processing of the “accounturi” "accounturi"
parameter or
“validationmethods” parameters the
"validationmethods" parameter for a given CA domain name as specifiable in CAA
“issue”
"issue" or “issuewild” properties MUST NOT "issuewild" Properties <bcp14>MUST NOT</bcp14> implement support for these
parameters. Failure to do so would result in an implementation of these
parameters which that does not provide effective security.</t>
      </section>
      <section anchor="uri-ambiguity" title="URI Ambiguity"> numbered="true" toc="default">
        <name>URI Ambiguity</name>
        <t>Suppose that CA A recognises “a.example.com” recognizes "a.example.com" as identifying itself, itself and
CA B is a subsidiary of CA A which recognises that recognizes both “a.example.com” "a.example.com" and “b.example.com” "b.example.com" as
identifying itself.</t>
        <t>Suppose that both CA A and CA B issue account URIs of the form</t>

<t>“urn:example:account-id:1234”</t> form:</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   "urn:example:account-id:1234" ]]></artwork>
        <t>If the CA domain name in a CAA record is specified as “a.example.com” "a.example.com", then this
could be construed as identifying account number 1234 at CA A CA&nbsp;A or at CA B. These
may be different accounts, creating ambiguity.</t>
        <t>Thus, CAs MUST <bcp14>MUST</bcp14> ensure that the URIs they recognise recognize as pertaining to a specific
account of that CA are unique within the scope of all domain names which that they
recognise
recognize as identifying that CA for the purpose of CAA record validation.</t>
        <t>CAs SHOULD <bcp14>SHOULD</bcp14> satisfy this requirement by using URIs which that include an authority
(see Section 3.2 of <xref target="RFC3986"/>):</t>

<t>“https://a.example.com/account/1234”</t> target="RFC3986" sectionFormat="of" section="3.2"/>):</t>
        <artwork name="" type="" align="left" alt=""><![CDATA[
   "https://a.example.com/account/1234" ]]></artwork>
      </section>
      <section anchor="authorization-freshness" title="Authorization Freshness"> numbered="true" toc="default">
        <name>Authorization Freshness</name>
        <t>The CAA specification <xref target="RFC8659" format="default"/> governs the act of issuance by a CA. In some cases, a CA
may establish authorization for an account to request certificate issuance for
a specific domain separately to from the act of issuance itself. Such authorization
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
a CA will issue certificates in a manner inconsistent with the presently
published CAA policy.</t>
        <t>CAs SHOULD <bcp14>SHOULD</bcp14> adopt practices to reduce the risk of such circumstances. Possible
countermeasures include issuing authorizations with very limited validity
periods, such as an hour, or revalidating the CAA policy for a domain at
certificate issuance time.</t>
      </section>
      <section anchor="use-with-and-without-dnssec" title="Use numbered="true" toc="default">
        <name>Use with and without DNSSEC"> DNSSEC</name>
        <t>The “domain validation” "domain validation" model of validation commonly used for certificate
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 attack is an attack which that can intercept traffic to or from a
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
appear to have control of the given domain.</t>
        <t>Where a domain is signed using DNSSEC, the authenticity of its DNS data can be
assured, providing that a given CA makes all DNS resolutions via a trusted
DNSSEC-validating resolver. A domain can use this property Property to protect itself
from the threat posed by an adversary capable of performing a global
man-in-the-middle attack against that domain.</t>
        <t>In order to facilitate this, a CA validation process must either rely solely on
information obtained via DNSSEC, DNSSEC or meaningfully bind the other parts of the
validation transaction using material obtained via DNSSEC.</t>
        <t>The CAA parameters described in this specification can be used to ensure that
only validation methods meeting these criteria are used. In particular, a
domain secured via DNSSEC SHOULD <bcp14>SHOULD</bcp14> either:</t>

<t><list style="numbers">
  <t>Use
        <ol spacing="normal" type="1">
          <li>Use the “accounturi” "accounturi" parameter to ensure that only accounts which that it
controls are authorized to obtain certificates, or</t>
  <t>Exclusively or</li>
          <li>Exclusively use validation methods which that rely solely on information
obtained via DNSSEC, DNSSEC and use the “validationmethods” "validationmethods" parameter to ensure
that only such methods are used.</t>
</list></t> used.</li>
        </ol>
        <t>A CA supporting the “accounturi” "accounturi" parameter or “validationmethods” parameters MUST the "validationmethods" parameter <bcp14>MUST</bcp14> perform
CAA validation using a trusted, DNSSEC-validating trusted DNSSEC&#8209;validating resolver.</t>

<t>“Trusted”
        <t>"Trusted" in this context means that the CA both trusts the resolver itself and
ensures that the communications path between the resolver and the system
performing CAA validation are is secure. It is RECOMMENDED <bcp14>RECOMMENDED</bcp14> that a CA ensure this
by using a DNSSEC-validating resolver running on the same machine as the system
performing CAA validation.</t>

<t>Use
        <t>The use of the “accounturi” "accounturi" parameter or “validationmethods” parameters the "validationmethods" parameter does not confer
additional security against an attacker capable of performing a
man-in-the-middle attack against all validation attempts made by a given CA
which
that is authorized by CAA where:</t>

<t><list style="numbers">
  <t>A
        <ol spacing="normal" type="1">
          <li>A domain does not secure its nameservers using DNSSEC, or</t>
  <t>That or</li>
          <li>That CA does not perform CAA validation using a trusted DNSSEC-validating
resolver.</t>
</list></t> DNSSEC&#8209;validating
resolver.</li>
        </ol>
        <t>Moreover, the use of the “accounturi” "accounturi" parameter or “validationmethods” parameters the "validationmethods" parameter does not
mitigate against man-in-the-middle attacks against CAs which that do not validate
CAA records, records or which that do not do so using a trusted DNSSEC-validating resolver,
regardless of whether or not those CAs are authorized by CAA or not; CAA; see
<xref target="limited-to-cas-processing-caa-records"/>.</t> target="limited-to-cas-processing-caa-records" format="default"/>.</t>
        <t>In these cases, the “accounturi” "accounturi" and “validationmethods” "validationmethods" parameters still
provide an effective means of administrative control over issuance, except
where control over DNS is subdelegated (see below).</t>
      </section>
      <section anchor="restrictions-supercedable-by-dns-delegation" title="Restrictions Supercedable anchor="restrictions-supersedable-by-dns-delegation" numbered="true" toc="default">
        <name>Restrictions Supersedable by DNS Delegation"> Delegation</name>
        <t>CAA records are located during validation by walking up the DNS hierarchy until
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
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>
      </section>
      <section anchor="misconfiguration-hazards" title="Misconfiguration Hazards"> numbered="true" toc="default">
        <name>Misconfiguration Hazards</name>
        <t>Because the “accounturi” "accounturi" and “validationmethods” "validationmethods" parameters express restrictive
security policies, misconfiguration of said parameters may result in legitimate
issuance requests being refused.</t>
      </section>
      <section anchor="revelation-of-account-uris" title="Revelation numbered="true" toc="default">
        <name>Revelation of Account URIs"> URIs</name>
        <t>Because CAA records are publically publicly accessible, the use of the “accounturi” "accounturi"
parameter enables third parties to observe the authorized account URIs for a
domain. This may allow third parties to identify a correlation between domains
if those domains use the same account URIs.</t>
        <t>CAs are encouraged to select and process account URIs under the assumption that
untrusted third parties may learn of them.</t>
      </section>
    </section>
    <section anchor="iana-considerations" title="IANA Considerations">

<t>None. numbered="true" toc="default">
      <name>IANA Considerations</name>
      <t>This document has no IANA actions. As per the CAA specification, <xref target="RFC8659" format="default"/>, the parameter namespace for the CAA “issue” "issue"
and “issuewild” properties "issuewild" Properties has CA-defined semantics semantics, and the identifiers within
that namespace may be freely and arbitrarily assigned by a CA. This document
merely specifies recommended semantics for parameters of the names “accounturi” "accounturi"
and “validationmethods”, "validationmethods", which CAs may choose to adopt.</t>
    </section>
  </middle>
  <back>

    <references title='Normative References'>
    <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"/>

<!-- draft-ietf-lamps-rfc6844bis (was RFC 8644; now RFC 8659) -->
      <reference  anchor="RFC2119" target='https://www.rfc-editor.org/info/rfc2119'> anchor="RFC8659" target="https://www.rfc-editor.org/info/rfc8659">
        <front>
<title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <title>DNS Certification Authority Authorization (CAA) Resource Record</title>
          <seriesInfo name="DOI" value="10.17487/RFC8659"/>
          <seriesInfo name="RFC" value="8659"/>
          <author initials="P" surname="Hallam-Baker" fullname="Phillip Hallam-Baker">
            <organization/>
          </author>
          <author initials='S.' surname='Bradner' fullname='S. Bradner'><organization /></author> initials="R" surname="Stradling" fullname="Rob Stradling">
            <organization/>
          </author>
          <author initials="J" surname="Hoffman-Andrews" fullname="Jacob Hoffman-Andrews">
            <organization/>
          </author>
          <date year='1997' month='March' />
<abstract><t>In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized. This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t></abstract> month="November" year="2019"/>
        </front>
<seriesInfo name='BCP' value='14'/>
<seriesInfo name='RFC' value='2119'/>
<seriesInfo name='DOI' value='10.17487/RFC2119'/>
</reference>

<reference  anchor="RFC3986" target='https://www.rfc-editor.org/info/rfc3986'>
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='T. Berners-Lee'><organization /></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 characters that identifies an abstract or physical resource.  This specification defines 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 use 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 possible identifier.  This specification does not define a generative grammar for URIs; 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'><organization /></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 syntax.  Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications.  The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power.  The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges.  This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications.  [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 Authorities (CAs) authorized to issue certificates for that domain name.  CAA Resource Records 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 issuers.  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 /></author>
<date year='2017' month='May' />
<abstract><t>RFC 2119 specifies common key words that may be used in protocol  specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the  defined special meanings.</t></abstract>
</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 /></author>
<author initials='J.' surname='Hoffman-Andrews' fullname='J. Hoffman-Andrews'><organization /></author>
<author initials='D.' surname='McCarney' fullname='D. McCarney'><organization /></author>
<author initials='J.' surname='Kasten' fullname='J. Kasten'><organization /></author>
<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 domain name(s) in the certificate.  As of this writing, this verification is done through 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 certificate issuance.  The protocol also provides facilities for other certificate management functions, such as certificate revocation.</t></abstract>
</front>
<seriesInfo name='RFC' value='8555'/>
<seriesInfo name='DOI' value='10.17487/RFC8555'/>
      </reference>
    </references>
    <section anchor="examples" title="Examples"> numbered="true" toc="default">
      <name>Examples</name>
      <t>The following shows an example DNS zone file fragment which that nominates two
account URIs as authorized to issue certificates for the domain “example.com”. "example.com".
Issuance is restricted to the CA “example.net”.</t>

<figure><artwork><![CDATA[ "example.net".</t>
      <artwork name="" type="" align="left" alt=""><![CDATA[
example.com. IN CAA 0 issue "example.net; \
  accounturi=https://example.net/account/1234"
example.com. IN CAA 0 issue "example.net; \
  accounturi=https://example.net/account/2345"
]]></artwork></figure> ]]></artwork>
      <t>The following shows a zone file fragment which that restricts the ACME methods which that
can be used; only ACME methods “dns-01” "dns-01" and “xyz-01” "xyz-01" can be used.</t>

<figure><artwork><![CDATA[
      <artwork name="" type="" align="left" alt=""><![CDATA[
example.com. IN CAA 0 issue "example.net; \
  validationmethods=dns-01,xyz-01"
]]></artwork></figure> ]]></artwork>
      <t>The following shows an equivalent way of expressing the same restriction:</t>

<figure><artwork><![CDATA[
      <artwork name="" type="" align="left" alt=""><![CDATA[
example.com. IN CAA 0 issue "example.net; validationmethods=dns-01"
example.com. IN CAA 0 issue "example.net; validationmethods=xyz-01"
]]></artwork></figure> ]]></artwork>
      <t>The following shows a zone file fragment in which one account can be used to
issue with the “dns-01” "dns-01" method and one account can be used to issue with the
“http-01”
"http-01" method.</t>

<figure><artwork><![CDATA[
      <artwork name="" type="" align="left" alt=""><![CDATA[
example.com. IN CAA 0 issue "example.net; \
  accounturi=https://example.net/account/1234; \
  validationmethods=dns-01"
example.com. IN CAA 0 issue "example.net; \
  accounturi=https://example.net/account/2345; \
  validationmethods=http-01"
]]></artwork></figure> ]]></artwork>
      <t>The following shows a zone file fragment in which only ACME method “dns-01” "dns-01" or
a CA-specific method “ca-foo” "ca-foo" can be used.</t>

<figure><artwork><![CDATA[
      <artwork name="" type="" align="left" alt=""><![CDATA[
example.com. IN CAA 0 issue "example.net; \
  validationmethods=dns-01,ca-foo"
]]></artwork></figure> ]]></artwork>
    </section>
  </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>