Lez's avatar
Lez lez@nostr.hu 2 weeks ago
For one, we have relays, they have pubkeys, and yet, we still rely on the certificate chain. In a better world, relay lists should contain the relay host (or better, its IP) AND its pubkey, and those pubkeys should be directly used in diffie-hellmann key exchange when initializing secure connection. The problem with this approach is that there is - to my knowledge - no technology embedded in browsers by default that achieves it effectively.
↑ Parent

Replies (4)

JOE2o's avatar
JOE2o 2 weeks ago
Biggest issue there imo is secp256k1. It's just not a curve you can easily do this kind of core infra stuff with. It's not supported by passkeys (webauthn), it's not supported by SubtleCrypto, it's not supported by the secure enclaves of iOS or Android devices, you can't use a secp256k1-based certificate to sign a tls 1.3 handshake, then there's JWTs, JOSE, list goes on. It's just absent from a ton of web standards. mainly because it isn't NIST-stamped, so it's sidelined most places by secp256r1. Basically if the goal from the start is to replace the certificate chain and all the rest, secp256k1 is definitely not what you'd choose.
2 replies ↓
Freakoverse's avatar
Freakoverse naBobAbout 2 weeks ago
Already worked on / working on what you're thinking. On what I've built (still in-dev) resulted in no more reliance on DNS at all, IANA / IP can 'not' be the identity target but rather an NPUB would be, and there's no reliance on CA to co-sign your cert, you self-sign and it's still secure without a need for validity expiration. Here's a short demo:
↑