Ballot SC098v2: Process RFC 8657 CAA Parameters

Ballot overview

• Ballot code/title: SC-098v2: Process RFC 8657 CAA Parameters
• Working group: Server Certificate Working Group
• Purpose: Add a requirement that CAs process the Certification Authority Authorization (CAA) parameters defined in RFC 8657.
• What RFC 8657 enables (per ballot page): CAA record issuance policy can include the account and domain validation methods that may be used to issue a certificate for the subject domain.
• Additional changes (per ballot page):
  • Define a syntax for specifying non-ACME domain validation methods in section 4.2.2.1.3.
  • Require CAs supporting non-ACME accounts to document the accepted accounturi format in their CP or CPS.
  • Consolidate CAA requirements into section 4.2.

CA requirements introduced

• CAA record processing:
  • As part of the certificate issuance process, the CA MUST retrieve and process CAA records in accordance with RFC 8659 for each dNSName in subjectAltName that does not contain an Onion Domain Name.
  • When processing CAA records, the CA MUST process the issue, issuewild, and iodef property tags as specified in RFC 8659.
  • If the CA issues a certificate after processing a CAA record, it MUST do so within the TTL of the CAA record, or 8 hours, whichever is greater.
  • CAs MUST NOT rely on exceptions specified in their CP or CPS unless one of the listed exceptions applies.
  • CAs are permitted to treat a record lookup failure as permission to issue if the listed conditions are met.
  • CAs MUST document potential issuances prevented by a CAA record and SHOULD dispatch reports to the contact(s) in the CAA iodef record(s) if present.
• RFC 8657 parameters (accounturi and validationmethods):
  • Effective 2027-03-15, when processing CAA records, CAs MUST process the accounturi and validationmethods parameters as specified in RFC 8657.
  • Effective 2027-03-15:
    • If the CA does not identify the Subscriber account via an ACME Account URL, the CA MUST define the supported format of accounturi in Section 4.2 of their CP and/or CPS, and SHOULD comply with the acct URI scheme.
    • For ACME protocol requests, the CA MAY permit accounturi to identify a primary organizational Parent Account, with an explicit exception allowing issuance for a Subordinate ACME Account only if the listed mapping/authorization/audit-log conditions are met.
    • If the CA supports domain validation methods not registered in the IANA ACME Validation Methods registry, the CA MUST interpret and process validationmethods labels formed by concatenating ca-tbr- with the BR 3.2.2.4 subsection number.
    • The canonical representation of validationmethods labels is lowercase letters; if case-insensitive matching is performed, it MUST be documented in CP and/or CPS.
• DNSSEC validation for CAA record lookups:
  • DNSSEC validation back to the IANA DNSSEC root trust anchor MUST be performed on all DNS queries associated with CAA record lookups performed by the Primary Network Perspective.
  • The DNS resolver used for Primary Network Perspective CAA record lookups MUST perform DNSSEC validation using the specified algorithm and support the listed features.
  • CAs MUST NOT use local policy to disable DNSSEC validation on any DNS query associated with CAA record lookups.
  • DNSSEC-validation errors observed by the Primary Network Perspective MUST NOT be treated as permission to issue.
  • DNSSEC validation back to the IANA DNSSEC root trust anchor MAY be performed for Remote Network Perspectives as part of Multi-Perspective Issuance Corroboration.

Dates and process (as stated on the ballot page)

• Discussion: Start 2026-04-27 00:00 UTC; End 2026-05-04 15:00 UTC
• Voting: Start 2026-05-13; Voting end 2026-06-12
• IPR review period: Start 2026-05-13 15:00:00 UTC; End 2026-06-12 15:00:00 UTC
• Effective date for the new requirements: 2027-03-15