CATALOG Authorization Transparency And Log Overlay for Graph-based DNS

2.1. Keywords

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119], [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

2.2. Abbreviations and Definitions

2.3. CAA Syntax conformity

All syntax introduced in this draft is strictly in accordance with the CAA RR framework defined in [RFC8659], and [RFC8657] when and only when NOT stated otherwise.¶

3.1. CAA "issuect" Property Tag Definitions

ALPHA              = %x41-5A / %x61-7A           ; A-Z / a-z
DIGIT              = %x30-39                     ; 0-9
SP                 = %x20                        ; SPACE
DQUOTE             = %x22                        ; "
HEXDIG             = DIGIT / %x41-46 / %x61-66   ; 0-9 / A-F / a-f

issuect-property   = "issuect" SP DQUOTE issuect-value DQUOTE

issuect-value      = issuer-domain-name ";" SP
                     critical-param ";" SP
                     desc-param ";" SP
                     validfrom-param ";" SP
                     validtill-param ";" SP
                     cturi-param ";" SP
                     logid-param ";" SP
                     pubkey-param ";"

issuer-domain-name = label *("." label)
label              = (ALPHA / DIGIT) *( *("-") (ALPHA / DIGIT) )

critical-param     = "critical" "=" ( "true" / "false" )

desc-param         = "desc" "=" "'" desc-text "'"
desc-text          = *( %x20-26 / %x28-7E )      ; printable ASCII without: '

validfrom-param    = "validfrom" "=" date-time
validtill-param    = "validtill" "=" date-time

date-time          = date "T" time "Z"
date               = 4DIGIT "-" 2DIGIT "-" 2DIGIT
time               = 2DIGIT ":" 2DIGIT ":" 2DIGIT

cturi-param        = "cturi" "=" uri
uri                = absolute-URI

logid-param        = "logid" "=" "'" b64-string "'"

pubkey-param       = "pubkey" "=" "'" b64-string "'"

b64-char           = ALPHA / DIGIT / "+" / "/"
b64-string         = 1*( b64-char / "=" )

issuect "<issuer-domain>; <critical>; <description>; <validfrom>; <validtill>; <uri>; <logid>; <pubkey>;"

issuect ";"

5.1. IANA registration CAA Property Tag "issuect"

The following IANA registration is requested.¶

According to [RFC8126] these information are provided:¶

• Registry: Certification Authority Restriction Properties.¶
• Registry Group: Public Key Infrastructure using X.509 (PKIX) Parameters.¶
• Expert Contact: Mr. Phillip Hallam-Baker (at time of writing).¶
• URI: Public Key Infrastructure using X.509 (PKIX) Parameters [8].¶

IANA is asked to assign the property tag "issuect" to this subregistry, documenting its name, ABNF syntax, and reference to this specification.¶

5.2. Well-Known URIs Registry

The following IANA registration is requested.¶

According to [RFC8126] these information are provided:¶

• Registry: Well-Known URIs¶
• Registry Group: Well-Known URIs.¶
• Expert Contact: Mr. Mark Nottingham (at time of writing).¶
• URI: Well-Known URIs [9].¶

IANA is asked to assign the "well-known" URI Suffix "caa-ct-sts.txt" to this registry, whose Change Controller is: IETF¶

5.3. CAA-CT-STS Strict Transport Security Registry Creation

The following IANA "Registry" registration is requested.¶

According to [RFC8126] these information are provided:¶

• Registry: CAA-CT-STS Strict Transport Security (CAA-CT-STS) [to be created]¶
• Subregistry: CAA-CT-STS TXT Record Fields [to be created]¶
• Subregistry: CAA-CT-STS TXT Policy Fields [to be created]¶
• Expert Contact: (tba).¶

IANA is asked to create the before mentioned Registry.¶

6.1. Global considerations

This specification augments the CAA RR framework by introducing finer-grained controls over both Certificate issuance and CT-Log submission. Domain owners can now explicitly authorize which CAs may issue Certificates and which CT-Log operators must or may record those Certificates. When used in tandem with compliant CAs and CT-Log operators, "issuect" significantly strengthens the issuance security posture for domains that opt in.¶

Using "critical=true" ensures that no Certificate is ever issued without logging to the specified CT-Log endpoints, preventing accidental or malicious bypass of transparency requirements.¶

By co-locating CT-Log authorization data within DNSSEC-protected CAA RRs, this extension also reduces reliance on out-of-band lists and third-party dependencies, thereby minimizing attack surface and improving resilience against CT-Log Operator compromise.¶

To further harden CAA "issuect" Policy discovery and protect against DNS manipulation, CAs SHOULD implement a CAA-CT-STS HTTPS fallback mechanism. This provides a second, TLS-authenticated channel for retrieving CAA "issuect" Policies directly from the domain owner.¶

6.4. Scope Limited to CAs and CT-Log Operators Processing CAA RRs

This extension empowers domain owners, who already maintain relationships with compliant CAs and CT-Log operators, to impose additional constraints on both Certificate issuance and log submission, provided those parties implement the "issuect" mechanism. It does not strengthen guarantees for any CA or CT-Log operator that does not support this extension: non-conforming entities retain their existing ability to issue Certificates or submit log entries regardless of "issuect" policy. Consequently, domains that authorize only participating CAs and CT-Log operators remain vulnerable to unauthorized issuance or logging by entities that ignore or merely advise upon CAA RRs. Even in DNSSEC-protected zones, the risk of misissuance persists if a CA or CT-Log operator fails to validate CAA RRs via a trusted, DNSSEC-validating resolver.¶

6.5. Additional CAA-CT-STS Security Considerations

When a domain owner already employs DNSSEC, it is RECOMMENDED, that the HTTPS endpoint serving the CAA-CT-STS Policy be further bound via DANE/TLSA records. By publishing TLSA RR for both leaf and intermediate certificates, CAs retrieving "/.well-known/caa-ct-sts.txt" gain an additional multipath validation and out-of-band binding to the X.509 chain:¶

1. TLSA Usage¶

   • 3 1 1 — SHA-256 hash of the leaf certificate's SPKI¶
   • 3 1 2 — SHA-512 hash of the leaf certificate's SPKI¶
   • 2 1 1 — SHA-256 hash of the issuing intermediate certificate's SPKI¶
   • 2 1 2 — SHA-512 hash of the issuing intermediate certificate's SPKI¶

   Here, TLSA-usage 3 (DANE-EE) and 2 (DANE-TA), selector 1 (SPKI), and matching types 1 (SHA-256) and 2 (SHA-512) ensure that CAs validate the exact certificates used by the policy host, preventing MITM.¶

2. SVCB / HTTPS Record¶

   One can define a SVCB (or HTTPS) DNS RR for "caa-ct-sts.<domain>", advertising support for HTTP/3 (QUIC) and pointing to the same IP addresses as the A/AAAA records. This allows CAs to connect over the most modern, UDP-based transport with built-in encryption and connection resilience.¶

3. Strict TLS Configuration¶

   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.¶

4. Optional DANE-Style Binding in the Policy File (NOT implemented in this draft)¶

   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:¶

   
   version: CAACTSTSv1
   max_age: 60
   kzk_id: 32768
   kzk_hash: 'MII(...)'
   ct_policy: ( "example.ca; \
     critical=true; \
     desc='Example Log FunnyNameNet 2025'; \
     validfrom=2025-01-01T00:00:00Z; \
     validtill=2026-01-01T00:00:00Z; \
     cturi=https://ct.example.net/logs/eu/funnynamenet2025; \
     logid='sh4(...)'; \
     pubkey='MFk(...)';" )
   
   

   Whereas "kzk_id" would be an integer identifier of the Key-Id of the KZK of the domain, and "kzk_hash" would be a Base64-encoded hash of the KZK of the domain. By combining DNSSEC-protected TLSA and in-CAA-CT-STS-Policy kzk_hash and kzk_id values, CAs gain cryptographic assurance of both the CAA-CT-STS Policy files authenticity and the CT-Log endpoints identity, further reducing the risk of policy-fetch or logging interception attacks.¶

6.6. Authorization Freshness

CAA allows a Certification Authority to pre-authorize an account, to request Certificates for a domain well before the actual issuance event. As a result, the CAA policy in effect at authorization time may differ from the policy published at issuance time. To mitigate this risk, CAs SHOULD adopt one or more of the following practices:¶

• Issue pre-authorizations with short validity intervals (for example, one hour).¶
• Re-validate the domain's current CAA policy immediately prior to certificate issuance.¶

By limiting the window during which stale authorizations remain valid and by re-checking CAA RRs at issuance time, CAs reduce the likelihood of complying with outdated or revoked policy statements.¶

6.7. Use with and without DNSSEC

The standard domain-validation model does not protect against an adversary capable of intercepting all traffic to a domain (a "global man-in-the-middle" [MITM] attack). Such an attacker can hijack validation requests from any CA and thus impersonate domain control. When a domain is DNSSEC-signed, and the CA resolves DNS exclusively via a trusted DNSSEC-validating resolver, however, the authenticity and integrity of DNS data are assured.¶

To leverage this protection, a CA's validation process SHOULD either:¶

• Rely solely on DNSSEC-authenticated DNS responses for all validation data; or¶
• Cryptographically bind every other validation channel (e.g., HTTP-01, TLS-ALPN-01) to material obtained via DNSSEC.¶

6.8. Scenario Effects for "issuect" and Security

DNSSEC-secured¶

• CAA and "issuect" RRs are authenticated.¶
• Any modification to these RRs is detected by DNSSEC validation failures.¶
• The CA can trust that CT-Log authorizations originate from the domain owner.¶
• Certificates cannot be issued "out of band," nor can CAA-driven CT-Log instructions be tampered with undetected.¶

Not DNSSEC-secured¶

• CAA and "issuect" RRs may be forged or suppressed.¶
• A CA relying on cached or unauthenticated responses risks seeing incorrect policies.¶
• An attacker could inject a false empty "issuect" ";" to disable logging, or point to malicious CT-Logs, subverting transparency.¶
• In extreme "SOA interception" scenarios, an attacker could entirely block certificate issuance by dropping CAA/A RRs.¶

6.9. Restrictions Supersedable by DNS Delegation

CAA RRs are discovered during validation by traversing up the DNS hierarchy until one or more RRs are located. Because of this lookup behavior, CAA RRs cannot reliably restrict or control Certificate issuance for subdomains whose DNS management has been delegated to another party (for example, via NS delegation or by granting limited DNS-editing rights for a subdomain).¶

C.1. CAA-CT-STS Policy File Example

The following example indicates that Certificates for the domain must be logged in:¶

• https://ct.example.net/logs/eu/funnynamenet2025¶
• https://ct.example.org/logs/eu/funnynameorg2025¶
• https://ct.example.sh/logs/eu/funnynamesh2025¶
• https://ct.example.xyz/logs/eu/funnynamexyz2025¶

version: CAACTSTSv1
max_age: 60
ct_policy: ( "example.ca; \
  critical=true; \
  desc='Example Log FunnyNameNet 2025'; \
  validfrom=2025-01-01T00:00:00Z; \
  validtill=2026-01-01T00:00:00Z; \
  cturi=https://ct.example.net/logs/eu/funnynamenet2025; \
  logid='sh4(...)'; \
  pubkey='MFk(...)';" )

ct_policy: ( "example.ca; \
  critical=true; \
  desc='Example Log FunnyNameOrg 2025'; \
  validfrom=2025-01-01T00:00:00Z; \
  validtill=2026-01-01T00:00:00Z; \
  cturi=https://ct.example.org/logs/eu/funnynameorg2025"; \
  logid='sh4(...)'; \
  pubkey='MFk(...)';" )

ct_policy: ( "example.ca; \
  critical=true; \
  desc='Example Log FunnyNameSh 2025'; \
  validfrom=2025-01-01T00:00:00Z; \
  validtill=2026-01-01T00:00:00Z; \
  cturi=https://ct.example.sh/logs/eu/funnynamesh2025; \
  logid='sh4(...)'; \
  pubkey='MFk(...)';" )

ct_policy: ( "example.ca; \
  critical=true; \
  desc='Example Log FunnyNameXyz 2025'; \
  validfrom=2025-01-01T00:00:00Z; \
  validtill=2026-01-01T00:00:00Z; \
  cturi=https://ct.example.xyz/logs/eu/funnynamexyz2025; \
  logid='sh4(...)'; \
  pubkey='MFk(...)';" )

D.1. Shell "issuect" Generator script

The following POSIX [POSIX]-compliant shell script retrieves information from the regularly updated Google curated CT-Log-Operators file JSON List of CT-Logs that are currently compliant with Chromes CT policy [4] and generates zone-file compliant DNS RRs.¶

#!/bin/sh
set -eu
readonly OWN_DOMAIN="$1"
readonly CAA_DOMAIN="$2"
readonly CRIT__FLAG="$3"
readonly ZONE__FILE="zone_${OWN_DOMAIN}_CAA.txt"
case "${CRIT__FLAG}" in
  true|false) ;;
  *) echo "Error: CRIT_FLAG MUST be either 'true' or 'false'." >&2
    exit 1
    ;;
esac
:> "${ZONE__FILE}"
JSON=$(curl -fsSL https://www.gstatic.com/ct/log_list/v3/log_list.json)
readonly JSON
echo "${JSON}" | awk -v OWN="${OWN_DOMAIN}" -v CA="${CAA_DOMAIN}" -v CRIT="${CRIT__FLAG}" -v OUT="${ZONE__FILE}" '
  BEGIN { FS="\""; }
  /{[[:space:]]*"description"/ {
    desc=""; url=""; start=""; endt=""; logid=""; key="";
  }
  /"description":/ {
    desc = $4
    gsub(/\047/, "", desc)
  }
  /"url":/ {
    url = $4
  }
  /"start_inclusive":/ {
    start = $4
  }
  /"end_exclusive":/ {
    endt = $4
  }
  /"log_id":/ {
    logid = $4
  }
  /"key":/ {
    key = $4
    gsub(/\047/, "", key)
  }
  /"end_exclusive":/ {
    if (desc != "" && url != "" && start != "" && logid != "" && key != "") {
      printf "%s. 60 IN CAA 0 issuect ( \"%s; critical=%s; desc='\''%s'\''; validfrom=%s; validtill=%s; cturi=%s; logid='\''%s'\''; pubkey='\''%s'\'';\" )\n", \
        OWN, CA, CRIT, desc, start, endt, url, logid, key \
      >> OUT
    }
  }
'

D.2. Shell "caa-ct-sts.txt" Generator script

The following POSIX [POSIX]-compliant shell script retrieves information from the regularly updated Google curated CT-Log-Operators file JSON List of CT-Logs that are currently compliant with Chromes CT policy [4] and generates a "caa-ct-sts.txt"-Policy file.¶

#!/bin/sh
set -eu
readonly OWN_DOMAIN="$1"
readonly CAA_DOMAIN="$2"
readonly CRIT__FLAG="$3"
readonly CAA_CTS_TS="caa-ct-sts.${OWN_DOMAIN}.txt"
case "${CRIT__FLAG}" in
  true|false) ;;
  *) echo "Error: CRIT_FLAG MUST be either 'true' or 'false'." >&2
    exit 1 ;;
esac
:> "${CAA_CTS_TS}"
{ echo "version: CAACTSTSv1"
  echo "max_age: 60"
} > "${CAA_CTS_TS}"
JSON=$(curl -fsSL https://www.gstatic.com/ct/log_list/v3/log_list.json)
readonly JSON
echo "${JSON}" | awk -v OWN="${OWN_DOMAIN}" -v CA="${CAA_DOMAIN}" -v CRIT="${CRIT__FLAG}" -v OUT="${CAA_CTS_TS}" '
  BEGIN { FS="\""; }
  /{[[:space:]]*"description"/ {
    desc=""; url=""; start=""; endt=""; logid=""; key="";
  }
  /"description":/ {
    desc = $4
    gsub(/\047/, "", desc)
  }
  /"url":/ {
    url = $4
  }
  /"start_inclusive":/ {
    start = $4
  }
  /"end_exclusive":/ {
    endt = $4
  }
  /"log_id":/ {
    logid = $4
  }
  /"key":/ {
    key = $4
    gsub(/\047/, "", key)
  }
  /"end_exclusive":/ {
    if (desc != "" && url != "" && start != "" && logid != "" && key != "") {
      printf "ct_policy: ( \"%s; critical=%s; desc='\''%s'\''; validfrom=%s; validtill=%s; cturi=%s; logid='\''%s'\''; pubkey='\''%s'\'';\" )\n", \
        CA, CRIT, desc, start, endt, url, logid, key \
      >> OUT
    }
  }
'

E.1. High-Security, High-Change Environments

It is RECOMMENDED to prefer very low TTL (60-300 s). In case of compromise or mistakes a real time reaction is still possible.¶

E.2. Stable, Low-Risk Domains with DDoS Concerns

It is RECOMMENDED to prefer high TTL (86 400 s+) to minimize DNS-load and reduce resolver queries.¶

E.3. Balanced Approach for Most

It is RECOMMENDED 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.¶

F.1. draft-weidner-catalog-rr-ext-00

Initial Version¶