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

[Phillip Hallam-Baker <[e-mail]>]

On Wed, Dec 16, 2015 at 2:54 PM, Stephen Farrell
<[e-mail]> wrote:
>
>
> 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.

I have no idea how this relates to the choice of A or SRV records.

CAs already have to cope with the public suffix list issues. That
has been part of being a CA since forever.


> 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.

We already went through all that on RFC6844 (CAA).

CAs are required to climb the tree. BUT to be compliant with the
specification, they are only required to state what they do when
authorization is denied.

The assumption built into CAA is that if someone delegates part of a
domain, they are also delegating the cert issue authority. So
cs.tcd.ie does not get to set policy for down.dsg.cs.tcd.ie once they
have delegated control of the DNS there.


> 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.

I don't see how SRV makes things more complex. That might be
because I am more comfortable with SRV or it might be because I
think the basic A record validation is a bigger can of worms than you
imagine.

The complication factor here isn't the use of SRV vs A record, it
is the decision to automate. We have automated systems but
they will fallback to manual processes when a corner case is
encountered. Trying to cover every corner case is what is making
this a lot hairy-er.


> 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.

Consider pi.dsg.cs.tcd.ie, a $5 Raspberry Pi.

* Might it require a TLS cert? - Yes!
* Might it need this to be a WebPKI cert? - Possibly not.
* Should this be a wildcard cert for *.tcd.ie? - EEEK!

The thing that probably isn't obvious to folk who don't operate PKI is
that if the cert isn't a WebPKI cert, it is almost certainly going to
have to be issued under an RA to be any use to anyone at all.

So what looks like a useful tool to remove your student's need for a
WebPKI and a reduction in vulnerability actually opens up the
requirements you don't want to consider.


> 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.

I think it will take exactly as long to understand the nature of the
problem regardless of the nature of the solutions you accept.