Is Digicert's continued use of the "Distrusted" certificates for code signing still valid?

[Bert Eisen]

Hi Sean.
Thanks for looking into this issue.  I was wondering if there had been any
further updates?
Regards
Bert

On Tue, 25 Jun 2019 at 19:08, Bert Eisen <bert.eisen.1952 at gmail.com> wrote:

> Hello,
>
> I’m trying to understand why Digicert are still issuing signing
> certificates from the distrusted Symantec root CAs and as a consequence if
> the java code signing is still meaningful?  I know for sure that they are
> still issing certificates from the distrusted "thawte Primary Root CA - G3"
> root, because i'm trying to verify the signing certificate that has just
> been issued to the company that I work for.
>
> The root CA’s were distrusted by Google following the discovery of a
> number of invalid certificates incorrectly issued by Symantec and their
> partners[1].  And the subsequent investigation by Google reviled that
> Symantec’s partners were allowed to issue certificates without appropriate
> controls or adequate security processed.  It would appear that only
> certificates used for protecting websites are listed in the Sectigo search
> engine [ <https://crt.sh>https://crt.sh/], thus it is unclear what other
> types of certificates have been issued.  Ultimately this means that you
> should not “Trust” any certificate issued from those roots.
>
> According to the Thawte Certification practice statement v3.7.20[2], (as
> refernced by the G3 root certificate,) it describes the CA as being
> “inactive”.  In addition the policy document also describes the
> intermediate code signing certificate “thawte SHA256 Code Signing CA - G2”
> has having have a daily updates to its CRL, but the URL seems to point to
> the wrong crl distribution list, which is only being updated every 3 months.
>
> Which brings us onto the java code signing.  In response to the Googles
> distrust statement, the JDK and the SunJSSE provider has been updated[3] to
> explicitly reject TLS sessions rooted in the affected CAs, however it
> stopped short of removing the CA’s completely.  This means that jar files
> signed by the affected roots are still considered valid and pass all
> verification checks without warning.
>
> Given that the Trust has been eroded from the affected roots, a third
> party can no-longer believe with certainty that the signed code hasn’t been
> tampered with or has originated from the party named in the certificate.
> As such I believe that digicert should not be continuing to issue
> certifcates from those CAs and that java (and other platforms) should
> deprecate the use of the affected CA’s.  At the very least the the JDK
> shoud warn of code and other artefacts that have been signed since the
> distrust date.
>
> Regards
> Bert
>
> [1]
> <https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html>
> https://security.googleblog.com/2017/09/chromes-plan-to-distrust-symantec.html
> [2]
> <https://www.thawte.com/assets/documents/repository/cps/Thawte_CPS_3_7.20.pdf>
> https://www.thawte.com/assets/documents/repository/cps/Thawte_CPS_3_7.20.pdf
> [3]  <https://bugs.openjdk.java.net/browse/JDK-8207258?subTaskView=all>
> https://bugs.openjdk.java.net/browse/JDK-8207258?subTaskView=all
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20190722/b639694a/attachment.htm>