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

[Stephen Farrell <[e-mail]>]

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
>