授權憑證機構簽發憑證（CAA）之參數

CAA Parameters

When processing CAA records, CAs SHOULD process the accounturi and validationmethods parameters as specified in RFC 8657. Effective 2027-03-15, when processing CAA records, CAs MUST process the accounturi and validationmethods parameters as specified in RFC 8657.

處理 CAA 紀錄時，憑證機構（Certification Authority，CA）宜（SHOULD）依 RFC 8657 之規定處理 accounturi 與 validationmethods 參數。

自 2027-03-15 起，處理 CAA 紀錄時，CA 應（MUST）依 RFC 8657 之規定處理 accounturi 與 validationmethods 參數。

In addition, Effective 2027-03-15:

• If the CA does not identify the Subscriber account via an ACME Account URL as described in RFC 8555, the CA MUST define the supported format of the accounturi in Section 4.2 of their CP and/or CPS, and SHOULD comply with the ‘acct’ URI scheme defined in RFC 7565.
• For certificate requests made using the ACME protocol, the CA MAY permit the ‘accounturi’ parameter to identify a primary organizational account (the “Parent Account”). As an explicit exception to Section 3 of RFC 8657, the CA MAY issue a certificate requested by a different account (the “Subordinate ACME Account”) if and only if the CA ensures all of the following:

1. The CA maintains an internal, auditable mapping that binds the Subordinate ACME Account to the Parent Account identified by the ‘accounturi’.
2. The CA has cryptographically or administratively verified that the Parent Account explicitly authorized the Subordinate ACME Account to obtain certificates under this mapping.
3. The CA retains audit logs demonstrating this authorization and mapping for the standard data retention period required by these Requirements.

• If the CA supports domain validation methods that are not registered in the IANA ACME Validation Methods registry, the CA MUST interpret and process validationmethods labels formed by concatenating the string ‘ca-tbr-’ with the BR 3.2.2.4 subsection number, e.g. ‘ca-tbr-7’ represents the DNS method described in TLS BR 3.2.2.4.7. If a CA performs domain validation using a mechanism that can be represented by multiple labels (e.g. ‘http-01’ and ‘ca-tbr-19’), the CA SHOULD accept any of the labels as granting permission to issue.
• The canonical representation of validationmethods labels is lowercase letters. However, the CA MAY perform case insensitive matching of labels. If the CA does perform case insensitive matching of labels, this practice MUST be documented in their CP and/or CPS.

此外，自 2027-03-15 起：

• 若 CA 未依 RFC 8555 所述，以 ACME Account URL 識別憑證用戶的帳號，CA 應（MUST）於其憑證政策（CP）及／或憑證實務作業基準（CPS）第 4.2 節中定義其所支援的 accounturi 格式，並宜（SHOULD）遵循 RFC 7565 所定義的「acct」URI scheme。
• 對於使用 ACME 協定提出的憑證申請，CA 得（MAY）允許 accounturi 參數指定主要組織帳號（「父帳號」（Parent Account））。作為 RFC 8657 第 3 節之明確例外，若且唯若（if and only if）CA 確保下列各項均成立，CA 得（MAY）簽發由另一帳號（「下屬 ACME 帳號」（Subordinate ACME Account））所申請之憑證：
  1. CA 維護一份內部且可供稽核之對應關係，將下屬 ACME 帳號繫結至 accounturi 所指定的父帳號。
  2. CA 已透過密碼學方式或管理程序驗證，父帳號已明確授權下屬 ACME 帳號依此對應關係取得憑證。
  3. CA 於本文件所規定之標準資料保存期限內，保存足以證明此項授權及對應關係的稽核紀錄。
• 若 CA 支援未登記於 IANA ACME Validation Methods registry 的網域驗證方法，CA 應（MUST）解析並處理由字串「ca-tbr-」與《基本要求》第 3.2.2.4 節之小節編號所串接而成的 validationmethods 標籤，例如「ca-tbr-7」代表《基本要求》第 3.2.2.4.7 節所述之 DNS 方法。若 CA 使用可由不同標籤表示的機制執行網域驗證（例如「http-01」與「ca-tbr-19」），CA 宜（SHOULD）將其中任一標籤視為授權簽發憑證的驗證方法。
• validationmethods 標籤的規範表示形式為小寫字母。但 CA 得（MAY）以不區分大小寫（case insensitive）之方式比對標籤。若 CA 確實採用不區分大小寫的標籤比對方式，此項實務作業應（MUST）記載於其憑證政策（CP）及／或憑證實務作業基準（CPS）中。