Michel Le Bihan <[email protected]> wrote: > *Problem Statement:* Many services (XMPP, Matrix, SIP, etc.) use DNS SRV > records to delegate hosting to third-party providers while maintaining their > domain identity. Currently, hosting providers cannot obtain appropriate > certificates for customer domains without either:
I had some difficulty understanding the problem.
You buried the lead: this is about issuing certificates with SRV-ID
identifiers, per RFC4985. Not DNS-ID names.
Today, we do not exactly have this problem, because I think that (XMPP) clients
do
not validate SRV-ID, but rather than DNS-ID of the thing that the SRV points to.
When I connect to example.com using XMPP, and it looks up
_xmpp-server._tcp.example.com, and that points to xmpp.example.net,
what I experience is that the XMPP server has "xmpp.example.net" in its SAN,
and the client validates that.
(Securing the mapping from example.com -> xmpp.example.net is a DNSSEC problem)
> While CNAME delegation of _acme-challenge allows DNS validation without
DNS
> control, it only works for a single service provider - you cannot CNAME
the
> same subdomain to multiple providers. Additionally, the resulting
> certificates are overly broad - they're valid for the entire domain rather
> than being scoped to specific services.
This also took me some effort to understand.
I have regularly used a specific CNAME from a zone in which I don't want to
allow dynamic DNS updates to one that I do. For instance, for
jed.sandelman.ca, I have:
_acme-challenge.jed 60 IN CNAME
_acme-challenge.jed.sandelman.ca.dasblinkenled.org.
I think you are saying, if I had multiple SRV records at
_xmpp-server._tcp.jed.sandelman.ca:
_xmpp-server._tcp.example.com. 300 IN SRV 1 1 5269 xmpp.providerA.example.
_xmpp-server._tcp.example.com. 300 IN SRV 1 1 5269 xmpp.providerB.example.
that I would be unable to do dns-01 CNAME mapping for the SRV, because that
would require that I CNAME _acme_challenge._xmpp-server._tcp.example.com to
two different places. One controlled by providerA, and another controlled by
providerB.
> *Proposed Solution:* The draft extends ACME to:
> * Define a new "srv" identifier type for authorization objects
> * Specify validation using dns-01 challenges at service-specific DNS
> locations (e.g., _acme-challenge._service.example.com)
I guess you mean _acme-challenge._service._tcp.example.com?
That's where the TXT records would go?
How does providerA vs providerB update that?
I would have assumed the ACME server has to chase the SRV targets down.
> * Enable issuance of certificates containing SRV-ID identifiers per
> RFC 4985
> This allows hosting providers to obtain certificates properly scoped to
> specific services without requiring control over the source domain's
general
> infrastructure.
> *Current Status:* This is an early draft seeking feedback on the overall
> approach before formal submission. I'm particularly interested in any
> concerns about the validation mechanism or security model.
It sounds reasonable.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | IoT architect [
] [email protected] http://www.sandelman.ca/ | ruby on rails [
--
Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list -- [email protected] To unsubscribe send an email to [email protected]
