<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>I like Bernd's first suggestion: instead of "weak key" use "weak
key size" (or something similar). This seems like a relatively
simple solution that will clarify what is actually being tested.<br>
</p>
<br>
<div class="moz-cite-prefix">On 3/25/2017 11:09 AM, Bernd Eckenfels
wrote:<br>
</div>
<blockquote
cite="mid:DB6P193MB0023FB92286667B2758C166EFF310@DB6P193MB0023.EURP193.PROD.OUTLOOK.COM"
type="cite">
<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>
<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 moz-do-not-send="true" 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 style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
security-dev <a class="moz-txt-link-rfc2396E" href="mailto:security-dev-bounces@openjdk.java.net"><security-dev-bounces@openjdk.java.net></a>
on behalf of Weijun Wang <a class="moz-txt-link-rfc2396E" href="mailto:weijun.wang@oracle.com"><weijun.wang@oracle.com></a><br>
<b>Sent:</b> Saturday, March 25, 2017 1:46:03 AM<br>
<b>To:</b> <a class="moz-txt-link-abbreviated" href="mailto:security-dev@openjdk.java.net">security-dev@openjdk.java.net</a><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 moz-do-not-send="true"
href="http://bernd.eckenfels.net">http://bernd.eckenfels.net</a><br>
>>>> <<a moz-do-not-send="true"
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
<a class="moz-txt-link-rfc2396E" href="mailto:security-dev-bounces@openjdk.java.net"><security-dev-bounces@openjdk.java.net></a> on behalf<br>
>>>> of Weijun Wang
<a class="moz-txt-link-rfc2396E" href="mailto:weijun.wang@oracle.com"><weijun.wang@oracle.com></a><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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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>
</blockquote>
<br>
</body>
</html>