Re: [Acme] Issuing certificates based on Simple HTTP challenges

[Julian Dropmann <[e-mail]>]

If they trust you with that, they could just add an ACRE specific SRV
record, and thereby delegate that privilege to create certs to you and
everything would be fine.
They were able to do this with the A record too.

I just do not find it intuitive in general that by defining any record you
do this implicitly as a domain owner.
At least I personally was not expecting this, but maybe its just me that is
so stupid.

And the question was not about whether you personally are legitimated to
create certs for your university, but whether this should be the case for
any host of every single zone.

On Wed, Dec 16, 2015 at 1:01 PM, Stephen Farrell <[e-mail]>
wrote:

>
> 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 <
> [e-mail]>
> > 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
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/acme
> >
>