RSAPrivateKeyImpl and RSAPrivateCrtKeyImpl
- throws InvalidKeyException when RSAUtil.createAlgorithmId(type, keyParams)
fails. I'll keep it.
EdDSAPrivateKeyImpl, XDHPrivateKeyImpl and ECPrivateKeyImpl
- check the input ECParameterSpec params and might throw an
InvalidKeyException. I'll keep it
On 6/3/20 3:05 PM, Anthony Scarpino wrote:
On 6/3/20 9:23 AM, Sean Mullan wrote:
On 6/2/20 6:33 PM, Anthony Scarpino wrote:
"If this signature has been previously initialized with parameters
(by calling {@link #setParameter(AlgorithmParameterSpec)} or {@link
#setParameter(String, Object)}) and
Hi,
Anyone can help review this straightforward enhancement? The changes are
mostly based on the submitted patch with some minor polishing.
Essentially re-using existing buffer instead of relying on the Cipher
object to allocate new buffers.
RFE: https://bugs.openjdk.java.net/browse/JDK-8087
Hi,
Anyone can help review this fix? I changed
com.sun.crypto.provider.HmacCore class and
sun.security.ssl.HandshakeHash class to check for cloneability based on
the clone() call instead of the Cloneable interface. Noticed a bug in
sun.security.provider.DigestBase class which misses to reset
Hi, Max,
Overall looks very good. Just one more thing:
Different key classes seems to differ in their handling of IOException
in their constructor which produces the DER bytes.
DSAPrivateKey changed to use AssertionError, XDHPrivateKeyImpl and
EdDSAPrivateKeyImpl throws ProviderException. It
On 6/3/20 9:23 AM, Sean Mullan wrote:
On 6/2/20 6:33 PM, Anthony Scarpino wrote:
"If this signature has been previously initialized with parameters
(by calling {@link #setParameter(AlgorithmParameterSpec)} or {@link
#setParameter(String, Object)}) and the underlying signature
implementation sup
On 6/2/20 6:33 PM, Anthony Scarpino wrote:
"If this signature has been previously initialized with parameters
(by calling {@link #setParameter(AlgorithmParameterSpec)} or {@link
#setParameter(String, Object)}) and the underlying signature
implementation supports returning the parameters as {@cod
On 2020/6/3 22:57, Weijun Wang wrote:
TsaParam.java:
- Please group the fields into different area. Looks like some are fields in
TSTInfo, and some are server internals.
One usage of this class is carrying all parameters delivered by HTTP
request. Do you mean they should be grouped in differ
On 6/3/2020 8:15 AM, Weijun Wang wrote:
On Jun 3, 2020, at 10:10 PM, Xuelei Fan wrote:
It looks good to me.
Thanks.
BTW, I may declare KnownOIDs.oid as final and use it directly, rather than use
the value() method.
I'll keep it flexible at the moment. I dreamed of a day where an OID
> On Jun 3, 2020, at 10:10 PM, Xuelei Fan wrote:
>
> It looks good to me.
Thanks.
>
> BTW, I may declare KnownOIDs.oid as final and use it directly, rather than
> use the value() method.
I'll keep it flexible at the moment. I dreamed of a day where an OID is only
its DER sequence and sel
> On Jun 3, 2020, at 10:14 PM, sha.ji...@oracle.com wrote:
>
> Hi Max,
>
> On 2020/6/3 17:17, Weijun Wang wrote:
>> TimeStampCheck.java:
>>
>> - Can you please inline all those private getXyz() calls in Interceptor into
>> getRespParam()? I would like to see all these customizations in one p
Hi Max,
On 2020/6/3 17:17, Weijun Wang wrote:
TimeStampCheck.java:
- Can you please inline all those private getXyz() calls in Interceptor into
getRespParam()? I would like to see all these customizations in one place. Just
add a blank line in between and it will be clean enough for me.
OK
It looks good to me.
BTW, I may declare KnownOIDs.oid as final and use it directly, rather
than use the value() method.
Xuelei
On 6/2/2020 11:27 PM, Weijun Wang wrote:
Please review the code change at
http://cr.openjdk.java.net/~weijun/8246397/webrev.00/
The following KnownOIDs lines a
TimeStampCheck.java:
- Can you please inline all those private getXyz() calls in Interceptor into
getRespParam()? I would like to see all these customizations in one place. Just
add a blank line in between and it will be clean enough for me.
TsaParam.java:
- Please group the fields into differ
The source change looks fine to me.
In TrustedCert.java:
- You can use FileOutputStream and Files.copy(Path,OutputStream) in cat().
- There is no need to recreate root.jks and root.pem.
- Why not use -trustcacerts below?
160 kt("-importcert -file server.pem -noprompt", "server.jks");
15 matches
Mail list logo
