In a way - I somewhat wasn't aware handling of certificates in case of mail (MX) records (thus target domain certificate is presented instead of the one pertaining to the main domain).
However - I'd argue it's due to historical usage and "it's been done this way" and avoiding breaking things more than anything. There was an RFC with SRV records for mail but noone is using it…
Interestingly enough the first one is by P. Saint-Andre, which is basically a grandfather of XMPP and the second one is by A. Melnikov from Isode (one of the more known XMPP server implementations)
Yes.
Though your explanation is a bit problematic - I know I can't obtain certificate for the exact service record (i.e. _xmpp._tcp.example.com) but the certificate would be for the actual domain and not the service (example.com).
We are doing that (with deployment hook that @griffin mentioned) but - it's rather more advanced for typical user. They may be fine adding DNS records (SRV for example) to have their domain handled by external XMPP entity but doing the above (setting temporal http server and either doing redirects or creating and configuring post-update hook may be above what they can do.
Going back to the example of hosting your website on github pages (which handles obtaining LE certificate) - you have a guide, prepare the website and then you only have to add couple of DNS records and "it works". Noone is telling you "spin up temporary webserver and use post-update hook". Granted, that it works because main domain (A record) points to github so everything "just works" but I'd argue it's because the current state: everyone settling on http and everything else being afterthought. It completely ignores possibility to run a service on same domain under different port/protocol (at least in the context of obtaining certificate).
Though It may also be a problem of trying to mould/bend http-01 verification and maybe something more flexible like completely new srv-01 protocol would be better in this case.
Though I was slightly confused on the connection of the above two points (scoped permissions and dns-02): my understanding of the draft proposal was that it would be possible for multiple entities to perform validation without crating a conflict (multiple entities updating the entry) however if there is a random identifier wouldn't that somewhat break the scoped-permissions policy? Though I guess dns-account-01 would be responsible for obtaining "stable token ID" which could then be used to grant (stable) permission/policy?
AWS does support very fine-grained permissions for DNS updates a couple years now. I have an identity set up that only has access to the one TXT record that a system needs to update, and that's what the instance of lego on that system uses to get a certificate.
It may be that the certbot plugin documentation should be updated to recommend it.
So I haven't looked into the draft closely (I probably should at some point), but for existing DNS-01, if you're providing a service that needs a certificate, in addition to the XMPP SRV record the system could add a CNAME for _acme-challenge to your system, and your system could then get a certificate. But then only you could use DNS-01 to get a certificate, and the "normal" domain name owner wouldn't be able to. With the proposed additional challenge types, you'd get your very own subdomain hostname for the domain owner to add as a CNAME, so it wouldn't interfere with any other usages that other systems might want.
But I think that it may be worth looking more into whether the clients are supposed to be using the original hostname, or the SRV-pointed-to-name, when validating certificates. It's still not clear to me which is the "right" behavior, and if you're looking to work on updating standards and specifications, I suspect that that's the area that's more likely to need help than the CA validation end of things.
I think the issue is not about ownership but rather about concurrency and multiple actors colliding when tryging to obtain the certificate. Using DNS-01 in low-concurrent environment shouldn't be that much of an issue (chances of running the update/challnge at the same time being lower).
Hmm... in case of XMPP I'm 100% sure it's the original hostname/main domain (so example.com) and not the SRV target.
cf.
(it's about starttls but directtls uses same logic)
The receiving entity SHOULD choose which certificate to present based on the domainpart contained in the 'to' attribute of the initial stream header (in essence, this domainpart is functionally equivalent to the Server Name Indication defined for TLS in [TLS‑EXT]).
(where mentioned to is actual entity domain, e.g. gmail.com or somesuch)
If both systems are updating the TXT record directly, then yes you only have to worry about concurrency. Though the DNS protocol supports multiple TXT records for the same name, so if the DNS provider and ACME client are smart enough about only adding and removing their own specific records then even updating at the same time can work.
The trouble comes when DNS providers aren't quite as sophisticated, and so people want to have _acme-challenge delegated somewhere else via CNAME or NS to another system. That can of course only happen once, so both systems wanting to update it would need to agree on what system it should be delegated to, which may not be easy if they're different vendors trying to integrate their existing solutions. That's the use case where having different names for each ACME account or system for them to individually control can make more sense, and I think is why people are proposing those updates to the ACME challenge types.
Yup, that's the use case here... and possibly doing mixing of HTTP-01/DNS-01 - being able to set said static hostname for verification purposed (http-01 endpoint) would also work/be convenient - user wouldn't have to deal with creating policy/users to update DNS but rather only add single "service TXT entry" pointing to the actual verification system (it would be in a way akin to "service discovery").
(from what I read the proposed draft is more about per-service DNS identifier and it does nothing about re-using it as endpoint for a service that would be doing verification -- maybe a possibility for yet another extension?)
