Network Working Group M. L. Bihan Internet-Draft August 2025 Intended status: Standards Track Expires: 24 February 2026 Automated Certificate Management Environment (ACME) SRV Identifier Validation Extension draft-lebihan-srv-identifier-validation-extension-00 Abstract This document specifies an extension to the Automated Certificate Management Environment (ACME) protocol to enable validation and issuance of certificates containing SRV-ID identifiers as defined in RFC 4985. This allows secure delegation of services where the service domain and hosting infrastructure are controlled by different entities, addressing the multi-tenancy challenges in protocols that use SRV records for service discovery. 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://mimi89999.github.io/srv-identifier-validation-extension/ draft-lebihan-srv-identifier-validation-extension.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-lebihan-srv-identifier- validation-extension/. Source for this draft and an issue tracker can be found at https://github.com/mimi89999/srv-identifier-validation-extension. 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." Bihan Expires 24 February 2026 [Page 1] Internet-Draft ACME SRV Validation August 2025 This Internet-Draft will expire on 2 February 2026. 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 4. SRV Identifier Type . . . . . . . . . . . . . . . . . . . . . 4 5. Identifier Validation Challenges . . . . . . . . . . . . . . 5 6. Validation Process . . . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7.1. DNS Security . . . . . . . . . . . . . . . . . . . . . . 6 7.2. Scope of Authorization . . . . . . . . . . . . . . . . . 6 7.3. Client Support . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8.1. ACME Identifier Types . . . . . . . . . . . . . . . . . . 7 8.2. ACME Validation Methods . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction Many application protocols can use DNS SRV records [RFC2782] for service discovery and delegation to third-party hosting providers. Organizations often wish to maintain their domain identity (e.g., example.com) while delegating the actual service hosting to specialized providers. Bihan Expires 24 February 2026 [Page 2] Internet-Draft ACME SRV Validation August 2025 Currently, obtaining proper PKIX certificates for such delegated services presents significant operational challenges. The hosting provider cannot easily obtain certificates for the customer's domain without either: * Access to the customer's DNS infrastructure for validation * Access to the customer's web server for HTTP validation * The customer obtaining certificates and sharing private keys These approaches are either operationally infeasible, introduce security risks, or do not scale effectively in multi-tenant environments. This document extends ACME [RFC8555] to support SRV-ID identifiers [RFC4985], enabling hosting providers to obtain certificates that properly identify delegated services without requiring control over the source domain's infrastructure. 2. Terminology 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. This document uses the following terms: Source Domain: The domain that owns the service identity (e.g., example.com in _myservice.example.com) Target Domain: The domain providing the actual service hosting (e.g., hosting.example.net) SRV-ID: An identifier type defined in [RFC4985] representing a service-specific identity 3. Problem Statement Consider an organization using example.com that wishes to delegate multiple services to different providers: * Service A to provider-a.example * Service B to provider-b.example Bihan Expires 24 February 2026 [Page 3] Internet-Draft ACME SRV Validation August 2025 * Service C to provider-c.example These services might be discovered via SRV records such as: _service-a._tcp.example.com. 86400 IN SRV 0 5 5001 provider-a.example. _service-b._tcp.example.com. 86400 IN SRV 0 5 5002 provider-b.example. _service-c._tcp.example.com. 86400 IN SRV 0 5 5003 provider-c.example. Without DNSSEC (which has limited deployment), these delegations are vulnerable to DNS spoofing attacks. Current ACME validation methods cannot be used by the hosting providers to obtain certificates for example.com without coordination that is often impractical. Existing approaches have significant limitations: * *DANE [RFC6698]*: Requires DNSSEC deployment, which remains limited across many TLDs and registrars * *POSH [RFC7711]*: Requires placing files in .well-known on the source domain's web server. If that web server is compromised (e.g., through a CMS vulnerability), an attacker could modify the POSH files * *dns-account-01 [I-D.ietf-acme-dns-account-label]*: While this challenge type allows multiple providers to independently validate the same domain through unique DNS labels, it ties the validation to a specific ACME account URL that includes the CA endpoint. This creates operational inflexibility: if a hosting provider needs to switch CAs (due to rate limits, outages, pricing changes, or other operational reasons), every customer would need to update their DNS records to reflect the new account URL. This requirement is impractical at scale and effectively locks providers into a single CA * *Certificate sharing*: Requires distributing private keys between organizations, creating security and operational concerns 4. SRV Identifier Type This document defines a new ACME identifier type "srv" for use in authorization objects. An SRV identifier object has the following fields: type (required, string): The string "srv" value (required, string): The SRVName as defined in [RFC4985], in Bihan Expires 24 February 2026 [Page 4] Internet-Draft ACME SRV Validation August 2025 the format "_service.domain". MUST begin with an underscore followed by the service name, then a dot, then the domain name. This format corresponds to the SRVName structure in [RFC4985] Section 2, which omits the protocol component found in DNS SRV records. Example identifier object: { "type": "srv", "value": "_myservice.example.com" } 5. Identifier Validation Challenges SRV identifiers MUST be validated using the dns-01 challenge type as defined in [RFC8555] Section 8.4, with the following modification: When validating an SRV identifier, the challenge TXT record MUST be provisioned under the service name rather than the base domain. Specifically: 1. The client constructs the validation domain name by prepending "_acme-challenge." to the SRV identifier value. 2. For an SRV identifier "_myservice.example.com", the resulting validation domain would be: "_acme- challenge._myservice.example.com" 3. The client provisions a TXT record at this location containing the base64url encoding of the SHA-256 digest of the key authorization, as specified in the standard dns-01 challenge. The server performs validation by: 1. Computing the SHA-256 digest of the stored key authorization 2. Querying for TXT records at the validation domain name constructed from the SRV identifier 3. Verifying that the contents of one of the TXT records matches the digest value HTTP-01 and other challenge types MUST NOT be used for SRV identifier validation, as they cannot properly demonstrate control of a service- specific identifier. Bihan Expires 24 February 2026 [Page 5] Internet-Draft ACME SRV Validation August 2025 6. Validation Process The validation flow is: 1. Client creates a newOrder request with an SRV identifier 2. Server creates authorization with dns-01 challenge 3. Client provisions DNS TXT record at the service-specific location 4. Server validates the dns-01 challenge 5. Upon successful validation, server issues certificate containing the SRV-ID from the original identifier value The issued certificate MUST contain the SRV-ID in the subjectAltName extension as specified in [RFC4985], using the id-on-dnsSRV form. The issued certificate MUST NOT include a Common Name (CN) in the subject field. Placing a SRVName in the CN field could lead to interpretation issues with software interpreting the SRVName in the CN field as a standard domain name. 7. Security Considerations 7.1. DNS Security This mechanism relies on the integrity of DNS SRV records. In the absence of DNSSEC, it is vulnerable to DNS spoofing attacks. ACME servers SHOULD: * Use DNSSEC-validating resolvers where possible * Perform validation from multiple network vantage points * Apply similar mitigations as for standard DNS-based validation 7.2. Scope of Authorization Unlike certificates with DNS-ID identifiers, certificates with SRV-ID identifiers are restricted to the specific service. This provides better isolation in multi-tenant environments where different services are hosted by different providers. A certificate for "_service-a.example.com" cannot be used to impersonate "_service- b.example.com" or the base domain example.com. Bihan Expires 24 February 2026 [Page 6] Internet-Draft ACME SRV Validation August 2025 7.3. Client Support Clients MUST properly validate SRV-ID certificates and not accept them as valid for general DNS names. Protocol specifications using this extension SHOULD clearly define certificate validation requirements. 8. IANA Considerations 8.1. ACME Identifier Types IANA is requested to add the following entry to the "ACME Identifier Types" registry: +=======+===========+ | Label | Reference | +=======+===========+ | srv | RFC XXXX | +-------+-----------+ Table 1 8.2. ACME Validation Methods IANA is requested to add the following entry to the "ACME Validation Methods" registry: +========+=================+======+===========+ | Label | Identifier Type | ACME | Reference | +========+=================+======+===========+ | dns-01 | srv | Y | RFC XXXX | +--------+-----------------+------+-----------+ Table 2 9. References 9.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, . [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, . Bihan Expires 24 February 2026 [Page 7] Internet-Draft ACME SRV Validation August 2025 [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure Subject Alternative Name for Expression of Service Name", RFC 4985, DOI 10.17487/RFC4985, August 2007, . [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, . 9.2. Informative References [I-D.ietf-acme-dns-account-label] Chariton, A., "Automated Certificate Management Environment (ACME) DNS Labeled With ACME Account ID Challenge", Work in Progress, Internet-Draft, draft-ietf- acme-dns-account-label-01, May 2025, . [RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, . [RFC7711] Miller, M. and P. Saint-Andre, "PKIX over Secure HTTP (POSH)", RFC 7711, DOI 10.17487/RFC7711, November 2015, . Acknowledgments Author's Address Michel Le Bihan Email: michel@lebihan.pl Bihan Expires 24 February 2026 [Page 8]