RFR JDK-8179614: Test for jarsigner on verifying jars that are signed and timestamped by other JDK releases
Weijun Wang
weijun.wang at oracle.com
Mon Jun 12 09:29:46 UTC 2017
Great. Only 2 questions:
459 // Return key sizes according to the specified key algorithm.
460 private static int[] keySizes(String digestAlgorithm, String
keyAlgorithm) {
461 if (digestAlgorithm == DEFAULT) {
462 return new int[] { 0 };
463 }
464
465 if (keyAlgorithm == RSA || keyAlgorithm == DSA) {
466 return new int[] { 1024, 2048 };
467 } else if (keyAlgorithm == EC) {
468 return new int[] { 384, 571 };
469 }
470
471 return null;
472 }
Why is keysize dependent on digestalg? I mean, is it possible to always
return {1024,2048,0} and {384,571,0}?
379 // If signing fails, the following verifying has to
380 // be ignored.
381 if (signingStatus == STATUS.ERROR) {
382 continue;
383 }
Now that you've already checked sigalg support earlier in what cases it
could go wrong here?
Thanks
Max
On 06/12/2017 03:20 PM, sha.jiang at oracle.com wrote:
> Hi Max,
> Would you like to review the updated webrev:
> http://cr.openjdk.java.net/~jjiang/8179614/webrev.02/
> It can create certificate without -sigalg and -keysize, and jar signing
> also can use this certificate.
>
> Best regards,
> John Jiang
>
> On 09/06/2017 22:04, Weijun Wang wrote:
>>
>> On 06/09/2017 09:25 PM, sha.jiang at oracle.com wrote:
>>> Hi Max,
>>>
>>> On 09/06/2017 20:05, Weijun Wang wrote:
>>>> The test can be more friendly with default values.
>>>>
>>>> For example, in createCertificates(), you can generate certs that
>>>> use default sigalg and keysize (i.e. without specifying -siglag and
>>>> -keysize), and give them aliases with "default" or "null" inside.
>>>>
>>>> And in jar signing when signing with one -sigalg you can also choose
>>>> cert generated with different or default sigalgs.
>>> I supposed this test just focus on signed jar verifying, but not
>>> certificate creating and jar signing. So, I'm not sure such cases are
>>> necessary.
>>
>> Well sometimes a test can do many things. If you only care about jar
>> verification, why bother creating certs with different digest algorithms?
>>
>> On the other hand, if you do care about more, then in
>>
>> 338 // If the digest algorithm is not specified, then it
>> 339 // uses certificate with SHA256 digest and 1024 key
>> 340 // size.
>> 341 if (digestAlgorithm == DEFAULT) {
>> 342 certDigest = SHA256;
>> 343 certKeySize = 1024;
>> 344 }
>>
>> it seems a little awkward to hardcode the algorithm and keysize. If
>> signing is using a default algorithm, it seems natural to use the cert
>> that was generated with a default algorithm. In fact, this test case
>> is quite useful that it ensures our different tools are using the same
>> (or at least interoperable) default algorithms.
>>
>> --Max
>>
>>>>
>>>> BTW, I remember certain pairs of -keysize and -sigalg do not work
>>>> together. For example, 1024 bit of DSA key cannot be used with
>>>> SHA512withDSA signature algorithm. Have you noticed it?
>>> It looks SHA512withDSA is not supported yet.
>>> I was using JDK10 build 10. When the test tried to create certificate
>>> with -keyalg DSA -sigalg SHA512withDSA -keysize 1024, the below error
>>> raised:
>>> keytool error: java.security.NoSuchAlgorithmException: unrecognized
>>> algorithm name: SHA512withDSA
>>>
>>> If used -keyalg DSA -sigalg SHA1withDSA -keysize 2048, the error was:
>>> keytool error: java.security.InvalidKeyException: The security
>>> strength of SHA-1 digest algorithm is not sufficient for this key size
>>>
>>> Again, this test focus on signed jar verifying. If some problems are
>>> raised on certificate creating or jar signing, the associated
>>> verifying cases will be ignored.
>>>
>>> Best regards,
>>> John Jiang
>>>>
>>>> Thanks
>>>> Max
>>>>
>>>>
>>>> On 06/09/2017 04:44 PM, sha.jiang at oracle.com wrote:
>>>>> Hi Sean and Max,
>>>>> Thanks for your comments.
>>>>> Please review the updated webrev:
>>>>> http://cr.openjdk.java.net/~jjiang/8179614/webrev.01/
>>>>>
>>>>> The test has been modified significantly. The main points are:
>>>>> 1. Adds cases on EC. Now the test supports key algorithms RSA, DSA
>>>>> and EC.
>>>>> 2. Adds cases on SHA-512. Now the test supports digest algorithms
>>>>> SHA-1, SHA-256 and SHA-512.
>>>>> 3. Adds cases on key size. Exactly, [384, 571] for EC, [1024, 2048]
>>>>> for RSA and DSA.
>>>>> 4. Adds cases on default signature algorithm. Now the test report
>>>>> can display the default algorithmat column [Signature Algorithm].
>>>>> 5. Adds property -Djava.security.egd=file:/dev/./urandom for
>>>>> keytool and jarsigner commands.
>>>>> 6. Create a separated application, JdkUtils.java, to determine the
>>>>> JDK build version (java.runtime.version) and check if a signature
>>>>> algorithm is supported by a JDK.
>>>>> 7. Introduces a new property, named javaSecurityFile, for allowing
>>>>> users to specify alternative java security properties file.
>>>>> 8. Renames report column [Cert Type] to [Certificate]. This column
>>>>> displays the certificate identifiers, which is a combination of key
>>>>> algorithm, digest algorithm, key size and expired mark (if any).
>>>>> 9. The test summary also be updated accordingly.
>>>>>
>>>>> Best regards,
>>>>> John Jiang
>>>>>
>>>>>
>>>>> On 07/06/2017 23:11, Sean Mullan wrote:
>>>>>> On 6/6/17 9:14 PM, sha.jiang at oracle.com wrote:
>>>>>>> Hi Sean,
>>>>>>>
>>>>>>> On 07/06/2017 04:27, Sean Mullan wrote:
>>>>>>>> Hi John,
>>>>>>>>
>>>>>>>> This looks like a very useful test. I have not gone through all
>>>>>>>> of the code, but here are a few comments for now until I have
>>>>>>>> more time:
>>>>>>>>
>>>>>>>> - add tests for EC keys
>>>>>>>> - add tests for SHA-512 variants of the signature algorithms
>>>>>>>> - add tests for larger key sizes (ex: 2048 for DSA/RSA)
>>>>>>>> - you can use the diamond operator <> in various places
>>>>>>>> - might be more compact if jdkList() used Files.lines() to parse
>>>>>>>> the file into a stream then an array
>>>>>>> I did consider about the above two points. Because the test will
>>>>>>> be backported to JDK 6, so I only used the features those
>>>>>>> supported by JDK 6.
>>>>>>> I supposed that would make the backport easier. Does it make sense?
>>>>>>
>>>>>> Yes, that makes sense.
>>>>>>
>>>>>> --Sean
>>>>>>
>>>>>>>
>>>>>>> Best regards,
>>>>>>> John Jiang
>>>>>>>> - did you consider using the jarsigner API
>>>>>>>> (jdk.security.jarsigner) instead of the command-line? I think
>>>>>>>> this would be better (if possible) and it would give us some
>>>>>>>> more tests of that API.
>>>>>>>>
>>>>>>>> --Sean
>>>>>>>>
>>>>>>>> On 6/5/17 6:31 AM, sha.jiang at oracle.com wrote:
>>>>>>>>> Hi,
>>>>>>>>> Please review this manual test for checking if a jar, which is
>>>>>>>>> signed and timestamped by a JDK build, could be verified by
>>>>>>>>> other JDK builds.
>>>>>>>>> It also can be used to check if the default timestamp digest
>>>>>>>>> algorithm on signing is SHA-256.
>>>>>>>>> For more details, please look through the test summary.
>>>>>>>>>
>>>>>>>>> Issue: https://bugs.openjdk.java.net/browse/JDK-8179614
>>>>>>>>> Webrev: http://cr.openjdk.java.net/~jjiang/8179614/webrev.00/
>>>>>>>>>
>>>>>>>>> Best regards,
>>>>>>>>> John Jiang
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the security-dev
mailing list