Julian, On 16/12/15 09:22, Julian Dropmann wrote: > If the owners of the domain decide you not to give you write access to > their zone, there is probably a reason for that. > And this reason is that _they_ want to remain in control. > > So why do you even assume that you should be able to obtain a certificate > for their domain if you do not even have control over that zone? > In my opinion that is exactly the definition of what CAs should verify: If > the requester has control over the zone the CA signs the certificate for. > If the CA issues a certificate for the whole zone, it has to check if this > happens in consent with the people who have control over that entire zone, > and not just one guy running a service there. > > You push this discussion in a direction where its all about ease of use for > the guy running the box to obtain a certificate. > But please explain to me then, why the host behind an A record should have > that legitimization.
I'm sorry but I am not seeing what else there is to explain. But I'll try one more time. I control the hosts in question and have for >10 years, even through h/w upgrades. The university don't care that I have been using self-signed certs for all that time and now don't care that I can finally present a cert that verifies in a browser. They are happy enough to trust me to not mess about inside the college network. All of that is entirely legitimate. S. > > On Wed, Dec 16, 2015 at 3:26 AM, Stephen Farrell <[email protected]> > wrote: > >> >> Hiya, >> >> On 16/12/15 01:44, Julian Dropmann wrote: >>> The target users are server admins right? In order to set up their >>> services, they should be familiar with DNS. >> >> Familiar with != has write access to. >> >> In my university, I have root on 24U of boxen with zero write >> access to the routers, f/w, DNS or mail servers, meaning that >> for 13 years I couldn't get the two that are publicly visible >> web servers certified by any CA any time I checked, which was >> admittedly not that often. > > >> ACME (via LE in that case, but I've no allegiance) fixed that >> in a couple of minutes. And those minutes didn't require deep >> knowledge of anything - relative ignorance would have worked >> just as well, which is fantastic:-) >> >> And before someone argues, sure there are other situations but >> our goal here is to define a protocol that works in the most >> common of those cases as easily as possible and that supports >> automation. >> >>> To use the current >>> mechanism they already need to configure the A record. >> >> Not necessarily the same admins. That much is pretty obvious >> and unless someone has demographics about how many sysadmins >> have what access to what (which would be great!) I think this >> is repetitive argument and therefore pointless. >> >> Cheers, >> S. >> >> >>> So whats the >>> big difference? Instead of an A record they need to use an SRV >>> record. So technically only the record type changes. Nothing else. >>> How is that even a higher level of interaction? >>> >>> There are other services requiring admins to create DNS records >>> (Google Apps for example). They are being used. >> >> > > > > _______________________________________________ > Acme mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/acme > _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
