Nick raises some good points. The WebPKI was originally designed with a very specific purpose and working within the limits of the machines of the day. 30 years later we are using it for completely different purposes.
Back in 1995, strong encryption was subject to export control. Confidentiality was limited to a 40 bit work factor. The WebPKI was not designed to support confidentiality, it was an Authentication and Authorization infrastructure. The goal being to make shopping online with your credit card as safe as shopping in a store.
Confidentiality would have been much easier. Don't really need the certificates at all, can use TAFU like SSH does. The complexity came from the need to revoke credentials for fraudulent merchants. But path dependence is a real thing in standards.
Confidentiality would have been much easier. Don't really need the certificates at all, can use TAFU like SSH does. The complexity came from the need to revoke credentials for fraudulent merchants. But path dependence is a real thing in standards.
The simplest fix for the issue Nick raises would be for browsers to silently accept self-signed certificates and turn on encryption without notification to the user. I am aware this creates a MITM issue but that is better than no encryption at all which is what most IoT devices end up with.
Lets Encrypt has done some great things but it isn't really an IoT solution as the device has to have a DNS name and that has to be validated to the public key. Most home users don't have a DNS name and so IoT fails.
How could we do things differently? I do have a proposal and I do have running code, drafts and quite a bit else. I will be making some videos soon.
First change in perspective I think is needed is the WebPKI mediates every transaction which was necessary because we were telling users which merchants were safe and which were not. For general Web browsing and IoT, the Trusted Third Party should be an introducer rather than a mediator. Or at the very least, the roles should be separated.
Second change is that Public Key Infrastructure failed on the client side because it lacked infrastructure to manage PRIVATE keys. This was the first thing I fixed with the Mesh, the Mesh uses Threshold to make management of private keys practical.
Third change is that each user should be their own root of trust. If Alice meets up with Bob in person and they exchange contact information, they should not need any third party to authenticate any credential issued by the other. So Alice knows Bob's Signal, Telegram, OpenPGP, S/MIME etc public keys and also his SSH, Git signature, code signing, etc, etc.
Third change is that each user should be their own root of trust. If Alice meets up with Bob in person and they exchange contact information, they should not need any third party to authenticate any credential issued by the other. So Alice knows Bob's Signal, Telegram, OpenPGP, S/MIME etc public keys and also his SSH, Git signature, code signing, etc, etc.
Fourth, people have to recognize that not calling yourself a CA does not mean you are not performing a CA function and thus subject to the same defection concerns. DNSSEC is a PKI with a single CA called ICANN. Signal is a PKI with a single trust provider called Signal. Having end to end encryption isn't enough any more, you have to have end to end trust.
[Now that NIST has released its proposals for its PQC, I will be making the infrastructure PQC ready so that all encrypted data is PQC secure and signatures are robust. I cannot rely on the PQC algorithms alone because there are no PQC threshold algorithms specified at this point.]
To address Nick's specific point, well, I really wish ISOC had got shot of .org because IETF has a conflict of interest as a result. DNS names are just too expensive for billions of users for whom $10 is a significant fraction of their weekly income.
The Mesh itself doesn't really need a name scheme. Requiring Mesh Service Providers to have an externally routable IPv4 and IPv6 address and a DNS name is pretty minimal. Anyone can set up an MSP on Digital Ocean for $5/mo. But if people are going to use IoT devices through a Web browser, they are going to need a DNS name which is theirs FOR LIFE, no ongoing subscription.
My solution here is the callsign registry which I believe I can issue names from for less than $0.10 each. That is only for registration, the costly part, resolution isn't included. Instead, the registry publishes an append only log of all the registration transactions and resolvers read the log and provide resolution on that basis.
So Alice registers @alice, it is bound to her Mesh profile which contains the signature keys used to authenticate changes. The registration entry also specifies IP addresses and DNSSEC key for an authoritative DNS server for alice.mm-- Oh and no, I do not feel like applying for the TLD or anything of that sort. ICANN can respect my assignment of mm-- or I will take .mesh.
So Alice can now publish a blog at blog.alice.mm-- and those addresses can be resolved if the mm-- tld points to any DNS resolver that publishes the callsign DNS entries. So Alice does not need to pay an additional subscription to have complete independence from her service provider.
Alice can provision her IoT devices within her domain as well. But I suggest that if the names are $0.10 each, it is going to be a lot more convenient to assign the IoT devices for the house to a separate callsign and that way she can just transfer control of the name when she moves.
Issue of TLS certificates is also straightforward, While we could use TLSA, a much simpler solution is for Alice to issue a TLS cert to the device under her own PKIX root which is in turn authenticated under her personal profile root key.
So in summary:
* Each user is their own personal root of trust.
* Trust is end-to-end
* Role of TTPs is limited to making introductions
* Names are cheap and do not expire
* Backwards compatible with legacy infrastructure
* Transparent to the end user
