Post #1312444

Having spent nearly 30 years building PKIs, I have some thoughts on the matter that I think may be relevant to adding end-to-end communication capabilities to Mastodon. 1) Don't add crypto capabilities to Mastodon, add them to the Fediverse. If Fred is using some Fediverse version of a Medium/Substack like service, I want to be able to use the same contact info to contact him there as I use here. 2) Don't add crypto capabilities to the Fediverse, add them to the Internet. Take the big picture. All it takes to add an existing service to the Fediverse is to start publishing an Activity Pub (or RSS feed). I remember when people laughed at the idea that the Web would eat AOL and Compuserve less than 12 months before it did exactly that. Facebook will be the last to join the Fediverse but it will. 3) Don't get hung up over debates about PKI structures. Every functioning open PKI in existence has elements of Web of Trust and brokered trust. A hybrid model is provably superior to either. 4) Don't get hung up on Blockchain either. And by that, I mean recognize that notary hash chains are just another tool, but they are still a very useful one. Just ignore the hyper authoritarian Blockchain bullshit and understand that proof of work is fragile security besides being horrifically inefficient. I have been using structured cryptography in my designs for over a decade and proposed using a notary chain at IETF before Hal Finney wrote his original BitCoin paper. And that is because of the little bit of magic that happens when you enroll an assertion in a notary chain: The work factor for forging the timestamp goes to close to infinity if you get the construct right. The Mesh uses cross notarization which gives provably superior security (as measured by work factor) to crockchain and consumes (almost) no electricity. 5) End to end is between the public key and the private key. If you don't control either one, your communication is end-to-end but the ends are not what you think. I don't want to whale on Signal, it is a fine E2E channel. But the Signal app is not end to end as far as I am concerned. I don't have direct control of my private key, I don't have visibility into the curation of other people's public keys. Now I used to trust Moxie but then he started pushing weird crypto-Ponzi coins and so that puts him on my 'do not trust' list. BTW, having helped build the first commercial CA and being a part of that industry for 25 years, I have never taken objection to people asking why they should trust me or my product. But I do find it rather off that while it is very trendy to slag off CAs, usually using false or misleading claims, the same people will then turn round and declare some trendy system beyond all reproach like it has been blessed by the pope himself. 6) Pay close attention to the management of the private keys. Modern users have multiple devices. They are not going to use your E2E system unless they can read their mail on their phone, laptop and iPad. I discovered threshold cryptography solves this problem about ten years ago and I am still trying to get people to listen. The Mesh has the architecture, the specification, even the code you need to do this right. 7) Support key recovery as an option if you want people to encrypt valuable data at rest. Since I have been attacked by the IRG and have been warned that I am a target of other hostile foreign powers, my approach to securing my most sensitive data is simple: I don't keep any. If I did keep that type of data, I would keep it separate and use keys that I don't keep recovery capability for. My photographs and documents are encrypted by default. But I make damn sure I keep the recovery keys. 8) The proper role of Trusted parties is to act as introducers rather than being a continuous active role in the communication thereafter. Any system that allows me to send mail to an employee at Microsoft in their role at Microsoft is going to end up looking like an X.509/PKIX architecture. You can change the syntax of the certificates, you can call the CA and LRA different things. But the task of credentialing an employee of a corporation or government is going to have a hierarchical structure because that is how enterprises work. 9) You cannot expect to successfully bind any credential to a name that the user does not actually control. Not your name, not your credential. What this means is that if you are trying to set up some sort of validation process for alice@example.com, the best you will ever manage is to bind the credential to 'example.com'. You are not going to end up with a binding that the holder of example.com cannot corrupt. 10) If you want human readable names bound to a public key, build out the naming infrastructure and the PKI at the same time. I explore that approach in the callsign registry. To register a callsign entry, Alice first has to generate herself a Mesh account. She then applies to the callsign registry to bind however many callsigns she wants to use to the root signature key of that account. So, @alice, @alice_lastname, @alice1, @alice2 are all aliases for the same Mesh account issued on a first come first served basis. I have been involved in running registries and while it can be done a lot cheaper than DNS, it cannot be done well without adequate resources. But one very simple way to reduce the cost of running the registry is to issue names that never expire. It is not clear to me that we need to go that route. But if we did, registration can be done for $0.10 one-time fee. If we did that, I have a scheme that would also map the callsigns to a fake DNS TLD, mm--. Which has some interesting properties in itself. Instead of paying ICANN $10/yr for a name that will expire. Alice can pay 1% of that as a one-time fee and get alice.mm-- [Yes, name registries are hard, I was Principal Scientist at VeriSign, I know the issues. That is why I am saying cheap, not free]