this post was submitted on 06 Sep 2025
529 points (97.8% liked)

Technology

74957 readers
3531 users here now

This is a most excellent place for technology news and articles.


Our Rules


  1. Follow the lemmy.world rules.
  2. Only tech related news or articles.
  3. Be excellent to each other!
  4. Mod approved content bots can post up to 10 articles per day.
  5. Threads asking for personal tech support may be deleted.
  6. Politics threads may be removed.
  7. No memes allowed as posts, OK to post as comments.
  8. Only approved bots from the list below, this includes using AI responses and summaries. To ask if your bot can be added please contact a mod.
  9. Check for duplicates before posting, duplicates may be removed
  10. Accounts 7 days and younger will have their posts automatically removed.

Approved Bots


founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
[–] InnerScientist@lemmy.world 1 points 3 days ago (1 children)

Doesn't work, the reason they can expire is to make certificate rotation possible. If an expired ssl certificate is cracked it doesn't matter because no browser will accept the expired certificate, with your idea the expired certificate just signs an app with the date of 1984 and it works.

Certificates in SSL can't change the date because that date is signed by a certificate higher in the hierarchy.

[–] xthexder@l.sw0.com 2 points 3 days ago* (last edited 3 days ago) (1 children)

This isn't "my idea", this is how the industry already does code signing. You can't sign something with a date of 1984 because your certificate has a start and end date, and is usually only valid for 1 year.

You can read more about how this works here: https://knowledge.digicert.com/general-information/rfc3161-compliant-time-stamp-authority-server

https://en.wikipedia.org/wiki/Trusted_timestamping

[–] InnerScientist@lemmy.world 2 points 3 days ago (1 children)

Then you need a Trusted Third Party, right? Still requires some though on how to prevent that third party from blocking applications they don't like but I can see how a group of trusted authorities could work.

[–] xthexder@l.sw0.com 2 points 3 days ago

The trusted 3rd party in this case is actually multiple 3rd parties. There's several options for trusted timestamping just like there's multiple trusted root CAs for SSL. Since the timestamping service is free and public, anyone can use it to sign anything, even self-signed certificates. There's no mechanism to deny access, at least for this portion.

There's always a risk the root CAs all collude and refuse to give out certificates to people they don't like, but at least so far this hasn't been a problem. I don't have a better solution unfortunately. If we could have a 100% decentralized signing scheme that would be ideal, but I have no idea how you would build such a thing without identity verification and some inherit trust in the system