My main point was that we seem to be trying to build workarounds for a problem
that exists (IMHO ONLY) for targets/URLs that may need to be entered by muggles
into browsers. For this case, W3C has come up with a nice useful approach:
- URLs need to have muggle safe, simple human recognizeable domain names
- The authenticity of the domain names is validated via a WebPKI certificate
But because of the dominance of this use case, it seems that all software and
solutions
we're working on are viewed as necessarily having to fit into that problem
field.
- TLS libraries only allow you to validate WebPKI certificates
- IETF Working groups (6MAN) reject drafts for e.g.: link-local,scoped IPv6
addresses
in URLs because they are difficult (and unnecessary) to implement for browsers
command line interface.
IMHO, i would really lvoe to see TLS not being constrained to only browser
business,
but i'd love to use certificate authentication where feasible for all IOT
environments.
But that won't work with WebPKI certificates. And that's highly annoying
because we already
know how it is easily feasible to build IOT specific certificate extensions
(because we've
done it for other use cases in other RFCs).
Cheers
Toerless
On Mon, Sep 09, 2024 at 03:05:02PM -0400, Michael Richardson wrote:
>
> Toerless Eckert <[email protected]> wrote:
> > If i want to go through all the trouble of A), assigning muggle
> friendly names first,
> > then i really wonder if we're promoting the best solution by first
> looking into
> > .local solutions instead of trying to figure out what's missing so that
> i can run
> > my own ACME certification on e.g.: my home (or private
> industry/enterprise) network's
> > router for my own global domain. And how to get this all
> auto-configured so that
> > muggles can operate it. I for once am not aware of any easily
> deployable self-hosted
> > ACME server solution, and if whatever we come up with for .local would
> not be a heck
> > of a lot easier than ACME, then we're not going to get that deployed
> either in the
> > networks where we would like it.
>
> ACME is mostly about establishing authorization of the device across the
> Internet using DNS. (Either DNS-01, or indirectly DNS for HTTP-01 challenge).
>
> I'm not sure what it brings in a home network using .local.
> Doing EST with an unauthenticated TLS connection, but using IPv6-LL addresses
> would seem to be as strong as an HTTP-01 challenge would be.
>
> > In other words: I'd love to see good solutions for B), and i'd
> challenge the priority
> > of A) (for .local) over solutions that do make global domain names more
> > easy to use in non-internet
> > use-cases. After all, it could be piece of cake to add my own networks
> root-CA to
> > my browsers web-pki trust-anchor list if we wanted that to be the
> solution.
>
> It's a piece of cake for you, and your five devices. Harder when you have
> five members of the household with five devices each, and then guests. And
> then, device to device communication.
>
> Would you like to be able to shush your multi-room surround-sound music
> so that you can hear: the door bell, the coffee is ready, or the oven has
> preheated, waiting for the next tray of ordeuves?
>
> --
> Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting )
> Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
--
---
[email protected]
_______________________________________________
Anima mailing list -- [email protected]
To unsubscribe send an email to [email protected]
