msw/draft-weidner-catalog-rr-ext
SHA256
1
1
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
8c414c502576330925f21023bbad942d386b2cc7a40c251cf64562279c2ad4e4
draft-weidner-catalog-rr-ext/draft-weidner-catalog-rr-ext-00.rfc.xml
Marc S. Weidner d556bb58c5 V1.00.128.2025.06.03 
Signed-off-by: Marc S. Weidner <msw@coresecret.dev>
2025-06-03 21:44:00 +02:00

2248 lines
101 KiB
XML
Raw Blame History

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]>
<rfc
xmlns:xi="http://www.w3.org/2001/XInclude"
category="info"
docName="draft-weidner-catalog-rr-ext-00"
ipr="trust200902"
obsoletes=""
updates=""
submissionType="IETF"
xml:lang="en"
version="3">
<front>
<title abbrev="CATALOG: CAA DNS RR CT Log URI Binding">CATALOG Authorization Transparency And Log Overlay for
Graph-based DNS
</title>
<seriesInfo name="Internet-Draft"
value="draft-weidner-catalog-rr-ext-00"/>
<author fullname="Marc Simon Weidner" initials="M. S." role="editor"
surname="Weidner">
<organization>Centurion Intelligence Consulting Agency
</organization>
<address>
<postal>
<city>Lisboa</city>
<country>Portugal</country>
</postal>
<phone>+1 (202) 992 1702</phone>
<email>rfc.editor@coresecret.eu</email>
<uri>https://coresecret.eu/</uri>
</address>
</author>
<date year="2025" month="06" day="03"/>
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<keyword>CAA</keyword>
<keyword>CATALOG</keyword>
<keyword>CT</keyword>
<keyword>CT-Log</keyword>
<keyword>Log</keyword>
<keyword>RR</keyword>
<keyword>URI-Binding</keyword>
<abstract>
<t>This document proposes an extension to the Certification Authority Authorization (CAA) DNS Resource Record (RR)
that enables the mandatory or optional binding of Certificate Transparency (CT) Log URIs directly within DNS.
By embedding CT-Log endpoints in CAA RR, Certification Authorities (CAs) gain a standardized, discoverable
mechanism for retrieving preferred and permitted CT-Log endpoint information, thereby enhancing the security
and auditability of X.509 TLS certificate issuance.
The extension defines the syntax and semantics for a new CAA property tag, <strong>"issuect"</strong>,
and introduces a parameter set consisting of <em>"desc"</em>, <em>"critical"</em>, <em>"validfrom"</em>,
<em>"validtill"</em>, <em>"cturi"</em>, <em>"logid"</em>, and <em>"pubkey"</em>.
It outlines validation and processing rules, discusses deployment considerations, privacy implications, and
interoperability with existing DNS, CA, and CT infrastructures.
Additionally, the draft proposes an MTA-STS-like hardening mechanism, called <strong>CAA-CT-STS</strong>,
for the new property to further strengthen the PKI ecosystem.
Finally, it introduces the recursive acronym
CATALOG (CATALOG Authorization Transparency And Log Overlay for Graph-based DNS)
as a mnemonic for the overall extension framework.
</t>
</abstract>
<note>
<name>Note</name>
<t>TO BE REMOVED: This document is being collaborated on in Gitea at:
<eref target="https://git.coresecret.dev/msw/draft-weidner-catalog-rr-ext.git">
https://git.coresecret.dev/msw/draft-weidner-catalog-rr-ext.git
</eref>
<xref target="URI1" format="none">[1]</xref>
The most recent working version of this document, open issues, and related resources are available there.
The author gratefully accepts pull requests.
The author's PGP key is available at:
<eref target="https://keys.openpgp.org/vks/v1/by-fingerprint/7A8341E5F1570319D80F4418A11E88519A3D8CF6">
7A83 41E5 F157 0319 D80F 4418 A11E 8851 9A3D 8CF6
</eref>
<xref target="URI2" format="none">[2]</xref>.
</t>
</note>
</front>
<middle>
<section>
<name>Introduction</name>
<section>
<name>Certification Authority Authorization</name>
<t>Certification Authority Authorization (CAA)
<xref target="RFC8659"/>
RRs empower domain owners
to specify, via DNS<xref target="RFC1035"/>, which Certificate Authorities (CAs) in a
Public Key Infrastructure
<xref target="RFC5280"/>
may or may not issue Certificates for their domains.
</t>
<t>Similarly, the
CAA RR Extensions for Account URI and Automatic Certificate Management Environment
(ACME) Method Binding
<xref target="RFC8657"/>
extend the CAA grammar to introduce additional parameters
for CAA RRs. These extensions enable or disable specified validation methods and bind a domain to
specific accounts authorized to submit Certificate Signing Requests (CSRs) and retrieve end-entity
Certificates.
</t>
<t>Additionally, the Certification Authority Authorization (CAA) processing for Email Addresses
<xref target="RFC9495"/>
extends the established CAA RR mechanism by introducing a new property,
"issuemail", to apply CAA controls to the issuance of S/MIME
<xref target="RFC8551"/>
Certificates.
</t>
</section>
<section>
<name>Certificate Transparency</name>
<t>Furthermore, Certificate Transparency (CT) Version 1
<xref target="RFC6962"/>
(still in use), and
Certificate Transparency (CT) Version 2
<xref target="RFC9162"/>
(which obsoletes RFC6962),
provide public, append-only ledgers of issued certificates, enabling domain owners and relying parties
to detect misissuance.
</t>
</section>
<section>
<name>CATALOG approach</name>
<t>Currently, there is no standardized, discoverable mechanism in DNS for a domain owner to declare, which
Certificate Transparency (CT) Logs must or may record its Certificates. As a result, CAs rely on
out-of-band configurations or hard-coded lists,
increasing operational complexity and expanding the attack surface.
</t>
<section>
<name>CAA "issuect" Property Tag</name>
<t>This extension introduces a new CAA Property Tag, <strong>"issuect"</strong>,
<xref target="caa_property"/>, with the following parameters:
<em>"critical"</em>,
<em>"desc"</em>,
<em>"validfrom"</em>,
<em>"validtill"</em>,
<em>"cturi"</em>,
<em>"logid"</em>, and
<em>"pubkey"</em>.
Domain owners can embed as many CT-Log endpoints directly in their DNS zones.
Each CAA <strong>"issuect"</strong> RR names a single URI for log submission and retrieval,
specifies the time window during which whitelisted CAs may or must submit entries, and enumerates the
authorized CT-Logs Public Keys.
Because <strong>"issuect"</strong> lives alongside existing CAA tags in a DNSSEC
<xref target="RFC9364"/>
protected zone CAs can discover, validate, and enforce CT-Log policies without additional
out-of-band trust anchors.
To enforce secure-by-default behavior, <strong>"issuect"</strong> supports explicit
whitelisting combined with default-deny semantics.
Domain owners list only approved CT-Logs; any CT-Log not so listed is implicitly excluded.
Furthermore, a special blacklist flag can be set, preventing all CT-Log operations unless explicitly
permitted.
An optional critical flag (when true) mandates that no Certificate may be issued without being logged
to the specified CT-Log endpoint.
These dual mechanisms guard against accidental use of unvetted logs, and mitigate risks from
CT-Log Operator compromise, preventing downgrade or surprise attacks.
</t>
<t>Google, for instance, maintains a publicly available
"List of Trustworthy CT-Log Operators", CT-Truststore,
including its
<eref
target="https://github.com/google/certificate-transparency-community-site/blob/master/docs/google/known-logs.md">
Known CT-Logs
</eref>
<xref target="URI3" format="none">[3]</xref>, and a
<eref target="https://www.gstatic.com/ct/log_list/v3/log_list.json">
JSON list of Logs compliant with Chrome's CT Policy
</eref>
<xref target="URI4" format="none">[4]</xref>.
Apple similarly publishes its own CT-Truststore, detailed in its
<eref target="https://support.apple.com/en-us/103214">
Certificate Transparency Policy
</eref>
<xref target="URI5" format="none">[5]</xref>, and a
<eref target="https://valid.apple.com/ct/log_list/current_log_list.json">
JSON list of Logs meeting Apple's CT requirements
</eref>
<xref target="URI6" format="none">[6]</xref>.
</t>
<t>By republishing and allowlisting selected entries from these audited CT-Log lists,
and any future community-maintained CT-Truststore, within the same DNS zone that hosts a
domain's CAA RRs, domain owners gain a single, authoritative repository for:
</t>
<ol type="(%c)">
<li>CA authorization,</li>
<li>CA authorization metadata (e.g., validation methods and ACME account bindings),</li>
<li>CA authorization for S/MIME Certificate issuance,</li>
<li>CT-Log authorization.</li>
</ol>
<t>Embedding curated CT-Log trust anchors directly in DNS consolidates trust management,
reduces external dependencies for CAs, minimizes lookup latency, preserves privacy by
limiting out-of-band queries, and surfaces misconfigurations or tampering at DNSSEC validation time.
</t>
</section>
<section>
<name>CAA Certificate Transparency Strict Transport Security (CAA-CT-STS)</name>
<t>CAA-CT-STS,<xref target="caa_ct_sts"/>, is a policy framework
that combines the mechanisms of CAA, CT, and MTA-STS
by which a domain holder can publish Certificate-Transparency enforcement
requirements alongside CA Authorization (CAA) over a second secured channel.
It mirrors the approach of SMTP MTA-STS<xref target="RFC8461"/>, using DNS TXT RR, a specific
subdomain and an HTTPS only served policy file.
A special DNS TXT record <strong>"_caa-ct-sts"</strong>
<xref target="caa_ct_sts_txt"/>
lets clients discover the existence and version of the policy, and a policy file,
retrieved from "<em>https://caa-ct-sts.&lt;domain&gt;/.well-known/caa-ct-sts.txt</em>",
contains structured rules in a canonical key:value format.
The before mentioned section defines the discovery mechanism,
DNS TXT RR and policy format (with ABNF), and procedures for fetching, validating,
and applying CAA-CT-STS policies.
</t>
</section>
<section>
<name>Operational discussions</name>
<t>Lastly, practical aspects such as a CA Processing Checklist,<xref target="caa_processing_checklist"/>,
caching behavior<xref target="dns_ttl"/>, and fallback,<xref target="dnssec_fallback"/>,
strategies for non-DNSSEC zones are addressed.
Throughout this document, the framework is referred to by the recursive acronym
<strong>CATALOG</strong>
(CATALOG Authorization Transparency And Log Overlay for Graph-based DNS).
</t>
<t>The following sections specify the complete syntax and semantics of both of the
CAA <strong>"issuect"</strong> Property Tag,<xref target="caa_property"/>, and
CAA-CT-STS framework,<xref target="caa_ct_sts"/>,
detail processing rules for CAs and resolvers for both of the
CAA <strong>"issuect"</strong> Property Tag,<xref target="issuect_processing"/>, and
CAA-CT-STS,<xref target="caa_ct_sts_processing"/>, framework.
</t>
</section>
</section>
</section>
<section anchor="requirements">
<name>Terminology</name>
<section>
<name>Keywords</name>
<t>The keywords
<strong>"MUST"</strong>, <strong>"MUST NOT"</strong>, <strong>"REQUIRED"</strong>, <strong>"SHALL"</strong>,
<strong>"SHALL NOT"</strong>, <strong>"SHOULD"</strong>, <strong>"SHOULD NOT"</strong>,
<strong>"RECOMMENDED"</strong>, <strong>"NOT RECOMMENDED"</strong>, <strong>"MAY"</strong>, and
<strong>"OPTIONAL"</strong>
in this document are to be interpreted as described in
BCP 14<xref target="RFC2119"/>,
<xref target="RFC8174"/>
when, and only when,
they appear in all capitals, as shown here.
</t>
</section>
<section>
<name>Abbreviations and Definitions</name>
<table>
<name>Abbreviations and Definitions</name>
<tbody>
<tr>
<td align="left">CA</td>
<td align="left">Certification Authority</td>
<td align="left">An Issuer that issues Certificates in accordance with a specified Certificate
Policy (CP).
</td>
</tr>
<tr>
<td align="left">CAA</td>
<td align="left">Certification Authority Authorization</td>
<td align="left">Allows a DNS domain name holder to specify one or more CAs authorized to issue
Certificates for that domain name.
See:<xref target="RFC8657"/>,<xref target="RFC8659"/>.
</td>
</tr>
<tr>
<td align="left">CAA-CT-STS</td>
<td align="left">CAA Certificate Transparency Strict Transport Security</td>
<td align="left">CAA-CT-STS is a policy framework, by which a domain holder can publish
Certificate-Transparency enforcement requirements alongside CA authorization (CAA).
See:<xref target="caa_ct_sts"/>.
</td>
</tr>
<tr>
<td align="left">CAA-CT-STS Policy</td>
<td align="left">CAA-CT-STS Policy File</td>
<td align="left">The set of rules fetched via HTTPS from the Policy Domains
"/.well-known/caa-ct-sts.txt".
See:<xref target="caa_ct_sts_policy"/>.
</td>
</tr>
<tr>
<td align="left">CATALOG</td>
<td align="left">CATALOG Authorization Transparency And Log Overlay for Graph-based DNS</td>
<td align="left">A Proposal to enrich DNS-based CAA RRs with Certificate Transparency URI
bindings.
This document:<xref target="URI1"/>.
</td>
</tr>
<tr>
<td align="left">CA-TS</td>
<td align="left">Certification Authority Truststore</td>
<td align="left">A CA-TS is the set of root certificates from Certificate Authorities that a
platform (e.g., Mozilla, Apple, Microsoft, or the Java runtime) pre-loads and implicitly trusts
when TLS Certificates are validated.
It defines, which CAs are accepted by default and is maintained through regular audits
and policy checks to remove or distrust any CA that fails to meet security or
operational requirements.
</td>
</tr>
<tr>
<td align="left">CP</td>
<td align="left">Certificate Policy</td>
<td align="left">Specifies the criteria that a CA undertakes to meet in its issue of Certificates.
See:<xref target="RFC3647"/>.
</td>
</tr>
<tr>
<td align="left">CPS</td>
<td align="left">Certification Practices Statement</td>
<td align="left">Specifies the means by which the criteria of the CP are met.
In most cases, this will be the document against which the operations of the CA are audited.
See:<xref target="RFC3647"/>.
</td>
</tr>
<tr>
<td align="left">CT</td>
<td align="left">Certification Transparency</td>
<td align="left">Certificate Transparency aims to mitigate the problem of misissued Certificates by
providing append-only logs of issued Certificates.
See:<xref target="RFC6962"/>,<xref target="RFC9162"/>.
</td>
</tr>
<tr>
<td align="left">CT-TS</td>
<td align="left">Certificate Transparency Truststore</td>
<td align="left">A Certificate Transparency Truststore is a curated whitelist of public
Certificate Transparency Logs, maintained primarily by Apple and Google,
that are accepted as valid append-only repositories for issued TLS certificates.
By requiring certificates to be submitted to one of these approved logs, the CT-TS ensures how
could be verified that a Certificate has been publicly recorded,
making misissuance or hidden Certificates easier to detect.
</td>
</tr>
<tr>
<td align="left">DANE</td>
<td align="left">DNS-Based Authentication of Named Entities</td>
<td align="left">TLSA RRs associate a Certificate or a public
key of an end-entity or a trusted issuing authority with the
corresponding Transport Layer Security (TLS)
<xref target="RFC5246"/>
or Datagram Transport Layer Security (DTLS)
<xref target="RFC6347"/>
transport endpoint. See:<xref target="RFC6698"/>,<xref target="RFC7671"/>.
</td>
</tr>
<tr>
<td align="left">DNS</td>
<td align="left">Domain Name System</td>
<td align="left">The Internet naming system specified in
<xref target="RFC1034"/>,<xref target="RFC1035"/>,<xref target="RFC9499"/>, and any
revisions to these specifications.
</td>
</tr>
<tr>
<td align="left">DNSSEC</td>
<td align="left">DNS Security Extensions</td>
<td align="left">Extensions to the DNS that provide authentication services as specified in
<xref target="RFC4033"/>,<xref target="RFC4034"/>,<xref target="RFC4035"/>,
<xref target="RFC5155"/>,
<xref target="RFC9364"/>, and any revisions to these specifications.
</td>
</tr>
<tr>
<td align="left">DT</td>
<td align="left">DNSSEC DS RR Transparency</td>
<td align="left">DNSSEC Transparency applies the Certificate Transparency model to DNSSEC by
logging every Delegation Signer (DS) RR in an append-only Merkle tree,
enabling cryptographic proofs of inclusion and consistent auditing of DNSSEC key delegations.
This ensures that any unauthorized or missing DS updates become publicly detectable,
strengthening trust in the DNS delegation chain.
(This is still in the early stages of development before a first I-D is released.)
</td>
</tr>
<tr>
<td align="left">MTA-STS</td>
<td align="left">SMTP MTA Strict Transport Security</td>
<td align="left">SMTP MTA Strict Transport Security (MTA-STS) is a mechanism enabling
mail service providers (SPs) to declare their ability to receive
Transport Layer Security (TLS) secure SMTP connections
<xref target="RFC8461"/>.
</td>
</tr>
<tr>
<td align="left">RR</td>
<td align="left">DNS Resource Record</td>
<td align="left">A particular entry in the DNS, including the owner name, class, type, time to live,
and data, as defined in
<xref target="RFC1034"/>,<xref target="RFC2181"/>.
</td>
</tr>
</tbody>
</table>
</section>
<section>
<name>CAA Syntax conformity</name>
<t>All syntax introduced in this draft is strictly in accordance with the CAA RR framework defined in
<xref target="RFC8659"/>, and
<xref target="RFC8657"/>
when and only when <strong>NOT</strong> stated
otherwise.
</t>
</section>
</section>
<section anchor="caa_property">
<name>CAA "issuect" Property Tag</name>
<section>
<name>CAA "issuect" Property Tag Definitions</name>
<section anchor="issuect">
<name>CAA "issuect" Property Tag and its Parameters Syntax</name>
<t>This document defines the CAA <strong>"issuect"</strong> Property Tag.
</t>
<t>The presence of one or more CAA <strong>"issuect"</strong> Properties in the relevant
CAA Resource Record Set (RRSet) indicates that the domain is requesting that
Certification Authorities restrict the submission of Certificates to specified
Certification Transparency Logs only.
</t>
<t>The CAA <strong>"issuect"</strong> Property Tag has the following sub-syntax (specified in ABNF as per
<xref target="RFC5234"/>).
</t>
<t>The production rules for</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li><strong>"ALPHA"</strong>,
</li>
<li><strong>"DIGIT"</strong>,
</li>
<li><strong>"DQUOTE"</strong>,
</li>
<li><strong>"SP"</strong>,
</li>
</ul>
<t>are defined in <eref target="https://rfc-editor.org/rfc/rfc5234#appendix-B.1">Appendix B.1</eref> of
<xref target="RFC5234"/>.
</t>
<t>In addition, <strong>absolute-URI</strong> is defined in
<eref target="https://www.rfc-editor.org/rfc/rfc3986.html#section-4.3">Section 4.3</eref>
of<xref target="RFC3986"/>.
</t>
<figure>
<name>CAA "issuect" Property Tag ABNF Syntax</name>
<sourcecode type="abnf" markers="false">
<![CDATA[
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SP = %x20 ; SPACE
DQUOTE = %x22 ; "
HEXDIG = DIGIT / %x41-46 / %x61-66 ; 0-9 / A-F / a-f
issuect-property = "issuect" SP DQUOTE issuect-value DQUOTE
issuect-value = issuer-domain-name ";" SP
critical-param ";" SP
desc-param ";" SP
validfrom-param ";" SP
validtill-param ";" SP
cturi-param ";" SP
logid-param ";" SP
pubkey-param ";"
issuer-domain-name = label *("." label)
label = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT) )
critical-param = "critical" "=" ( "true" / "false" )
desc-param = "desc" "=" "'" desc-text "'"
desc-text = *( %x20-26 / %x28-7E ) ; printable ASCII without: '
validfrom-param = "validfrom" "=" date-time
validtill-param = "validtill" "=" date-time
date-time = date "T" time "Z"
date = 4DIGIT "-" 2DIGIT "-" 2DIGIT
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
cturi-param = "cturi" "=" uri
uri = absolute-URI
logid-param = "logid" "=" "'" b64-string "'"
pubkey-param = "pubkey" "=" "'" b64-string "'"
b64-char = ALPHA / DIGIT / "+" / "/"
b64-string = 1*( b64-char / "=" )
]]>
</sourcecode>
</figure>
<t>The meanings of each production rule within the issuect-value grammar are as follows:</t>
<dl newline="true">
<dt>issuer-domain-name</dt>
<dd>: A Certification Authority's domain name, composed of one or more labels.</dd>
<dt>label</dt>
<dd>: A single domain label consisting only of ASCII letters, digits, or hyphens (an "LDH label").</dd>
<dt>critical-param</dt>
<dd>: The parameter name critical, followed by "=", followed by the boolean value true or false.</dd>
<dt>desc-param</dt>
<dd>: The parameter name desc, followed by "=", followed by a desc-text value enclosed in single quotes.</dd>
<dt>desc-text</dt>
<dd>: A string of printable ASCII characters (letters, digits, and symbols), excluding the single-quote character
(').
</dd>
<dt>validfrom</dt>
<dd>: The parameter name validfrom, followed by "=", followed by a date-time value.</dd>
<dt>validtill</dt>
<dd>: The parameter name validtill, followed by "=", followed by a date-time value.</dd>
<dt>date-time</dt>
<dd>: A date value, the letter "T", a time value, then the letter "Z".</dd>
<dt>date</dt>
<dd>: Four digits, a hyphen, two digits, another hyphen, and two digits (i.e., YYYY-MM-DD).</dd>
<dt>time</dt>
<dd>: Two digits, a colon, two digits, another colon, and two digits (i.e., hh:mm:ss).</dd>
<dt>cturi-param</dt>
<dd>: The parameter name cturi, followed by "=", followed by an uri.</dd>
<dt>uri</dt>
<dd>: An absolute URI as defined by<xref target="RFC3986"/>.
</dd>
<dt>logid-param</dt>
<dd>: The parameter name logid, followed by "=", followed by a b64-string enclosed in single quotes.</dd>
<dt>pubkey-param</dt>
<dd>: The parameter name pubkey, followed by "=", followed by a b64-string enclosed in single quotes.</dd>
<dt>b64-string</dt>
<dd>: One or more Base64 characters (b64-char), optionally ending with "=" padding.</dd>
<dt>b64-char</dt>
<dd>: A single character drawn from uppercase and lowercase letters (A - Z, a-z), digits (0-9), plus ("+"), slash
("/"), or hyphen ("-").
</dd>
</dl>
</section>
<section>
<name>CAA "issuect" Property Tag Canonical Presentation Format</name>
<t>
The canonical presentation format of the CAA <strong>"issuect"</strong> Property Tag is:
</t>
<figure>
<name>Canonical Presentation Format</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
issuect "<issuer-domain>; <critical>; <description>; <validfrom>; <validtill>; <uri>; <logid>; <pubkey>;"
]]>
</sourcecode>
</figure>
<ol type="(%c)">
<li>The tag <strong>"issuect"</strong>
<strong>MUST</strong> always appear in lowercase.
</li>
<li>The complete property parameter set <strong>MUST</strong> be enclosed in double quotes.
</li>
<li>A single space <strong>MUST</strong> appear after <strong>"issuect"</strong> and after each semicolon,
except for the final semicolon after the last parameter, where no space follows.
</li>
<li>All domain labels and hostnames <strong>MUST</strong> be in lowercase.
</li>
<li>The value of the "critical" flag <strong>MUST</strong> be either "true" or "false".
</li>
<li>The string following "desc=" <strong>MUST</strong> be enclosed in single quotes,
and <strong>MUST NOT</strong> contain any single quote character ("'") within the string itself.
</li>
<li>Timestamps <strong>MUST</strong> strictly follow the format "YYYY-MM-DDThh:mm:ssZ".
</li>
<li>The URI <strong>MUST</strong> remain unchanged, except that all hostnames within it
<strong>MUST</strong>
be lowercase, in accordance with DNS naming conventions.
</li>
<li>The string following "logid=" <strong>MUST</strong> be enclosed in single quotes
and <strong>MUST</strong> contain the BASE64-encoded SHA-256 hash of the CT-Log's
DER-encoded SubjectPublicKeyInfo.
</li>
<li>The string following "pubkey=" <strong>MUST</strong> be enclosed in single quotes
and <strong>MUST</strong> contain the BASE64-encoded ASN.1-format SubjectPublicKeyInfo
of the CT-Log itself.
</li>
<li>A trailing semicolon <strong>MUST</strong> follow the "pubkey" parameter.
</li>
</ol>
<t>Whereas</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Timestamps are according to<xref target="ISO-8601"/>.
</li>
<li>BASE64-encoding is according to<xref target="RFC4648"/>.
</li>
<li>SHA256-hash is according to<xref target="RFC6234"/>.
</li>
<li>DER-encoding is according to<xref target="X.690"/>.
</li>
<li>ASN.1-format is according to<xref target="X.680"/>.
</li>
</ul>
</section>
<section>
<name>CAA "issuect" Property Tag and its Parameters Definition, Meaning and Order</name>
<t>The CAA <strong>"issuect"</strong> Property Tag contains exactly eight elements,
which <strong>MUST</strong> appear in the order listed below.
Each element <strong>MUST</strong> be terminated by a semicolon (;) and a single space,
except where noted.
</t>
<ol type="(%d)">
<li>
<t>
<strong>Issuer Domain Name</strong>
</t>
<t>The authorized Certification Authority's domain name, in LDH notation (ASCII letters, digits, hyphens), as
defined in Section 3.1.
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Position: #1</li>
<li>Syntax: issuer-domain-name;</li>
</ul>
</li>
<li>
<t>
<strong>critical</strong>
</t>
<t>A boolean flag enforcing mandatory logging.</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Position: #2</li>
<li>Value: "true" or "false"</li>
<li>Syntax: critical=&lt;true|false&gt;;</li>
</ul>
</li>
<li>
<t>
<strong>desc</strong>
</t>
<t>A human-readable description of the CT-Log.</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Position: #3</li>
<li>Value: any printable ASCII string excluding the single-quote character ('), enclosed in single quotes</li>
<li>Syntax: desc='&lt;desc-text&gt;';</li>
</ul>
</li>
<li>
<t>
<strong>validfrom</strong>
</t>
<t>The start of the CT-Log acceptance window.</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Position: #4</li>
<li>Value: UTC timestamp in strict ISO 8601 format (YYYY-MM-DDThh:mm:ssZ)</li>
<li>Syntax: validfrom=&lt;YYYY-MM-DDThh:mm:ssZ&gt;;</li>
</ul>
</li>
<li>
<t>
<strong>validtill</strong>
</t>
<t>The end of the CT-Log acceptance window.</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Position: #5</li>
<li>Value: UTC timestamp in strict ISO 8601 format (YYYY-MM-DDThh:mm:ssZ)</li>
<li>Syntax: validtill=&lt;YYYY-MM-DDThh:mm:ssZ&gt;;</li>
</ul>
</li>
<li>
<t>
<strong>cturi</strong>
</t>
<t>The absolute URI for CT-Log submissions and queries.</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Position: #6</li>
<li>Value: any URI conforming to<xref target="RFC3986"/>, with hostnames in lowercase
</li>
<li>Syntax: cturi=&lt;absolute-URI&gt;;</li>
</ul>
</li>
<li>
<t>
<strong>logid</strong>
</t>
<t>The CT-Log's identifier.</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Position: #7</li>
<li>Value: Base64-encoded SHA-256 hash of the CT-Log's DER-encoded SubjectPublicKeyInfo, enclosed in single
quotes
</li>
<li>Syntax: logid='&lt;BASE64-SHA256&gt;';</li>
</ul>
</li>
<li>
<t>
<strong>key</strong>
</t>
<t>The CT-Log's public key.</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Position: #8</li>
<li>Value: Base64-encoded ASN.1-format SubjectPublicKeyInfo of the CT-Log, enclosed in single quotes</li>
<li>Syntax: key='&lt;BASE64-PUBKEY&gt;';</li>
</ul>
</li>
</ol>
</section>
<section>
<name>Special Case: Empty "issuect" Parameter</name>
<t>A CAA <strong>"issuect"</strong> RR containing only the terminating semicolon (;)
and no parameters <strong>MUST</strong> be interpreted as a prohibition on all CT-Log submissions
for the specified domain.
In other words:
</t>
<figure>
<name>Special Case: Empty "issuect" Parameter</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
issuect ";"
]]>
</sourcecode>
</figure>
<t>indicates that no CT-Logs may be used.
Because CAA authorizations are additive,
if multiple CAA <strong>"issuect"</strong> RRs exist, any non-empty
CAA <strong>"issuect"</strong> RR (with actual parameters) <strong>MUST</strong> take precedence over
an empty one.
Thus, the effective set of permitted CT-Logs is the union of all non-empty
CAA <strong>"issuect"</strong> RRs, and an empty CAA <strong>"issuect"</strong> RR
contributes no additional authorizations.
</t>
</section>
</section>
<section anchor="issuect_processing">
<name>CAA "issuect" Property Tag Processing</name>
<section anchor="minimum_logs">
<name>Pre-issuance Requirements</name>
<t>Prior to issuing a Certificate, a Certification Authority <strong>MUST</strong> obtain at least n + 1
unique CAA <strong>"issuect"</strong> RRs for each CA account,
where n is the minimum number of Signed Certificate Timestamps (SCTs)
<eref target="https://www.rfc-editor.org/rfc/rfc6962#section-3.2">Section 3.2</eref>
as per
<xref target="RFC6962"/>.
The value of n <strong>MAY</strong> vary based on the requested Certificate's validity period,
CT-Log Operator Policies, the CA's CP/CPS, and the CA/Browser Forum Baseline Requirements.
The additional "n + 1" RR provides redundancy to tolerate one CT-Log failure or unavailability.
</t>
<aside>
<t>Note: Determining the exact minimum number of unique CAA <strong>"issuect"</strong> RRs per CA is
outside the scope of this document.
Domain owners <strong>SHOULD</strong> refer to the CT-Log policies published by major operators,
(e.g.,
<eref target="https://googlechrome.github.io/CertificateTransparency/ct_policy.html">
Apple's Certificate Transparency Policy
</eref>
<xref target="URI5" format="none">[5]</xref>, and
<eref target="https://googlechrome.github.io/CertificateTransparency/ct_policy.html">
Chrome's Certificate Transparency Policy
</eref>
<xref target="URI7" format="none">[7]</xref>, and
to the CP/CPS of the issuing CA for specific requirements.
</t>
</aside>
</section>
<section>
<name>Prior to Issuing a Certificate</name>
<t>Before issuing a Certificate that certifies a domain, the Certification Authority
<strong>MUST</strong>
check for the publication of a relevant RRSet.
Discovery of the relevant RRSet <strong>MUST</strong> be performed according to the algorithm specified in
<eref target="https://www.rfc-editor.org/rfc/rfc8659#section-3">Section 3</eref>
of<xref target="RFC8659"/>.
If the relevant RRSet is empty or does not contain any <strong>"issuect"</strong> Properties,
it is interpreted that the domain owner has not requested any restrictions regarding the submission
to specific CT-Logs.
If the Certificate certifies multiple domains (for example, in the Subject Alternative Name extension),
the Certification Authority <strong>MUST</strong> perform the above procedure separately for each domain
being certified.
The presence of an <strong>"issuect"</strong> Property <strong>MUST NOT</strong> replace or supersede
the required validation of the domain name as specified by the "issue" or "issuewild" Properties in the
CAA RRSet, as outlined in the CAA specification<xref target="RFC8659"/>.
Certification Authorities <strong>MUST</strong> still validate authorization according to the CAA
"issue" and / or "issuewild" policies.
For example, if a CAA issue Property authorizes "CA A" to issue Certificates, but the
<strong>"issuect"</strong>
Property references a CT-Log belonging to "CA B",
this results in an unsatisfiable configuration.
In such cases, issuance <strong>MUST NOT</strong> proceed.
Furthermore, if the <strong>"issuect"</strong> Parameter Set is incorrectly formatted or contains
invalid values, it <strong>MUST</strong> be treated as non-existent.
</t>
</section>
<section anchor="runtime_processing">
<name>Runtime Processing</name>
<t>The internal handling of <strong>"issuect"</strong> parameters is left to each Certification Authority's
implementation and is outside the scope of this document.
</t>
<t>However, the following requirements <strong>MUST</strong> be met:
</t>
<ol type="(%d)">
<li>
<t>
<strong>ABNF Conformance</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Any CAA <strong>"issuect"</strong> RR whose parameters do not conform to the ABNF grammar
in Section 3 <strong>MUST</strong> be treated as though the
<strong>"issuect"</strong>
tag does not exist.
</li>
</ul>
</li>
<li>
<t>
<strong>Malformed RRs</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>If a RR is syntactically malformed (e.g., missing parameters, incorrect ordering,
invalid quoting), it <strong>MUST</strong> be ignored in its entirety.
</li>
</ul>
</li>
<li>
<t>
<strong>CT-Log Policy Enforcement</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>After parsing all valid CAA <strong>"issuect"</strong> RRs, the CA
<strong>MUST</strong>
verify that the resulting set of whitelisted CT-Logs satisfies its own CT-Log policy,
(as published in its CP/CPS,
CT-Log operator requirements, or other policy documents).
</li>
<li>If the CA's policy cannot be met, for example, because too few CT-Logs are whitelisted,
Certificate issuance <strong>MUST</strong> fail.
</li>
</ul>
</li>
</ol>
</section>
</section>
</section>
<section anchor="caa_ct_sts">
<name>CAA Certificate Transparency Strict Transport Security (CAA-CT-STS)</name>
<section anchor="policy_discovery">
<name>CAA-CT-STS Definitions</name>
<section anchor="caa_ct_sts_txt">
<name>DNS "_caa-ct-sts" TXT RR</name>
<t>The DNS <strong>"_caa-ct-sts"</strong> TXT RR is a DNS TXT RR named <strong>"_caa-ct-sts"</strong> at the
Policy domain.
</t>
<t>It must be encoded in US-ASCII and consists of semicolon-separated key/value pairs.
The following fields are defined:
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>v (plaintext, required): protocol version. The only valid value is "CAACTSTSv1".</li>
<li>id (plaintext, required): a version identifier string (1-32 alphanumeric chars) used to signal updates.
This must change whenever the policy file is updated.
</li>
<li>Extension fields (optional): any other key:value pairs (see ABNF below).</li>
</ul>
<t>The record must begin with the "v="-field.
The "id="-field is used by clients to detect policy updates (similar to MTA-STS).
</t>
<t>If DNS returns multiple <strong>"_caa-ct-sts"</strong> TXT RR, or if none of them starts with
"v=CAACTSTSv1", or if parsing fails, clients <strong>MUST</strong> assume no
<strong>CAA-CT-STS</strong>
policy is available.
DNS CNAME RR are allowed:
if <strong>"_caa-ct-sts"</strong> is a CNAME to another <strong>"_caa-ct-sts"</strong> RR,
clients follow the alias (as in MTA-STS).
</t>
</section>
<section anchor="syntax_caa_ct_sts_record">
<name>DNS "_caa-ct-sts" TXT RR Syntax</name>
<t>The DNS <strong>"_caa-ct-sts"</strong> TXT RR content has the following sub-syntax
(specified in ABNF as per<xref target="RFC7405"/>):
</t>
<figure>
<name>ABNF Syntax of "_caa-ct-sts" TXT RR</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
issuect-text-record = issuect-version 1*(issuect-field-delim issuect-field) \
[issuect-field-delim]
issuect-field = issuect-id / issuect-extension
issuect-field-delim = *WSP ";" *WSP
issuect-version = %s"v=CAACTSTSv1"
issuect-id = %s"id=" 1*32(ALPHA / DIGIT)
issuect-extension = issuect-ext-name "=" issuect-ext-value
issuect-ext-name = (ALPHA / DIGIT) *31(ALPHA / DIGIT / "_" / "-" / ".")
issuect-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
; printable chars excluding "=" ";" and space
]]>
</sourcecode>
</figure>
<t>This mirrors the MTA-STS TXT ABNF.
Clients accept a single TXT string
(concatenating fragments if needed) and ignore extra semicolons.
The id string has no semantics beyond change detection; it imposes no ordering.
</t>
</section>
<section anchor="caa_ct_sts_policy">
<name>CAA-CT-STS Policy File</name>
<t>Once a <strong>"_caa-ct-sts"</strong> RR indicates support, the
<strong>"CAA-CT-STS"</strong>
policy is fetched via HTTPS contains newline-separated "key:value"-pairs, similar to MTA-STS.
The canonical policy fields are:
</t>
<ol type="(%c)">
<li>version (required): <strong>MUST</strong> be "CAACTSTSv1". This identifies the policy version.
</li>
<li>max_age (required): a non-negative integer (seconds) giving the lifetime of the policy.
Clients <strong>SHOULD</strong> cache the policy up to max_age (up to 31 557 600).
</li>
<li>ct_policy (required): at least one.
For each CT-Log a single entry has to be provided according to the same syntax as
defined in
<xref target="issuect"/>
while ignoring the leading "issuect" Tag, see:
<xref target="caa_ct_sts_policy_examples"/>
for examples.
</li>
<li>Extension fields: additional key:value pairs allowed.</li>
</ol>
<t>All fields appear as &lt;key&gt;:[space]*&lt;value&gt; on separate lines.</t>
</section>
<section anchor="syntax_caa_ct_sts_policy">
<name>CAA-CT-STS Policy File Syntax</name>
<t>The <strong>"/.well-known/caa-ct-sts.txt"</strong> Policy File has the following sub-syntax
(specified in ABNF as per<xref target="RFC7405"/>):
</t>
<figure>
<name>ABNF Syntax of "/.well-known/caa-ct-sts.txt" Policy File</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SP = %x20 ; SPACE
DQUOTE = %x22 ; "
SEMICOLON = %x3B ; ";"
LPAREN = %x28 ; "("
RPAREN = %x29 ; ")"
CRLF = %x0D.0A / %x0A ; CRLF or LF
b64-char = ALPHA / DIGIT / "+" / "/"
b64-string = 1*( b64-char / "=" )
date = 4DIGIT "-" 2DIGIT "-" 2DIGIT
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
date-time = date "T" time "Z"
uri = absolute-URI
issuect-value = issuer-domain-name ";" SP
"critical" "=" ( "true" / "false" ) ";" SP
"desc" "=" "'" desc-text "'" ";" SP
"validfrom" "=" date-time ";" SP
"validtill" "=" date-time ";" SP
"cturi" "=" uri ";" SP
"logid" "=" "'" b64-string "'" ";" SP
"pubkey" "=" "'" b64-string "'" ";"
issuer-domain-name = label *("." label)
label = (ALPHA / DIGIT) *( *( "-" ) (ALPHA / DIGIT) )
desc-text = *( %x20-26 / %x28-7E )
; printable ASCII except apostrophe
;----------------------------------------------------------------------------
; CAA-CT-STS Policy File Grammar
;----------------------------------------------------------------------------
caa-ct-sts-file = *WSP
version-line CRLF
mode-line CRLF
max-age-line CRLF
1*ct-policy-line
*WSP
version-line = "version:" SP "CAACTSTSv1"
max-age-line = "max_age:" SP 1*DIGIT
ct-policy-line = "ct_policy:" SP
LPAREN SP
DQUOTE issuect-value DQUOTE
SP RPAREN
WSP = *( SP / HTAB )
]]>
</sourcecode>
</figure>
<t>In the above, each policy field occupies an entire line and policy fields may appear in any order.
Parsers <strong>MUST</strong> accept policies that are syntactically valid; unknown fields are treated
as extensions and ignored.
A policy with no "ct_log" entries (and "mode" not explicitly set to "none") is invalid.
See Section TODO for policy validation.
</t>
</section>
</section>
<section anchor="caa_ct_sts_processing">
<name>CAA-CT-STS Processing</name>
<section anchor="https_policy_fetching">
<name>CAA-CT-STS Policy File HTTPS Fetching</name>
<t>The CAA-CT-STS Policy File is fetched via "HTTPS GET" via TLS1.3<xref target="RFC8446"/>, only, from
</t>
<figure>
<name>HTTPS GET "/.well-known/caa-ct-sts.txt" Policy File</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
]]>
</sourcecode>
</figure>
<t>where &lt;domain&gt; is the Policy Domain (e.g., example.com).
This follows the well-known URI convention.
The Policy Server <strong>MUST</strong> present a Certificate, that is valid for the
"caa-ct-sts" DNS-ID (e.g., "caa-ct-sts.example.com"),
chain to a Root CA that is trusted by the Certification Authority, which is asked to issue a new
Certificate, as the Certification Authority rely on TLS security for policy integrity.
Certification Authorities <strong>SHOULD</strong> verify that the HTTP Content-Type is "text/plain"
(ignoring any parameters); other content types indicate an invalid policy file.
Line separators must be either LF or CRLF; the file <strong>MUST</strong> be US-ASCII or UTF-8 without
a byte-order mark.
No authentication is performed beyond standard TLS trust.
After fetching, Certification Authorities parse the file as above.
If the HTTP request fails for whatever reason,
(network error, invalid cert, status ≠ 200, or parse error),
the policy is considered unavailable or invalid, and Certification Authorities fall back to "no policy".
HTTP 3xx redirects <strong>MUST NOT</strong> be followed, and HTTP caching
<xref target="RFC7234"/>
<strong>MUST NOT</strong> be used.
A new or updated Policy is identified when its content differs
(e.g., a new "id" in DNS or new "version" in the Policy File);
while the "max_age" field controls how long a policy may be cached.
As in MTA-STS, Certification Authorities <strong>SHOULD</strong> check for updated policy via DNS
before permanently acting on failures.
</t>
</section>
<section anchor="policy_validation">
<name>CAA-CT-STS Policy File Validation</name>
<t>Before use, a retrieved Policy File by a Certification Authority <strong>MUST</strong> be checked
for correct syntax and semantics:
</t>
<ul>
<li>The "version" field <strong>MUST</strong> equal "CAACTSTSv1",
</li>
<li>While "max_age" <strong>MUST</strong> be a valid non-negative integer,
</li>
<li>and at least "1 + n" "ct_log" <strong>MUST</strong> be present, see:
<xref target="minimum_logs"/>.
</li>
</ul>
<t>If the policy file is malformed or has invalid values, it is rejected
(treated as if no policy were present), as with MTA-STS.
</t>
<t>Lastly the Runtime Processing as described in
<xref target="runtime_processing"/>
is applicable, too.
</t>
</section>
</section>
</section>
<section anchor="IANA">
<name>IANA Considerations</name>
<section>
<name>IANA registration CAA Property Tag "issuect"</name>
<t>The following IANA registration is requested.</t>
<t>According to
<xref target="RFC8126"/>
these information are provided:
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Registry: Certification Authority Restriction Properties.</li>
<li>Registry Group: Public Key Infrastructure using X.509 (PKIX) Parameters.</li>
<li>Expert Contact: Mr. Phillip Hallam-Baker (at time of writing).</li>
<li>URI:
<eref target="https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml">
Public Key Infrastructure using X.509 (PKIX) Parameters
</eref>
<xref target="URI8" format="none">[8]</xref>.
</li>
</ul>
<t>IANA is asked to assign the property tag <strong>"issuect"</strong> to this subregistry,
documenting its name, ABNF syntax, and reference to this specification.
</t>
<section>
<name>IANA Subregistry Entry "issuect"</name>
<table>
<name>IANA Subregistry Entry "issuect"</name>
<thead>
<tr>
<th>Tag</th>
<th>Meaning</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">issuect</td>
<td align="left">Authorized CT-Log submission URI</td>
<td align="left">(This document)</td>
</tr>
</tbody>
</table>
</section>
</section>
<section>
<name>Well-Known URIs Registry</name>
<t>The following IANA registration is requested.</t>
<t>According to
<xref target="RFC8126"/>
these information are provided:
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Registry: Well-Known URIs</li>
<li>Registry Group: Well-Known URIs.</li>
<li>Expert Contact: Mr. Mark Nottingham (at time of writing).</li>
<li>URI:
<eref target="https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml">
Well-Known URIs
</eref>
<xref target="URI9" format="none">[9]</xref>.
</li>
</ul>
<t>IANA is asked to assign the "well-known" URI Suffix <strong>"caa-ct-sts.txt"</strong> to this registry,
whose Change Controller is: IETF
</t>
<section>
<name>IANA Registry Entry URI Suffix "caa-ct-sts.txt"</name>
<table>
<name>IANA Registry Entry URI Suffix "caa-ct-sts.txt"</name>
<thead>
<tr>
<th>URI Suffix</th>
<th>Reference</th>
<th>Change Controller</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">caa-ct-sts.txt</td>
<td align="left">(This document)</td>
<td align="left">IETF</td>
</tr>
</tbody>
</table>
</section>
</section>
<section>
<name>CAA-CT-STS Strict Transport Security Registry Creation</name>
<t>The following IANA "Registry" registration is requested.</t>
<t>According to
<xref target="RFC8126"/>
these information are provided:
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Registry: CAA-CT-STS Strict Transport Security (CAA-CT-STS) [to be created]</li>
<li>Subregistry: CAA-CT-STS TXT Record Fields [to be created]</li>
<li>Subregistry: CAA-CT-STS TXT Policy Fields [to be created]</li>
<li>Expert Contact: (tba).</li>
</ul>
<t>IANA is asked to create the before mentioned Registry.</t>
<section>
<name>CAA-CT-STS Record Fields</name>
<table>
<name>CAA-CT-STS Record Fields</name>
<thead>
<tr>
<th>Field name</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">v</td>
<td align="left">Record version</td>
<td align="left">This document</td>
</tr>
<tr>
<td align="left">id</td>
<td align="left">Policy instance ID</td>
<td align="left">This document</td>
</tr>
</tbody>
</table>
</section>
<section>
<name>CAA-CT-STS Record Policy Fields</name>
<table>
<name>CAA-CT-STS Policy Fields</name>
<thead>
<tr>
<th>Field name</th>
<th>Description</th>
<th>Reference</th>
</tr>
</thead>
<tbody>
<tr>
<td align="left">version</td>
<td align="left">Policy version</td>
<td align="left">This document</td>
</tr>
<tr>
<td align="left">mode</td>
<td align="left">Enforcement behavior</td>
<td align="left">This document</td>
</tr>
<tr>
<td align="left">max_age</td>
<td align="left">Policy lifetime</td>
<td align="left">This document</td>
</tr>
<tr>
<td align="left">ct_policy</td>
<td align="left">Unique CT-Log property string</td>
<td align="left">This document</td>
</tr>
</tbody>
</table>
</section>
</section>
</section>
<section anchor="security">
<name>Security Considerations</name>
<t>This extension inherits and adapts security considerations from:</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>CAA framework<xref target="RFC8659"/>,
</li>
<li>CAA Record Extensions for Account URI and (ACME) Binding<xref target="RFC8657"/>,
</li>
<li>Certificate Transparency Version 2.0.<xref target="RFC9162"/>,
</li>
<li>ACME protocol<xref target="RFC8555"/>,
</li>
<li>SMTP MTA Strict Transport Security (MTA-STS)<xref target="RFC8461"/>.
</li>
</ul>
<t>As an extension of the DNS-based CAA framework, this proposal generally falls within the
Internet threat model defined by<xref target="RFC3552"/>.
</t>
<section>
<name>Global considerations</name>
<t>This specification augments the CAA RR framework by introducing finer-grained controls over both
Certificate issuance and CT-Log submission.
Domain owners can now explicitly authorize which CAs may issue Certificates and which CT-Log operators
must or may record those Certificates.
When used in tandem with compliant CAs and CT-Log operators, <strong>"issuect"</strong> significantly
strengthens the issuance security posture for domains that opt in.
</t>
<t>Using <em>"critical=true"</em> ensures that no Certificate is ever issued without logging to the specified
CT-Log endpoints, preventing accidental or malicious bypass of transparency requirements.
</t>
<t>By co-locating CT-Log authorization data within DNSSEC-protected CAA RRs,
this extension also reduces reliance on out-of-band lists and third-party dependencies,
thereby minimizing attack surface and improving resilience against CT-Log Operator compromise.
</t>
<t>To further harden CAA "issuect" Policy discovery and protect against DNS manipulation,
CAs <strong>SHOULD</strong> implement a CAA-CT-STS HTTPS fallback mechanism.
This provides a second, TLS-authenticated channel for retrieving CAA "issuect" Policies directly
from the domain owner.
</t>
<section anchor="dnssec_fallback">
<name>CAs Preferred Proposed Validation Path</name>
<t>The <strong>RECOMMENDED</strong> multi-stage retrieval process is:
</t>
<ol>
<li>
<strong>DNSSEC-first:</strong>
Attempt to fetch the CAA <strong>"issuect"</strong> RR via DNS, validating all responses with DNSSEC.
If the RR validates successfully, process it per normal CAA logic.
</li>
<li>
<strong>Well-Known HTTPS (fast-path):</strong>
If DNSSEC validation fails, or the zone is not signed, perform a single HTTPS GET to
"https://caa-ct-sts.&lt;domain&gt;/.well-known/caa-ct-sts.txt",
resolving the hostname only to it's
A/AAAA address (no further name recursion),
to minimize exposure to poisoned or spoofed DNS replies.
</li>
<li>
<strong>IP-only HTTPS (slow-path):</strong>
If step 2 fails, explicitly fetch the A/AAAA record for
"caa-ct-sts.&lt;domain&gt;", then open a TLS connection by IP address
(SNI still "caa-ct-sts.&lt;domain&gt;")
to retrieve the same policy file.
</li>
<li>
<strong>Insecure DNS with ODoH:</strong>
Should all prior steps be unreachable, fall back to fetching CAA <strong>"issuect"</strong> RRs
over standard DNS, but prefer an
Oblivious DoH (ODoH)
<xref target="RFC9230"/>
transport to obscure queries
from on-path attackers.
</li>
</ol>
<t>By layering these channels, DNSSEC, well-known HTTPS, IP-only HTTPS, and finally ODoH-protected DNS,
the CA dramatically reduces the attack surface for policy tampering,
while still providing robust fallback when certain transports are unavailable.
</t>
</section>
</section>
<section anchor="caa_ct_sts_discussions">
<name>CAA-CT-STS Advantages and Disadvantages</name>
<t>Advantages: The HTTPS source prevents a DNS attacker from simply replacing or deleting the
DNS CAA RR Extension <strong>"issuect"</strong>, they would also have to manipulate the HTTPS connection.
If the DNS (CA side) fails, for example, the CA can use this defined backup channel to determine
which Logs to use.
Since web servers are usually TLS-enabled anyway, the hurdle for domain owners would be relatively low.
</t>
<t>Disadvantages: The domain owner needs a valid web certificate, which can initially be a "chicken and egg"
problem (how does one provide "/.well-known/caa-ct-sts.txt" before one has a Certificate?).
In addition, the CA must be configured to perform HTTPS retrieval in the first place,
this is not provided for in the current CA/ACME implementations.
Another point is that an attacker who is already performing MITM at the network level
could manipulate both DNS and HTTPS, (e.g., via a fake Root Certificate),
so that even the "/.well-known/caa-ct-sts.txt" approach only provides limited protection.
MTA-STS solves this through HSTS and policy caching, among other things.
Overall, HTTPS "/.well-known/caa-ct-sts.txt" would therefore be a useful additional measure
that could serve as a secondary source of trust, especially in the absence of DNSSEC.
</t>
</section>
<section anchor="redundancy">
<name>Policy Redundancy Considerations</name>
<t>Let c be the number of critical CT-Logs and w be the number of whitelisted (non-critical) CT-Logs,
then the following expression is strongly <strong>RECOMMENDED</strong>:
|c| ≥ n + 1 ∧ |w| ≤ 2
</t>
<t>While the "critical=true" flag in the CAA <strong>"issuect"</strong> Parameter enforces that every
Certificate issuance must be logged to all specified CT-Logs, this strict requirement can introduce
availability risks: if any one of those CT-Log endpoints becomes temporarily unreachable
(maintenance, network partition, DDoS, etc.), the CA, per specification, must reject the
Certificate Signing Request.
To balance tamper-resistance against operational resilience,
it is therefore strongly <strong>RECOMMENDED</strong> the following guardrails:
</t>
<ol>
<li>Minimum Redundancy ("n + 1").
Let n be the minimum number of distinct, trusted CT-Logs mandated by major CT-Truststore policies
(for instance, Apple and Google currently require a Certificate to be embedded with at
least "n = 2" or "n = 3" unique SCTs from independent logs to be accepted in their roots).
Domain owners <strong>MUST NOT</strong> specify less than n + 1 CT-Logs under "critical=true".
This ensures that even if one of the critical CT logs is unavailable,
the CA can still obtain the remaining n SCTs and proceed with issuance.
</li>
<li>"+ 2" Whitelist of Non-Critical CT-Logs.
In addition to the n + 1 critical logs, domain owners <strong>SHOULD</strong> nominate at least
up to two further CT-Logs without the "critical=true" flag.
These “whitelisted” CT-Logs provide extra transparency channels,
enabling issuance to continue if a critical CT-Log fails,
but do not block issuance if they are unreachable.
They <strong>MUST NOT</strong> not carry "critical=true"; otherwise,
a transient failure at any one CT-Log would force a full issuance rejection.
These non-critical logs help broaden auditing coverage (e.g., corporate or private logs)
without jeopardizing certificate availability.
</li>
</ol>
<section anchor="ca_operational_procedure">
<name>Operational Procedure for CAs</name>
<ul>
<li>Fetch and Validate CAA <strong>"issuect"</strong>: Retrieve the CAA <strong>"issuect"</strong> RR
(via DNSSEC or the HTTPS fallback) and parse the list of critical versus non-critical CT-Logs.
</li>
<li>Attempt Precertificate Submission: For each critical CT-Log, send the Precertificate
and collect its SCT.
If all critical logs successfully return SCTs, proceed.
If any critical CT-Log fails, but at least n SCTs from the remaining critical CT-Logs
are still obtained (thanks to the n + 1 redundancy), proceed; otherwise, reject the CSR.
</li>
<li>Optionally Submit to Non-Critical CT-Logs: Attempt to send it to non-critical CT-Logs in parallel.
If they also fail or are slow, reject issuance; report any failures for domain-owner monitoring.
</li>
</ul>
<t>By embedding n + 1 redundancy and a + 2 non-critical whitelist, this framework simultaneously
enforces strong, mandatory CT logging (protecting against malicious or erroneous omission) and
maintains the operational flexibility necessary to keep issuance flowing even
during intermittent CT-Log outages.
</t>
</section>
</section>
<section>
<name>Scope Limited to CAs and CT-Log Operators Processing CAA RRs</name>
<t>This extension empowers domain owners, who already maintain relationships with compliant CAs and
CT-Log operators, to impose additional constraints on both Certificate issuance and log submission,
provided those parties implement the <strong>"issuect"</strong> mechanism.
It does not strengthen guarantees for any CA or CT-Log operator that does not support this extension:
non-conforming entities retain their existing ability to issue Certificates or submit log entries
regardless of <strong>"issuect"</strong> policy.
Consequently, domains that authorize only participating CAs and CT-Log operators remain vulnerable
to unauthorized issuance or logging by entities that ignore or merely advise upon CAA RRs.
Even in DNSSEC-protected zones, the risk of misissuance persists if a CA or CT-Log operator fails
to validate CAA RRs via a trusted, DNSSEC-validating resolver.
</t>
</section>
<section>
<name>Additional CAA-CT-STS Security Considerations</name>
<t>When a domain owner already employs DNSSEC, it is <strong>RECOMMENDED</strong>, that the HTTPS endpoint
serving the CAA-CT-STS Policy be further bound via DANE/TLSA records.
By publishing TLSA RR for both leaf and intermediate certificates,
CAs retrieving "/.well-known/caa-ct-sts.txt" gain an additional multipath validation and
out-of-band binding to the X.509 chain:
</t>
<ol>
<li>
<t>TLSA Usage</t>
<ul>
<li>3 1 1 — SHA-256 hash of the leaf certificate's SPKI</li>
<li>3 1 2 — SHA-512 hash of the leaf certificate's SPKI</li>
<li>2 1 1 — SHA-256 hash of the issuing intermediate certificate's SPKI</li>
<li>2 1 2 — SHA-512 hash of the issuing intermediate certificate's SPKI</li>
</ul>
<t>Here, TLSA-usage 3 (DANE-EE) and 2 (DANE-TA), selector 1 (SPKI), and matching
types 1 (SHA-256) and 2 (SHA-512) ensure that CAs validate the exact certificates
used by the policy host, preventing MITM.
</t>
</li>
<li>
<t>SVCB / HTTPS Record</t>
<t>One can define a SVCB (or HTTPS) DNS RR for "caa-ct-sts.&lt;domain&gt;",
advertising support for HTTP/3 (QUIC)
and pointing to the same IP addresses as the A/AAAA records.
This allows CAs to connect over the most modern, UDP-based transport with built-in encryption
and connection resilience.
</t>
</li>
<li>
<t>Strict TLS Configuration</t>
<t>The policy server should only accept TLS1.3 with strong cipher suites
(e.g., AES_256_GCM) and elliptic-curve key exchange using X448, P-521, or P-384 (in this order).
This ensures forward secrecy and resistance to known TLS attacks.
</t>
</li>
<li>
<t>Optional DANE-Style Binding in the Policy File (NOT implemented in this draft)</t>
<t>For maximum end-to-end integrity, the "/.well-known/caa-ct-sts.txt" file itself may include
DANE-like fields to bind a specific DNSSEC KZK.
For example:
</t>
<figure>
<name>CAA-CT-STS Policy incl. DNSSEC KZK-Binding</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
version: CAACTSTSv1
max_age: 60
kzk_id: 32768
kzk_hash: 'MII(...)'
ct_policy: ( "example.ca; \
critical=true; \
desc='Example Log FunnyNameNet 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.example.net/logs/eu/funnynamenet2025; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
]]>
</sourcecode>
</figure>
<t>Whereas "kzk_id" would be an integer identifier of the Key-Id of the KZK of the domain, and
"kzk_hash" would be a Base64-encoded hash of the KZK of the domain.
By combining DNSSEC-protected
TLSA and in-CAA-CT-STS-Policy kzk_hash and kzk_id values, CAs gain cryptographic assurance of
both the CAA-CT-STS Policy files authenticity and the CT-Log endpoints identity,
further reducing the risk of policy-fetch or logging interception attacks.
</t>
</li>
</ol>
</section>
<section>
<name>Authorization Freshness</name>
<t>CAA allows a Certification Authority to pre-authorize an account, to request Certificates for a domain
well before the actual issuance event.
As a result, the CAA policy in effect at authorization time may differ from the policy published at
issuance time.
To mitigate this risk, CAs SHOULD adopt one or more of the following practices:
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Issue pre-authorizations with short validity intervals (for example, one hour).</li>
<li>Re-validate the domain's current CAA policy immediately prior to certificate issuance.</li>
</ul>
<t>By limiting the window during which stale authorizations remain valid and by re-checking CAA RRs
at issuance time, CAs reduce the likelihood of complying with outdated or revoked policy statements.
</t>
</section>
<section>
<name>Use with and without DNSSEC</name>
<t>The standard domain-validation model does not protect against an adversary capable of intercepting
all traffic to a domain (a "global man-in-the-middle" [MITM] attack).
Such an attacker can hijack validation requests from any CA and thus impersonate domain control.
When a domain is DNSSEC-signed,
and the CA resolves DNS exclusively via a trusted DNSSEC-validating resolver,
however, the authenticity and integrity of DNS data are assured.
</t>
<t>To leverage this protection, a CA's validation process <strong>SHOULD</strong> either:
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Rely solely on DNSSEC-authenticated DNS responses for all validation data; or</li>
<li>Cryptographically bind every other validation channel (e.g., HTTP-01, TLS-ALPN-01)
to material obtained via DNSSEC.
</li>
</ul>
</section>
<section>
<name>Scenario Effects for "issuect" and Security</name>
<t>DNSSEC-secured</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>CAA and <strong>"issuect"</strong> RRs are authenticated.
</li>
<li>Any modification to these RRs is detected by DNSSEC validation failures.</li>
<li>The CA can trust that CT-Log authorizations originate from the domain owner.</li>
<li>Certificates cannot be issued "out of band," nor can CAA-driven CT-Log instructions be tampered
with undetected.
</li>
</ul>
<t>Not DNSSEC-secured</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>CAA and <strong>"issuect"</strong> RRs may be forged or suppressed.
</li>
<li>A CA relying on cached or unauthenticated responses risks seeing incorrect policies.</li>
<li>An attacker could inject a false empty <strong>"issuect"</strong> ";" to disable logging,
or point to malicious CT-Logs, subverting transparency.
</li>
<li>In extreme "SOA interception" scenarios, an attacker could entirely block certificate issuance by
dropping CAA/A RRs.
</li>
</ul>
</section>
<section>
<name>Restrictions Supersedable by DNS Delegation</name>
<t>CAA RRs are discovered during validation by traversing up the DNS hierarchy until one or more
RRs are located.
Because of this lookup behavior, CAA RRs cannot reliably restrict or control
Certificate issuance for subdomains whose DNS management has been delegated to another party
(for example, via NS delegation or by granting limited DNS-editing rights for a subdomain).
</t>
</section>
</section>
</middle>
<back>
<references>
<name>References</name>
<references>
<name>Normative References</name>
<reference anchor="ISO-8601" target="https://www.iso.org/standard/70907.html">
<front>
<title>Date and time — Representations for information interchange</title>
<author>
<organization>International Organization for Standardization</organization>
</author>
<date month="June" year="2019"/>
</front>
<seriesInfo name="ISO" value="ISO 8601:2019"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1034.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1035.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2181.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4648.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5155.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5280.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6698.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6962.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7234.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7405.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7671.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8551.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8657.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8659.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9364.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9495.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9499.xml"/>
<reference anchor="X.680" target="https://www.itu.int/rec/T-REC-X.680-X.693-202102-I/en">
<front>
<title>Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation</title>
<author>
<organization>International Telecommunication Union, Telecommunication Standardization Sector (ITU-T)
</organization>
</author>
<date month="June" year="2021"/>
</front>
<seriesInfo name="ITU-T" value="X.680 (06/2021)"/>
</reference>
<reference anchor="X.690" target="https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf">
<front>
<title>Information technology - ASN.1 encoding rules: Specification of Basic, Canonical, and Distinguished Encoding
Rules
</title>
<author>
<organization>International Telecommunication Union, Telecommunication Standardization Sector (ITU-T)
</organization>
</author>
<date month="July" year="2021"/>
</front>
<seriesInfo name="ITU-T" value="X.690 (07/2021)"/>
</reference>
</references>
<references>
<name>Informative References</name>
<reference anchor="POSIX" target="https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/">
<front>
<title>Portable Operating System Interface (POSIX™) - Base Specifications</title>
<author>
<organization>The Institute of Electrical and Electronics Engineers; The Open Group</organization>
</author>
<date month="December" year="2017"/>
</front>
<seriesInfo name="IEEE Std" value="1003.1-2017"/>
<seriesInfo name="The Open Group Base Specifications" value="Issue 7, 2018 Edition"/>
<seriesInfo name="ISO/IEC" value="9945:2009/Cor 2:2017(E)"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3552.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3647.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4033.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4034.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.4035.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.5246.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6347.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8461.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8555.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9162.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9230.xml"/>
</references>
<references>
<name>URI</name>
<reference anchor="URI1" target="https://coresecret.dev/msw/draft-weidner-catalog-rr-ext.git">
<front>
<title>This document</title>
<author/>
</front>
</reference>
<reference anchor="URI2"
target="https://keys.openpgp.org/vks/v1/by-fingerprint/7A8341E5F1570319D80F4418A11E88519A3D8CF6">
<front>
<title>7A83 41E5 F157 0319 D80F 4418 A11E 8851 9A3D 8CF6</title>
<author/>
</front>
</reference>
<reference anchor="URI3"
target="https://github.com/google/certificate-transparency-community-site/blob/master/docs/google/known-logs.md">
<front>
<title>Known Logs</title>
<author/>
</front>
</reference>
<reference anchor="URI4" target="https://www.gstatic.com/ct/log_list/v3/log_list.json">
<front>
<title>JSON List of CT-Logs that are currently compliant with Chromes CT policy</title>
<author/>
</front>
</reference>
<reference anchor="URI5" target="https://support.apple.com/en-us/103214">
<front>
<title>Apple's Certificate Transparency policy</title>
<author/>
</front>
</reference>
<reference anchor="URI6" target="https://valid.apple.com/ct/log_list/current_log_list.json">
<front>
<title>JSON List of CT-Logs that are currently compliant with Apple's CT policy</title>
<author/>
</front>
</reference>
<reference anchor="URI7" target="https://googlechrome.github.io/CertificateTransparency/ct_policy.html">
<front>
<title>Chrome's Certificate Transparency Policy</title>
<author/>
</front>
</reference>
<reference anchor="URI8" target="https://www.iana.org/assignments/pkix-parameters/pkix-parameters.xhtml">
<front>
<title>Public Key Infrastructure using X.509 (PKIX) Parameters</title>
<author/>
</front>
</reference>
<reference anchor="URI9" target="https://www.iana.org/assignments/well-known-uris/well-known-uris.xhtml">
<front>
<title>Well-Known URIs</title>
<author/>
</front>
</reference>
</references>
</references>
<section anchor="caa_processing_checklist">
<name>Informational: CAA "issuect" Property Tag Processing Checklist</name>
<ol type="(%d)">
<li>
<t>
<strong>Discover Relevant RRSet</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Perform DNS lookup for the domain's CAA RRSet using the algorithm from
<eref target="https://www.rfc-editor.org/rfc/rfc8659#section-3">Section 3</eref>
of
<xref target="RFC8659"/>
</li>
</ul>
</li>
<li>
<t>
<strong>Check for "issuect" Presence</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>If the RRSet is empty or contains no <strong>"issuect"</strong> RRs,
proceed without CT-Log restrictions.
</li>
</ul>
</li>
<li>
<t>
<strong>Repeat for Each Domain</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>For multi-domain Certificates (e.g., via SANs), repeat steps 1-2 for each domain name.</li>
</ul>
</li>
<li>
<t>
<strong>Validate issue / issuewild Authorization</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Independently verify any "issue" or "issuewild" CAA RRs before considering CT-Log restrictions.</li>
<li>If CAA authorization and <strong>"issuect"</strong> parameters reference different CAs,
treat the configuration as unsatisfiable.
</li>
</ul>
</li>
<li>
<t>
<strong>Parse and Validate issuect Parameters</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Ensure exactly eight parameters appear in the correct order (see Section 3.3).</li>
<li>Enforce RFC 2119 rules:</li>
<li>critical: must be "true" or "false".</li>
<li>desc: single-quoted, no internal '.</li>
<li>validfrom / validtill: strict YYYY-MM-DDThh:mm:ssZ.</li>
<li>cturi: absolute URI with lowercase hostname.</li>
<li>logid / pubkey: single-quoted Base64 values.</li>
<li>Trailing semicolon only after pubkey.</li>
<li>Treat any formatting errors as if the RR does not exist.</li>
</ul>
</li>
<li>
<t>
<strong>Enforce Whitelist and Default-Deny Semantics</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>If one or more valid <strong>"issuect"</strong> RRs exist:
</li>
<li>Permit CT-Log submissions only to the union of all whitelisted URIs.</li>
<li>If any RR has "critical=true", reject issuance unless all issued SCTs are
logged to a whitelisted CT-Log.
</li>
<li>If an empty <strong>"issuect"</strong> ";" RR is present,
and no non-empty RRs exist, prohibit all CT-Log submissions.
</li>
</ul>
</li>
<li>
<t>
<strong>Determine Required SCT Count</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>For each CA, obtain at least n + 1 unique CAA <strong>"issuect"</strong> RRs,
where n is the minimum SCT count (Section 4.1).
</li>
<li>Consult CA policies (e.g., Google's or Apple's CT-Log requirements) for the exact value of n.</li>
</ul>
</li>
<li>
<t>
<strong>Proceed with Certificate Issuance</strong>
</t>
<ul spacing="normal" empty="false" indent="2" bare="false">
<li>Only after all the above checks pass,
CAA authorization, <strong>"issuect"</strong> validation, SCT count and logging requirements,
issue the Certificate.
</li>
</ul>
</li>
</ol>
</section>
<section anchor="dns_examples">
<name>Informational: DNS Zone-file Examples</name>
<section anchor="preface">
<name>Preface</name>
<t>The following examples are provided for informational purposes only and are supplied "as is", without
a warranty of any kind or liability.
They illustrate relevant RRSets, and their expected processing semantics.
Their BIND file notation format is defined in<xref target="RFC1035"/>.
Parentheses are used to ignore a line break in DNS zone-file presentation format, as per
<eref target="https://rfc-editor.org/rfc/rfc1035#section-5.1">Section 5.1</eref>
of<xref target="RFC1035"/>.
</t>
</section>
<section anchor="comprehensive_example">
<name>CAA "issuect" Comprehensive and Proper Example</name>
<t>The following shows a comprehensive and proper example DNS zone-file fragment of the "example.com" zone
that nominates six distinguished CT-Log URIs for the "example.ca" Certification Authority,
which must (n + 1) and could (+ 2) [redundancy rule<xref target="redundancy"/>],
log any Certificates requested to the specified CT-Log, as authorized to log >180-day valid
Certificates for the "sub.example.com" domain.
The submission is limited to the critical CT-Logs "ct.example.net", "ct.example.org", "ct.example.sh",
and "ct.example.xyz" and to the non-critical CT-Logs "ct.non-critical.net" and "ct.non-critical.org".
</t>
<aside>
<t><strong>NOTE</strong>: "CAA authorizations are additive; thus, the result of specifying both the empty
issuer, and a specified issuer is the same as specifying just the specified issuer alone."
</t>
</aside>
<figure>
<name>Zone-file: CAA "issuect" Comprehensive and Proper Example</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
sub.example.com. 60 IN CAA 0 issuect ( "example.ca; \
critical=true; \
desc='Example Log FunnyNameNet 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.example.net/logs/eu/funnynamenet2025; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
sub.example.com. 60 IN CAA 0 issuect ( "example.ca; \
critical=true; \
desc='Example Log FunnyNameOrg 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.example.org/logs/eu/funnynameorg2025"; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
sub.example.com. 60 IN CAA 0 issuect ( "example.ca; \
critical=true; \
desc='Example Log FunnyNameSh 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.example.sh/logs/eu/funnynamesh2025; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
sub.example.com. 60 IN CAA 0 issuect ( "example.ca; \
critical=true; \
desc='Example Log FunnyNameXyz 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.example.xyz/logs/eu/funnynamexyz2025; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
sub.example.com. 60 IN CAA 0 issuect ( "example.ca; \
critical=false; \
desc='Example Log NonCriticalNet 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.non-critical.net/logs/eu/noncriticalnet2025; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
sub.example.com. 60 IN CAA 0 issuect ( "example.ca; \
critical=false; \
desc='Example Log NonCriticalOrg 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.non-critical.org/logs/eu/noncriticalorg2025; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
]]>
</sourcecode>
</figure>
</section>
<section anchor="no_submission">
<name>CAA "issuect" No CT-Log Submission Example</name>
<t>The following shows a no CT-Log submission at all example DNS zone-file fragments of the "example.com" zone
that wishes to not submit their Certificates to any CT-Log.
</t>
<figure>
<name>Zone-file: CAA "issuect" No CT-Log Submission Example</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
sub.example.com. 60 IN CAA 0 issuect ";"
]]>
</sourcecode>
</figure>
</section>
<section anchor="erroneous_example">
<name>CAA "issuect" Erroneous Example</name>
<t>The following shows an erroneous example DNS zone-file fragment of the "example.com" zone that falsely set
the
Parameter Set, so that according to the Processing definitions, the erroneous Property will be treated as
non-existent.
</t>
<figure>
<name>Zone-file: CAA "issuect" Erroneous Example</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
sub.example.com. 60 IN CAA 0 issuect ( "example.ca; \
critical=true; \
desc='Example Log FunnyNameXyz 2025'; \
validfrom=; \
validtill=; \
cturi=https://ct.example.xyz/logs/eu/funnynamexyz2025; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
]]>
</sourcecode>
</figure>
</section>
<section anchor="caa_ct_sts_example">
<name>CAA-CT-STS "_caa-ct-sts" Example</name>
<figure>
<name>Zone-file: CAA-CT-STS "_caa-ct-sts" Example</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
_caa-ct-sts.example.com. 60 IN TXT "v=CAACTSTSv1; id=20250427121212Z;"
]]>
</sourcecode>
</figure>
</section>
</section>
<section anchor="caa_ct_sts_policy_examples">
<name>Informational: CAA-CT-STS Examples</name>
<section>
<name>CAA-CT-STS Policy File Example</name>
<t>The following example indicates that Certificates for the domain must be logged in:</t>
<ul>
<li>https://ct.example.net/logs/eu/funnynamenet2025</li>
<li>https://ct.example.org/logs/eu/funnynameorg2025</li>
<li>https://ct.example.sh/logs/eu/funnynamesh2025</li>
<li>https://ct.example.xyz/logs/eu/funnynamexyz2025</li>
</ul>
<figure>
<name>CAA-CT-STS Policy File Example</name>
<sourcecode type="dns-rr" markers="false">
<![CDATA[
version: CAACTSTSv1
max_age: 60
ct_policy: ( "example.ca; \
critical=true; \
desc='Example Log FunnyNameNet 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.example.net/logs/eu/funnynamenet2025; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
ct_policy: ( "example.ca; \
critical=true; \
desc='Example Log FunnyNameOrg 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.example.org/logs/eu/funnynameorg2025"; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
ct_policy: ( "example.ca; \
critical=true; \
desc='Example Log FunnyNameSh 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.example.sh/logs/eu/funnynamesh2025; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
ct_policy: ( "example.ca; \
critical=true; \
desc='Example Log FunnyNameXyz 2025'; \
validfrom=2025-01-01T00:00:00Z; \
validtill=2026-01-01T00:00:00Z; \
cturi=https://ct.example.xyz/logs/eu/funnynamexyz2025; \
logid='sh4(...)'; \
pubkey='MFk(...)';" )
]]>
</sourcecode>
</figure>
</section>
</section>
<section anchor="shell_scripts">
<name>Informational: POSIX compliant Scripts</name>
<t>The following Shell scripts are provided for informational purposes only and are supplied "as is", without
a warranty of any kind or liability.
</t>
<section>
<name>Shell "issuect" Generator script</name>
<t>The following POSIX
<xref target="POSIX"/>-compliant shell script retrieves information from the regularly updated Google
curated
CT-Log-Operators file
<eref target="https://www.gstatic.com/ct/log_list/v3/log_list.json">
JSON List of CT-Logs that are currently compliant with Chromes CT policy
</eref>
<xref target="URI4" format="none">[4]</xref>
and generates zone-file compliant DNS RRs.
</t>
<figure>
<name>Shell "issuect" Generator script</name>
<sourcecode type="bash" markers="false">
<![CDATA[
#!/bin/sh
set -eu
readonly OWN_DOMAIN="$1"
readonly CAA_DOMAIN="$2"
readonly CRIT__FLAG="$3"
readonly ZONE__FILE="zone_${OWN_DOMAIN}_CAA.txt"
case "${CRIT__FLAG}" in
true|false) ;;
*) echo "Error: CRIT_FLAG MUST be either 'true' or 'false'." >&2
exit 1
;;
esac
:> "${ZONE__FILE}"
JSON=$(curl -fsSL https://www.gstatic.com/ct/log_list/v3/log_list.json)
readonly JSON
echo "${JSON}" | awk -v OWN="${OWN_DOMAIN}" -v CA="${CAA_DOMAIN}" -v CRIT="${CRIT__FLAG}" -v OUT="${ZONE__FILE}" '
BEGIN { FS="\""; }
/{[[:space:]]*"description"/ {
desc=""; url=""; start=""; endt=""; logid=""; key="";
}
/"description":/ {
desc = $4
gsub(/\047/, "", desc)
}
/"url":/ {
url = $4
}
/"start_inclusive":/ {
start = $4
}
/"end_exclusive":/ {
endt = $4
}
/"log_id":/ {
logid = $4
}
/"key":/ {
key = $4
gsub(/\047/, "", key)
}
/"end_exclusive":/ {
if (desc != "" && url != "" && start != "" && logid != "" && key != "") {
printf "%s. 60 IN CAA 0 issuect ( \"%s; critical=%s; desc='\''%s'\''; validfrom=%s; validtill=%s; cturi=%s; logid='\''%s'\''; pubkey='\''%s'\'';\" )\n", \
OWN, CA, CRIT, desc, start, endt, url, logid, key \
>> OUT
}
}
'
]]>
</sourcecode>
</figure>
</section>
<section>
<name>Shell "caa-ct-sts.txt" Generator script</name>
<t>The following POSIX
<xref target="POSIX"/>-compliant shell script retrieves information from the regularly updated Google
curated
CT-Log-Operators file
<eref target="https://www.gstatic.com/ct/log_list/v3/log_list.json">
JSON List of CT-Logs that are currently compliant with Chromes CT policy
</eref>
<xref target="URI4" format="none">[4]</xref>
and generates a "caa-ct-sts.txt"-Policy file.
</t>
<figure>
<name>Shell "caa-ct-sts.txt" Generator script</name>
<sourcecode type="bash" markers="false">
<![CDATA[
#!/bin/sh
set -eu
readonly OWN_DOMAIN="$1"
readonly CAA_DOMAIN="$2"
readonly CRIT__FLAG="$3"
readonly CAA_CTS_TS="caa-ct-sts.${OWN_DOMAIN}.txt"
case "${CRIT__FLAG}" in
true|false) ;;
*) echo "Error: CRIT_FLAG MUST be either 'true' or 'false'." >&2
exit 1 ;;
esac
:> "${CAA_CTS_TS}"
{ echo "version: CAACTSTSv1"
echo "max_age: 60"
} > "${CAA_CTS_TS}"
JSON=$(curl -fsSL https://www.gstatic.com/ct/log_list/v3/log_list.json)
readonly JSON
echo "${JSON}" | awk -v OWN="${OWN_DOMAIN}" -v CA="${CAA_DOMAIN}" -v CRIT="${CRIT__FLAG}" -v OUT="${CAA_CTS_TS}" '
BEGIN { FS="\""; }
/{[[:space:]]*"description"/ {
desc=""; url=""; start=""; endt=""; logid=""; key="";
}
/"description":/ {
desc = $4
gsub(/\047/, "", desc)
}
/"url":/ {
url = $4
}
/"start_inclusive":/ {
start = $4
}
/"end_exclusive":/ {
endt = $4
}
/"log_id":/ {
logid = $4
}
/"key":/ {
key = $4
gsub(/\047/, "", key)
}
/"end_exclusive":/ {
if (desc != "" && url != "" && start != "" && logid != "" && key != "") {
printf "ct_policy: ( \"%s; critical=%s; desc='\''%s'\''; validfrom=%s; validtill=%s; cturi=%s; logid='\''%s'\''; pubkey='\''%s'\'';\" )\n", \
CA, CRIT, desc, start, endt, url, logid, key \
>> OUT
}
}
'
]]>
</sourcecode>
</figure>
</section>
</section>
<section anchor="dns_ttl">
<name>Informational: DNS TTL</name>
<section>
<name>High-Security, High-Change Environments</name>
<t>It is <strong>RECOMMENDED</strong> to prefer very low TTL (60-300 s).
In case of compromise or mistakes a real time reaction is still possible.
</t>
</section>
<section>
<name>Stable, Low-Risk Domains with DDoS Concerns</name>
<t>It is <strong>RECOMMENDED</strong> to prefer high TTL (86 400 s+) to minimize
DNS-load and reduce resolver queries.
</t>
</section>
<section>
<name>Balanced Approach for Most</name>
<t>It is <strong>RECOMMENDED</strong> to use a medium TTL (e.g., 3 600 s / 1 h).
It limits exposure to cache-poisoning and CA mis-issuance to an hour,
while keeping query volume manageable.
</t>
</section>
</section>
<section anchor="change_history">
<name>Informational: Change History</name>
<section>
<name>draft-weidner-catalog-rr-ext-00</name>
<t>Initial Version</t>
</section>
</section>
<section anchor="Acknowledgements" numbered="false">
<name>Acknowledgements</name>
<t>This Draft uses extracts from templates written by Pekka Savola, Elwyn Davies, and Henrik Levkowetz.
</t>
</section>
<section anchor="Contributors" numbered="false">
<name>Contributors</name>
<t>The author gratefully acknowledges the contributors rigorous and professional critique, which materially
improved the technical clarity and robustness of this draft. Their objective and insightful feedback has been
invaluable in refining the specification.
</t>
<contact fullname="Andre Horst Zimnol" initials="A. H."
surname="Zimnol">
<organization>Private Contributor</organization>
<address>
<email>rfc.editor@zimnol.net</email>
</address>
</contact>
</section>
</back>
</rfc>
Reference in New Issue View Git Blame Copy Permalink