
<html>

<head>

<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">

<meta name="Generator" content="Microsoft Exchange Server">

<!-- converted from text --><style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>

</head>

<body>

<div>

<div id="x_compose-container" itemscope="" itemtype="https://schema.org/EmailMessage">

<span itemprop="creator" itemscope="" itemtype="https://schema.org/Organization"><span itemprop="name"></span></span>

<div>

<div>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. <br>

<br>

<div class="x_acompli_signature">Gruss<br>

Bernd<br>

-- <br>

<a dir="ltr" href="http://bernd.eckenfels.net">http://bernd.eckenfels.net</a></div>

<br>

</div>

</div>

</div>

<hr tabindex="-1" style="display:inline-block; width:98%">

<div id="x_divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" color="#000000" style="font-size:11pt"><b>From:</b> security-dev <security-dev-bounces@openjdk.java.net> on behalf of Weijun Wang <weijun.wang@oracle.com><br>

<b>Sent:</b> Saturday, March 25, 2017 1:46:03 AM<br>

<b>To:</b> security-dev@openjdk.java.net<br>

<b>Subject:</b> Re: RFR: 3 security-libs release notes on keytool/krb5/etc</font>

<div> </div>

</div>

</div>

<font size="2"><span style="font-size:10pt;">

<div class="PlainText">After I said I would use short key I was also wondering how I should

<br>

describe this in the keytool and jarsigner output. Now I think "weak" is <br>

more general and it covers the short length. I'll stick with it.<br>

<br>

Bernd, hopefully you find this OK. When one see "512-bit key (weak)", it <br>

means some quality test is already done.<br>

<br>

Thanks<br>

Max<br>

<br>

On 03/25/2017 04:06 AM, Anthony Scarpino wrote:<br>

> I'd agree with Sean, "weak" implies anything risk, the weakness isn't<br>

> necessarily key length related.<br>

><br>

> Tony<br>

><br>

> On 03/24/2017 11:56 AM, Sean Mullan wrote:<br>

>> On 3/24/17 7:01 AM, Weijun Wang wrote:<br>

>>> I'll use "short key".<br>

>><br>

>> I prefer the term "weak" which implies it is a risk. We already use that<br>

>> term in jarsigner so I think we should keep it consistent. You also<br>

>> print the size of the key so that describes what is wrong with it.<br>

>><br>

>> --Sean<br>

>><br>

>>><br>

>>> Thanks<br>

>>> Max<br>

>>><br>

>>> On 03/24/2017 06:26 PM, Bernd Eckenfels wrote:<br>

>>>> I wonder if "weak key" should be replaced by "weak key length" or<br>

>>>> "short<br>

>>>> key". It might otherwise imply key quality tests which are not carried<br>

>>>> out.<br>

>>>><br>

>>>> Gruss<br>

>>>> Bernd<br>

>>>> --<br>

>>>> <a href="http://bernd.eckenfels.net">http://bernd.eckenfels.net</a><br>

>>>> <<a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__bernd.eckenfels.net&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=L95YSg0eIcTu_shXWyN3XgC5kRlt5xJJuqogC6Ulqlk&m=nQPaZ9oNisvgXYmsVbzFkcB0qjPKYWTsWh0IIQtt1nw&s=yLFl1pk3TBMwqMqZMDE2e4d8rt9AVyNfUaC84QV3Lr0&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__bernd.eckenfels.net&d=DwMFAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=L95YSg0eIcTu_shXWyN3XgC5kRlt5xJJuqogC6Ulqlk&m=nQPaZ9oNisvgXYmsVbzFkcB0qjPKYWTsWh0IIQtt1nw&s=yLFl1pk3TBMwqMqZMDE2e4d8rt9AVyNfUaC84QV3Lr0&e=</a>><br>

>>>><br>

>>>><br>

>>>><br>

>>>><br>

>>>> ------------------------------------------------------------------------<br>

>>>><br>

>>>> *From:* security-dev <security-dev-bounces@openjdk.java.net> on behalf<br>

>>>> of Weijun Wang <weijun.wang@oracle.com><br>

>>>> *Sent:* Friday, March 24, 2017 2:12:01 AM<br>

>>>> *To:* Security Dev OpenJDK<br>

>>>> *Subject:* RFR: 3 security-libs release notes on keytool/krb5/etc<br>

>>>><br>

>>>> Hi All<br>

>>>><br>

>>>> Please take a review on 3 release notes. The content itself is<br>

>>>> pasted as<br>

>>>> quotation below.<br>

>>>><br>

>>>> <a href="https://bugs.openjdk.java.net/browse/JDK-8176087">https://bugs.openjdk.java.net/browse/JDK-8176087</a><br>

>>>> keytool now prints warnings when reading or generating cert/cert req<br>

>>>> using weak algorithms<br>

>>>><br>

>>>>> In all keytool functions, if the certificate/certificate request/CRL<br>

>>>>> that is working on (whether it be the input, the output, or an<br>

>>>>> existing object) is using a weak algorithm or key, a warning will be<br>

>>>>> printed out.<br>

>>>>><br>

>>>>> Precisely, an algorithm or a key is weak if it matches the value of<br>

>>>>> the jdk.certpath.disabledAlgorithms security property defined in<br>

>>>>> conf/security/java.security.<br>

>>>><br>

>>>> <a href="https://bugs.openjdk.java.net/browse/JDK-8174143">https://bugs.openjdk.java.net/browse/JDK-8174143</a><br>

>>>> Deprecate security APIs that have been superseded<br>

>>>><br>

>>>>> The classes and interfaces in the `java.security.acl` and<br>

>>>>> `javax.security.cert` packages have been superseded by replacements<br>

>>>>> for a long time and are deprecated in JDK 9. Two methods<br>

>>>>> `javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain()` and<br>

>>>>> `javax.net.ssl.SSLSession.getPeerCertificateChain()` are also<br>

>>>>> deprecated since they return the<br>

>>>>> `javax.security.cert.X509Certificate` type.<br>

>>>><br>

>>>> <a href="https://bugs.openjdk.java.net/browse/JDK-8168635">https://bugs.openjdk.java.net/browse/JDK-8168635</a><br>

>>>> rcache interop with krb5-1.15<br>

>>>><br>

>>>>> The hash algorithm used in the Kerberos 5 replay cache file (rcache)<br>

>>>>> is updated from MD5 to SHA256 with this change. This is also the<br>

>>>>> algorithm used by MIT krb5-1.15. This change is interoperable with<br>

>>>>> earlier releases of MIT krb5, which means Kerberos 5 acceptors from<br>

>>>>> JDK 9 and MIT krb5-1.14 can share the same rcache file.<br>

>>>>><br>

>>>>> A new system property named jdk.krb5.rcache.useMD5 is introduced. If<br>

>>>>> the system property is set to "true", JDK 9 will still use the MD5<br>

>>>>> hash algorithm in rcache. This is useful when both of the following<br>

>>>>> conditions are true: 1) the system has a very coarse clock and has to<br>

>>>>> depend on hash values in replay attack detection, and 2)<br>

>>>>> interoperability with earlier versions of JDK or MIT krb5 for rcache<br>

>>>>> files is required. The default value of this system property is<br>

>>>>> "false".<br>

>>>><br>

>>>> Thanks<br>

>>>> Max<br>

>>>><br>

>>>><br>

>>>><br>

><br>

</div>

</span></font>

</body>

</html>