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/
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
