DEPLOY BOT: 🔁 Auto-Generate PDFs from *.rfc.xml. [skip ci]

X-CI-Metadata: master@47b20f7 at 2025-06-06T17:04:41Z on be9158e29fc7

Generated at: 2025-06-06T17:04:41Z
Runner Host : be9158e29fc7
Workflow ID : 🔁 Render RFCXML to PDF.
Git Commit  : 47b20f7 HEAD → master

.gitea/workflows/linter_char_scripts.yaml

@@ -127,14 +127,16 @@ jobs:
           #
           # We capture:
           # - All files '*.sh', '*.rfc.xml'
-          # - All files whose first line begins with “#!” (shebang)
+          # - All files whose first line begins with "#!" (shebang)
           # -------------------------------
           mapfile -t files_to_check < <(
-            find . -type f \( \
-              -iname '*.sh' -o \
-              -iname '*.rfc.xml' -o \
-              -exec grep -Iq '^#!' {} \; \
-            \) -print
+            find . \
+              -path './.git' -prune -o \
+              -type f \( \
+                -iname '*.sh' -o \
+                -iname '*.rfc.xml' -o \
+                -exec grep -Iq '^#!' {} \; \
+              \) -print
           )
 
           # -------------------------------

LINTER_RESULTS.txt

@@ -1,5 +1,5 @@
 # SPDX-Version: 3.0
-# SPDX-CreationInfo: 2025-06-06; WEIDNER, Marc S.; <msw@coresecret.dev>
+# SPDX-CreationInfo: 2025-06-05; WEIDNER, Marc S.; <msw@coresecret.dev>
 # SPDX-ExternalRef: GIT https://git.coresecret.dev/msw/CISS.debian.live.builder.git
 # SPDX-FileContributor: WEIDNER, Marc S.; Centurion Intelligence Consulting Agency
 # SPDX-FileCopyrightText: 2024-2025; WEIDNER, Marc S.; <msw@coresecret.dev>
@@ -9,8 +9,8 @@
 # SPDX-PackageName: CISS.debian.live.builder
 # SPDX-Security-Contact: security@coresecret.eu
 
-This file was automatically generated by the DEPLOY BOT on: "2025-06-06T16:18:43Z".
+This file was automatically generated by the DEPLOY BOT on: "2025-06-06T17:04:33Z".
 
-⚠️ The last linter check was NOT successful. ⚠️
+✅ The last linter check was successful. ✅
 
 # vim: number et ts=2 sw=2 sts=2 ai tw=128 ft=text

docs/graphviz/ciss.developer.branch.dot

@@ -138,15 +138,15 @@ digraph CISS_debian_live_builder {
     // Jump Host → Hidden-Master
     Jump_Host -> Hidden_Master [color=green];
 
-    // Hidden-Master → Name servers (each green with the label “HMAC SHA512”)
+    // Hidden-Master → Name servers (each green with the label "HMAC SHA512")
     Hidden_Master -> ns00 [color=green, label="HMAC SHA512"];
     Hidden_Master -> ns01 [color=green, label="HMAC SHA512"];
     Hidden_Master -> ns02 [color=green, label="HMAC SHA512"];
     Hidden_Master -> ns03 [color=green, label="HMAC SHA512"];
 
-    // Red arrows “DNSSEC” from name server cluster (ns_anchor) → B cluster (b_big_anchor)
+    // Red arrows "DNSSEC" from name server cluster (ns_anchor) → B cluster (b_big_anchor)
     ns_anchor -> b_big_anchor [color=red, label="DNSSEC"];
-    // Red arrow “DNSSEC” from nameserver cluster (ns_anchor) → cloud cluster (cloud_anchor)
+    // Red arrow "DNSSEC" from nameserver cluster (ns_anchor) → cloud cluster (cloud_anchor)
     ns_anchor -> cloud_anchor [color=red, label="DNSSEC"];
 
     // Red arrows from TLS Internet → B-Cluster and cloud

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

@@ -41,7 +41,7 @@
       </address>
     </author>
 
-    <date year="2025" month="06" day="03"/>
+    <date year="2025" month="06" day="06"/>
 
     <area>General</area>
     <workgroup>Internet Engineering Task Force</workgroup>
@@ -102,7 +102,7 @@
         <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
+          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.
@@ -212,11 +212,11 @@
         </section>
         <section>
           <name>CAA Certificate Transparency Strict Transport Security (CAA-CT-STS)</name>
-          <t>CAA-CT-STS,<xref target="caa_ct_sts"/>, is a policy framework
+          <t>CAA-CT-STS, <xref target="caa_ct_sts"/>, is a policy framework
             that combines the mechanisms of CAA, CT, and MTA-STS
             by which a domain holder can publish Certificate-Transparency enforcement
             requirements alongside CA Authorization (CAA) over a second secured channel.
-            It mirrors the approach of SMTP MTA-STS<xref target="RFC8461"/>, using DNS TXT RR, a specific
+            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"/>
@@ -230,19 +230,19 @@
         </section>
         <section>
           <name>Operational discussions</name>
-          <t>Lastly, practical aspects such as a CA Processing Checklist,<xref target="caa_processing_checklist"/>,
-            caching behavior<xref target="dns_ttl"/>, and fallback,<xref target="dnssec_fallback"/>,
+          <t>Lastly, practical aspects such as a CA Processing Checklist, <xref target="caa_processing_checklist"/>,
+            caching behavior <xref target="dns_ttl"/>, and fallback, <xref target="dnssec_fallback"/>,
             strategies for non-DNSSEC zones are addressed.
             Throughout this document, the framework is referred to by the recursive acronym
             <strong>CATALOG</strong>
             (CATALOG Authorization Transparency And Log Overlay for Graph-based DNS).
           </t>
           <t>The following sections specify the complete syntax and semantics of both of the
-            CAA <strong>"issuect"</strong> Property Tag,<xref target="caa_property"/>, and
-            CAA-CT-STS framework,<xref target="caa_ct_sts"/>,
+            CAA <strong>"issuect"</strong> Property Tag, <xref target="caa_property"/>, and
+            CAA-CT-STS framework, <xref target="caa_ct_sts"/>,
             detail processing rules for CAs and resolvers for both of the
-            CAA <strong>"issuect"</strong> Property Tag,<xref target="issuect_processing"/>, and
-            CAA-CT-STS,<xref target="caa_ct_sts_processing"/>, framework.
+            CAA <strong>"issuect"</strong> Property Tag, <xref target="issuect_processing"/>, and
+            CAA-CT-STS, <xref target="caa_ct_sts_processing"/>, framework.
           </t>
         </section>
       </section>
@@ -258,7 +258,7 @@
           <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"/>,
+          BCP 14 <xref target="RFC2119"/>,
           <xref target="RFC8174"/>
           when, and only when,
           they appear in all capitals, as shown here.
@@ -281,7 +281,7 @@
               <td align="left">Certification Authority Authorization</td>
               <td align="left">Allows a DNS domain name holder to specify one or more CAs authorized to issue
                 Certificates for that domain name.
-                See:<xref target="RFC8657"/>,<xref target="RFC8659"/>.
+                See: <xref target="RFC8657"/>, <xref target="RFC8659"/>.
               </td>
             </tr>
             <tr>
@@ -289,7 +289,7 @@
               <td align="left">CAA Certificate Transparency Strict Transport Security</td>
               <td align="left">CAA-CT-STS is a policy framework, by which a domain holder can publish
                 Certificate-Transparency enforcement requirements alongside CA authorization (CAA).
-                See:<xref target="caa_ct_sts"/>.
+                See: <xref target="caa_ct_sts"/>.
               </td>
             </tr>
             <tr>
@@ -297,7 +297,7 @@
               <td align="left">CAA-CT-STS Policy File</td>
               <td align="left">The set of rules fetched via HTTPS from the Policy Domains
                 "/.well-known/caa-ct-sts.txt".
-                See:<xref target="caa_ct_sts_policy"/>.
+                See: <xref target="caa_ct_sts_policy"/>.
               </td>
             </tr>
             <tr>
@@ -305,7 +305,7 @@
               <td align="left">CATALOG Authorization Transparency And Log Overlay for Graph-based DNS</td>
               <td align="left">A Proposal to enrich DNS-based CAA RRs with Certificate Transparency URI
                 bindings.
-                This document:<xref target="URI1"/>.
+                This document: <xref target="URI1"/>.
               </td>
             </tr>
             <tr>
@@ -323,7 +323,7 @@
               <td align="left">CP</td>
               <td align="left">Certificate Policy</td>
               <td align="left">Specifies the criteria that a CA undertakes to meet in its issue of Certificates.
-                See:<xref target="RFC3647"/>.
+                See: <xref target="RFC3647"/>.
               </td>
             </tr>
             <tr>
@@ -331,7 +331,7 @@
               <td align="left">Certification Practices Statement</td>
               <td align="left">Specifies the means by which the criteria of the CP are met.
                 In most cases, this will be the document against which the operations of the CA are audited.
-                See:<xref target="RFC3647"/>.
+                See: <xref target="RFC3647"/>.
               </td>
             </tr>
             <tr>
@@ -339,7 +339,7 @@
               <td align="left">Certification Transparency</td>
               <td align="left">Certificate Transparency aims to mitigate the problem of misissued Certificates by
                 providing append-only logs of issued Certificates.
-                See:<xref target="RFC6962"/>,<xref target="RFC9162"/>.
+                See: <xref target="RFC6962"/>,<xref target="RFC9162"/>.
               </td>
             </tr>
             <tr>
@@ -362,14 +362,14 @@
                 <xref target="RFC5246"/>
                 or Datagram Transport Layer Security (DTLS)
                 <xref target="RFC6347"/>
-                transport endpoint. See:<xref target="RFC6698"/>,<xref target="RFC7671"/>.
+                transport endpoint. See: <xref target="RFC6698"/>,<xref target="RFC7671"/>.
               </td>
             </tr>
             <tr>
               <td align="left">DNS</td>
               <td align="left">Domain Name System</td>
               <td align="left">The Internet naming system specified in
-                <xref target="RFC1034"/>,<xref target="RFC1035"/>,<xref target="RFC9499"/>, and any
+                <xref target="RFC1034"/>, <xref target="RFC1035"/>, <xref target="RFC9499"/>, and any
                 revisions to these specifications.
               </td>
             </tr>
@@ -377,7 +377,7 @@
               <td align="left">DNSSEC</td>
               <td align="left">DNS Security Extensions</td>
               <td align="left">Extensions to the DNS that provide authentication services as specified in
-                <xref target="RFC4033"/>,<xref target="RFC4034"/>,<xref target="RFC4035"/>,
+                <xref target="RFC4033"/>, <xref target="RFC4034"/>, <xref target="RFC4035"/>,
                 <xref target="RFC5155"/>,
                 <xref target="RFC9364"/>, and any revisions to these specifications.
               </td>
@@ -407,7 +407,7 @@
               <td align="left">DNS Resource Record</td>
               <td align="left">A particular entry in the DNS, including the owner name, class, type, time to live,
                 and data, as defined in
-                <xref target="RFC1034"/>,<xref target="RFC2181"/>.
+                <xref target="RFC1034"/>, <xref target="RFC2181"/>.
               </td>
             </tr>
           </tbody>
@@ -456,7 +456,7 @@
           </t>
           <t>In addition, <strong>absolute-URI</strong> is defined in
             <eref target="https://www.rfc-editor.org/rfc/rfc3986.html#section-4.3">Section 4.3</eref>
-            of<xref target="RFC3986"/>.
+            of <xref target="RFC3986"/>.
           </t>
           <figure>
             <name>CAA "issuect" Property Tag ABNF Syntax</name>
@@ -545,7 +545,7 @@ 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>: An absolute URI as defined by <xref target="RFC3986"/>.
             </dd>
 
             <dt>logid-param</dt>
@@ -612,15 +612,15 @@ issuect "<issuer-domain>; <critical>; <description>; <validfrom>; <validtill>; <
           </ol>
           <t>Whereas</t>
           <ul spacing="normal" empty="false" indent="2" bare="false">
-            <li>Timestamps are according to<xref target="ISO-8601"/>.
+            <li>Timestamps are according to <xref target="ISO-8601"/>.
             </li>
-            <li>BASE64-encoding is according to<xref target="RFC4648"/>.
+            <li>BASE64-encoding is according to <xref target="RFC4648"/>.
             </li>
-            <li>SHA256-hash is according to<xref target="RFC6234"/>.
+            <li>SHA256-hash is according to <xref target="RFC6234"/>.
             </li>
-            <li>DER-encoding is according to<xref target="X.690"/>.
+            <li>DER-encoding is according to <xref target="X.690"/>.
             </li>
-            <li>ASN.1-format is according to<xref target="X.680"/>.
+            <li>ASN.1-format is according to <xref target="X.680"/>.
             </li>
           </ul>
         </section>
@@ -792,7 +792,7 @@ issuect ";"
             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"/>.
+            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
@@ -804,7 +804,7 @@ issuect ";"
 
             The presence of an <strong>"issuect"</strong> Property <strong>MUST NOT</strong> replace or supersede
             the required validation of the domain name as specified by the "issue" or "issuewild" Properties in the
-            CAA RRSet, as outlined in the CAA specification<xref target="RFC8659"/>.
+            CAA RRSet, as outlined in the CAA specification <xref target="RFC8659"/>.
 
             Certification Authorities <strong>MUST</strong> still validate authorization according to the CAA
             "issue" and / or "issuewild" policies.
@@ -1068,7 +1068,7 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
             After fetching, Certification Authorities parse the file as above.
 
             If the HTTP request fails for whatever reason,
-            (network error, invalid cert, status ≠ 200, or parse error),
+            (network error, invalid cert, status != 200, or parse error),
             the policy is considered unavailable or invalid, and Certification Authorities fall back to "no policy".
 
             HTTP 3xx redirects <strong>MUST NOT</strong> be followed, and HTTP caching
@@ -1277,19 +1277,19 @@ 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>CAA framework <xref target="RFC8659"/>,
         </li>
-        <li>CAA Record Extensions for Account URI and (ACME) Binding<xref target="RFC8657"/>,
+        <li>CAA Record Extensions for Account URI and (ACME) Binding <xref target="RFC8657"/>,
         </li>
-        <li>Certificate Transparency Version 2.0.<xref target="RFC9162"/>,
+        <li>Certificate Transparency Version 2.0. <xref target="RFC9162"/>,
         </li>
-        <li>ACME protocol<xref target="RFC8555"/>,
+        <li>ACME protocol <xref target="RFC8555"/>,
         </li>
-        <li>SMTP MTA Strict Transport Security (MTA-STS)<xref target="RFC8461"/>.
+        <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"/>.
+        Internet threat model defined by <xref target="RFC3552"/>.
       </t>
       <section>
         <name>Global considerations</name>
@@ -1377,7 +1377,7 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
         <name>Policy Redundancy Considerations</name>
         <t>Let c be the number of critical CT-Logs and w be the number of whitelisted (non-critical) CT-Logs,
           then the following expression is strongly <strong>RECOMMENDED</strong>:
-          |c| ≥ n + 1 ∧ |w| ≤ 2
+          |c| >= n + 1 ^ |w| &lt;= 2
         </t>
         <t>While the "critical=true" flag in the CAA <strong>"issuect"</strong> Parameter enforces that every
           Certificate issuance must be logged to all specified CT-Logs, this strict requirement can introduce
@@ -1399,7 +1399,7 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
           <li>"+ 2" Whitelist of Non-Critical CT-Logs.
             In addition to the n + 1 critical logs, domain owners <strong>SHOULD</strong> nominate at least
             up to two further CT-Logs without the "critical=true" flag.
-            These “whitelisted” CT-Logs provide extra transparency channels,
+            These "whitelisted" CT-Logs provide extra transparency channels,
             enabling issuance to continue if a critical CT-Log fails,
             but do not block issuance if they are unreachable.
             They <strong>MUST NOT</strong> not carry "critical=true"; otherwise,
@@ -1459,10 +1459,10 @@ https://caa-ct-sts.<domain>.<tld>/.well-known/caa-ct-sts.txt
           <li>
             <t>TLSA Usage</t>
             <ul>
-              <li>3 1 1 — SHA-256 hash of the leaf certificate's SPKI</li>
-              <li>3 1 2 — SHA-512 hash of the leaf certificate's SPKI</li>
-              <li>2 1 1 — SHA-256 hash of the issuing intermediate certificate's SPKI</li>
-              <li>2 1 2 — SHA-512 hash of the issuing intermediate certificate's SPKI</li>
+              <li>3 1 1 - SHA-256 hash of the leaf certificate's SPKI</li>
+              <li>3 1 2 - SHA-512 hash of the leaf certificate's SPKI</li>
+              <li>2 1 1 - SHA-256 hash of the issuing intermediate certificate's SPKI</li>
+              <li>2 1 2 - SHA-512 hash of the issuing intermediate certificate's SPKI</li>
             </ul>
             <t>Here, TLSA-usage 3 (DANE-EE) and 2 (DANE-TA), selector 1 (SPKI), and matching
               types 1 (SHA-256) and 2 (SHA-512) ensure that CAs validate the exact certificates
@@ -1600,7 +1600,7 @@ ct_policy: ( "example.ca; \
         <name>Normative References</name>
         <reference anchor="ISO-8601" target="https://www.iso.org/standard/70907.html">
           <front>
-            <title>Date and time — Representations for information interchange</title>
+            <title>Date and time - Representations for information interchange</title>
             <author>
               <organization>International Organization for Standardization</organization>
             </author>
@@ -1659,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>
@@ -1685,7 +1685,7 @@ ct_policy: ( "example.ca; \
       </references>
       <references>
         <name>URI</name>
-        <reference anchor="URI1" target="https://coresecret.dev/msw/draft-weidner-catalog-rr-ext.git">
+        <reference anchor="URI1" target="https://git.coresecret.dev/msw/draft-weidner-catalog-rr-ext">
           <front>
             <title>This document</title>
             <author/>
@@ -1863,7 +1863,7 @@ ct_policy: ( "example.ca; \
           Their BIND file notation format is defined in<xref target="RFC1035"/>.
           Parentheses are used to ignore a line break in DNS zone-file presentation format, as per
           <eref target="https://rfc-editor.org/rfc/rfc1035#section-5.1">Section 5.1</eref>
-          of<xref target="RFC1035"/>.
+          of <xref target="RFC1035"/>.
         </t>
       </section>
       <section anchor="comprehensive_example">