Certificate Expiration Times?

[AustinFoss]

Was looking into a implementing server node that would be reachable by a browser node without a domain name, so of the 3 transports only webrtc and webtransport had self signed certs (from my understanding websockets secure, wss, needs a CA signed cert)

Today someone informed me that the webtransport w3c spec has a limit of 2 weeks for a self signed cert. This posed a problem for my use cause I wanted my server to have a fairly long lived constant multiaddr to act as a boot strap node.

Looking at webrtc I found it has 30 days recommended in the w3c spec, to up to 365. The go libp2p webrtc implementation seems to default to a month. What’s weird is that when I was looking into the rust libp2p webrtc implementation it seems to have a ridiculously long validity time, expires in the year 4096 by default.

For my use if LibP2P ever enforced a 30 day limit for webrtc that wouldn't be the end of the world but would it be worth adding it to the spec that 1 year should be the max?

When I asked From apparently some webrtc certs are quite often set to 10 years for some reason.

[MarcoPolo]

You could propose that change, but I'd argue against it as shorter lived keys are generally better from a security perspective. Indeed, the industry as a whole has been moving towards shorter and shorter key validity windows.

I think someone has linked this before, but you may find the autotls feature useful: https://blog.libp2p.io/autotls/

[AustinFoss]

That was a fantastic read, and informed me about the couple drawbacks I wasn't aware of. Thanks for sharing!

Just to be clear, I'm not suggesting proposing an increase to the libp2p webtransport spec, if the w3c says no more than weeks then I accept that. What I was suggesting is that the libp2p webrtc spec include similar guidelines for webrtc self signed certs mirroring the w3c spec in the same way libp2p's webtransport spec does.

I didn't dig into the respective libp2p implementations of each transport to see if they simply check that the certs are not expired, regardless if they are outside the W3C spec, or if tye spec guidelines are enforced.

Back to the blog post and to elaborate more on why I'm focusing on the self signed certs. The blog gives the exact reason why I'm trying this

Admittedly, it may seem paradoxical that a centralized public good service like AutoTLS could help the Web become more decentralized. But the reality is that AutoTLS is a necessary step to this end...

I'm just trying to jump ahead to that end.

The particular use I had in mind was to try and build a proof of concept PWA that doesn't touch DNS or a certificate authority even once.

Ethereum Name Service (ENS) offers a way to custom records beyond just a content hash for a webpage that's distributed over IPFS. I wanted to create a multiaddr similar to 0.0.0.0 & 1.1.1.1 DNS services that perform ENS name resolution

Currently ens registered, ipfs distributed, web apps need to be accessed by an ens gatway or I believe the MetaMask extension hijacks the URL bar to resolve .eth addresses (Brave also does this on its own); both methods are analogous to an IPFS public gateway and how the IPFS companion also hijacks the URL bar to provide ipfs:// functionality.

The problem with both the gateway resolver and extension methods is they both operate in the DNS/CA traditional web model. To move away from this entirely there needs to first be a well known 1.1.1.1 like multiaddr that provides further multiaddr/content-hash resolution from ENS (or other web3 style human readable name registrar).

WebRTC can get this started if libp2p respects certificates that are valid for 1 year, which the w3c says is okay. But if the libp2p spec says 30 days, that's too frequent to be used as a constant multiaddr; at least easily without trying to implement a hacky workaround.

I guess another way around this would be to have the ENS org become a CA, but browsers wouldn't trust it by default, installing a custom cert isn't convenient for most people, and it still doesn't solve the problem of having to resort to a centralized authority. Or if cloudflare offered ENS resolution at /ip4/1.1.1.1/<PORT>/quic/webtransport/p2p/<PeerID>, but again centralized authority.

My reply has started become too lengthy, and if you read the whole thing I appreciate it. As the blog you linked to says, AutoTLS is a stepping stone. Maybe one day a browser compatible transport will exist that doesn't need a cert.

[MarcoPolo]

Thanks for the reply. As it stands today, you will probably will have to deal with CA certs. Some offer IP certificates that at least remove the domain name aspect of this. Good luck 🫡

[AustinFoss]

Hey, sorry to bother you again but if you have time to take another question I came across something that might help produce a psudo-constant multiaddr that still follows certificate best practice expiration times and rotations even with self signed certs and would like to know your thoughts.

I found out about the W3C DID spec. It defines a syntax for a document that has a cryptographically identified "controller", a cryptographically defined "subject", and then any number of revokable attributes attached to the subject dictated by the controller. These documents can be host on things like a git server, ipfs, or distributed ledger.

So in my use case above a controller (ethereum multisig, the subject itself, or other) would batch assign a bunch of certificats to an IPFS Peer ID as the subject. Let's say 52 certs staggered 1 week apart, vqlid for 1 month per the webrtc w3c spec. All but the 4 valid certs are held offline until they need to be rotated in.

The DID document can be shipped with any app that needs to access the multiaddr.