Comment on Google's plan to restrict sideloading on Android has a potential escape hatch for users
InnerScientist@lemmy.world 2 days agoDoesn’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 days ago
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: …digicert.com/…/rfc3161-compliant-time-stamp-auth…
InnerScientist@lemmy.world 2 days ago
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 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