<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Sep 29, 2021 at 12:57 AM Dave Horsfall <<a href="mailto:dave@horsfall.org">dave@horsfall.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Seen on another list...<br>
<br>
-- Dave<br>
<br>
---------- Forwarded message ----------<br>
Date: Tue, 28 Sep 2021 15:47:23 +1000<br>
From: Andrew McNamara<br>
Subject: APPLIX-L Old Let's Encrypt's Root Certificate expires 30th September<br>
     2021<br>
<br>
Popular CA Let's Encrypt's original root certificate expires on 30th <br>
September 2021. Their issued certs autorenew, and are signed with a new <br>
root, however vendors were slack about picking up the new root, and there <br>
are a lot of devices that no longer receive vendor cert updates, so <br>
there's going to be certain amount of pain after the 30th.<br>
<br>
<a href="https://scotthelme.co.uk/lets-encrypt-old-root-expiration/" rel="noreferrer" target="_blank">https://scotthelme.co.uk/lets-encrypt-old-root-expiration/</a></blockquote><div><br></div><div><div class="gmail_default" style="font-size:small">[ObDisclosure, I have not been employed by a company operating a CA for over four years now. This is not different to what I said in those days. The replacement I am working on will render much of the existing WebPKI market obsolete but it will create a much larger market in the process. [*]]</div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">The WebPKI is just a bad fit for IoT security. Not what it was designed for. Problem is that we have path dependence.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The WebPKI was only designed to make shopping online as secure as shopping in line at the store. That was the design brief I wrote, that is what we delivered. Confidentiality was not a part of that brief because in 1994, crypto was still under export control.</div><br></div><div><div class="gmail_default" style="font-size:small">Of course, it is inevitable that just as the high price of gas in the UK is being blamed on the shift to wind rather than Russia and Brexit, the botched root rollover is blamed on everyone except the CA what botched it. But as with crypto-securities, there is a force of darkness and a force of light and every failure of the forced of darkness must be severely punished (e.g. Symantec CA) and we must understand that if the forces of light have any difficulties these must be excused as their system is still in development and it is in any case the fault of the forces of darkness that there were any difficulties at all.</div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">If all you want is confidentiality, unauthenticated ephemeral key exchange is sufficient to defeat passive attack which is more than sufficient to control my conversations with my house thermostats, etc. It was not necessary to dismantle my work and the work of others to turn the WebPKI into the WebPKI-Lite we have left.</div><br></div><div><div class="gmail_default" style="font-size:small">Let's say we do want to authenticate that conversation. The WebPKI isn't designed to do that, nor does a LetsEncrypt cert add any value because it only binds an endpoint to a DNS name and user's don't have DNS names either. All LetsEncrypt does is prevent Comcast, Verizon etc. replacing Google's ads in content their customer's download through their ISP. Which is something I am not entirely sure they were really planning to do because stealing revenue like that would be a stupid business model and be regulated out of existence.</div><br></div><div><div class="gmail_default" style="font-size:small">If its Alice's thermostat you want to authenticate, you need to validate the key to Alice. Alice is not an organization. So the WebPKI which is an organizational authentication was clearly not the right fit. A device cert is only saying that 'Nest made me', it is not saying what Alice needs to know which is 'I belong to Alice'.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The WebPKI-Lite and DNSSEC are no better because they only authenticate to a DNS name and the DNS is only designed to name organizations. It is also a stupidly expensive infrastructure that costs $10/yr to rent names.</div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">That is why I am proposing the callsign infrastructure. Alice buys a name for a really modest fee which is then hers for life. No rental. No renewal. So she can bind her thermostats to @alice and they are bound to her Mesh until she unbinds them. Alice's browser can have an extension that recognizes a Mesh Connection Assertion[*]. </div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The callsign registry as designed costs very little to run because 1) the expensive part of DNS is cost shifted to Alice's Mech Service Provider and 2) 99% of the cost of core DNS is dealing with abuse which becomes pointless when bringing it down doesn't cause the Internet as a whole to fail.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">My design goal is to sell (not rent) callsigns for $0.10 each. Why charge at all? Well, I can certainly fund the registry myself if it only has a few million users but running it for a billion users is going to cause costs to rise beyond what anyone who is not build-a-spaceship rich. Not thinking about costs until it was too late caused the DNS to end up with the very worst cost model in which the entire enterprise is rent seeking. GTLDs should not cost any more than names in .com. The money will go to a not-for profit which will put any surplus into funding development of Mesh applications and other related work. </div></div><div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">OK so why does the Mesh Callsign PKI work when efforts to make S/MIME and PGP web o' trust failed?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">The answer is simple, every Mesh name registration is a key registration. So there is no ambiguity[*] in what key to use to communicate with @alice, for Trust On First Use, it is the key published in the registration of @alice which belongs to Alice. For Trust After First Use, it is the key that was obtained in the first use interaction.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I spent 30 years trying to work out a better way to validate Alice's claim to <a href="mailto:alice@example.com">alice@example.com</a> and failed because the name does not belong to Alice. There is no way to make that system work well except for the case where it it <a href="http://example.com">example.com</a> that is being authenticated and 'alice@' is merely a specializer narrowing down the field of communication.</div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">The Mesh just passed its complete functional unit tests for phase 1 before I started writing this email. I have to re-integrate the transport layer after making changes to the authentication scheme and I have to write some more tests but Phase 1 is almost ready to ship. The Callsign registry is not a part of that work but there is code and it is the first priority for phase 2.</div></div><div><br></div><div><br></div><div><div class="gmail_default" style="font-size:small">[*] Many details and curlicues elided. </div><br></div></div></div>