On 08/26/2015 07:16 PM, Rajan Halade wrote:
Hi Sean,
On 8/26/15 8:39 AM, Sean Mullan wrote:
This looks ok now, although I would probably eliminate the tests for
SHA-1 and bump up the keysize to 2048, so that this test won't have to
be updated when those algorithms/keysizes are constrained in the future.
I would take up other enhancements later. For now, I have updated test
to reset jdk.tls.disabledAlgorithms to remove constraints.
http://cr.openjdk.java.net/~rhalade/8049237/webrev.02
I don't think the different signature variants buy you much, since what
you are mainly testing here is the ability to parse the created
certificate without errors. I would simplify the test by just having a
single test for each key type.
--Sean
Thanks,
Rajan
--Sean
On 08/25/2015 02:30 PM, Rajan Halade wrote:
On 8/25/15 10:09 AM, Sean Mullan wrote:
On 08/18/2015 09:01 PM, Xuelei Fan wrote:
Hi Rajan,
Sorry for the delay. The code looks fine to me. I was just
wondering,
what's the purpose for the V1toV3Cert.java test? Is it practice
behavior?
I had the same question. I would remove this test as it seems like a
obscure case not supported by any of our tools/APIs.
This test tries to convert V1 to V3 certificate. Ok, I removed this test
case.
http://cr.openjdk.java.net/~rhalade/8049237/webrev.01/
Thanks,
Rajan
--Sean
Thanks,
Xuelei
On 7/15/2015 9:37 AM, Rajan Halade wrote:
May I request you to review two new tests added. V1toV3Cert tries to
covert a existing V1 certificate to V3 and V3Certificate test
tries to
generate V3 certificate with different extensions.
Webrev: http://cr.openjdk.java.net/~rhalade/8049237/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8049237
Thanks,
Rajan