Subject: [Acme] Want client-defined callback port

From: Bruce Gaya <[email-masked]>
Date: Wed, 15 Apr 2015 20:04:29 -0700

Hello Acme  list,

I want to use an ACME client to get a new certificate without taking down my existing web services that are using a port 443 (with a self-signed certificate or a certificate issued by another CA).

I therefore request that the Response payloads for Challenge messages that will later lead to server-to-client callback, such as Simple HTTP and DVSNI, include an optional  port number. The ACME server would then use the optional port when calling back to the client.  If no optional port is specified, the server would use port 443.

Thanks,
Bruce

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Thu, 16 Apr 2015 18:09:29 -0400

> I want to use an ACME client to get a new certificate without taking down my existing web services that are using a port 443 (with a self-signed certificate or a certificate issued by another CA).
Right now the Simple HTTP and DVSNI challenges are designed specifically
to work well with a running server. For the DVSNI challenge type, the
web server must support config reloads without downtime in order to make
the test cert available under a special SNI name. Can you tell us more
about why these approaches won't work for you?

Thanks,
Jacob

---

From: Bruce Gaya <[email-masked]>
Date: Thu, 16 Apr 2015 16:10:28 -0700

> On 16 Apr 2015, at 15:09, Jacob Hoffman-Andrews <[email-masked]> wrote:
> 
> about why these approaches won’t work for you?

Because using a client-defined port for call backs does not have the requirement you just mentioned,  That leads to simpler ACME client design. 

Why must there be a dependency on another process that is already using port 443?

Bruce

---

From: Nico Williams <[email-masked]>
Date: Thu, 16 Apr 2015 19:56:35 -0500

You have to be able to prevent unauthorized users from using this
alternative callback port to get certs with which to impersonate your
service.

---

From: "Salz, Rich" <[email-masked]>
Date: Fri, 17 Apr 2015 01:48:12 +0000

> Because using a client-defined port for call backs does not have the
> requirement you just mentioned,  That leads to simpler ACME client design.

It's a trade-off.  On many common server systems being able to manipulate what's on 443 requires more privileges, and therefore is a stronger answer about "ownership" then, say, standing up some little scripting language server on port 55530

Having validation rely not just on the domain, but on the 443, seems like a good thing.

--  
Senior Architect, Akamai Technologies
IM: [email-masked] Twitter: RichSalz

---

From: Richard Barnes <[email-masked]>
Date: Thu, 16 Apr 2015 21:57:16 -0400

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 <[email-masked]>
wrote:

> _______________________________________________
> Acme mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/acme
>

---

From: Bruce Gaya <[email-masked]>
Date: Thu, 16 Apr 2015 19:50:56 -0700

> On 16 Apr 2015, at 18:57, Richard Barnes <[email-masked] <mailto:[email-masked]>> 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 <[email-masked] <mailto:[email-masked]>> wrote:

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.

- Bruce

---

From: Randy Bush <[email-masked]>
Date: Fri, 17 Apr 2015 12:09:27 +0900

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

can't you use DV?  you can't have your cheese and eat it too.

randy

---

From: Richard Barnes <[email-masked]>
Date: Fri, 17 Apr 2015 08:08:55 -0400

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

>
> On 16 Apr 2015, at 18:57, Richard Barnes <[email-masked]> wrote:
>
> 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
>
> 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

---

From: Bruce Gaya <[email-masked]>
Date: Tue, 21 Apr 2015 15:19:00 -0700

> On 17 Apr 2015, at 05:08, Richard Barnes <[email-masked]> wrote:
> 
> 
> 
> On Thu, Apr 16, 2015 at 10:50 PM, Bruce Gaya <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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.  

The real scenario is that some application may already have a web server instance running on port 443 for any number of reasons.  Now another application, say CalDAV administration, wants to get a certificate using ACME. With the current port 443 callback requirement, all the CalDAV administration application can do is display an error message.  But this is completely unnecessary and adds nothing, IMHO, to system security.  It would be much, much better for certificate issuance to “just work”. (I note that the current Let’s Encrypt Demo client has this same issue even when using the “stand-alone” authenticator.)

Of course a particular CA may require port 443 callbacks to issue a certificate, fine. But that policy should not be built into the ACME protocol.

I would encourage the Let’s Encrypt CA to allow *any* client-defined port for SimpleHTTS and DVSNI callbacks because I want the ACME client to “just work” without unneeded user actions.

Bruce

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Apr 2015 01:23:48 +0000

I understand that you want it to “just work” (you said that a couple of times :), but other folks have raised security concerns – do you understand or agree with them?

One way forward is to say a client MAY specific a port, where the default is 443. An ACME server MAY reject requests for ports other than 443 if it is in violation of the operating policy.

Does that work?

---

From: Bruce Gaya <[email-masked]>
Date: Tue, 21 Apr 2015 19:53:25 -0700

> On 21 Apr 2015, at 18:23, Salz, Rich <[email-masked]> wrote:
> 

I agree that client access to ports below 1024 usually requires more privileges and that’s generally safer than allowing any client port.

> One way forward is to say a client MAY specific a port, where the default is 443. An ACME server MAY reject requests for ports other than 443 if it is in violation of the operating policy.

That would work.

The policy of Let’s Encrypt Certificate Authority, however, is very important!   I also would very much like that CA to allow client-defined callback ports below 1024.

Bruce

---

From: Viktor Dukhovni <[email-masked]>
Date: Wed, 22 Apr 2015 04:09:47 +0000

On Tue, Apr 21, 2015 at 07:53:25PM -0700, Bruce Gaya wrote:

> The policy of Let's Encrypt Certificate Authority, however, is
> very important!   I also would very much like that CA to allow
> client-defined callback ports below 1024.

That level of diligence would finally expose the security of
certificate issuance for the charade that it is.  If the LE CA
adopted this policy, I would expect its certificates to be worth
exactly the price charged for them.  Relying parties should not
trust such a CA.

Of course relying parties should also not trust certificates based
on many of the other types of "it just works" issuance practices.
For example, certificates issued on the basis of the ability to
respond to an insecure email sent to an "admin" mailbox at the
domain, etc.

However much we pretend otherwise, the only party in position to
make a low (near zero) cost assurance that a particular owner
legitimately controls a given domain is the domain registrar.

The domain owner can attempt to demonstrate such control by injecting
"cookie" records into the DNS, but such demonstrations are subject
to MiTM attacks on the DV certificate issuing CA.

So in my view DV certificates are largely worthless (not significantly
better than unauthenticated TLS, and are used only because HTTPS
insists on an often meaningless CA signature).  The fact that LE
helps to bring the cost, including deployment costs, of meaningless
certificates to $0 is I guess progress.

-- 
	Viktor.

---

From: "Salz, Rich" <[email-masked]>
Date: Wed, 22 Apr 2015 11:26:07 +0000

> The policy of Let’s Encrypt Certificate Authority, however, is very important!   I also would very much like that CA to allow client-defined callback ports below 1024.

While many LE folks are on this list, you'll need to take that up with them over on some other forum.   To bring back an old phrase, this list is about mechanism, not policy. 

	/r$

---

From: Richard Barnes <[email-masked]>
Date: Wed, 22 Apr 2015 18:10:13 -0400

On Tue, Apr 21, 2015 at 10:53 PM, Bruce Gaya <[email-masked]> wrote:

>  I understand that you want it to “just work” (you said that a couple of
> times :), but other folks have raised security concerns – do you understand
> or agree with them?
>
>
> I agree that client access to ports below 1024 usually requires more
> privileges and that’s generally safer than allowing any client port.
>

So would you be OK with the spec saying that the server MUST reject
client-specified ports that are greater than 1023?

> One way forward is to say a client MAY specific a port, where the default
> is 443. An ACME server MAY reject requests for ports other than 443 if it
> is in violation of the operating policy.
>
>
> That would work.
>

Let's return to the question of protocol, however.  The CA needs to know
how to validate the challenge.  Are you envisioning that this would be an
extension to the simpleHttps challenge, so that the validation would still
be done using an HTTP request to a .well-known URI, just on a different
port?

--Richard

>
> The policy of Let’s Encrypt Certificate Authority, however, is very
> important!   I also would very much like that CA to allow client-defined
> callback ports below 1024.
>
> Bruce
>
>
>
>

---

From: Bruce Gaya <[email-masked]>
Date: Wed, 22 Apr 2015 15:23:00 -0700

> On 22 Apr 2015, at 15:10, Richard Barnes <[email-masked]> wrote:
> 
> 
> 
> On Tue, Apr 21, 2015 at 10:53 PM, Bruce Gaya <[email-masked] <mailto:[email-masked]>> wrote:
> 
>> On 21 Apr 2015, at 18:23, Salz, Rich <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> So would you be OK with the spec saying that the server MUST reject client-specified ports that are greater than 1023?

Yes.  

Because the ACME client code will run as root any unused port will work so I am happy with this restriction.  My intention is for the ACME client to be as independent as possible from other running services.

> Let's return to the question of protocol, however.  The CA needs to know how to validate the challenge.  Are you envisioning that this would be an extension to the simpleHttps challenge, so that the validation would still be done using an HTTP request to a .well-known URI, just on a different port?

Yes.  As a developer, it’s easier to have the ACME code be completely separate rather than coordinate with another process.

Bruce

---

From: Richard Barnes <[email-masked]>
Date: Wed, 22 Apr 2015 18:24:23 -0400

On Wed, Apr 22, 2015 at 6:23 PM, Bruce Gaya <[email-masked]> wrote:

> Because the ACME client code will run as root any unused port will work so
> I am happy with this restriction.  My intention is for the ACME client to
> be as independent as possible from other running services.
>
>
>
> Yes.  As a developer, it’s easier to have the ACME code be completely
> separate rather than coordinate with another process.
>

OK.  That at least seems well-defined to me.  I could probably live with it
if others are comfortable.

--Richard

---

From: Ted Hardie <[email-masked]>
Date: Wed, 22 Apr 2015 16:09:17 -0700

Forgive the top posting, but I want to be sure I understand something.  If
the client specifies a port that is below 1024 but canonically used for
something else, what is the specified behavior?  My reading of the thread
so far is that the server would expect to run ACME over it, even if were
specified for, say, LDAP (389).

Is that what folks expect?

Ted

On Wed, Apr 22, 2015 at 3:24 PM, Richard Barnes <[email-masked]> wrote:

>>>  I understand that you want it to “just work” (you said that a couple
>>> of times :), but other folks have raised security concerns – do you
>>> understand or agree with them?
>>>
>>>
>> Because the ACME client code will run as root any unused port will work
>> so I am happy with this restriction.  My intention is for the ACME client
>> to be as independent as possible from other running services.
>>
>>
>>
>>> One way forward is to say a client MAY specific a port, where the
>>> default is 443. An ACME server MAY reject requests for ports other than 443
>>> if it is in violation of the operating policy.
>>>
>>>
>>> That would work.
>>>
>>
> OK.  That at least seems well-defined to me.  I could probably live with
> it if others are comfortable.
>
> --Richard
>
>
>
>>
>> Bruce
>>
>
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Apr 2015 17:23:07 -0700

On Apr 22, 2015 4:09 PM, "Ted Hardie" <[email-masked]> wrote:
>
> Forgive the top posting, but I want to be sure I understand something.
If the client specifies a port that is below 1024 but canonically used for
something else, what is the specified behavior?  My reading of the thread
so far is that the server would expect to run ACME over it, even if were
specified for, say, LDAP (389).
> Is that what folks expect?

Just to get this on the record, I think that we should have some advice
that suggests a set of ports (other than 1024+) that are off-limits. I note
that browsers are unwilling to connect to certain ports because of the
concerns you allude to, we can recommend that the CA policy do the same
(and be advised by the experience of browsers here). 389 is on that list,
25 probably too.

I can try to find the list that Firefox uses if people think that is good
advice to include.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Wed, 22 Apr 2015 21:51:12 -0400

I think this discussion is getting way too deep into the weeds of
policy. That isn't a concern IETF has generally taken a definitive
stand on. If it had there would not have been the need to set up
CABForum outside IETF.

As I see it the specification should allow:

* A mechanism for the client to indicate the proof(s) of DNS control
it can provide.

* A mechanism for the service to indicate the proof(s) of DNS control
it will accept.

Who offers and who chooses is something the protocol can make a
decision on but it is probably best if a 'no' from the service is
accompanied by a list of what is acceptable.

It is useful for IETF to provide security considerations on particular
proofs but IETF cannot and should not choose. That is ultimately up to
the people who write the path validation code and the data it consumes
(including root lists). They bear the liability, unless they can
figure out how to hand the hot potato to someone else.

Another reason to not make the choice in IETF is that this is not a
once and for all decision. It is a decision that should be under
constant review.

---

From: Peter Eckersley <[email-masked]>
Date: Wed, 22 Apr 2015 19:33:58 -0700

> client-specified ports that are greater than 1023?

I'd support adding a mechanism to ACME to run one of the available
challenge types on a non-443 but privileged port, if the client needs it
for practical reasons (whether Let's Encrypt should use that mechanism
is a different question, of course).

It seems to be a bad idea to leave the choice of privileged port up to
the client, or even up to the client but constrained by a short
blacklist (Martin Thompson's suggestion).  The problem is that there is
an enormous diversity of software deployed on privileged ports, and it's
very hard to tell when some of that software might be trickable by
remote attackers into responding in a way that causes a Challenge to
succeed.

So the CA should have a policy of only allowing validation on perhaps
0-2 of the other ports below 1023, with that choice backed by fairly
thorough research, and then the question will be how the client knows
the CA's policy, and which port it should try to ask for.

Perhaps those policies can be stored out of band, or perhaps we can add
a separate REST API endpoint where clients ask what ports the server
considers acceptable for DV Challenges.

-- 
Peter Eckersley                            [email-masked]
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

---

From: Martin Thomson <[email-masked]>
Date: Wed, 22 Apr 2015 21:09:12 -0700

> considers acceptable for DV Challenges.

Or just pick port 100 (or another that isn't already taken) and say
443 or _that_.  I can't imagine you would need to have many numbers
before you found one that was free.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 Apr 2015 09:16:18 -0400

On Wed, Apr 22, 2015 at 9:51 PM, Phillip Hallam-Baker <[email-masked]

> * A mechanism for the service to indicate the proof(s) of DNS control

I thought that's what this thread was about :)

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 Apr 2015 09:18:50 -0400

> before you found one that was free.

This seems like a simpler and safer option to me.  Register an ACME port
and use that if HTTPS isn't feasible.

Bruce, would that meet your use case?  That is, in your scenario, can the
CalDAV service open a new (privileged) port, or does the ACME verification
have to happen on the CalDAV port?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Apr 2015 09:37:14 -0400

On Thu, Apr 23, 2015 at 9:16 AM, Richard Barnes <[email-masked]> wrote:
>
>
> On Wed, Apr 22, 2015 at 9:51 PM, Phillip Hallam-Baker
> <[email-masked]> wrote:
>>

No, people were discussing the stuff that I said should be left to CABForum.

An IETF working group is temporary. They are not meant to be permanent
institutions.

Why beat ourselves up here deciding an issue that we can't decide here?

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 Apr 2015 10:16:49 -0400

On Thu, Apr 23, 2015 at 9:37 AM, Phillip Hallam-Baker <[email-masked]

> Why beat ourselves up here deciding an issue that we can't decide here?

We can design mechanisms here that we believe have a sufficient level of
security.  CABF and the individual CAs are free to opine on whether those
mechanisms are suitable for a given context.

In other words, it is my earnest hope that the validation methods listed in
Section 11.1.1 of the BRs [1] will not be designed by the CABF, but
selected from a list that IETF defines.  CABF is not an engineering
organization, after all.

--Richard

[1] https://cabforum.org/wp-content/uploads/BRv1.2.5.pdf

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Apr 2015 11:28:48 -0400

On Thu, Apr 23, 2015 at 10:16 AM, Richard Barnes <[email-masked]> wrote:

> Section 11.1.1 of the BRs [1] will not be designed by the CABF, but selected
> from a list that IETF defines.  CABF is not an engineering organization,
> after all.

I think we can decide on a mechanism. But getting into long arguments
as to whether ports other then 443 should be accepted or if so which
ones seems to be unnecessary.

IETF should deliver

* A mechanism with sufficient agility and flexibility
* Security considerations explaining the consequences of a CA
permitting various approaches

Then let the decision of which ports are to be allowed and when to CABForum.

This is exactly what happens with crypto algorithms. IETF has
described dozens of algorithms and curves for ECC, CABForum has chosen
RSA plus three of the NIST curves.

What I am saying is let CABForum select the color to paint the bike
shed but point out where the choice has consequences.

---

From: Richard Barnes <[email-masked]>
Date: Thu, 23 Apr 2015 11:40:15 -0400

On Thu, Apr 23, 2015 at 11:28 AM, Phillip Hallam-Baker <
[email-masked]> wrote:

> selected

I think what we're arguing about here is what constitutes "sufficient
flexibility".  That is, if there's not a need to open up arbitrary ports,
then a scheme with a single reserved non-443 port might provide sufficient
flexibility.

--Richard

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 23 Apr 2015 15:56:08 +0000

> I think we can decide on a mechanism. But getting into long arguments as to
> whether ports other then 443 should be accepted or if so which ones seems
> to be unnecessary.

I am fully in favor of mechanism, not policy.  But we would HAVE to change the protocol to allow a port to be specified.

It's a slippery slope.  Taking your argument only a little bit further, should PKIX have shut down once CABForum spun up?

If you're not a browser or well-established CA, you need special dispensation to join[1].  That leaves a very important community -- users[2], who haven't been well-served by previous efforts in this area -- out.  I am not sympathetic to "just let CABForum do it" arguments.

	/r$

[1] https://cabforum.org/information-for-potential-members/
[2] some reference to classic Tron here.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 23 Apr 2015 13:01:53 -0400

> I am fully in favor of mechanism, not policy.  But we would HAVE to change the protocol to allow a port to be specified.

The protocol has to support multiple validation mechanisms, not all of
which are going to be relevant to WebPKI. So one approach would be to
say 'if you are going to use a port other than 443 then its a
different mechanism that is out of scope for now'.

> It's a slippery slope.  Taking your argument only a little bit further, should PKIX have shut down once CABForum spun up?

Some say it should have shut down earlier.

PKIX does not just support the WebPKI. It also has all the peculiar
policy constraint curlicues.

> If you're not a browser or well-established CA, you need special dispensation to join[1].  That leaves a very important community -- users[2], who haven't been well-served by previous efforts in th…

Well both sides have a veto power as far as the WebPKI goes. So if
IETF wants to say '443 or nothing' it certainly can make it stick.
Alternatively it can leave the choice of port blank and let CABForum
decide if they want to choose one or more for WebPKI. But deciding
other port numbers seems to me to be down in the weeds. Its like
offering fifty options for desert to a child who will only eat mac and
cheese.

Another point to consider here is the framing of the problem. People
are discussing this as validating a certificate request. I think that
is the wrong way to look at it. What we are doing is to validate the
holdership of a DNS name. Which is not the same thing. That may be a
component of a certificate validation process but it is not
necessarily one that would apply to every certificate issue.

Ten years from now, I would expect we will be using short lived certs
that roll every 24 hours, that every service has a separate cert and
the default configuration for systems is load balanced and fault
tolerant.

In that configuration a SOHO configuration using a couple of off the
shelf appliances is going to be consuming two sets of half a dozen
certs every day. I don't think we need to do twelve separate domain
validations every day. In fact I don't think we really need or want to
do validation every day. Or at least I don't want to be using this
particular scheme on a repeat basis.

What I would prefer is to validate the certificate applications under
a device key and push the fingerprint of the two device keys out into
the DNS (It was one of the extended use cases for CAA records). So if
the DNS record changes we can infer that a change of control has
occurred and we want to retest holdership.

Now would such a scheme eliminate the need for a port443 check? Well
it certainly does not support the 'run this one program and go'
scenario so it can't be the only scheme. And I am not even sure that
CAA record validation alone is sufficient for reasons I don't want to
go into right now.

But looking at where we are likely to go with ACME, I think we could
make a good case for 443 validation only right now and punt on the
question of seamless issue for protocols on ports other than 443 where
there isn't a connection to the Web server.

The protocol we are designing right now is the one I think will be the
LRA<->CA protocol long term. I think we want the device<->LRA protocol
to do a bit more. In particular I think stuffing HSTS/HPKP records
into the DNS is a no brainer and we probably want to configure the A,
AAAA, SRV etc records as well.

---

From: Bruce Gaya <[email-masked]>
Date: Thu, 23 Apr 2015 10:12:22 -0700

> On 23 Apr 2015, at 06:18, Richard Barnes <[email-masked]> wrote:
> 
> 
> 
> On Thu, Apr 23, 2015 at 12:09 AM, Martin Thomson <[email-masked] <mailto:[email-masked]>> wrote:
> On 22 April 2015 at 19:33, Peter Eckersley <[email-masked] <mailto:[email-masked]>> wrote:
> This seems like a simpler and safer option to me.  Register an ACME port and use that if HTTPS isn't feasible.
> 
> Bruce, would that meet your use case?  That is, in your scenario, can the CalDAV service open a new (privileged) port, or does the ACME verification have to happen on the CalDAV port?
> 

Any port that is currently unused on the client is fine with me.  (CalDAV was just as example.)

Bruce

---

From: Viktor Dukhovni <[email-masked]>
Date: Thu, 23 Apr 2015 17:20:43 +0000

> necessarily one that would apply to every certificate issue.

Amen.

> there isn't a connection to the Web server.

Agreed, and as you note even 443 checks are really not the right
proof of "holdership".  So there'll be more work to do to flesh
out the whole architecture.

-- 
	Viktor.