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

[Stephen Farrell <[e-mail]>]

On 16/12/15 20:11, Michael Wyraz wrote:
> Stephen,
> 
> I fear I have no idea what you mean with a "suffix list" and such. 

(Caveat: I'm very much an amateur at DNS issues, I hope someone
else provides a better/more accurate response if one's needed.)

Pretty much all mechanisms of the kind you envisage end up
requiring a way to allow the "real" authority for a set of
names to control what happens deeper in the hierarchy. So
tcd.ie could decide what cs.tcd.ie are allowed to do with
acme for example. That means you end up needing to know
roughly where the zone cuts are, which is a hard problem
in general. The public suffix list is how that's mostly
done in the web and dbound is (an IETF activity) trying to
tease apart the various uses of that.

So one of the problems with what you suggest is that the
"right" place to look for my web servers is two up in the
hierarchy and not the public suffix and not one up.

S.

> Maybe
> it's what Phillip pointed out in his mail a few minutes ago. I mean a
> SRV record for ACME challenge/response that replaces the A record for
> this use case if pressent.
> 
> Example:
> mydomain.com. IN A 1.1.1.1
> sub1.mydomain.com. IN A 2.2.2.2
> sub2.mydomain.com. IN A 3.3.3.3
> _acme-validate._tcp.sub2.mydomain.com. IN SRV 80 acme.mydomain.com.
> sub3.mydomain.com. IN A 4.4.4.4
> _acme-validate._tcp.sub3.mydomain.com. IN SRV 8080 sub3.mydomain.com.
> 
> 
> ACME server would expect the challenge's response:
> for mydomain.com at http://mydomain.com/.well-kown/...
> for sub1.mydomain.com at http://sub1.mydomain.com/.well-kown/...
> for sub2.mydomain.com at http://acme.mydomain.com/.well-kown/...
> for sub3.mydomain.com at http://sub3.mydomain.com:8080/.well-kown/...
> for subsub.sub2.mydomain.com at
> http://subsub.sub2.mydomain.com/.well-kown/...
> 
> That's exactly the way MX works for mail and SRV works for those
> services that uses it. It behaves exactly as with A, so if the zone contains
> other.mydomain.com. IN NS sometwherelse.com.
> This NS can A records as well as _acme-validate._tcp SRV records for
> other.mydomain.com and all it's subdomains.
> 
> So just don't add this SRV record and you will be as happy as you are at
> the moment (probably more happy since xmas is comming ;-) )
> 
> Kind regards,
> Michael.
> 
> 
> 
> 
>>
>> On 16/12/15 19:29, Michael Wyraz wrote:
>>> An optional ACME SRV record in the spec would make all happy:
>> tl;dr: No, it would not make me happy and I will object to it.
>>
>> Sorry about that but it's just a bad idea;-)
>>
>> We'd need something like the public suffix list for that to
>> work. I really don't want the basic mechanism for acme to
>> depend on dbound. [1] If someone suggests walking the DNS
>> tree to find the RR, then that'll not be accepted by DNS
>> folks - there's lots of history for how that discussion
>> goes.
>>
>> And even if/when the public suffix issue is sorted, it'd
>> still be a bad idea for people in my specific situation.
>> For example, a record in tcd.ie (which is the correct public
>> suffix) could prevent me from getting down.dsg.cs.tcd.ie certified
>> even though the nearest real DNS authority is for cs.tcd.ie who
>> probably would not publish such a record. That would push me
>> back to using self-signed certs which would mean that acme was
>> a step backwards, not forwards. Again, I don't know what the
>> numbers are like for folks in my situation, but every time I
>> have described it, people have recognised it as not uncommon.
>>
>> And even if none of that were an issue, I want (me and others)
>> to be able to use acme to deal with CAs without there being
>> a new complex RA interaction as a part of the basic mode of
>> operation. An optional SRV scheme would inevitably evolve to
>> have that level of complexity. In my case, cs.tcd.ie if they
>> wanted to publish such a record would need a way to point to
>> different PIs (i.e. people) in the department as being the
>> ones who were responsible for authorizing certification
>> requests. And those people would decide to delegate that to
>> some student, so we'd have all sorts of non-trivial delegation
>> issues to tackle if the SRV scheme is to be well-defined.
>> Even optional things need to be well-defined.
>>
>> By all means define an SRV based challenge but I will argue
>> strongly against it's inclusion as an option in the basic
>> mechanism. I will also argue against the basic mechanism
>> having any documentation dependency on such a scheme (because
>> I think it'll take 1-2 more years to get done right). OTOH,
>> if acme gets the basics done and soon and deployed, then I'll
>> be happy to try help with subsequent work on RA features.
>>
>> Cheers,
>> S.
>>
>> [1] https://tools.ietf.org/wg/dbound/
>>
> 
> 
> 
> 
> _______________________________________________
> Acme mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/acme
>