Automated Certificate Management Environment S. Heurich Internet-Draft Fastly Intended status: Standards Track 23 June 2025 Expires: 25 December 2025 Automated Certificate Management Environment (ACME) Challenge for Persistent DNS TXT Record Validation draft-sheurich-acme-dns-persist-latest Abstract This document specifies "dns-persist-01", a new validation method for the Automated Certificate Management Environment (ACME) protocol. This method allows a Certification Authority (CA) to verify control over a domain by confirming the presence of a persistent DNS TXT record containing CA and account identification information. This method is particularly suited for environments where traditional challenge methods are impractical, such as IoT deployments, multi- tenant platforms, and scenarios requiring batch certificate operations. The validation method is designed with a strong focus on security and robustness, incorporating widely adopted industry best practices for persistent domain control validation. This design aims to make it suitable for Certification Authorities operating under various policy environments, including those that align with the CA/ Browser Forum Baseline Requirements. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://sheurich.github.io/draft-sheurich-acme-dns-persist/draft- sheurich-acme-dns-persist.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-sheurich-acme- dns-persist/. Discussion of this document takes place on the Automated Certificate Management Environment Working Group mailing list (mailto:acme@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/acme/. Subscribe at https://www.ietf.org/mailman/listinfo/acme/. Source for this draft and an issue tracker can be found at https://github.com/sheurich/draft-sheurich-acme-dns-persist. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 25 December 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction 1.1. Robustness and Alignment with Industry Best Practices 2. Conventions and Definitions 3. The "dns-persist-01" Challenge 3.1. Challenge Object 4. Challenge Response and Verification 4.1. Multi-Perspective Validation 4.2. Validation Data Reuse and TTL Handling 5. Wildcard Certificate Validation 6. Subdomain Certificate Validation 7. Security Considerations 7.1. Persistent Record Risks 7.2. Account Binding Security 7.3. Subdomain Validation Risks 7.4. Cross-CA Validation Reuse 7.5. Record Tampering and Integrity 7.6. Revocation and Invalidation of Persistent Authorizations 8. IANA Considerations 8.1. ACME Validation Methods Registry 9. Implementation Considerations 9.1. CA Implementation Guidelines 9.2. Client Implementation Guidelines 9.3. DNS Provider Considerations 10. Examples 10.1. Basic Validation Example (FQDN Only) 10.2. Specific Subdomain Validation Example 10.3. Wildcard Validation Example 11. References 11.1. Normative References 11.2. Informative References Acknowledgments Author's Address 1. Introduction The Automated Certificate Management Environment (ACME) protocol [RFC8555] defines mechanisms for automating certificate issuance and domain validation. The existing challenge methods, "http-01" and "dns-01", require real-time interaction between the ACME client and the domain's infrastructure during the validation process. While effective for many use cases, these methods present challenges in certain deployment scenarios. Examples include: * Internet of Things (IoT) deployments where devices may not be able to host an HTTP service or coordinate DNS updates in real-time. * Edge compute and multi-tenant hosting platforms where the entity managing the DNS zone is distinct from the tenant subscribing to the certificate. * Organizations that wish to pre-validate domains and batch issuance operations offline or at a later time. * Scenarios requiring wildcard certificates where domain control is proven once and reused over an extended period. * Environments with strict change management processes where DNS modifications require approval workflows. This document defines a new ACME challenge type, "dns-persist-01". This method proves control over a Fully Qualified Domain Name (FQDN) by confirming the presence of a persistent DNS TXT record containing CA and account identification information. The record format is based on the "issue-value" syntax from [RFC8659], incorporating an issuer-domain-name and a mandatory accounturi parameter [RFC8657] that uniquely identifies the applicant's account. This design provides strong binding between the domain, the CA, and the specific account requesting validation. 1.1. Robustness and Alignment with Industry Best Practices This validation method is designed to provide a robust and persistent mechanism for domain control verification within the ACME protocol. Its technical design incorporates widely adopted security principles and best practices for domain validation, ensuring high assurance regardless of the specific CA policy environment. These principles include, but are not limited to: 1. The use of a well-defined, unique DNS label (e.g., "_validation- persist") for persistent validation records, minimizing potential conflicts. 2. Mandatory multi-perspective validation by the Certificate Authority, enhancing resilience against localized DNS attacks and ensuring global visibility of the record (see Section 4.1). 3. Consideration of DNS TTL values when determining the effective validity period of an authorization, balancing persistence with responsiveness to DNS changes (see Section 4.2). 4. Explicit binding of the domain validation to a specific ACME account through a unique identifier, establishing clear accountability and enhancing security against unauthorized use. Certification Authorities operating under various trust program requirements will find this technical framework suitable for their domain validation needs, as its design inherently supports robust and auditable validation practices (see Section 4.1). 2. Conventions and Definitions The key words "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. Authorization Domain Name The domain name at which the validation TXT record is provisioned. It is formed by prepending the label "_validation-persist" to the FQDN being validated. DNS TXT Record Persistent DCV Domain Label The label "_validation- persist" as specified in this document. This label is consistent with industry practices for persistent domain validation. Issuer Domain Name A domain name disclosed by the CA in Section 4.2 of the CA's Certificate Policy and/or Certification Practices Statement to identify the CA for the purposes of this validation method. Validation Data Reuse Period The period during which a CA may rely on validation data, as defined by the CA's practices and applicable requirements. 3. The "dns-persist-01" Challenge The "dns-persist-01" challenge allows an ACME client to demonstrate control over an FQDN by proving it can provision a DNS TXT record containing specific, persistent validation information. The validation information links the FQDN to both the Certificate Authority performing the validation and the specific ACME account requesting the validation. When an ACME client accepts a "dns-persist-01" challenge, it proves control by provisioning a DNS TXT record at the Authorization Domain Name. Unlike the existing "dns-01" challenge, this record is designed to persist and may be reused for multiple certificate issuances over an extended period. 3.1. Challenge Object The challenge object for "dns-persist-01" contains the following fields: * *type* (required, string): The string "dns-persist-01" * *url* (required, string): The URL to which a response can be posted * *status* (required, string): The status of this challenge * *issuer-domain-name* (required, string): The Issuer Domain Name that the client MUST include in the DNS TXT record Example challenge object: { "type": "dns-persist-01", "url": "https://ca.example/acme/authz/1234/0", "status": "pending", "issuer-domain-name": "authority.example" } 4. Challenge Response and Verification To respond to the challenge, the ACME client provisions a DNS TXT record for the Authorization Domain Name being validated. The Authorization Domain Name is formed by prepending the label "_validation-persist" to the domain name being validated. For example, if the domain being validated is "example.com", the Authorization Domain Name would be "_validation-persist.example.com". The RDATA of this TXT record MUST fulfill the following requirements: 1. The RDATA value MUST conform to the issue-value syntax as defined in [RFC8659], Section 4. 2. The issuer-domain-name portion of the issue-value MUST be the Issuer Domain Name provided by the CA in the challenge object. 3. The issue-value MUST contain an accounturi parameter. The value of this parameter MUST be a unique URI identifying the account of the applicant which requested the validation, constructed according to [RFC8657], Section 3. 4. The issue-value MAY contain a policy parameter. If present, this parameter modifies the validation scope. The policy parameter follows the key=value syntax. The policy parameter key and its defined values MUST be treated as case-insensitive. The following values for the policy parameter are defined with respect to subdomain and wildcard validation: * policy=specific-subdomains-only: If this value is present, the CA MAY consider this validation sufficient for issuing certificates for the validated FQDN and for specific subdomains of the validated FQDN, as described in Section 6. This policy value explicitly does NOT authorize wildcard certificates. * policy=wildcard-allowed: If this value is present, the CA MAY consider this validation sufficient for issuing certificates for the validated FQDN, for specific subdomains of the validated FQDN (as covered by wildcard scope or specific subdomain validation rules), and for wildcard certificates (e.g., *.example.com). See Section 5 and Section 6. If the policy parameter is absent, or if its value is anything other than specific-subdomains-only or wildcard-allowed, the CA MUST proceed as if the policy parameter were not present (i.e., the validation applies only to the specific FQDN). CAs MUST ignore any unknown parameter keys. For example, if the ACME client is requesting validation for the FQDN "example.com" from a CA that uses "authority.example" as its Issuer Domain Name, and the client's account URI is "https://ca.example/ acct/123", and wants to allow only specific subdomains, it might provision: _validation-persist.example.com. IN TXT "authority.example; accounturi=https://ca.example/acct/123; policy=specific-subdomains-only" If no policy parameter is included, the record defaults to FQDN-only validation: _validation-persist.example.com. IN TXT "authority.example; accounturi=https://ca.example/acct/123" The ACME server verifies the challenge by performing a DNS lookup for the TXT record at the Authorization Domain Name and checking that its RDATA conforms to the required structure and contains both the correct issuer-domain-name and a valid accounturi for the requesting account. The server also interprets any policy parameter values according to this specification. 4.1. Multi-Perspective Validation CAs performing validations using the "dns-persist-01" method MUST implement Multi-Perspective Issuance Corroboration. To count as corroborating, a Network Perspective MUST observe the same challenge information as the Primary Network Perspective. 4.2. Validation Data Reuse and TTL Handling This validation method is explicitly designed for persistence and reuse. The period for which a CA may rely on validation data is its Validation Data Reuse Period (as defined in Section 2). However, if the DNS TXT record's Time-to-Live (TTL) is shorter than this period, the CA MUST adjust the effective validation data reuse period for that specific validation. In such cases, the effective validation data reuse period SHALL be the greater of: (a) the DNS TXT record's TTL, or (b) 8 hours. CAs MAY reuse validation data obtained through this method for the duration of their validation data reuse period, subject to the TTL constraints described in this section. 5. Wildcard Certificate Validation This validation method is suitable for validating Wildcard Domain Names (e.g., *.example.com). To authorize a wildcard certificate for a domain, a single DNS TXT record placed at the Authorization Domain Name for the base domain MUST be used. This TXT record MUST include the policy=wildcard-allowed parameter value. When such a record is present (i.e., containing policy=wildcard- allowed), it can validate the base domain, specific subdomains, and wildcard certificates for that domain. For example, a TXT record at _validation-persist.example.com containing policy=wildcard-allowed can validate certificates for example.com, www.example.com, and *.example.com. If the policy parameter is absent or set to specific- subdomains-only, the validation is not sufficient for *.example.com. 6. Subdomain Certificate Validation If an FQDN has been successfully validated using this method, the CA MAY also consider this validation sufficient for issuing certificates for other FQDNs that are subdomains of the validated FQDN, under the following conditions: * The persistent DNS TXT record MUST include either policy=specific- subdomains-only or policy=wildcard-allowed. To determine which subdomains are permitted, the FQDN for which the persistent TXT record exists (referred to as the "validated FQDN") must appear as the exact suffix of the FQDN for which a certificate is requested (referred to as the "requested FQDN"). For example, if dept.example.com is the validated FQDN, a certificate for server.dept.example.com is permitted because dept.example.com is its suffix. The key distinction between the policy values for subdomain authorization is as follows: * *policy=specific-subdomains-only:* When this value is present, the validation authorizes certificates for the _validated FQDN itself_ and for _any specific subdomain_ of the validated FQDN (i.e., any requested FQDN where the validated FQDN is an exact suffix). *Crucially, this policy explicitly DOES NOT authorize the issuance of wildcard certificates* (e.g., *.dept.example.com). This is intended for domain owners who want to enable automated issuance for individual subdomains but maintain strict control over wildcard certificates. * *policy=specific-subdomains-only:* When this value is present, the validation authorizes certificates for the _validated FQDN itself_ and for _any specific subdomain_ of the validated FQDN (i.e., any requested FQDN where the validated FQDN is an exact suffix). _Crucially, this policy explicitly DOES NOT authorize the issuance of wildcard certificates_ (e.g., *.dept.example.com). This is intended for domain owners who want to enable automated issuance for individual subdomains but maintain strict control over wildcard certificates. * *policy=wildcard-allowed:* When this value is present, the validation authorizes certificates for the _validated FQDN itself_, for _any specific subdomain_ of the validated FQDN (per the suffix rule), and *additionally for wildcard certificates* covering the validated FQDN (e.g., *.example.com if example.com is the validated FQDN). This policy grants the broadest scope of validation. If the policy parameter is absent, or if it is present but its value does not explicitly authorize subdomain validation (e.g., an unrecognized or future policy value), this validation MUST NOT be considered sufficient for issuing certificates for subdomains. See Section 7.3 for important security implications of enabling subdomain validation. _Example: Scope of 'specific-subdomains-only' Policy_ For a persistent TXT record provisioned at _validation- persist.dept.example.com with a policy of specific-subdomains-only, a CA may issue a certificate for server.dept.example.com (since dept.example.com is its suffix). However, this validation MUST NOT be used to issue a certificate for *.dept.example.com, dept.example2.com, or example.com. _Example: Scope of 'wildcard-allowed' Policy_ For a persistent TXT record provisioned at _validation- persist.example.com with a policy of wildcard-allowed, a CA may issue certificates for example.com, www.example.com, app.example.com, and *.example.com." *Rationale for specific-subdomains-only:* Imagine a large organization (e.g., university.edu) that wants to allow departments to get certificates for their specific subdomains (e.g., math.university.edu, cs.university.edu, biology.university.edu). They want this automated. However, they might _not_ want to grant the CA (or an ACME account) the power to issue *.university.edu unless explicitly handled through a much stricter, higher-level process. specific-subdomains-only provides this crucial intermediate level of control. 7. Security Considerations 7.1. Persistent Record Risks The persistence of validation records creates extended windows of vulnerability compared to traditional ACME challenge methods. If an attacker gains control of a DNS zone containing persistent validation records, they can potentially obtain certificates for the validated domains until the validation records are removed or modified. Clients SHOULD protect validation records through appropriate DNS security measures, including: * Using DNS providers with strong authentication and access controls * Implementing DNS security extensions (DNSSEC) where possible * Monitoring DNS zones for unauthorized changes * Regularly reviewing and rotating validation records 7.2. Account Binding Security The accounturi parameter provides strong binding between domain validation and specific ACME accounts. However, this binding depends on the security of the ACME account itself. The security of this method is fundamentally bound to the security of the ACME account's private key. If this key is compromised, an attacker can immediately use any pre-existing dns-persist-01 authorizations associated with that account to issue certificates, without needing any further access to the domain's DNS infrastructure. This elevates the importance of secure key management for ACME clients far above that required for transient challenge methods, as the window of opportunity for an attacker is tied to the lifetime of the persistent authorization, not a momentary challenge. CAs SHOULD implement robust account security measures, including: * Strong authentication requirements for ACME accounts * Account activity monitoring and anomaly detection * Rapid account revocation capabilities * Regular account security reviews * Account key rotation policies and procedures Clients SHOULD protect their ACME account keys with the same level of security as they would protect private keys for high-value certificates. 7.3. Subdomain Validation Risks Enabling subdomain validation via policy=specific-subdomains-only or policy=wildcard-allowed creates significant security implications. Organizations using this feature MUST carefully control subdomain delegation and monitor for unauthorized subdomains. These policy values serve as the explicit mechanism for domain owners to opt-in to broader validation scopes. The ability to issue certificates for subdomains of validated FQDNs creates significant security risks, particularly in environments with subdomain delegation or where subdomains may be controlled by different entities. Potential risks include: * Subdomain takeover attacks where abandoned subdomains are claimed by attackers * Unauthorized certificate issuance for subdomains controlled by different organizations * Confusion about which entity has authority over specific subdomains Organizations considering the use of subdomain validation MUST: * Maintain strict control over subdomain delegation * Implement monitoring for subdomain creation and changes * Consider limiting subdomain validation to specific, controlled scenarios * Provide clear governance policies for subdomain certificate authority 7.4. Cross-CA Validation Reuse The persistent nature of validation records raises concerns about potential reuse across different Certificate Authorities. While the issuer-domain-name parameter is designed to prevent such reuse, implementations MUST carefully validate that the issuer-domain-name in the DNS record matches the CA's disclosed Issuer Domain Name. 7.5. Record Tampering and Integrity DNS records are generally not authenticated end-to-end, making them potentially vulnerable to tampering. CAs SHOULD implement additional integrity checks where possible and consider the overall security posture of the DNS infrastructure when relying on persistent validation records. Additionally, CAs MUST protect their issuer-domain-name with robust security measures (such as DNSSEC). An attacker who compromises the DNS for a CA's issuer-domain-name could disrupt validation or potentially impersonate the CA in certain scenarios. While this is a systemic DNS security risk that extends beyond this specification, it is amplified by any mechanism that relies on DNS for identity. 7.6. Revocation and Invalidation of Persistent Authorizations The persistent nature of dns-persist-01 authorizations means that a valid DNS TXT record can grant control for an extended period, potentially even if the domain owner's intent changes or if the associated ACME account key is compromised. Therefore, explicit mechanisms for revoking or invalidating these persistent authorizations are critical. The primary method for an Applicant to invalidate a dns-persist-01 authorization for a domain is to *remove the corresponding DNS TXT record* from the Authorization Domain Name. Once the record is removed, the CA, upon subsequent validation attempts or periodic re- checks, will no longer find the required information, and the authorization will cease to be valid after the expiration of its effective Validation Data Reuse Period. ACME Clients SHOULD provide clear mechanisms for users to: * Remove the _validation-persist DNS TXT record. * Monitor the presence and content of their _validation-persist records to ensure they accurately reflect desired authorization. Certificate Authorities (CAs) implementing this method MUST: * Periodically re-check active dns-persist-01 authorizations to confirm the continued presence and validity of the DNS TXT record. The frequency of these re-checks SHOULD be at least as often as the effective Validation Data Reuse Period for that specific validation (as determined per Section 4.2), and MUST occur no less frequently than every 8 hours to promptly detect and act upon record removal or modification. * Invalidate an authorization if the corresponding DNS TXT record is no longer present or if its content does not meet the requirements of this specification (e.g., incorrect issuer-domain-name, missing accounturi, altered policy). * Ensure their internal systems are capable of efficiently handling the invalidation of authorizations when DNS records are removed or become invalid. While this method provides a persistent signal of control, the fundamental ACME authorization object (as defined in [RFC8555]) remains subject to its own lifecycle, including expiration. A persistent DNS record allows for repeated authorizations, but each authorization object issued by the CA will have a defined validity period, after which it expires unless renewed. 8. IANA Considerations 8.1. ACME Validation Methods Registry IANA is requested to register the following entry in the "ACME Validation Methods" registry: * *Label*: dns-persist-01 * *Identifier Type*: dns * *ACME*: Y * *Reference*: This document 9. Implementation Considerations 9.1. CA Implementation Guidelines Certificate Authorities implementing this validation method should consider: * Establishing clear policies for Issuer Domain Name disclosure in Certificate Policies and Certification Practice Statements * Implementing robust multi-perspective validation infrastructure * Developing procedures for handling validation record TTL variations * Creating account security monitoring and incident response procedures * Providing clear documentation for clients on proper record construction 9.2. Client Implementation Guidelines ACME clients implementing this validation method should consider: * Implementing secure DNS record management practices * Providing clear user interfaces for managing persistent validation records * Implementing validation record monitoring and alerting * Designing appropriate error handling for validation failures * Considering the security implications of persistent records in their threat models 9.3. DNS Provider Considerations DNS providers supporting this validation method should consider: * Implementing appropriate access controls for validation record management * Providing audit logging for validation record changes * Supporting reasonable TTL values for validation records * Considering dedicated interfaces or APIs for ACME validation record management 10. Examples 10.1. Basic Validation Example (FQDN Only) For validation of "example.com" by a CA using "authority.example" as its Issuer Domain Name, where the validation should only apply to "example.com": 1. CA provides challenge object: { "type": "dns-persist-01", "url": "https://ca.example/acme/authz/1234/0", "status": "pending", "issuer-domain-name": "authority.example" } 1. Client provisions DNS TXT record (note the absence of a policy parameter for scope): _validation-persist.example.com. IN TXT "authority.example; accounturi=https://ca.example/acct/123" 1. CA validates the record through multi-perspective DNS queries. This validation is sufficient only for "example.com". 10.2. Specific Subdomain Validation Example For validation of "example.com" and its specific subdomains (e.g., "www.example.com", "api.example.com"), but NOT for "*.example.com", by a CA using "authority.example": 1. Same challenge object format as above. 2. Client provisions DNS TXT record including policy=specific- subdomains-only: _validation-persist.example.com. IN TXT "authority.example; accounturi=https://ca.example/acct/123; policy=specific-subdomains-only" 1. CA validates the record. This validation authorizes certificates for "example.com" and specific subdomains like "www.example.com", but not for "*.example.com". 10.3. Wildcard Validation Example For validation of "*.example.com" (which also validates "example.com" and specific subdomains like "www.example.com") by a CA using "authority.example" as its Issuer Domain Name: 1. Same challenge object format as above. 2. Client provisions DNS TXT record at the base domain's Authorization Domain Name, including policy=wildcard-allowed: _validation-persist.example.com. IN TXT "authority.example; accounturi=https://ca.example/acct/123; policy=wildcard-allowed" 1. CA validates the record through multi-perspective DNS queries. This validation authorizes certificates for "example.com", "*.example.com", and specific subdomains like "www.example.com". 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . [RFC8657] Landau, H., "Certification Authority Authorization (CAA) Record Extensions for Account URI and Automatic Certificate Management Environment (ACME) Method Binding", RFC 8657, DOI 10.17487/RFC8657, November 2019, . [RFC8659] Hallam-Baker, P., Stradling, R., and J. Hoffman-Andrews, "DNS Certification Authority Authorization (CAA) Resource Record", RFC 8659, DOI 10.17487/RFC8659, November 2019, . 11.2. Informative References [CABF-BR] CA/Browser Forum, "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates", 2024, . Acknowledgments The author would like to acknowledge the CA/Browser Forum for developing the Baseline Requirements that motivated this specification, and the ACME Working Group for their ongoing work on certificate automation protocols. Thanks to the contributors and reviewers who provided feedback on early versions of this document. Author's Address Shiloh Heurich Fastly Email: sheurich@fastly.com