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]
