@@ -1,5 +1,4 @@
<?xml version="1.0" encoding="utf-8"?>
<?xml-model href="rfc7991bis.rnc"?>
<!DOCTYPE rfc [
<!ENTITY nbsp " ">
@@ -34,7 +33,7 @@
<address >
<postal >
<city > Lisboa</city>
<country > PT </country>
<country > Portugal </country>
</postal>
<phone > +1 (202) 992 1702</phone>
<email > rfc.editor@coresecret.eu</email>
@@ -51,7 +50,6 @@
<keyword > CATALOG</keyword>
<keyword > CT</keyword>
<keyword > CT-Log</keyword>
<keyword > DNS</keyword>
<keyword > Log</keyword>
<keyword > RR</keyword>
<keyword > URI-Binding</keyword>
@@ -89,23 +87,10 @@
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>
<dl newline= "true" >
<dt > The list of current Internet-Drafts can be accessed in plain text at:</dt>
<dd >
<eref target= "https://www.ietf.org/1id-abstracts.html" > https://www.ietf.org/1id-abstracts.html</eref>
</dd>
<dt > The list of current Internet-Drafts can also be accessed at:</dt>
<dd >
<eref target= "https://datatracker.ietf.org/drafts/current/" > https://datatracker.ietf.org/drafts/current/
7A83 41E5 F157 0319 D80F 4418 A11E 8851 9A3D 8CF6
</eref>
</dd >
<dt > The list of Internet-Draft Shadow Directories can be accessed at: </d t>
<dd >
<eref target= "https://www.ietf.org/shadow.html" > https://www.ietf.org/shadow.html</eref>
</dd>
</dl>
<xref target= "URI2" format= "none" > [2]</xref >.
</t>
</note>
</front>
@@ -114,26 +99,39 @@
<name > Introduction</name>
<section >
<name > Certification Authority Authorization</name>
<t > Certification Authority Authorization (CAA) <xref target= "RFC8659" /> RRs empower domain owners
<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.
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
(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.
<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= "RFC91 62" /> (which obsoletes RFC6962),
<t > Furthermore, Certificate Transparency (CT) Version 1
<xref target= "RFC6 962" />
(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>
@@ -160,7 +158,8 @@
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" />
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
@@ -178,17 +177,22 @@
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
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>
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>
<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>
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,
@@ -214,7 +218,8 @@
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" />
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.< domain> /.well-known/caa-ct-sts.txt</em> ",
contains structured rules in a canonical key:value format.
@@ -229,7 +234,8 @@
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).
<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
@@ -250,8 +256,11 @@
<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,
<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>
@@ -407,7 +416,8 @@
<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" />
<xref target= "RFC8659" /> , and
<xref target= "RFC8657" />
when and only when <strong > NOT</strong> stated
otherwise.
</t>
@@ -420,7 +430,8 @@
<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 > 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
@@ -431,10 +442,14 @@
</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>
<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" /> .
@@ -447,11 +462,11 @@
<name > CAA "issuect" Property Tag ABNF Syntax</name>
<sourcecode type= "abnf" markers= "false" >
<![CDATA[
ALPHA = %x41-5A / %x61-7A ; A– –
DIGIT = %x30-39 ; 0–
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– – –
HEXDIG = DIGIT / %x41-46 / %x61-66 ; 0- 9 / A- F / a- f
issuect-property = "issuect" SP DQUOTE issuect-value DQUOTE
@@ -507,7 +522,9 @@ b64-string = 1*( b64-char / "=" )
<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>
<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>
@@ -528,7 +545,8 @@ b64-string = 1*( b64-char / "=" )
<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>
<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>
@@ -540,7 +558,9 @@ b64-string = 1*( b64-char / "=" )
<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 – – – ("/"), or hyphen ("-").</dd>
<dd > : A single character drawn from uppercase and lowercase letters (A - Z, a- z), digits (0- 9), plus ("+"), slash
("/"), or hyphen ("-").
</dd>
</dl>
</section>
@@ -558,35 +578,50 @@ issuect "<issuer-domain>; <critical>; <description>; <validfrom>; <validtill>; <
</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 > 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 > 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 > 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.
<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>
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>
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>
<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 >
@@ -597,14 +632,22 @@ issuect "<issuer-domain>; <critical>; <description>; <validfrom>; <validtill>; <
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>
<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>
<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>
@@ -612,7 +655,10 @@ issuect "<issuer-domain>; <critical>; <description>; <validfrom>; <validtill>; <
<li > Syntax: critical=< true|false> ;</li>
</ul>
</li>
<li > <t > <strong > desc</strong> </t>
<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>
@@ -620,7 +666,10 @@ issuect "<issuer-domain>; <critical>; <description>; <validfrom>; <validtill>; <
<li > Syntax: desc='< desc-text> ';</li>
</ul>
</li>
<li > <t > <strong > validfrom</strong> </t>
<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>
@@ -628,7 +677,10 @@ issuect "<issuer-domain>; <critical>; <description>; <validfrom>; <validtill>; <
<li > Syntax: validfrom=< YYYY-MM-DDThh:mm:ssZ> ;</li>
</ul>
</li>
<li > <t > <strong > validtill</strong> </t>
<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>
@@ -636,23 +688,35 @@ issuect "<issuer-domain>; <critical>; <description>; <validfrom>; <validtill>; <
<li > Syntax: validtill=< YYYY-MM-DDThh:mm:ssZ> ;</li>
</ul>
</li>
<li > <t > <strong > cturi</strong> </t>
<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 > Value: any URI conforming to<xref target= "RFC3986" /> , with hostnames in lowercase
</li>
<li > Syntax: cturi=< absolute-URI> ;</li>
</ul>
</li>
<li > <t > <strong > logid</strong> </t>
<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 > Value: Base64-encoded SHA-256 hash of the CT-Log's DER-encoded SubjectPublicKeyInfo, enclosed in single
quotes
</li>
<li > Syntax: logid='< BASE64-SHA256> ';</li>
</ul>
</li>
<li > <t > <strong > key</strong> </t>
<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>
@@ -697,7 +761,8 @@ issuect ";"
<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
<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.
@@ -707,7 +772,8 @@ issuect ";"
<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" >
(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
@@ -721,10 +787,12 @@ issuect ";"
</section>
<section >
<name > Prior to Issuing a Certificate</name>
<t > Before issuing a Certificate that certifies a domain, the Certification Authority <strong > MUST</strong>
<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" /> .
<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
@@ -742,7 +810,8 @@ issuect ";"
"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",
<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.
@@ -757,26 +826,38 @@ issuect ";"
<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>
<t > However, the following requirements <strong > MUST</strong> be met:
</t>
<ol type= "(%d)" >
<li > <t > <strong > ABNF Conformance</strong> </t>
<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>
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>
<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>
<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>
<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).
@@ -805,7 +886,7 @@ issuect ";"
</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–
<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>
@@ -815,7 +896,8 @@ issuect ";"
</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.
<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).
@@ -858,18 +940,24 @@ issuect-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
</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>
<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 > 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>
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.
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>
@@ -884,8 +972,8 @@ issuect-ext-value = 1*(%x21-3A / %x3C / %x3E-7E)
<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– –
DIGIT = %x30-39 ; 0–
ALPHA = %x41-5A / %x61-7A ; A- Z / a- z
DIGIT = %x30-39 ; 0- 9
SP = %x20 ; SPACE
DQUOTE = %x22 ; "
SEMICOLON = %x3B ; ";"
@@ -942,14 +1030,16 @@ WSP = *( SP / HTAB )
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>
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>
<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" >
@@ -982,7 +1072,8 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
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.
<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);
@@ -998,15 +1089,21 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
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 > 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>
<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>
<t > Lastly the Runtime Processing as described in
<xref target= "runtime_processing" />
is applicable, too.
</t>
</section>
</section>
</section>
@@ -1016,13 +1113,18 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
<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>
<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 >
<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>
@@ -1054,13 +1156,18 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
<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>
<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" >
W ell-K nown URIs</eref >
<li > URI:
<eref target= "https://www.iana.org/assignments/w ell-k nown-uris/well-known-uris.xhtml"
Well-Known URIs
</eref>
<xref target= "URI9" format= "none" > [9]</xref> .
</li>
</ul>
@@ -1092,7 +1199,10 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
<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>
<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>
@@ -1167,14 +1277,20 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
<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>
<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>
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
@@ -1198,29 +1314,36 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
</t>
<section anchor= "dnssec_fallback" >
<name > CAs Preferred Proposed Validation Path</name>
<t > The <strong > RECOMMENDED</strong> multi-stage retrieval process is:</t>
<t > The <strong > RECOMMENDED</strong> multi-stage retrieval process is:
</t>
<ol >
<li > <strong > DNSSEC-first:</strong>
<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>
<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.< domain> /.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>
<li >
<strong > IP-only HTTPS (slow-path):</strong>
If step 2 fails, explicitly fetch the A/AAAA record for
"caa-ct-sts.< domain> ", then open a TLS connection by IP address
(SNI still "caa-ct-sts.< domain> ")
to retrieve the same policy file.
</li>
<li > <strong > Insecure DNS with ODoH:</strong>
<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
Oblivious DoH (ODoH)
<xref target= "RFC9230" />
transport to obscure queries
from on-path attackers.
</li>
</ol>
@@ -1271,7 +1394,8 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
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>
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.
@@ -1281,13 +1405,15 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
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>
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>
(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.
@@ -1330,7 +1456,8 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
out-of-band binding to the X.509 chain:
</t>
<ol >
<li > <t > TLSA Usage</t>
<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>
@@ -1342,7 +1469,8 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
used by the policy host, preventing MITM.
</t>
</li>
<li > <t > SVCB / HTTPS Record</t>
<li >
<t > SVCB / HTTPS Record</t>
<t > One can define a SVCB (or HTTPS) DNS RR for "caa-ct-sts.< domain> ",
advertising support for HTTP/3 (QUIC)
and pointing to the same IP addresses as the A/AAAA records.
@@ -1350,13 +1478,15 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
and connection resilience.
</t>
</li>
<li > <t > Strict TLS Configuration</t>
<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>
<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:
@@ -1397,7 +1527,8 @@ ct_policy: ( "example.ca; \
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>
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>
@@ -1416,7 +1547,8 @@ ct_policy: ( "example.ca; \
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>
<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)
@@ -1428,7 +1560,8 @@ ct_policy: ( "example.ca; \
<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 > 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
@@ -1437,10 +1570,12 @@ ct_policy: ( "example.ca; \
</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 > 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>
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>
@@ -1497,9 +1632,10 @@ ct_policy: ( "example.ca; \
<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 – </title>
<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>
<organization > International Telecommunication Union, Telecommunication Standardization Sector (ITU-T)
</organization>
</author>
<date month= "June" year= "2021" />
</front>
@@ -1507,9 +1643,12 @@ ct_policy: ( "example.ca; \
</reference>
<reference anchor= "X.690" target= "https://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf" >
<front >
<title > Information technology – Rules</title>
<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>
<organization > International Telecommunication Union, Telecommunication Standardization Sector (ITU-T)
</organization>
</author>
<date month= "July" year= "2021" />
</front>
@@ -1520,7 +1659,7 @@ ct_policy: ( "example.ca; \
<name > Informative References</name>
<reference anchor= "POSIX" target= "https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/" >
<front >
<title > Portable Operating System Interface (POSIX™) – </title>
<title > Portable Operating System Interface (POSIX™) - Base Specifications</title>
<author >
<organization > The Institute of Electrical and Electronics Engineers; The Open Group</organization>
</author>
@@ -1553,7 +1692,8 @@ ct_policy: ( "example.ca; \
</front>
</reference>
<reference anchor= "URI2" target= "https://keys.openpgp.org/vks/v1/by-fingerprint/7A8341E5F1570319D80F4418A11E88519A3D8CF6" >
<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 />
@@ -1616,27 +1756,40 @@ ct_policy: ( "example.ca; \
<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>
<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
<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>
<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>
<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– </li>
<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>
<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,
@@ -1644,7 +1797,10 @@ ct_policy: ( "example.ca; \
</li>
</ul>
</li>
<li > <t > <strong > Parse and Validate issuect Parameters</strong> </t>
<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>
@@ -1657,18 +1813,26 @@ ct_policy: ( "example.ca; \
<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>
<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 > 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>
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>
<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).
@@ -1676,7 +1840,10 @@ ct_policy: ( "example.ca; \
<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>
<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,
@@ -2030,19 +2197,22 @@ echo "${JSON}" | awk -v OWN="${OWN_DOMAIN}" -v CA="${CAA_DOMAIN}" -v CRIT="${CRI
<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–
In case of compromise or mistakes a real time reaction is still possible.</t>
<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>
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>
while keeping query volume manageable.
</t>
</section>
</section>
<section anchor= "change_history" >
