<?xml version="1.0" encoding="utf-8"?>
<!-- name="GENERATOR" content="github.com/mmarkdown/mmark Mmark Markdown Processor - mmark.nl" -->
<!DOCTYPE rfc SYSTEM 'rfc2629.dtd' []>
<rfc ipr="trust200902" submissionType="IETF" category="std" xml:lang="en" consensus="yes" updates="6844" docName="draft-wicinski-lamps-caa-00">
<?rfc toc="yes"?><?rfc symrefs="yes"?><?rfc sortrefs="yes"?><?rfc compact="yes"?><?rfc subcompact="no"?><?rfc comments="no"?>
<front>
<title abbrev="wicinski-lamps-caa">Alternative DNS Certification Authority Authorization (CAA) Resource Record</title><author initials="T." surname="Wicinski" fullname="Tim Wicinski"><organization>Salesforce</organization><address><postal><street></street>
<country>US</country>
</postal><email>tjw.ietf@gmail.com</email>
</address></author>
<date year="2019" month="March" day="24"></date>
<area>Internet</area><workgroup>LAMPS Working Group</workgroup>
<abstract><t><xref target="RFC6844"></xref> defines the Certification Authority Authorization
(CAA) DNS Resource Record type to specify one or more Certification
Authorities (CAs) authorized to issue certificates for that domain
name.  With large domains covering multiple web properties,
defining all possible certificate authorities for the domain has
security implications.  It would be beneficial to define a CAA for
individual host names.
This will allow CAA records that can be managed with fine grain control.</t>
<t>This document provides an alternative CAA record using a _caa prefix
label that will take precedent on a per Fully Qualified Domain Name (FQDN),
if it exists.  It will override any CAA record at the zone apex. This
will not change current CAA record behavior, but will be an additional
option.</t>
</abstract>

</front>

<middle>

<section anchor="introduction" title="Introduction">
<t>In <xref target="RFC6844"></xref> the Certification Authority Authorization (CAA)
DNS Resource Record is defined to allow a DNS domain name holder
to specify the Certification Authorities (CAs) authorized to
issue certificates for that domain name.</t>

<section anchor="definitions" title="Definitions">
<t>The key words &quot;MUST&quot;, &quot;MUST NOT&quot;, &quot;REQUIRED&quot;,
&quot;SHALL&quot;, &quot;SHALL NOT&quot;, &quot;SHOULD&quot;, &quot;SHOULD NOT&quot;,
&quot;RECOMMENDED&quot;, &quot;NOT RECOMMENDED&quot;, &quot;MAY&quot;, and
&quot;OPTIONAL&quot; in this document are to be interpreted as described in
BCP 14 <xref target="RFC2119"></xref> <xref target="RFC8174"></xref> when, and only when, they appear in all
capitals, as shown here.</t>
</section>
</section>

<section anchor="the-caa-prefix-label" title="The _caa prefix label">
<t>[_caa.www.example.com CAA 0 issue &quot;ca.example.net&quot;</t>
<t>_caa.www.example.com CNAME _caa.cdn.example.net</t>
<t>_]</t>
</section>

<section anchor="iana-considerations" title="IANA Considerations">
<t>IANA is requested to add an entry in the &quot;Underscored and
Globally Scoped DNS Node Names&quot; Registry with the fields
&quot;RR Type&quot; = &quot;CAA&quot; and &quot;Node Name&quot; = &quot;_caa&quot;,</t>
</section>

</middle>

<back>
<references title="Normative References">
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6844.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"?>
</references>

</back>

</rfc>
