Subject: [Acme] IP addresses

From: James Cloos <[email-masked]>
Date: Wed, 25 Mar 2015 09:51:15 -0400

There are cases where a cert covering both a dns name and its matching
ip addresses has value.  With SIP, for instance, it is common that urls
have ip rather than dns.  Remote validation therefore requires those
address(es) in the certs.

Even though web sites are the primary target, enabling other tls usages
is desirable.  Especially when it is reasonably easy.

(And I'll note that many SIP servers speak http, too.  Both for things
like webrtc, but also for control/monitoring and the like.  They may
also create custom per-call web pages for sip phones to display when
ringing.  All of which benefit from -- or even require -- https.  So
using acme to get certs for them is reasonable and can use the same auth
methods acme uses for web servers.)

Will acme support CSRs with not just dns names in subjectAltNames, but
also ip addresses?  Verifying that the dns name(s) resolve to the ip
address(es) is reasonable in such cases.

-JimC
-- 
James Cloos <[email-masked]>         OpenPGP: 0x997A9F17ED7DAEA6

---

From: Jacob Hoffman-Andrews <[email-masked]>
Date: Wed, 25 Mar 2015 10:48:11 -0700

> address(es) is reasonable in such cases.
This is more a question of policy for the implementing CA than a
protocol question, though validating IP addresses might require a new
type of challenge response.

---

From: Richard Barnes <[email-masked]>
Date: Wed, 25 Mar 2015 13:17:18 -0500

Automated validation of IP addresses seems pretty fraught to me.  You need
to verify not only that the applicant controls the IP address in question,
but also that he will continue to control it for some period of time, e.g.,
that it won't be assigned to some other DHCP client in 20 minutes.  The
definition of "control" is also a lot more fuzzy -- the 15 hosts behind my
home NAT are indistinguishable from the point of view of an ACME server.

So I would put IP addresses in the bin of "not amenable to automated
validation".  The only path I see to automatic IP address validation goes
through the RPKI, which implies that it is not a near-term proposition.

--Richard

On Wed, Mar 25, 2015 at 12:48 PM, Jacob Hoffman-Andrews <[email-masked]>
wrote:

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

---

From: James Cloos <[email-masked]>
Date: Wed, 25 Mar 2015 15:24:29 -0400

>>>>> "RB" == Richard Barnes <[email-masked]> writes:

RB> Automated validation of IP addresses seems pretty fraught to me.
RB> You need to verify not only that the applicant controls the IP
RB> address in question, but also that he will continue to control
RB> it for some period of time

Ok, yes.  It would have to be for static assignments only, and that is
difficult.

Would a >> name >-a/aaaa-> address >-ptr-> same_name << trip be enough?

-JimC

---

From: Martin Thomson <[email-masked]>
Date: Wed, 25 Mar 2015 14:39:02 -0500

> Would a >> name >-a/aaaa-> address >-ptr-> same_name << trip be enough?

Not really.  The PTR records are populated dynamically, so there is no
way to be sure that they are valid for the sort of duration that I
think this group cares about.  (Basically, these can have the same
sort of lifetime as a DHCP lease.)

---

From: Richard Barnes <[email-masked]>
Date: Wed, 25 Mar 2015 17:03:10 -0500

> sort of lifetime as a DHCP lease.)

And indeed, I have seen several deployments where the PTRs are dynamically
populated based on DHCP.