A good overview of the problem. Thank you Michael! We may want to start with a use-case document and see how we can interface with other standards. I think the consumer use case (web interfaces on local equipment) and the business use case (web interfaces on local systems) are a bit different.
Maybe a small business user with a broadband router and a consumer are the same from a use-case point of view, but a larger business user may have AD, DNS and other tools to help. A much larger enterprise can establish trust anchors in local equipment for an internal PKI, so they are not really in scope, even though a solution will help them. /O > On 6 Dec 2024, at 01:06, Michael Richardson <mcr+i...@sandelman.ca> wrote: > > Signed PGP part > > 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. We need to think about how technologies like mDNS plays in here > > 2. the certificate received has correspond in some way with the name that the > user provided. Naming is not a big thing in the consumer use case. Some devices provide an identifier to the DHCP server, but not all. Most people name their kids ;-) but not their broadband router. > > 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. > In addition there needs to be automatic renewal of certificates. Distribution of trust anchors will be an interesting issue. Can DHCP servers provide a URL to a trust anchor or the actual trust anchor? Can it be distributed via some DANE-like solution in mDNS? /O > > 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. > > -- > Michael Richardson <mcr+i...@sandelman.ca <mailto:mcr+i...@sandelman.ca>> . > o O ( IPv6 IøT consulting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > I雖曢殜XX黔禬阻��韬{.n�+壏瑉wZ濋殜[h彪m曢^j鳍z阻
_______________________________________________ Acme mailing list -- acme@ietf.org To unsubscribe send an email to acme-le...@ietf.org
