RFR (12): 8207258: Distrust TLS server certificates anchored by Symantec Root CAs

[Sean Mullan]

On 12/7/18 1:19 PM, Bernd Eckenfels wrote:
> Woha, having a specific property named after an brand looks awfully 
> specific and even hostile. (Yes it can be removed in a future version 
> when all existing certs are expected to expire, but having code patches 
> distributed for such policy enforcement does look like a heavy gun)

The property itself is named "jdk.security.caDistrustPolicies", so there 
is no brand information in the name. I guess you are referring to the 
name of the policy id that it can be set to: "SYMANTEC_TLS"?

This is a JDK-specific property, so other SE implementations do not have 
to support it.

Also, the root certificates are now part of OpenJDK. We should be able 
to implement controls which ensure they conform to acceptable industry 
standards, and if that means revealing the name of the CA, I don't see 
that as a problem.

> Won’t it be a bettter idea to have a generic blacklist framework (with 
> thumbrint and forced end date), maybe even by using WebStart blacklist 
> technology? (Or just put the list with new syntax in the algorithm 
> restriction properties - the list is long but if it’s limited to the 
> thumbprints it should be doable)

We did consider the existing blacklist framework. However, that is 
currently too coarse. It is all-or-nothing. If a certificate chain 
contains a blacklisted certificate, it is rejected regardless of the 
usage (TLS, code signing, etc) or other constraints (notBefore, notAfter 
dates). It would have been a much bigger effort to enhance the blacklist 
mechanism to support those features.

Another solution I considered was to tag the roots in the cacerts 
keystore with various attributes, but the cacerts keystore is currently 
in JKS format, which does not support attributes.

> Also, since this (without OCSP stapling or CT)  somewhat trust symantec 
> to not backdate issuances, why not trust them to not issue new ones? 
> Just wait for a few more month and remove them completely from the 
> cacerts file. (After all, this is not a Web Browser)

We may do that eventually, but if we unilaterally removed the roots, 
there is a significant risk that we would break existing code that has 
been signed with Symantec issued code signing certificates, especially 
with code that has also been timestamped. That code is expected to work 
beyond the lifetime of the certificate.

Thanks,
Sean

> 
> Gruss
> Bernd
> -- 
> http://bernd.eckenfels.net
> ------------------------------------------------------------------------
> *Von:* security-dev <security-dev-bounces at openjdk.java.net> im Auftrag 
> von Sean Mullan <sean.mullan at oracle.com>
> *Gesendet:* Freitag, Dezember 7, 2018 7:03 PM
> *An:* security Dev OpenJDK
> *Betreff:* RFR (12): 8207258: Distrust TLS server certificates anchored 
> by Symantec Root CAs
> Please review this change to Distrust TLS server certificates anchored
> by Symantec Root CAs. Although the restrictions won't kick in until
> after 12 GA, the fix touches code that validates certificate chains, so
> getting this into 12 now will provide more assurance that the chain
> validation code continues to work properly.
> 
> webrev: http://cr.openjdk.java.net/~mullan/webrevs/8207258/webrev.01/
> issue: https://bugs.openjdk.java.net/browse/JDK-8207258
> 
> Please see the recently posted blog for more information about the
> restrictions that are being imposed:
> https://blogs.oracle.com/java-platform-group/jdk-distrusting-symantec-tls-certificates 
> 
> 
> Thanks,
> Sean