Hi Michel, Thank you for the explanation and example!
Sorry if my comment came across as flippant. I suppose that "A workaround to get certificates for a domain that you don't own" and "A granular mechanism to delegate certificates for a subset of a domain that you own to a 3rd party" are two ways of looking at the same action. As you say, this is a new approach that may take time for the community to fully evaluate (myself included). My intuition is that both the operational as well as security aspects here will be more complex than they look from a quick skim of the document. IE if we adopt this work, this will not be a quick and straightforward document to progress to RFC. For adoption, I am looking to judge whether the IETF/ACME community sees this as being worth the time and effort to standardize. That is not to discredit the idea! Many good ideas never get standardized for various technical and commercial reasons. So yes, for something radically new like this, I definitely want to see the reactions (positive or negative) from the big players who would ultimately have to deploy it. If you haven't managed to get any substantial discussion going on the mailing list in a few weeks, then doing a Call For Adoption is certainly a good way to get people to read it and comment! On Fri, 12 Sept 2025 at 16:36, Michel Le Bihan <[email protected]> wrote: > Hello Mike, > > Thank you for taking the time to review my draft and for your thoughtful > response. > > I'd like to clarify an important point: this proposal is not a workaround > to obtain certificates for domains one isn't authorized for. Rather, it's > about enabling properly-scoped authorization that reflects the actual > delegation patterns used in modern service architectures. > > While SRV-ID certificates likely won't be used for email (which uses MX > records rather than SRV records), let me use mail delegation as an example > since many are familiar with how it works. Consider the IETF's own domain: > > $ dig +short ietf.org > 104.16.44.99 > 104.16.45.99 > > $ dig +short MX ietf.org > 0 mail2.ietf.org. > > $ dig +short mail2.ietf.org > 166.84.6.31 > > The IETF domain demonstrates a common pattern: the web service (A records) > and mail service (MX record) point to completely different infrastructure. > In many organizations, these services are operated by different teams or > even different providers. While mail is just an analogy here, the same > pattern applies to many SRV-based services where the service operator has > legitimate need for a certificate to secure connections, but giving them a > certificate for the entire domain would be an over-broad authorization that > violates the principle of least privilege. > > SRV-ID certificates solve this by providing service-scoped authorization. > A certificate for "_myservice.example.com" would allow the service > provider to secure their specific service without gaining the ability to > impersonate the web service or other services under the domain. This isn't > bypassing authorization - it's implementing more granular, appropriate > authorization that matches the actual trust boundaries in multi-service > deployments. > > The current situation forces organizations into suboptimal choices: either > share private keys across service boundaries (a security anti-pattern), > grant overly broad certificates to service providers, or forgo proper > certificate coverage for delegated services. This draft addresses a real > operational need for service-specific certificates that respect > organizational boundaries. > > I recognize that this is a new approach that may take time for the > community to fully evaluate. I understand that support from deployers would > strengthen the case for adoption. Would it be helpful if I prepared a more > detailed problem statement with specific deployment scenarios from > potential implementers to share on the mailing list? > > Best regards, > Michel Le Bihan > > Le 08/09/2025 à 17:30, Mike Ounsworth a écrit : > > Hi Michel. > > The chairs see your request for a Call-For-Adoption. This is an -00 draft, > tagged as Proposed Standard, that I imagine will generate quite a bit of > discussion; I don't claim to be an expert on the interactions between SRV > DNS records and X.509 Certificates, but the Introduction of your draft > certainly gives me the impression that this is a workaround to be able to > get certificates for a domain that you're not authorized to get > certificates for, which I imagine will generate a fair amount of > discussion. Since this is a brand new draft, I don't see much discussion on > the list about it yet. > > We could do a Call-For-Adoption if you like, which may generate some > discussion, but it also has a good chance of failing. Since you are > submitting this as Standards Track, I think you would be in a stronger > position for a CfA if you can get some large deployers (for example, cloud > service providers or ACME operators) to come to the list saying that this > draft solves a real-world problem they have, and they are interested in > deploying this. Maybe waiting and presenting this at IETF 124 in Montreal > would be a good way to generate discussion on this draft? > > On Wed, 3 Sept 2025 at 12:47, Michel Le Bihan <[email protected]> wrote: > >> Dear ACME WG, >> >> I would like to request that the working group consider adopting my >> draft, draft-lebihan-srv-identifier-validation-extension-00 ( >> https://datatracker.ietf.org/doc/draft-lebihan-srv-identifier-validation-extension/), >> “Automated Certificate Management Environment (ACME) SRV Identifier >> Validation Extension”, as a WG document. >> >> The draft extends ACME to cover SRV identifiers in a way that I believe >> is consistent with the WG’s scope and useful for real deployment scenarios. >> I would welcome a call for adoption and feedback from the group. >> >> Best regards, >> Michel Le Bihan >> >> _______________________________________________ >> Acme mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> >
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
