A security researcher was able to revoke a third party's Symantec certificate by presenting a fake private key.
https://blog.hboeck.de/archives/888-How-I-tricked-Symantec-with-a-Fake-Private-Key.html
Symantec have at least acknowledged that this is a problem.
https://www.symantec.com/connect/blogs/third-party-revocation-updates
... but seriously, why do we even still have PKI? Shouldn't DNS registrars be the ones signing certs.After all, that's *all* a cert means, that you own a domain.
@natecull Well one thing's for sure, we ought to kill the CA cartel. Let's Encrypt is a start, but the entire design is wrong.
So we know the goal... Like DNS, finding a proper solution is still a WIP :)
@cwebber This is where I wish we had a generalised 'key space' of some kind: eg, a namespace like DNS but where registering a name means you have a private key for that name.
But I guess there's a whole huge legal minefield around any kind of human readable names involving trademarks, libel law, hate speech etc, etc. And the problem of assigning 'root of trust' to the namespace root when we have no rational grounds to trust either nation-state or corporate level players.
@natecull We have possible solutions in progress!
So I'm convinced the DID spec (Decentralized Identifiers) is the right general "container" for these, though it's still WIP... see: https://opencreds.github.io/did-spec/
That's a bit general, and can be layered on top of a blockchain or DHT, with differing tradeoffs (basically, should objects be able to be garbage collected / disappear?)
@cwebber This looks interesting!
I'd MUCH rather any kind of DHT than any kind of blockchain - I think proof of work is a demonstrably failed mechanism which didn't accomplish any of the goals it set for itself and now is just a barrier to scaling and efficiency and, ironically, distributed hosting.
@natecull I'm wary of the blockchain approach myself (though note that you wouldn't need the kind of boil-the-ocean mining you have in bitcoin for this to work) and also think DHTs are a better route; what we need is a system to incentivize "archivists" to hold on to peoples' lightweight identifier objects.
@natecull I suspect Internet Archive would be super behind supporting that kind of thing
@cwebber Maybe I'm underthinking this, but it seems to me that there shouldn't be a *whole* lot of infrastructure needed to publish a lightweight crypto ID (petname and public ID pair):
like, literally just publish it as a signed update by the 'parent name space provider'.
and then the requester can check that 1, it is correct and 2, that it never changes. Boom, done.
But as I said, maybe I'm underthinking this. Probably the super hard part is deletion/update/cancellation?
@cwebber basically I'm thinking the ONLY EVER reason you would ever need the permission of a 'parent namespace' is to publish that one name-key pair. That should be absolutely all they ever do, you should be able to verify they did it and didn't lie and don't start lying at any point, and they should not ever be able to repudiate or change that after the fact.
But immutable publishing probably isn't sufficient for human use cases, sadly.
@natecull Yes, my thought was, "use fingerprints as the person's id! so easy!"
It seems that people working on this have tried that in practice, and found out that it doesn't work as well for humans...
@cwebber Namespace resolution seems a really tough problem now that we're in a global/national/corporate social environment where *we literally cannot trust any organisation not to bare-faced lie* when asked for credentials on our behalf.
@cwebber like even DNS still runs on a huge amount of trust. We can check that our DNS records resolve correctly now and here for US but we can't verify that they won't be faked in transit at any point elsewhere on the net or in the future. And we know well-funded adversaries are deliberately doing this.
So I guess the problem for me is 'how can I guarantee a name provider will never remap my human-readable name to a fake public key for some viewers without my knowledge'
@natecull yep the DID spec has some ideas, currently you can say, "here are five identifiers I trust, if 3 of them all agree that I changed my key, then it's true" type thing (so slot in your bank, a family member, a friend, your lawyer, etc and it should be harder to circumvent it while leaving a migration path)
@natecull You mean with petnames with that last sentence? A petnames solution with "localized human readable names" based off your local web of trust should be end-to-end secure because it relies on signatures of your peers
@cwebber mm, I guess requiring multiple signatories might help somewhat. Reduce the possibility of compromise at any one point.
The problem of getting a web of trust seems somewhat similar to the problem of doing basic research to verify facts on the Internet.
@cwebber and of course also 'what happens when I inevitably lose/delete my private key, or it gets stolen/leaked', both of which are going to happen.