5 ms·
The "Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates" is actually dated March 2017 -- that was the date the community started rea
by jrochkind1 5y ago
The "Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates" is actually dated March 2017 -- that was the date the community started realizing Symantec-signed certs should not be trusted.
That it took until August 2021 (~4.5 years) for that to actually affect trust for some things signed by Symantec certs... seems to say something about the ability of the ecosystem to actually act on removing trust from a CA? Like, if those apps won't open because it's been decided they can't be trusted... 4.5 years ago... and if in fact the apps were totally safe all along, why do they have to be rejected now? What should we take from this about how we understand code-signing and other uses of trusted certs and what they do for us?
- tru3_power 5y agoWhat lead up to the reasoning for no longer having faith in Symantec-signed certs? Also what exactly made them so trusted/popular originally? Seems like you still see a lot of people using their certs
- initplus 5y agohttps://wiki.mozilla.org/CA:Symantec_Issues https://wiki.mozilla.org/CA:Symantec_Issues
- zinekeller 5y ago> Seems like you still see a lot of people using their certs It's Symantec in name only, at least for the certificates (https://www.digicert.com/news/pr/digicert-completes-acquisition-of-symantec-ssl/ https://www.digicert.com/news/pr/digicert-completes-acquisit...). Symantec as a company has been completely disintegrated by this point, with the other half now merged into LifeLock.
- huhtenberg 5y agoRegrettably Digicert has gobbled up not just Symantec assets, but also its business ethics and practices. Their undoing from a top notch certificate company to a dumpster fire that it is now was as rapid as it was devastating to watch.
- zamadatix 5y agoNo need for FUD. Symantec for many years led shoddy certificate validations. As a result of many audits finding inappropriately assigned certs the security community at large decided to just stop trusting them rather than continuously find issues in audits. That being said the audits had already been done, the harm of just immediately distrusting the CA wholesale would be orders of magnitudes more than the harm of whatever cert assignments slipped though the audits. A target date for the distrust needed to be chosen, at the same time the security community had been shifting to a maximum of <3 years on TLS certificates and about the same for code signing certificates with a preference they be even less than that farther in the future. The combination of these 2 goals to harden certificate trust going forward leads to the reasoning of why distrust it after all of these years, any certificates that were trusted prior to the distrust of new Symantec certs should be well expired. Clearly quick reaction is possible if deemed necessary, new certs were almost immediately untrusted following concensus on action against Symantec. Should the situation have been more dire (e.g. a leak of the CA keys) a more dire course of action may have been warranted.
- hamburglar 5y agoI'm not an expert on code signing, but wouldn't a code-signing cert with a 2 year lifetime mean that none of the apps it signs can be used for more than 2 years? Or is the code-signing valid as long as the signature was generated within the signing cert's lifetime?
- marcan_42 5y agoThe latter. Code signing relies on a timestamping service to certify that the signature was made within the certificate's lifetime.
- zinekeller 5y agoThat assumes that the time-stamping certificate isn't revoked (not expired, revoked). Code signing is a mess.