Ryan Sleevi <[email protected]> wrote: > That same logic applies here - we 'could' use a distinct ALPN method, > in which case, omitting the IP is fine. However, including the IP > (albeit, encoded) makes it easier to reason about, dispatch, and less > likely to result in implementation flaws, and in particular, given that > the draft is reusing the ALPN tag of TLS-ALPN, observes the semantics > and security properties required of servers that 'speak' TLS-ALPN.
I ommited your great explanation of the situation. *I* think that certificates bound to IP addresses are useful for things like server management systems (Dell DRACs, HP iLO, IBM RSA..). As such, there are no cloud issues involved. A second use case is for end-systems to get certificates for use in things like TLS ClientCertificates. I can see my desktop or appliances doing this given that they might have a stable IPv6 addresses. Few users would have stable, public IPv4 today though. ACME could still be used to talk to internal CAs though. You have a different use case, and I still don't understand it. Maybe the document needs an applicability statement. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [
signature.asc
Description: PGP signature
_______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
