Compare commits

..

5 Commits

Author SHA256 Message Date
e0905e1f7c 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
2025-06-06 17:04:41 +00:00
47b20f7d35 DEPLOY BOT: 🛡️ Shell Script Linting [skip ci]
X-CI-Metadata: master@db1d923 at 2025-06-06T17:04:36Z on d4464d0bcd9c

Generated at: 2025-06-06T17:04:36Z
Runner Host : d4464d0bcd9c
Workflow ID : 🛡️ Shell Script Linting
Git Commit  : db1d923 HEAD -> master
2025-06-06 17:04:36 +00:00
db1d92322b V1.01.192.2025.06.06
All checks were successful
🛡️ Shell Script Linting / 🛡️ Shell Script Linting (push) Successful in 1m2s
🔁 Render RFCXML to PDF. / 🔁 Render RFCXML to PDF. (push) Successful in 1m7s
Signed-off-by: Marc S. Weidner <msw@coresecret.dev>
2025-06-06 19:03:26 +02:00
b3d0c169cf DEPLOY BOT: 🔁 Auto-Generate PDFs from *.rfc.xml. [skip ci]
X-CI-Metadata: master@14efc28 at 2025-06-06T16:43:05Z on 4b8ab6837309

Generated at: 2025-06-06T16:43:05Z
Runner Host : 4b8ab6837309
Workflow ID : 🔁 Render RFCXML to PDF.
Git Commit  : 14efc28 HEAD → master
2025-06-06 16:43:05 +00:00
14efc280b7 DEPLOY BOT: 🛡️ Shell Script Linting [skip ci]
X-CI-Metadata: master@4670708 at 2025-06-06T16:42:00Z on 316d44da4b19

Generated at: 2025-06-06T16:42:00Z
Runner Host : 316d44da4b19
Workflow ID : 🛡️ Shell Script Linting
Git Commit  : 4670708 HEAD -> master
2025-06-06 16:42:00 +00:00
5 changed files with 42 additions and 42 deletions

View File

@@ -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

Binary file not shown.

View File

@@ -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.
@@ -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>
@@ -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">