On Tue, Mar 2, 2021 at 3:56 PM Michael Thomas <mike@xxxxxxxx> wrote:
On 3/2/21 12:44 PM, Phillip Hallam-Baker wrote:
On Tue, Mar 2, 2021 at 1:39 PM Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
On Tue, Mar 02, 2021 at 10:19:53AM -0800, Michael Thomas wrote:
> [...] And once you rely
> on online crl's, it's all the same.
Yes, well, wherever possible we should be using short-lived credentials
and dispense with revocation.
Getting back to the constraints of 30MHz Windows 95 PCs. Has anyone here tried to create a 2048 bit RSA key on a BBN safekeyper box?
The notary videographer did not expect to be spending eight hours filming absolutely nothing happening.
Back in 1995, signing a new cert for each subscriber every day was impossible. Now it is completely feasible.
With threshold techniques, we don't even need the subscriber to make a new cert request and we can still roll the key:
* Alice creates public/private key pair {a.P, a}, sens a.P to Carol
t=0) Carol validates the request generates a new keypair {c0.P, c0} and sends back a certificate for { (a+c0).P, a+c}. and the value c0 Carol doesn't know a of course but she can calculate a.P + c0.P which is the same thing. This cert is valid for 48 hours.
t=1) The next day, Carol sends a certificate for { (a+c1).P, a+c}. and the value c1
t=2) The next day, Carol sends a certificate for { (a+c2).P, a+c}. and the value c3
t=3) 'Alice' turns out to have never been Alice, it was Mallet. Carol stops sending her new certificates.
Or skip all of this complexity and just enroll the naked public key bound to whatever name you like (if any) and having the side benefit of not having to deal with a dinosauric encoding scheme.
https is not the same as TLS. You don't need the TLS name to be bound to the domain but the https name does. And you also have to provide backwards compatibility for 30 years of https browsers.
We looked at this approach in 1995. Really we did. And the problem is that you aren't avoiding a central point of control, you are pretending ICANN is that point of control. And it isn't up to that role institutionally, nor is DNS suited for that purpose.
The Mesh callsign registry is designed to support exactly that.
Henry's Hosting registers the callsign @henry as follows
Callsign: @henry
Profile fingerprint : MD4R-HO4D-AZY3-MZ3A-K7KP-N67I-LSUT
DNS: {10.0.0.1, 10.0.0.2}
Alice uses Henry's hosting:
Callsign: @alice
Profile fingerprint : MCQB-GS7P-HBSV-TKWW-WSD5-NSID-VU4L
Service: @henry
Both are enrolled in the notorized, append only callsign log. Think of it as a blockchain that doesn't require more electricity than Argentina uses to function. So the binding from the callsigns to the keys is solid. It cannot be unrolled without relying parties being aware it has been unrolled.
The Mesh foundation is a wafer thin registry that does not provide query functions. All it supports is incremental zone transfer of the entire log to parties who do provide that function. The $0.10 fee to create a new callsign is principally there to keep the log size bounded so that an incumbent doesn't try to spam the log to raise the cost to service providers.
Alice can now create a web site https://alice.mesh/ which can be found by any Mesh aware browser as follows:
.mesh is a reserved TLD that I don't feel the need to pay $250,000 in ICANN rent to get. Flood the zone worked for .onion and it will work for this.
Bob's mesh aware browser interprets the domain as follows:
1) Query Bob's MSP to resolve the callsign @alice, this causes both records to be returned.
2) Query Henry's DNS at 10.0.0.1/10.0.02 which publishes the authoritative zone for alice.mesh. This zone MUST be DNSSEC secured under a key that has a validation path up to Henry's profile MD4R-...
3) Start TLS, get the cert back, this MUST include a valid chain to Alice's cert root under her profile MCQB-... It MAY include a valid chain up to a CABForum DV or EV root. A Mesh aware browser will trust it either way.
Carol's non mesh browser can only resolve this web site if there is some registry out there providing a shadow service of the .mesh pseudo domain using the callsign registry to populate it. That may happen of course. In fact it is likely to happen but Carol's non mesh aware browser will only consider the cert valid if there is a valid cross cert to one of the browser roots.
So did people notice what I did there? This trust chain costs only a few pennies to set up if Alice and Henry chose callsigns of 9 characters or more. It provides the functionality of a DNS name AND the functionality of a TLS DV cert. And there are no renewal fees for either.
This trust chain can be validated by Bob and the only thing he is trusting is that nobody have futzed with the Merkle Tree authenticated append only callsign log. And I can make the work factor on that practically infinite.
Oh and BTW, I didn't write a single line of description or code for this project until after I left Comodo and after my non compete clauses had expired (not that they would have been enforceable).
The trust path for validating the name of the site does not involve either ICANN or any CA. [There are some issues to do with IPR in the names I am eliding but these are considered in the detailed specs]
So what does this mean for CAs? Well they still have two important WebPKI roles. First, they are the only parties that can provide certs that work with legacy browsers and that will be a profitable number of users for at least a decade. Second, they will still have an important function for providing the accountability that the WebPKI is there to provide.
But more importantly for them, Threshold Key Infrastructure provides vastly more functionality than legacy PKI. The Mesh will cannibalize their legacy business over time but the opportunities that will replace that are orders of magnitude greater. The Mesh protocols make use of Lototypes for communicating trust to the end users. Also, the CAs are the parties best positioned to run MSPs.
What does this mean for the wider industry? Well it is simple: This is how all the IoT devices you are wanting to sell to Alice can use TLS to secure the connection to their local web server console. You give each customer a voucher that is redeemable for registering one callsign and that will cost you $0.10 if they need to use it.
