Re: [Acme] SNI extension for tls-alpn-01 challenge in draft-ietf-acme-ip-05

[Michael Richardson <[e-mail]>]

Ryan Sleevi <[e-mail]> 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  [ 
]     [e-mail]  http://www.sandelman.ca/        |   ruby on rails    [