X.509 certificates for wss generated from nostr keys

[mikedilger]

In order to be less dependent on certification authorities under SSL, maybe we could have a scheme to map a nostr key onto an X.509 signature key (RSA or DSA I guess), and a way for nostr clients to install as a trusted certification authority any number of trusted nostr keys.

I'm a bit tired at the moment but I wanted to get the thought down.

Maybe we could even extend it so that such CAs certify IP addresses instead of DNS names, and we could then not be dependent on DNS either.

Again I'm tired. Not sure how much sense this makes.

[ghost]

perphaps a distributed hash table, containing certificates and NIP-5 identifiers?

[fiatjaf]

This would be amazing if possible. Is it possible?

[mikedilger]

Well, I'm awake now, and there is no way to map these keys. You could derive a key from your private key, but it would not be related to (in a verifiable way) your nostr public key identity that everybody knows. Also, none of the X.509 algorithm update RFCs list secp256k1 (the closest they have is secp256r1).

What can be done is this, and it is pretty standard and less magical: 1) Uncle bob sets up a certification authority (CA) using a standard X.509 thing, RSA or ECDSA or whatever. 2) Uncle bob issues himself an SSL certificate. But he also gets letsencrypt/certbot/acme to issue one too. So he has two CAs signing his relay, one being his so-far-unknown one. He puts both certs in the file for his webserver, like you would do with a chain. It think that works. Maybe not. 3) Uncle bob sends out a nostr message with his CA's SSL certificate and asks people to trust it. Or it is in a DHT or something, I dunno. Somehow people become aware of it. 4) People configure this in their clients, which have new code designed to accept SSL certs certified by any CA that the user adds, besides the normal lot of "public" CAs. Browsers let you trust CAs you install, nostr clients could too. 5) Now letsencrypt gets mad at Uncle Bob and revokes his SSL cert. The rest of us nostr people could care less, we still recognize his relay from his own CA.

The DNS/IP idea is a bit of trouble... you would have to reissue a certificate if the IP changes, and you would have to advertise your relay in nostr with the IP instead of a DNS name. And if the IP changed clients would lose all statistics and relationship data.

(sorry @unclebob I needed a person as an example and I was listening to nostrovia when I wrote this).

[eskema]

could DANE work / be helpful in a nostr environment so we bypass CA? I have very little understanding of the technicals here so I don't know how this could work in practice, just throwing it out there as I know it can be used to serve SSL sites without a certificate authority.

[fiatjaf]

Do browsers support DANE?

[fiatjaf]

@markjr could be helpful in this discussion.

[eskema]

Do browsers support DANE?

Beacon, which is a chromium fork has DANE support (https://github.com/imperviousinc/beacon) but I don't think the big ones do

[ghost]

i think a new network, which can then be used for Nostr, is the best way to do this. Then we can use a distributed hash table that holds the relays public key, and a certificate signed with the matching private key. This way we wouldn't need to do complicated stuff that only chrome supports cough cough DANE and we can also use it for storing NIP-5 identifiers.

The problem is; we'd need to create a new network and protocol.

[markjr]

Beacon, which is a chromium fork has DANE support (https://github.com/imperviousinc/beacon) but I don't think the big ones do

This is the only browser I know that supports DANE - the devs are big HNS guys. Brave did some work on HNS support which would have DANE as a requirement but so far it hasn't materialized into the browser.

It's one of those things I always hoped would incrementally work its way into the mainstream, but I have also been hoping the same thing for SRV rec support in browsers for over 20 years.

(These days DANE is making more inroads in email than browser, Microsoft Exchange added DANE support for outbound email last year. )

But if you wanted to use DANE couldn't you just build the support into the clients themselves? Not all Nostr clients are browser based and for those that are, couldn't you add it to a browser plugin (I.e. Alby?) It's really just a TLSA lookup.

What if you extend NIP5 to specify a signature and maybe create something parallel to NIP5 for relays? (I'd still like to see NIP5 with the ability to specify at least the location of the nostr.json URI via DNS TXT, but @fiatjaf should know by now that it is impossible to invoke my name without me dredging that up again).

Admittedly, I'm a DNS guy, so I always come back to DNS - if you're willing to use it, you can pin whatever you want in there, even using generic TXT records, then DNSSEC sign the zone.

[randomodbuild]

As soon as I saw this I thought of DANE, especially as it relates to the Handshake naming system. This would allow verification without relying on a centralized system (ICANN for the domain and CAs for the tls cert). But as @markjr mentioned, this could just be implemented through the client.

[randomodbuild]

Admittedly I might’ve come on too strong in my support for Handshake, which I’m sure many disagree with. However, using DANE to verify a certificate’s validity would be beneficial regardless of which DNS solution is used, and would open the doors to more environments in which Nostr could run (not just clearnet). Any relay not running in the clearnet will be unable to obtain a valid TLS cert from a CA unless that CA recognizes this non-clearnet/non-icann IP or FQDN (let’s encrypt does not, I’m not sure about others) and hence clients will be unable to establish a websocket connection without using a self-signed cert. Sorry for just rambling, I haven’t presented any solution to be implemented with a NIP, but I wanted to get some thoughts down. Again, this probably could just be implemented in clients.

[melvincarvalho]

I've been using X.509 for single sign-on since 2007, and I love it. Works both in the browser and command line with curl.

I think ED keys would be better than RSA or DSA.

Some work on key generation here: https://melvincarvalho.github.io/noskey/docs/

[ghost]

RSA or DSA should definitely not be used, they're slow and very computationally intensive (the latter being important as Nostr is becoming popular on mobile devices too)

I think Ed25519 is the best option, it has decent security (128 bits if i'm correct) and is fast, Ed448 would be overkill imo.