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-boun...@openjdk.java.net> im Auftrag
von Sean Mullan <sean.mul...@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
