Hi,
That's an interesting idea. I don't think a method in SSLSession would
be the right place for such a method, maybe SSLContext given it's a
server side operation affecting many sessions. If we do enhance the API
for stateless operations, that would be a reasonable addition.
Thanks for t
Hello,
The change seems reasonable, but should there maybe a method to refresh
temporary keys used for those session tokens - I.e. "invalidate all" and link
to that so specific implementations are encourages to offer such an API.
Gruss
Bernd
--
http://bernd.eckenfels.net
___
Ah yes, you're correct.
But because of this delayed selection, the existence of CloneableDelegate is
not that useful unless user has specified a provider at the beginning. At first
every Signature is a Delegate and thus not a Cloneable, you would have to clone
it to make it Cloneable.
I notice
I added myself as reviewer of the CSR.
Xuelei
On 6/15/2020 5:42 PM, Anthony Scarpino wrote:
The specifications for TLS 1.3 (RFC 8446) and Stateless Resumption for
TLS 1.2 (RFC 5077) does not define session invalidation. Additionally,
RFC 5077 provides research that it is unnecessary. This chan
The specifications for TLS 1.3 (RFC 8446) and Stateless Resumption for
TLS 1.2 (RFC 5077) does not define session invalidation. Additionally,
RFC 5077 provides research that it is unnecessary. This change is to
clarify that session invalidation method in the Java API, in
javax.net.ssl.SSLSessio
Hmm, on a second thought, I reverted back on this last suggestion.
Signature class has this delayed provider selection mechanism, so the
clone() method should always rely on the chosen signatureSpi obj.
Thanks,
Valerie
On 6/15/2020 12:59 PM, Valerie Peng wrote:
Sure, sounds good. Webrev is upda
Sure, sounds good. Webrev is updated in place at webrev.01 since the
change is just one-line.
Will proceed with integration once the mach5 tests finish.
Thanks!
Valerie
On 6/14/2020 2:21 AM, Weijun Wang wrote:
Looks fine to me. Maybe you can also use "if (this instanceof Cloneable)" in
Signat
