]>

michel@lebihan.pl

ACME SRV certificate validation service delegation multi-tenancy 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 The latest revision of this draft can be found at . Status information for this document may be found at . Source for this draft and an issue tracker can be found at .

Introduction Many application protocols can use DNS SRV records 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. 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 to support SRV-ID identifiers , enabling hosting providers to obtain certificates that properly identify delegated services without requiring control over the source domain's infrastructure.

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 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 representing a service-specific identity

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
• Service C to provider-c.example

These services might be discovered via SRV records such as: 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 : Requires DNSSEC deployment, which remains limited across many TLDs and registrars
• POSH : 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 : 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

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 , in 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 Section 2, which omits the protocol component found in DNS SRV records.

Example identifier object:

Identifier Validation Challenges SRV identifiers MUST be validated using the dns-01 challenge type as defined in 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.

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

Security Considerations

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

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.

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.

IANA Considerations

ACME Identifier Types IANA is requested to add the following entry to the "ACME Identifier Types" registry:

Label	Reference
srv	RFC XXXX

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

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document describes a DNS RR which specifies the location of the server(s) for a specific protocol and domain. [STANDARDS-TRACK] This document defines a new name form for inclusion in the otherName field of an X.509 Subject Alternative Name extension that allows a certificate subject to be associated with the service name and domain name components of a DNS Service Resource Record. [STANDARDS-TRACK] RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Public Key Infrastructure using X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. As of this writing, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. Informative References Encrypted communication on the Internet often uses Transport Layer Security (TLS), which depends on third parties to certify the keys used. This document improves on that situation by enabling the administrators of domain names to specify the keys used in that domain's TLS servers. This requires matching improvements in TLS client software, but no change in TLS server software. [STANDARDS-TRACK] Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.

Acknowledgments