Re: [Acme] Want client-defined callback port

[Richard Barnes <[e-mail]>]

On Thu, Apr 16, 2015 at 10:50 PM, Bruce Gaya <[e-mail]> wrote:

>
> On 16 Apr 2015, at 18:57, Richard Barnes <[e-mail]> wrote:
>
> Right.  The property that we're trying to authenticate here is that the
> ACME client controls something associated with the hostname.  Ideally, this
> would be the person with write access to the zone file (cf. DNS
> challenges), but to facilitate validation, modern validation accepts
> validation of things like controlling an HTTP or HTTPS server.  It's less
> clear that it would be acceptable to validate that someone can provision a
> service on, say, port 36707.
>
> That said, the ability to do domain validation without service
> interruption seems like an important requirement.  It seems like the DNS
> challenge listed in the current draft meets that requirement.  We should be
> able to design the simpleHttps challenge so that you just have to to
> provision an extra file on an HTTPS server, not reconfigure it.
>
> --Richard
>
> On Thu, Apr 16, 2015 at 8:56 PM, Nico Williams <[e-mail]>
> wrote:
>
>> You have to be able to prevent unauthorized users from using this
>> alternative callback port to get certs with which to impersonate your
>> service.
>>
>
> The server (ACME client) computer may be shared between various
> administrators.  It may also have multiple DNS names and host multiple
> services.  If I use ACME to get a certificate for a non-web service, like a
> CalDAV service (default https port = 8443). I do not want to touch or
> reconfigure the web server or (whatever happens to be using port 443) just
> to get a cert for CalDAV.
>

This argument seems a little confused.  The certificates that CalDAV uses
are not "certs for CalDAV", they're DV certificates just like any others --
if you can get a cert for CalDAV, then you can use it for, say, HTTPS as
well.

>From that perspective, letting the CalDAV admin get a certificate for the
whole domain seems even a little reckless.  Likewise, requiring the CalDAV
admin to coordinate with the HTTPS admin, or someone else in the management
for the domain, doesn't seem unduly burdensome.

Now, if your concern is about CalDAV in particular, and not arbitrary
ports, you could define a validation mechanism that uses CalDAV explicitly,
so that a server could offer to validate that way.  That would address
another major gap in your proposal, namely what interaction should happen
over the client-selected port.

--Richard




>
> - Bruce
>
>