11 ms·

Are we self-sovereign PKI yet?

104 points by ca98am79 4mo ago

lxgr 4mo ago
Great concise description of the problem. 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.
- Krasnol 4mo ago
  Wait, actually, let me quickly...send it over in Whatsapp
- Terr_ 4mo ago
  It's interesting to imagine how different the security landscape would be if human brains could easily transcribe a smallish quantity of high-value bits [0] and then compare two versions for exact equality. I think the exact and trusted data-movement is the hard part. If we could instantly transcribe a 150 digit number (~512 bits) from eye to fingertips, then the actual memory/comparison could be done in any pocket-calculator, with X-Y==0.
- tptacek 4mo ago
  It's not "hard" for regular users; it's a complete non-starter for regular users. Every "non-custodial" or "self-sovereign" system of trusted identities founders on this issue: account recovery is the hardest problem in identity, and if you don't have a solution for it, your system is going to be a niche at best. People have been coming up with these schemes for decades, and for that entire time, the near-universal de facto standard trusted identity system has been "Google accounts". People knew at the beginning that they were delegating trust to Google; they know it now as well; they are not going to adopt "names resolve to a key, the same key, in every application", no matter how many different names that scheme is given.
  - merelydev 4mo ago
    Yes, the UI/UX of decentralized systems is so difficult for users that it creates demand for centralized systems to manage it for them, Coinbase, Gmail, Github, Twitter, The Pirate Bay.
    - buffrr 4mo ago
      there's nothing wrong with a keychain or password manager holding your keys. passkeys already work exactly this way, completely transparent to the user. it's fine for most users.
- buffrr 4mo ago
  > not address recovery of lost keys/identities Key loss is hard but not insurmountable. Social recovery / split-key custody seem like the right direction. Apple uses "recovery contacts" if you have advanced data protection enabled. A friend holds one share, Apple holds another but neither can recover alone. that's social recovery + split-key shipping to hundreds of millions of devices today > That, and general name confusion attacks, I suppose: "I'm lxgr17@key... pre-registering the obvious typo neighbors (lxrg, 1xgr ... etc) and it's cheap since handles batch-issue off-chain under a fixed 32-byte root, and strict ascii only charset ... etc could help mitigate some of this.
Edmond 4mo ago
>We have public-key infrastructure for machines. We don’t have it for people. We do, you just don't know about:) SDK: https://github.com/CipherTrustee/certisfy-js https://github.com/CipherTrustee/certisfy-js Web trust use: https://bsky.app/profile/bitlooter.bsky.social https://bsky.app/profile/bitlooter.bsky.social Some examples of how you could leverage it: https://blog.certisfy.com/ https://blog.certisfy.com/ Happy to answer questions.
- deleted 4mo ago
  [deleted]
cardmates 4mo ago
[flagged]
irq-1 4mo ago
> 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.
- lxgr 4mo ago
  > What we need is a system that allows people to easily create new IDs, that updates contacts that people choose. > Contacts would need to be always online. That also sounds impractical. > It's a required ID to use the internet How does any of that follow? Having a reusable self-sovereign ID format for those scenarios where people want to share it is very different from having an authority-issued ID format that's mandatory for some interaction. As a concrete example: I have an iMessage (CKV), Signal, WhatsApp, and GPG identity key, but I don't need to provide any of them when ordering pizza online. But what I can't do is choosing to use the same key for my same number on both e.g. Signal and iMessage to make it easier for people to switch between messengers without having to re-verify me. A hypothetical shared key format would fix that, but would (hopefully!) still allow me to create multiple keys/identities for multiple contexts, and to not provide any persistent identity when it's not necessary.
  - irq-1 4mo ago
    If the ID is permanent then governments will require it, because they can. If it has attestations or endorsements, governments will require a government endorsement. Think about what China, Iran or Russia would do with a permanent ID being a standard. The US, England and the EU are not immune to the same impulses. Always online is no different than an email account or website, and the rate of change would be, at least, minutes not seconds.
upofadown 4mo ago
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 particular flesh and blood person, and if you want to insure that you are back in the realm of ridiculously long numbers.
- XorNot 4mo ago
  Technically speaking the long numbered problem is solved with QR codes though. You want to be sure it's a particular person the you need to establish in-person trust.
- buffrr 4mo ago
  > The append-only, distributed nature of the traditional SKS PGP keyserver network seems to provide the same sort of thin > most of them would have to conspire to forge a mapping. The mapping is recorded in an immutable ledger (bitcoin) so forging is not feasible without breaking Bitcoin's proof of work. its a stronger guarantee than a key server. > They instead want to be sure that they are securely exchanging messages with an particular flesh and blood person comparing fingerprints doesn't verify a flesh-and-blood human either. "is this the specific person I mean" problem is still real and separate though. `grace@key` binding gives you a stable, human-readable identifier you can hand out like an email address, build reputation on, and that anyone can use to verify posts made by you and message you without having to meet you in person. It solves the UX of using public keys as your identity. You can post online with a public key as your id (e.g. nostr) but its harder to build your online identity around it. you can rotate the key underneath the name. with a bare key it becomes your identity, so rotating means becoming a new person and re-verifying with everyone. > you are back in the realm of ridiculously long numbers. not really. the long number is a disposable part, and there's a name above it. You can still exchange "grace@key" in person, and be sure you're talking to "grace@key"
captn3m0 4mo ago
I tried to follow the links, but could not discover the expected cost of a record creation. > "Supply is capped at about ten per day. Individual squatting (buy at auction, hold, resell) is possible. " Won't this mean that squatters will keep buying the top-alexa domains for the first few years? I'd have liked to see a comparision with other "crypto"-led infra in this space. .eth/ENS, namecoin, .box, .bit for eg.
NoahZuniga 4mo ago
The entire premise of this article is wrong! > Signal ships safety numbers because the platform might one day be compelled or compromised, and the architecture is meant to let you catch that. But almost nobody verifies We have a solution to this! Wa and Signal both have key transparency. This uses cryptography to make it possible to verify that everyone is getting the same data[1]. Now your phone can check the keys listed under your username are all keys you made (and your contacts can check this too!) Edit 2 (quick note): if you don't trust the app on your phone to verify your keys, then you also can't trust it to show you a valid security code, or do what the author proposed in their product spaces. Edit: It's also striking how similar (in essence) the current solution is to the solution the author is working on/proposing: > Spaces takes this shape. (Disclosure: I work on it.) Issued names live in a binary Merkle trie. The root of that trie is committed to Bitcoin’s chain, used here as a widely-replicated, hard-to-rewrite timestamp service Fundamentally the same: the name is your phone number (or alternatively in signal your username), key transparency also uses a merkle tree based structure. Instead of using the bitcoin chain as a consensus mechanism, key transparency implementations generally use trusted witnesses: simple servers that promise to only sign consistent versions of the merkle tree. This is better! Because essentially no clients (phones) have a local copy of the bitcoin chain, so you still have to trust a server to tell you what was posted in the bitcoin block. For the rest current key transparency systems also have verifiers, which verify that the append only merkle tree is transformed into a dictionary legitimately (this is pretty compute intensive, and needs to be done by a trusted server too. WA currently contracts cloudflare as their only verifier). Spaces would also have to do this to be secure if they reach any scale, but this isn't mentioned in TFA. Also a message for the author: Key transparency is cool tech, but you shouldn't reinvent the wheel! I hope you research current solutions more! You can ask questions in the transparency.dev slack (https://transparency.dev/slack/ https://transparency.dev/slack/) [1]: There are a bunch of details here. You need to check that everyone _is_ actually getting the same data. There are multiple ways to do this. The transparency ecosystem has generally stabilized on a system where you have trusted verifiers. But anyone (yes you!) can setup a server that can help monitor the chat app and trusted verifiers.
- buffrr 4mo ago
  I have addressed key transparency in the post :) Key transparency does help with detection (still requires trusting third parties or having to check yourself) but the proposed protocol makes it not possible to forge the mapping to begin with. > This is better! Because essentially no clients (phones) have a local copy of the bitcoin chain, so you still have to trust a server to tell you what was posted in the bitcoin block. Not quite :) also addressed in the post. look at the end of "The CA of all CAs " section.
philipallstar 4mo ago
> Spaces takes this shape. Why write in such a silly way? Do you mean "Spaces does this"?
- brabel 4mo ago
  Sounds like something a LLM would write.
TheColorYellow 4mo ago
> two parties have to be able to agree on which key grace@key is bound to without consulting anyone in particular. They need a shared, append-only record of which names exist and which keys they belong to. And that record can’t have a signing key to steal, an operator to coerce, or a committee to lobby Having studied this problem space for some time, this is also my read of what the ultimate solution requires. That said, as the author also mentions, the biggest challenges in this paradigm are social, not necessarily technical. Therefore, I think the new solution requires a protocol approach rather than just a technical standard or implementation. The KERI protocol (https://keri.one/ https://keri.one/) has been the best attempt I've seen at this. They focus on a similar concept, persistent long lasting identifiers built on top of cryptographic primitives, but they do so with a microledger approach than a monolithic blockchain as the root. The core primitive is what is known as a Key Event Log which tracks verified attestations of key transactions such as issuance, revocation, delegation, rotation, interaction, and so on. It is a very powerful concept that then facilitates stronger trust assumptions via end-to-end verification. And maybe most importantly, enables some very clean key management procedures that then can anchor the protocol behavior needed to optimize for those social challenges discussed earlier. Regardless, adoption of KERI and other solutions like Spaces has not been very productive. I fear we've reached a tipping point where the external threats are too large now and top-down authoritarian-like solutions that address these issues head on will be the winners, leaving out dociety with very poor tradeoffs in such a critical area. https://keri.one/ https://keri.one/
lrvick 4mo ago
Everyone is trying so hard to re-invent PGP, while parroting that PGP is dead because some security influencers said so. Well, there is a LOT of ongoing PGP modernization work on both specifications and implementations in recent years and my team and I at Distrust will be publishing a writeup on it any day now, as well as organizing yet another key generation and signing party in San Francisco next month. PGP is not going away any time soon, and it is more relevant than ever. For now check out this post about how we use it to build trust in the Linux ecosystem today: https://kron.fi/en/posts/stagex-web-of-trust/ https://kron.fi/en/posts/stagex-web-of-trust/
- growse 4mo ago
  > Everyone is trying so hard to re-invent PGP Which bit of PGP?
  - lrvick 4mo ago
    Self-sovereign PKI identity, key discovery, file encryption, artifact, code, review signing, security disclosures, boot signing etc etc.
    - growse 4mo ago
      Who's reinventing a tool that can do all that?
      - Grosvenor 4mo ago
        No one. The influencers are simply telling you you're wrong if you think you need that. Which is the thing, we do need a single key that can be used for all those things. So we get PGP.
        growse 4mo ago
        > No one. I thought everyone was "trying so hard to re-invent PGP". > we do need a single key that can be used for all those things We do? This is not obvious. Why does my disk encryption key need to be the same that I use to sign binaries that I release?
aliasxneo 4mo ago
I am co-founding a project that somewhat addresses some of this. The basis of it is a decentralized trust system built using human-readable names (think domain names), native mTLS, and post-quantum cryptography. This removes two barriers we've found: inability to easily confirm hashes (i.e. DIDs or fingerprints) and relying on a centralized trust giver (i.e. central certificate authorities). Happy to share more if anyone is interested in this space: hn@sepositus.com. We're in shadow mode so not much public material at this point (although we do have a full PoC).
AgentME 4mo ago
> Spaces takes this shape. (Disclosure: I work on it.) Issued names live in a binary Merkle trie. The root of that trie is committed to Bitcoin’s chain Who can update and publish the merkle trie onto the blockchain? Is it only Spaces themselves who can? If so, this seems a little inferior to more direct blockchain solutions like the Ethereum Name Service which exists as a smart contract on a blockchain that anyone can use directly.
- buffrr 4mo ago
  Operators are what assemble the bindings in the trie. Anyone can become an operator by bidding in an auction. You can read more about it at https://spacesprotocol.org https://spacesprotocol.org they don't have much power besides adding your name -> pubkey binding in the tree.
vmg12 4mo ago
Not revocable doesn't seem ideal. Someone will have their identity stolen and they would have to give up their entire online identity and generate a new one.
hmokiguess 4mo ago
Obligatory mention https://xkcd.com/1121/ https://xkcd.com/1121/
iririririr 4mo ago
i don't get spaces (the product) ebough to even read further the papers. this article shows "alice@key" which looks very sensible. then one click away, joining spaces, you can only get "horse-battery-staple@key AGE age1hsuwgduwhdiehhduwhdiheudhwi..." and one cannot even pick the first part! pure insanity!
bhawks 4mo ago
[flagged]
rkagerer 4mo ago
actual-raccoon-gas.genesis@key Take my money. (Care of randomly shuffled https://spacesprotocol.org/faucet/ https://spacesprotocol.org/faucet/)

104 points by ca98am79 4mo ago

lxgr 4mo ago

Great concise description of the problem. 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.

Krasnol 4mo ago
Wait, actually, let me quickly...send it over in Whatsapp
Terr_ 4mo ago
It's interesting to imagine how different the security landscape would be if human brains could easily transcribe a smallish quantity of high-value bits [0] and then compare two versions for exact equality. I think the exact and trusted data-movement is the hard part. If we could instantly transcribe a 150 digit number (~512 bits) from eye to fingertips, then the actual memory/comparison could be done in any pocket-calculator, with X-Y==0.
tptacek 4mo ago
It's not "hard" for regular users; it's a complete non-starter for regular users. Every "non-custodial" or "self-sovereign" system of trusted identities founders on this issue: account recovery is the hardest problem in identity, and if you don't have a solution for it, your system is going to be a niche at best. People have been coming up with these schemes for decades, and for that entire time, the near-universal de facto standard trusted identity system has been "Google accounts". People knew at the beginning that they were delegating trust to Google; they know it now as well; they are not going to adopt "names resolve to a key, the same key, in every application", no matter how many different names that scheme is given.
- merelydev 4mo ago
  Yes, the UI/UX of decentralized systems is so difficult for users that it creates demand for centralized systems to manage it for them, Coinbase, Gmail, Github, Twitter, The Pirate Bay.
  - buffrr 4mo ago
    there's nothing wrong with a keychain or password manager holding your keys. passkeys already work exactly this way, completely transparent to the user. it's fine for most users.
buffrr 4mo ago
> not address recovery of lost keys/identities Key loss is hard but not insurmountable. Social recovery / split-key custody seem like the right direction. Apple uses "recovery contacts" if you have advanced data protection enabled. A friend holds one share, Apple holds another but neither can recover alone. that's social recovery + split-key shipping to hundreds of millions of devices today > That, and general name confusion attacks, I suppose: "I'm lxgr17@key... pre-registering the obvious typo neighbors (lxrg, 1xgr ... etc) and it's cheap since handles batch-issue off-chain under a fixed 32-byte root, and strict ascii only charset ... etc could help mitigate some of this.

Edmond 4mo ago

>We have public-key infrastructure for machines. We don’t have it for people. We do, you just don't know about:) SDK: https://github.com/CipherTrustee/certisfy-js https://github.com/CipherTrustee/certisfy-js Web trust use: https://bsky.app/profile/bitlooter.bsky.social https://bsky.app/profile/bitlooter.bsky.social Some examples of how you could leverage it: https://blog.certisfy.com/ https://blog.certisfy.com/ Happy to answer questions.

deleted 4mo ago
[deleted]

cardmates 4mo ago

[flagged]

irq-1 4mo ago

> 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.

lxgr 4mo ago
> What we need is a system that allows people to easily create new IDs, that updates contacts that people choose. > Contacts would need to be always online. That also sounds impractical. > It's a required ID to use the internet How does any of that follow? Having a reusable self-sovereign ID format for those scenarios where people want to share it is very different from having an authority-issued ID format that's mandatory for some interaction. As a concrete example: I have an iMessage (CKV), Signal, WhatsApp, and GPG identity key, but I don't need to provide any of them when ordering pizza online. But what I can't do is choosing to use the same key for my same number on both e.g. Signal and iMessage to make it easier for people to switch between messengers without having to re-verify me. A hypothetical shared key format would fix that, but would (hopefully!) still allow me to create multiple keys/identities for multiple contexts, and to not provide any persistent identity when it's not necessary.
- irq-1 4mo ago
  If the ID is permanent then governments will require it, because they can. If it has attestations or endorsements, governments will require a government endorsement. Think about what China, Iran or Russia would do with a permanent ID being a standard. The US, England and the EU are not immune to the same impulses. Always online is no different than an email account or website, and the rate of change would be, at least, minutes not seconds.

upofadown 4mo ago

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 particular flesh and blood person, and if you want to insure that you are back in the realm of ridiculously long numbers.

XorNot 4mo ago
Technically speaking the long numbered problem is solved with QR codes though. You want to be sure it's a particular person the you need to establish in-person trust.
buffrr 4mo ago
> The append-only, distributed nature of the traditional SKS PGP keyserver network seems to provide the same sort of thin > most of them would have to conspire to forge a mapping. The mapping is recorded in an immutable ledger (bitcoin) so forging is not feasible without breaking Bitcoin's proof of work. its a stronger guarantee than a key server. > They instead want to be sure that they are securely exchanging messages with an particular flesh and blood person comparing fingerprints doesn't verify a flesh-and-blood human either. "is this the specific person I mean" problem is still real and separate though. `grace@key` binding gives you a stable, human-readable identifier you can hand out like an email address, build reputation on, and that anyone can use to verify posts made by you and message you without having to meet you in person. It solves the UX of using public keys as your identity. You can post online with a public key as your id (e.g. nostr) but its harder to build your online identity around it. you can rotate the key underneath the name. with a bare key it becomes your identity, so rotating means becoming a new person and re-verifying with everyone. > you are back in the realm of ridiculously long numbers. not really. the long number is a disposable part, and there's a name above it. You can still exchange "grace@key" in person, and be sure you're talking to "grace@key"

captn3m0 4mo ago

I tried to follow the links, but could not discover the expected cost of a record creation. > "Supply is capped at about ten per day. Individual squatting (buy at auction, hold, resell) is possible. " Won't this mean that squatters will keep buying the top-alexa domains for the first few years? I'd have liked to see a comparision with other "crypto"-led infra in this space. .eth/ENS, namecoin, .box, .bit for eg.

NoahZuniga 4mo ago

The entire premise of this article is wrong! > Signal ships safety numbers because the platform might one day be compelled or compromised, and the architecture is meant to let you catch that. But almost nobody verifies We have a solution to this! Wa and Signal both have key transparency. This uses cryptography to make it possible to verify that everyone is getting the same data[1]. Now your phone can check the keys listed under your username are all keys you made (and your contacts can check this too!) Edit 2 (quick note): if you don't trust the app on your phone to verify your keys, then you also can't trust it to show you a valid security code, or do what the author proposed in their product spaces. Edit: It's also striking how similar (in essence) the current solution is to the solution the author is working on/proposing: > Spaces takes this shape. (Disclosure: I work on it.) Issued names live in a binary Merkle trie. The root of that trie is committed to Bitcoin’s chain, used here as a widely-replicated, hard-to-rewrite timestamp service Fundamentally the same: the name is your phone number (or alternatively in signal your username), key transparency also uses a merkle tree based structure. Instead of using the bitcoin chain as a consensus mechanism, key transparency implementations generally use trusted witnesses: simple servers that promise to only sign consistent versions of the merkle tree. This is better! Because essentially no clients (phones) have a local copy of the bitcoin chain, so you still have to trust a server to tell you what was posted in the bitcoin block. For the rest current key transparency systems also have verifiers, which verify that the append only merkle tree is transformed into a dictionary legitimately (this is pretty compute intensive, and needs to be done by a trusted server too. WA currently contracts cloudflare as their only verifier). Spaces would also have to do this to be secure if they reach any scale, but this isn't mentioned in TFA. Also a message for the author: Key transparency is cool tech, but you shouldn't reinvent the wheel! I hope you research current solutions more! You can ask questions in the transparency.dev slack (https://transparency.dev/slack/ https://transparency.dev/slack/) [1]: There are a bunch of details here. You need to check that everyone _is_ actually getting the same data. There are multiple ways to do this. The transparency ecosystem has generally stabilized on a system where you have trusted verifiers. But anyone (yes you!) can setup a server that can help monitor the chat app and trusted verifiers.

buffrr 4mo ago
I have addressed key transparency in the post :) Key transparency does help with detection (still requires trusting third parties or having to check yourself) but the proposed protocol makes it not possible to forge the mapping to begin with. > This is better! Because essentially no clients (phones) have a local copy of the bitcoin chain, so you still have to trust a server to tell you what was posted in the bitcoin block. Not quite :) also addressed in the post. look at the end of "The CA of all CAs " section.

philipallstar 4mo ago

> Spaces takes this shape. Why write in such a silly way? Do you mean "Spaces does this"?

brabel 4mo ago
Sounds like something a LLM would write.

TheColorYellow 4mo ago

> two parties have to be able to agree on which key grace@key is bound to without consulting anyone in particular. They need a shared, append-only record of which names exist and which keys they belong to. And that record can’t have a signing key to steal, an operator to coerce, or a committee to lobby Having studied this problem space for some time, this is also my read of what the ultimate solution requires. That said, as the author also mentions, the biggest challenges in this paradigm are social, not necessarily technical. Therefore, I think the new solution requires a protocol approach rather than just a technical standard or implementation. The KERI protocol (https://keri.one/ https://keri.one/) has been the best attempt I've seen at this. They focus on a similar concept, persistent long lasting identifiers built on top of cryptographic primitives, but they do so with a microledger approach than a monolithic blockchain as the root. The core primitive is what is known as a Key Event Log which tracks verified attestations of key transactions such as issuance, revocation, delegation, rotation, interaction, and so on. It is a very powerful concept that then facilitates stronger trust assumptions via end-to-end verification. And maybe most importantly, enables some very clean key management procedures that then can anchor the protocol behavior needed to optimize for those social challenges discussed earlier. Regardless, adoption of KERI and other solutions like Spaces has not been very productive. I fear we've reached a tipping point where the external threats are too large now and top-down authoritarian-like solutions that address these issues head on will be the winners, leaving out dociety with very poor tradeoffs in such a critical area. https://keri.one/ https://keri.one/

lrvick 4mo ago

Everyone is trying so hard to re-invent PGP, while parroting that PGP is dead because some security influencers said so. Well, there is a LOT of ongoing PGP modernization work on both specifications and implementations in recent years and my team and I at Distrust will be publishing a writeup on it any day now, as well as organizing yet another key generation and signing party in San Francisco next month. PGP is not going away any time soon, and it is more relevant than ever. For now check out this post about how we use it to build trust in the Linux ecosystem today: https://kron.fi/en/posts/stagex-web-of-trust/ https://kron.fi/en/posts/stagex-web-of-trust/

growse 4mo ago
> Everyone is trying so hard to re-invent PGP Which bit of PGP?
- lrvick 4mo ago
  Self-sovereign PKI identity, key discovery, file encryption, artifact, code, review signing, security disclosures, boot signing etc etc.
  - growse 4mo ago
    Who's reinventing a tool that can do all that?
    - Grosvenor 4mo ago
      No one. The influencers are simply telling you you're wrong if you think you need that. Which is the thing, we do need a single key that can be used for all those things. So we get PGP.
      - growse 4mo ago
        > No one. I thought everyone was "trying so hard to re-invent PGP". > we do need a single key that can be used for all those things We do? This is not obvious. Why does my disk encryption key need to be the same that I use to sign binaries that I release?

aliasxneo 4mo ago

I am co-founding a project that somewhat addresses some of this. The basis of it is a decentralized trust system built using human-readable names (think domain names), native mTLS, and post-quantum cryptography. This removes two barriers we've found: inability to easily confirm hashes (i.e. DIDs or fingerprints) and relying on a centralized trust giver (i.e. central certificate authorities). Happy to share more if anyone is interested in this space: hn@sepositus.com. We're in shadow mode so not much public material at this point (although we do have a full PoC).

AgentME 4mo ago

> Spaces takes this shape. (Disclosure: I work on it.) Issued names live in a binary Merkle trie. The root of that trie is committed to Bitcoin’s chain Who can update and publish the merkle trie onto the blockchain? Is it only Spaces themselves who can? If so, this seems a little inferior to more direct blockchain solutions like the Ethereum Name Service which exists as a smart contract on a blockchain that anyone can use directly.

buffrr 4mo ago
Operators are what assemble the bindings in the trie. Anyone can become an operator by bidding in an auction. You can read more about it at https://spacesprotocol.org https://spacesprotocol.org they don't have much power besides adding your name -> pubkey binding in the tree.

vmg12 4mo ago

Not revocable doesn't seem ideal. Someone will have their identity stolen and they would have to give up their entire online identity and generate a new one.

hmokiguess 4mo ago

Obligatory mention https://xkcd.com/1121/ https://xkcd.com/1121/

iririririr 4mo ago

i don't get spaces (the product) ebough to even read further the papers. this article shows "alice@key" which looks very sensible. then one click away, joining spaces, you can only get "horse-battery-staple@key AGE age1hsuwgduwhdiehhduwhdiheudhwi..." and one cannot even pick the first part! pure insanity!

bhawks 4mo ago

[flagged]

rkagerer 4mo ago

actual-raccoon-gas.genesis@key Take my money. (Care of randomly shuffled https://spacesprotocol.org/faucet/ https://spacesprotocol.org/faucet/)