RFR: 3 security-libs release notes on keytool/krb5/etc

[Anthony Scarpino]

I'd agree with Sean, "weak" implies anything risk, the weakness isn't 
necessarily key length related.

Tony

On 03/24/2017 11:56 AM, Sean Mullan wrote:
> On 3/24/17 7:01 AM, Weijun Wang wrote:
>> I'll use "short key".
>
> I prefer the term "weak" which implies it is a risk. We already use that
> term in jarsigner so I think we should keep it consistent. You also
> print the size of the key so that describes what is wrong with it.
>
> --Sean
>
>>
>> Thanks
>> Max
>>
>> On 03/24/2017 06:26 PM, Bernd Eckenfels wrote:
>>> I wonder if "weak key" should be replaced by "weak key length" or "short
>>> key". It might otherwise imply key quality tests which are not carried
>>> out.
>>>
>>> Gruss
>>> Bernd
>>> --
>>> http://bernd.eckenfels.net
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__bernd.eckenfels.net&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=L95YSg0eIcTu_shXWyN3XgC5kRlt5xJJuqogC6Ulqlk&m=nQPaZ9oNisvgXYmsVbzFkcB0qjPKYWTsWh0IIQtt1nw&s=yLFl1pk3TBMwqMqZMDE2e4d8rt9AVyNfUaC84QV3Lr0&e=>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------
>>> *From:* security-dev <security-dev-bounces at openjdk.java.net> on behalf
>>> of Weijun Wang <weijun.wang at oracle.com>
>>> *Sent:* Friday, March 24, 2017 2:12:01 AM
>>> *To:* Security Dev OpenJDK
>>> *Subject:* RFR: 3 security-libs release notes on keytool/krb5/etc
>>>
>>> Hi All
>>>
>>> Please take a review on 3 release notes. The content itself is pasted as
>>> quotation below.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8176087
>>> keytool now prints warnings when reading or generating cert/cert req
>>> using weak algorithms
>>>
>>>> In all keytool functions, if the certificate/certificate request/CRL
>>>> that is working on (whether it be the input, the output, or an
>>>> existing object) is using a weak algorithm or key, a warning will be
>>>> printed out.
>>>>
>>>> Precisely, an algorithm or a key is weak if it matches the value of
>>>> the jdk.certpath.disabledAlgorithms security property defined in
>>>> conf/security/java.security.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8174143
>>> Deprecate security APIs that have been superseded
>>>
>>>> The classes and interfaces in the `java.security.acl` and
>>>> `javax.security.cert` packages have been superseded by replacements
>>>> for a long time and are deprecated in JDK 9. Two methods
>>>> `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and
>>>> `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also
>>>> deprecated since they return the
>>>> `javax.security.cert.X509Certificate` type.
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8168635
>>> rcache interop with krb5-1.15
>>>
>>>> The hash algorithm used in the Kerberos 5 replay cache file (rcache)
>>>> is updated from MD5 to SHA256 with this change. This is also the
>>>> algorithm used by MIT krb5-1.15. This change is interoperable with
>>>> earlier releases of MIT krb5, which means Kerberos 5 acceptors from
>>>> JDK 9 and MIT krb5-1.14 can share the same rcache file.
>>>>
>>>> A new system property named jdk.krb5.rcache.useMD5 is introduced. If
>>>> the system property is set to "true", JDK 9 will still use the MD5
>>>> hash algorithm in rcache. This is useful when both of the following
>>>> conditions are true: 1) the system has a very coarse clock and has to
>>>> depend on hash values in replay attack detection, and 2)
>>>> interoperability with earlier versions of JDK or MIT krb5 for rcache
>>>> files is required. The default value of this system property is
>>>> "false".
>>>
>>> Thanks
>>> Max
>>>
>>>
>>>