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

Weijun Wang weijun.wang at oracle.com
Mon Mar 27 15:00:22 UTC 2017


This sounds reasonable. After all, the keytool output looks like

   Signature algorithm name: SHA256withRSA
   Subject Public Key Algorithm: 512-bit RSA key (weak)

so it does mean the size (instead of the bits) is weak.

Thanks
Max

On 03/27/2017 10:46 PM, Adam Petcher wrote:
> 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.
>
>
> On 3/25/2017 11:09 AM, Bernd Eckenfels wrote:
>> 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
>> >>>>
>> >>>>
>> >>>>
>> >
>



More information about the security-dev mailing list