The next concerning thing is that did:plc truncates the hash to just 15 bytes of entropy.
I'm... again I'm not a cryptographer, but why throw away all that delicious entropy? So the did fits in 32 characters? Weird choice, and it means collisions are cheaper
This is public information, I don't need to file a CVE to tell you about the truncation of entropy. I am, again, not a cryptographer. Maybe it's fine?
I do remember the Debian short IDs fiasco tho https://gwolf.org/2016/06/stop-it-with-those-short-pgp-key-ids.html
Why not hold onto all the entropy you can get?
The first strange thing to me is that did:plc uses sha256 and, AFAICT, not sha256d (which is really just running sha256 again over the hash). Unless I am missing something? Am I wrong?
Maybe it's not a concern because of doc parsing but it's best practice to protect against length extension attacks
The next concerning thing is that did:plc truncates the hash to just 15 bytes of entropy.
I'm... again I'm not a cryptographer, but why throw away all that delicious entropy? So the did fits in 32 characters? Weird choice, and it means collisions are cheaper
There are some strange, strange things about did:plc that heightens the centralization concerns and, well
I'm not a cryptographer, but some of my good friends are cryptographers, etc etc. I got some... reactions to what is to follow
The first strange thing to me is that did:plc uses sha256 and, AFAICT, not sha256d (which is really just running sha256 again over the hash). Unless I am missing something? Am I wrong?
Maybe it's not a concern because of doc parsing but it's best practice to protect against length extension attacks
This is pretty good tbh, it lowers the stakes a lot to have certificate chains
I love certificate chains, certificate chains are great
Honestly, having a centralized registry for them, it's not the best but it's not the worst (aside from that damn naming thing)
However...
There are some strange, strange things about did:plc that heightens the centralization concerns and, well
I'm not a cryptographer, but some of my good friends are cryptographers, etc etc. I got some... reactions to what is to follow
In theory, once a DID is registered with Bluesky, it cannot be altered by Bluesky, because a cryptographic update from the original key is necessary; it's a certificate chain, a good design
Bluesky can refuse to share did:plc documents or their updates, but it can't manufacture updates
This is pretty good tbh, it lowers the stakes a lot to have certificate chains
I love certificate chains, certificate chains are great
Honestly, having a centralized registry for them, it's not the best but it's not the worst (aside from that damn naming thing)
However...
Aside from being irritated about the name misleading, I don't mind the centralization of did:plc too much (other things, I am more concerned about, we'll get there)
There's one organization that can be queried via their API that keeps a definitive list of certificate and their updates
In theory, once a DID is registered with Bluesky, it cannot be altered by Bluesky, because a cryptographic update from the original key is necessary; it's a certificate chain, a good design
Bluesky can refuse to share did:plc documents or their updates, but it can't manufacture updates
(aside: wow my eyes are getting tired from staring at my monitor while I recap of what was a 24 page blogpost, why do I do this to myself)
Aside from being irritated about the name misleading, I don't mind the centralization of did:plc too much (other things, I am more concerned about, we'll get there)
There's one organization that can be queried via their API that keeps a definitive list of certificate and their updates
If you read the documentation of did:plc, they're actually quite upfront about did:plc's centralization being non-ideal. That's good, I appreciate that. Again, you gotta dig though, and the name misleads (which is, to be fair, the original sin of the DID Working Group)
(aside: wow my eyes are getting tired from staring at my monitor while I recap of what was a 24 page blogpost, why do I do this to myself)
did:plc is centralized, and that bothers me because once again, users think something is more decentralized than it is, because they're being told it's decentralized
The particular way in which did:plc is centralized doesn't bug me too much but once again, few users have read into this
If you read the documentation of did:plc, they're actually quite upfront about did:plc's centralization being non-ideal. That's good, I appreciate that. Again, you gotta dig though, and the name misleads (which is, to be fair, the original sin of the DID Working Group)
For that matter, where did the term did:plc come from? Early versions of "did:plc" documentation called it the "Placeholder" DID method, that's what it stands for, to motivate changing it later
Well the docs no longer say that, it now says "Public Ledger of Credentials"
Good backronymn, but...
did:plc is centralized, and that bothers me because once again, users think something is more decentralized than it is, because they're being told it's decentralized
The particular way in which did:plc is centralized doesn't bug me too much but once again, few users have read into this
Christine Lemmer-Webber