RFR: 3 security-libs release notes on keytool/krb5/etc
Bernd Eckenfels
ecki at zusammenkunft.net
Sat Mar 25 15:09:10 UTC 2017
Sure, did not want to cause work. it is just a minor thing, I guess most people would read "weak" as "short" (even when weak key has another meaning in cryptography). It is good to have those warnings.
Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
From: security-dev <security-dev-bounces at openjdk.java.net> on behalf of Weijun Wang <weijun.wang at oracle.com>
Sent: Saturday, March 25, 2017 1:46:03 AM
To: security-dev at openjdk.java.net
Subject: Re: RFR: 3 security-libs release notes on keytool/krb5/etc
After I said I would use short key I was also wondering how I should
describe this in the keytool and jarsigner output. Now I think "weak" is
more general and it covers the short length. I'll stick with it.
Bernd, hopefully you find this OK. When one see "512-bit key (weak)", it
means some quality test is already done.
Thanks
Max
On 03/25/2017 04:06 AM, Anthony Scarpino wrote:
> 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
>>>>
>>>>
>>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20170325/7eed8b3f/attachment.htm>
More information about the security-dev
mailing list