V1.00.128.2025.06.03

Signed-off-by: Marc S. Weidner <msw@coresecret.dev>

README.md

@@ -42,7 +42,6 @@ Check out more:
 * [CenturionMeet](https://talk.e2ee.li/)
 * [Contact the author](https://coresecret.eu/contact/)
 
-
 ## 1.1. Preliminary Remarks
 
 ### 1.1.1. HSM

draft-weidner-catalog-rr-ext-00.rfc.xml

@@ -1,5 +1,4 @@
 <?xml version="1.0" encoding="utf-8"?>
-<?xml-model href="rfc7991bis.rnc"?>
 
 <!DOCTYPE rfc [
   <!ENTITY nbsp    "&#160;">
@@ -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>.
+          7A83 41E5 F157 0319 D80F 4418 A11E 8851 9A3D 8CF6
-            </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/
         </eref>
-                </dd>
+        <xref target="URI2" format="none">[2]</xref>.
-                <dt>The list of Internet-Draft Shadow Directories can be accessed at:</dt>
+      </t>
-                <dd>
-                    <eref target="https://www.ietf.org/shadow.html">https://www.ietf.org/shadow.html</eref>
-                </dd>
-            </dl>
     </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,
+          <xref target="RFC9495"/>
-                    "issuemail", to apply CAA controls to the issuance of S/MIME <xref target="RFC8551"/> Certificates.
+          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
+        <t>Furthermore, Certificate Transparency (CT) Version 1
-                    Certificate Transparency (CT) Version 2 <xref target="RFC9162"/> (which obsoletes RFC6962),
+          <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>
@@ -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.&lt;domain&gt;/.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
+          <strong>"OPTIONAL"</strong>
-                    BCP 14 <xref target="RFC2119"/>, <xref target="RFC8174"/> when, and only when,
+          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>"ALPHA"</strong>,
-                        <li><strong>"DIGIT"</strong>,</li>
+            </li>
-                        <li><strong>"DQUOTE"</strong>,</li>
+            <li><strong>"DIGIT"</strong>,
-                        <li><strong>"SP"</strong>, </li>
+            </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–Z / a–z
+ALPHA              = %x41-5A / %x61-7A           ; A-Z / a-z
-DIGIT              = %x30-39                     ; 0–9
+DIGIT              = %x30-39                     ; 0-9
 SP                 = %x20                        ; SPACE
 DQUOTE             = %x22                        ; "
-HEXDIG             = DIGIT / %x41-46 / %x61-66   ; 0–9 / A–F / a–f
+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 – Z, a–z), digits (0–9), plus ("+"), slash ("/"), 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 tag <strong>"issuect"</strong>
-                        <li>The complete property parameter set <strong>MUST</strong> be enclosed in double quotes.</li>
+              <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>All domain labels and hostnames <strong>MUST</strong> be in lowercase.
-                        <li>The value of the "critical" flag <strong>MUST</strong> be either "true" or "false".</li>
+            </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>
+              of the CT-Log itself.
-                        <li>A trailing semicolon <strong>MUST</strong> follow the "pubkey" parameter.</li>
+            </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>Timestamps are according to<xref target="ISO-8601"/>.
-                        <li>BASE64-encoding is according to <xref target="RFC4648"/>.</li>
+            </li>
-                        <li>SHA256-hash is according to <xref target="RFC6234"/>.</li>
+            <li>BASE64-encoding is according to<xref target="RFC4648"/>.
-                        <li>DER-encoding is according to <xref target="X.690"/>.</li>
+            </li>
-                        <li>ASN.1-format is according to <xref target="X.680"/>.</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>
+            <li>
-                            <t>The authorized Certification Authority's domain name, in LDH notation (ASCII letters, digits, hyphens), as defined in Section 3.1.</t>
+              <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=&lt;true|false&gt;;</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='&lt;desc-text&gt;';</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=&lt;YYYY-MM-DDThh:mm:ssZ&gt;;</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=&lt;YYYY-MM-DDThh:mm:ssZ&gt;;</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=&lt;absolute-URI&gt;;</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='&lt;BASE64-SHA256&gt;';</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–32 alphanumeric chars) used to signal updates.
+            <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:
+              defined in
-                            <xref target="caa_ct_sts_policy_examples"/> for examples.
+              <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–Z / a–z
+ALPHA              = %x41-5A / %x61-7A      ; A-Z / a-z
-DIGIT              = %x30-39                ; 0–9
+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>The "version" field <strong>MUST</strong> equal "CAACTSTSv1",
-                        <li>While "max_age" <strong>MUST</strong> be a valid non-negative integer,</li>
+            </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">
+          <li>URI:
-                    Public Key Infrastructure using X.509 (PKIX) Parameters</eref>
+            <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">
+          <li>URI:
-                        Well-Known URIs</eref>
+            <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>
@@ -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 framework<xref target="RFC8659"/>,
-                <li>CAA Record Extensions for Account URI and (ACME) Binding <xref target="RFC8657"/>,</li>
+        </li>
-                <li>Certificate Transparency Version 2.0. <xref target="RFC9162"/>,</li>
+        <li>CAA Record Extensions for Account URI and (ACME) Binding<xref target="RFC8657"/>,
-                <li>ACME protocol <xref target="RFC8555"/>,</li>
+        </li>
-                <li>SMTP MTA Strict Transport Security (MTA-STS) <xref target="RFC8461"/>.</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.&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>
+            <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>
+            <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.&lt;domain&gt;",
               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 – Abstract Syntax Notation One (ASN.1): Specification of basic notation</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 – ASN.1 encoding rules: Specification of Basic, Canonical, and Distinguished Encoding 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™) – Base Specifications</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–2 for each domain name.</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–300 s).
+        <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>
+          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">