> >This effectively means, as a domain zone admin, I have to trust every single 
> >service I define, not just to properly deliver this service, but also not to 
> >exploit his ability to obtain signed certificates in my name.

> And you are perfectly aware, that this was not the case before ACME-enabled 
> CAs existed, and now applies to every single domain admin on this planet, 
> right?

This absolutely was the case.  Other CA's have had http/https-based service.  
Many do email-based confirmation, which requires that nobody run a "rogue" 
email server, for example.  Others have just replied with similar cases.

The DNS owner must trust or ensure that the hosts he/she is putting into the 
DNS data are behaving properly, for *their own definition of properly.*  This 
was always the case.  Likewise, the host owner must trust or ensure that all 
services on the host are similarly well-behaved, for their own definition of 
behavior.  This was always the case.

> If it was not for security, then why not allow other ports, so you can verify 
> the ownership while for example an application server is bound to that port? 
> The A record does not specify the port anyway.

As you say, the record does not specify the port.  The certificate is *for the 
host* So in essence, your last sentence answers your own question.

But alternative ports as being discussed on the mailing list here.  Have you 
been following it?

_______________________________________________
Acme mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/acme

Reply via email to