Please review the change at
http://cr.openjdk.java.net/~weijun/8205507/webrev.00/
Here I cached the keys for each signature method. Running 100 times on
solaris-sparcv9 and the longest duration is 10 minutes, much shorter than the
timeout threshold of 50 mins.
I didn't hardcoded the keys be
In my understanding, the author deliberately wants to show the absolute paths
when there are multiple jar files with the same name (Ex: a jar hell). Maybe we
can add some more detail in the java.security so an admin knows what exact
impact it has.
--Max
> On Sep 8, 2018, at 3:41 AM, Sean Mulla
> On Sep 7, 2018, at 12:08 PM, Adam Petcher wrote:
>
> This is a good suggestion. I don't have particularly strong feelings about
> using separate providers vs a property in a single provider. I think the
> fundamental issues are the same, and this choice mostly affects API details.
>
> Do
On 8/29/18 10:01 AM, Baesken, Matthias wrote:
Hi Max, thanks for your input .
I created another webrev , this contains now the suggested
SecurityProperties class :
http://cr.openjdk.java.net/~mbaesken/webrevs/8205525.6/
java/util/jar/Attributes.java
469 return AccessController
Hi,
I have not had a chance to review this JEP yet. Personally, if
possible, I would expect there is no public APIs update so that more
applications can benefit from the enhancement, and SunJSSE could
benefits from more crypto providers. I'm not sure if it is possible or
not now, or how co
Hi,
In general, System properties should be avoided, they add complexity to
configurations and
especially if they change sensitive behavior. In any case, the defaults
should be secure-by-default;
not the other way around.
Perhaps two different providers, one secure and one more secure.
$.02
This is a good suggestion. I don't have particularly strong feelings
about using separate providers vs a property in a single provider. I
think the fundamental issues are the same, and this choice mostly
affects API details.
Do you think this should be a system property, security property, or
On 8/27/18 10:25 AM, Baesken, Matthias wrote:
Will sun.net.util.SocketExceptions be changed to use the supporting
class or is that a separate issue?
I think this is a separate issue .
I think we should fix it as part of this issue. It shouldn't be hard and
then we don't have to file another
Adam,
I tend to agree with Mike that disallowing import/export of keys using
BigInteger is not the value of a branchless implementation. As you point out
in the JEP the provider is greatly hindered by this design choice. I feel it
would be better to implementing the BigInteger parts and have a
I'm only going to respond to one of your points in detail, see inline below.
For the other points, I don't think we are going to agree. You want the
implementation to be more interoperable, and I have stated that the
level of interoperability that you want is not a goal of the JEP. This
is sup
On 9/6/2018 9:53 AM, Adam Petcher wrote:
On 9/5/2018 5:53 PM, Michael StJohns wrote:
BigInteger is not required to encode a PKCS8 key, but its trivial to
translate from BigInteger to PKCS8 and vice versa. Note that
internally, the current BigInteger stores the magnitude as an array
of int i
> I'm not sure if the second x25519/x448 strings (for algorithm and
> NamedParameterSpec names) would still be needed, since I can use
> the OID in some of these places.
I see your points. However, we may want to think if third party wants
to implement a JSSE provider, whether the JCE providers
On 9/7/2018 9:03 AM, Adam Petcher wrote:
This is more clear, thanks. See below.
On 9/7/2018 11:34 AM, Xuelei Fan wrote:
EncodedKeySpec keySpec = ... // find a way to construct the keySpec
// at least, we can use:
// new EncodedKeySpe
This is more clear, thanks. See below.
On 9/7/2018 11:34 AM, Xuelei Fan wrote:
EncodedKeySpec keySpec = ... // find a way to construct the keySpec
// at least, we can use:
// new EncodedKeySpec(byte[]);
//
Please let me know if you understand the following logic. Otherwise, I
will see if I could do something for you, maybe a prototype, maybe a
more detailed description. However, I may need more time for a
prototype/detailed description.
Per RFC 8446/7748, the X25519 key size is 32 bytes. Here
On 9/7/2018 9:34 AM, Xuelei Fan wrote:
JSSE should use the 'x25519' name (via NamedParameterSpec object) only.
This is the part that I don't know how to do. In JSSE, we convert
between the array containing the encoded public key and the BigInteger
representation of the public key used in XEC
On 9/7/2018 6:34 AM, Xuelei Fan wrote:
> The NamedParameterSpec object holds the name only, and not the key size.
The name is not a meaningless string, it refer to a specific thing. For
more examples, please refer to the standard names documentation, every
name has its specific meaning and
> The NamedParameterSpec object holds the name only, and not the key size.
The name is not a meaningless string, it refer to a specific thing. For
more examples, please refer to the standard names documentation, every
name has its specific meaning and the background. If the name is just a
mea
On 8/23/18 8:10 AM, Langer, Christoph wrote:
Hi Sean,
thanks for the information.
Can you please let me know when you've crated the Jira item for removal that I
can add me as a watcher?
There was actually an existing bug for this which had been marked
Confidential initially but I have now m
On 9/6/2018 4:49 PM, Xuelei Fan wrote:
I asked the question in a previous email. The key size for x25529 is
fixed, right?
Right.
If it is not right, stop here and tell me that it is not right. Keep
reading if it is right.
OK, as the key size for x25519 is fixed, when you know the algori
20 matches
Mail list logo
