Michael, Been bogged down in other work and finally trying to get caught up on email...
> On Dec 5, 2024, at 7:06 PM, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > > This is what I see as the three hurdles towards securing access to local > resources. > > 1. the name or other identifier that the user types into has to get > translated to an IP address using some local context. mDNS exists and has been the "state of the art" for home networks for a long time now. Local DNS with a local domain also exists, primarily on enterprise networks. > 2. the certificate received has correspond in some way with the name that the > user provided. IoT ACME requires certificates corresponding to the mDNS hostname and/or local FQDN. > 3. the certificate received has to be valid (notBefore/notAfter), and be > signed by one or more subordinate CAs that lead to a trust anchor. IoT ACME formalizes what has been used on enterprise networks for decades - a local trust anchor (root certificate) that is used by the local certificate server (using ACME for what I've proposed vs. some vendor proprietary protocol...) And in my own local testing/prototyping it certainly seems like all of the major browsers have no trouble with this once the trust anchor is configured. > On the public internet, (1) is provided by DNS, (2) is provided by the > subjectAltName (now detailed by RFC9525), and (3) comes from the browser > and/or operating system trust store, along with various CABFORUM rules which > has reduced the validity period from 2+bit years to 1+bit years, and perhaps > soon > to 90 days. > > There are many different ways of getting at these three points. > One reason I am not enthusiastic about Michael Sweet's ACME efforts is > because it does not seem address any of these three points. It's not enough. I don't agree that IoT ACME doesn't address these things - see above. However, equally important is that the current working draft does not address: 1. How to securely connect an IoT device to the local network - "bootstrapping" a secure(ish) identity. 2. How to securely manage certificate requests on the local ACME server - the current model provides a trustable X.509 certificate to anyone that asks, but that has some obvious security issues, even with #1. ________________________ Michael Sweet _______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
