A cryptographic identity is a public key as used in a public key signature scheme. So a particular person is represented by a ridiculously long number. That number can be shortened with some sort of hash to a shorter value to make a key fingerprint, which is a shorter ridiculously long number.
The scheme described in the system seems to use a blockchain to create a shared mapping between a name and a cryptographic identity. So a third party is still in control of that mapping, but there are a lot of third parties and most of them would have to conspire to forge a mapping. Then you could send a message to a name, rather than a number, with confidence that someone in the past picked that name and locked in the mapping between that name and the cryptographic identity.
The append-only, distributed nature of the traditional SKS PGP keyserver network seems to provide the same sort of thing. If you query several keyservers you can be reasonably sure that someone mapped a name (and email address) to a particular cryptographic identity sometime in the past. A single server operator can not forge a mapping without the possibility of that forgery being detected.
The thing is, people don't actually want a reliable name to cryptographic identity mapping service for end to end encrypted messaging. They instead want to be sure that they are securely exchanging messages with an actual flesh and blood person, and if you want to insure that you are back in the realm of ridiculously long numbers.
> The same key, in every app, for every recipient. Not assignable to anyone else, not revocable, not subject to suspension. Yours forever.
This is impractical and the opposite of what we want. It's a required ID to use the internet, monitored by governments, tracked by corporations, and forever unchanging.
What we need is a system that allows people to easily create new IDs, that updates contacts that people choose. Think of a contact book that sends new keys to all contacts on every change. (Contacts would need to be always online.) It could update the key used on a website or not, depending on the users choice.
Breaking tracking and required IDs means flux and churn.
As for the solution, it seems to explicitly not address recovery of lost keys/identities, which is however exactly the part that makes this hard for regular users.
That, and general name confusion attacks, I suppose: "I'm lxgr17@key, yeah, don't ask about the first 16. Oh also make sure 'key' is not the one with the Georgian lowercase e in the middle, that one's an impostor. Wait, actually, let me quickly spell it out in hexadecimal Unicode points..."
At least blockchain addresses have that going for them: They're way too long to even try and remember or spell out on the phone.
The scheme described in the system seems to use a blockchain to create a shared mapping between a name and a cryptographic identity. So a third party is still in control of that mapping, but there are a lot of third parties and most of them would have to conspire to forge a mapping. Then you could send a message to a name, rather than a number, with confidence that someone in the past picked that name and locked in the mapping between that name and the cryptographic identity.
The append-only, distributed nature of the traditional SKS PGP keyserver network seems to provide the same sort of thing. If you query several keyservers you can be reasonably sure that someone mapped a name (and email address) to a particular cryptographic identity sometime in the past. A single server operator can not forge a mapping without the possibility of that forgery being detected.
The thing is, people don't actually want a reliable name to cryptographic identity mapping service for end to end encrypted messaging. They instead want to be sure that they are securely exchanging messages with an actual flesh and blood person, and if you want to insure that you are back in the realm of ridiculously long numbers.
This is impractical and the opposite of what we want. It's a required ID to use the internet, monitored by governments, tracked by corporations, and forever unchanging.
What we need is a system that allows people to easily create new IDs, that updates contacts that people choose. Think of a contact book that sends new keys to all contacts on every change. (Contacts would need to be always online.) It could update the key used on a website or not, depending on the users choice.
Breaking tracking and required IDs means flux and churn.
As for the solution, it seems to explicitly not address recovery of lost keys/identities, which is however exactly the part that makes this hard for regular users.
That, and general name confusion attacks, I suppose: "I'm lxgr17@key, yeah, don't ask about the first 16. Oh also make sure 'key' is not the one with the Georgian lowercase e in the middle, that one's an impostor. Wait, actually, let me quickly spell it out in hexadecimal Unicode points..."
At least blockchain addresses have that going for them: They're way too long to even try and remember or spell out on the phone.
We do, you just don't know about:)
SDK: https://github.com/CipherTrustee/certisfy-js
Web trust use: https://bsky.app/profile/bitlooter.bsky.social
Some examples of how you could leverage it: https://blog.certisfy.com/
Happy to answer questions.