Re: [Internet]Re: Re: Re: JEP Review Request: TLS Certificate Compression

2023-07-20 Thread Xuelei Fan
]: https://chromestatus.com/feature/5696925844111360 > On Aug 2, 2022, at 7:53 PM, Xuelei Fan wrote: > >> >> On Aug 2, 2022, at 2:55 PM, Bradford Wetmore >> wrote: >> >> Hi Xuelei, >> >> Sean wrote: >> >>> I haven't had time to

Re: JEP draft: Key Encapsulation Mechanism API

2023-02-08 Thread Xuelei Fan
> On Jan 25, 2023, at 8:43 PM, Wei-Jun Wang wrote: > If someone really cares about the result of getProvider(), they should be > careful no other thread calls encapsulation or decapsulation. If no-one care about the result of getProvider(), is it possible to remove this method from the desi

Re: Update to JEP draft: Key Encapsulation Mechanism API

2023-02-04 Thread Xuelei Fan
n designed as more immutable, the APIs may look different. - var kemS = KEM.getInstance("DHKEM”); + var kemS = KEM.getInstance("DHKEM”, pkR, new DerivedKeyParameterSpec("AES", 32)); Best, Xuelei > Thanks, > Max > > > > On Feb 4, 2023, at 10:44 AM, Xuelei Fan

Re: Update to JEP draft: Key Encapsulation Mechanism API

2023-02-04 Thread Xuelei Fan
Hi, Thank you for the update. What’s the different impact of parameters like algorithm name, KEMParameterSpec, PublicKey/PrivateKey and DerivedKeyParameterSpec? I’m not very sure of it. For example, at 2013, the following cord should work without any issues: 1. var kemS = KEM.getInstance("

Re: JEP draft: Key Encapsulation Mechanism API

2023-01-25 Thread Xuelei Fan
> On Jan 25, 2023, at 8:43 PM, Wei-Jun Wang wrote: > If someone really cares about the result of getProvider(), they should be > careful no other thread calls encapsulation or decapsulation. If no-one care about the result of getProvider(), is it possible to remove this method from the desi

Re: JEP draft: Key Encapsulation Mechanism API

2023-01-25 Thread Xuelei Fan
Jun Wang wrote: > > Hi Xuelei, > > That's a bold suggestion. However, we'd like to the tradition of JCA/JCE at > the moment. > > Thanks, > Max > > >> On Jan 25, 2023, at 3:03 PM, Xuelei Fan wrote: >> >> For new set of service API

Re: JEP draft: Key Encapsulation Mechanism API

2023-01-25 Thread Xuelei Fan
For new set of service APIs, it may be worthy of considering to simplify the design and avoid duplicated SPIs by using java.util.ServiceLoade. Xuelei > On Jan 25, 2023, at 11:24 AM, Wei-Jun Wang wrote: > > Hi All, > > We are working on providing a new API for KEM (Key Encapsulation Mechanism)

Re: RFR: 8296408: Make the PCSCException public accessible

2022-11-23 Thread Xuelei Fan
I’m not very sure what the update public APIs may look like. If we are able to collect the possible card exception reasons, the design of CertPathValidatorException and CertPathValidatorException.BasicReason could be a reference. Xuelei > On Nov 23, 2022, at 9:21 AM, Michael StJohns wrote: >

Re: Undo deprecation of brainpool EC

2022-11-20 Thread Xuelei Fan
Hi, As I’m working on this area recently, I will see if I can contribute. But it may be no easier than JDK 21. If you don’t mind, I may ask for more requirement details later and help for testing. Thanks, Xuelei > On Nov 15, 2022, at 11:23 PM, > wrote: > > Hi Xuelei and Sean, > > We use

Re: RFR: 8296820: Add implementation note to SSLContext.getInstance noting subsequent behavior if protocol is disabled

2022-11-15 Thread Xuelei Fan
> The wording in this PR specifically refers to the protocol version that was specified. It isn't covering other optional protocols that may be supported. Sorry, I may not make it clear. The protocol specified in SSLContext.getInstance is not TLS protocol version. I think the protocol disabled i

Re: Undo deprecation of brainpool EC

2022-11-15 Thread Xuelei Fan
Hi Benjamin, May I ask what are the sizes of brainpool curves used in practice? Thank, Xuelei > On Nov 14, 2022, at 12:36 AM, benjamin.marw...@f-i.de wrote: > > Hello everyone! > > To our surprise, brainpool EC have been deprecated with Java 14+ [1]. > However, JDK-8234924 [1] does not add any

Re: TLS1.3 record padding

2022-11-07 Thread Xuelei Fan
4434> > [3] https://trac.nginx.org/nginx/ticket/1977 > <https://trac.nginx.org/nginx/ticket/1977> > > > sob., 5 lis 2022 o 04:01 Bradford Wetmore <mailto:bradford.wetm...@oracle.com>> napisał(a): > > > On 11/4/2022 8:58 AM, Xuelei Fan wrote: > > The

Re: TLS1.3 record padding

2022-11-04 Thread Xuelei Fan
The padding may be also necessary to prevent from a kind of attacks, besides hiding the length. But I cannot recall the details. Removing padding may be not the direction. Instead, a padding length customizable solution may be more flexible. Here is an enhancement request in JBS (https://bug

Re: Post handshake client verification with TLSv1.3

2022-08-10 Thread Xuelei Fan
lto:b...@coldbox.org> > ColdBox Platform: http://www.coldbox.org <http://www.coldbox.org/> > Blog: http://www.codersrevolution.com <http://www.codersrevolution.com/> > > > > On Wed, Aug 10, 2022 at 9:36 AM Xuelei Fan <mailto:xuele...@gmail.com>> wrote:

Re: Post handshake client verification with TLSv1.3

2022-08-10 Thread Xuelei Fan
> > ColdBox Platform: http://www.coldbox.org <http://www.coldbox.org/> > Blog: http://www.codersrevolution.com <http://www.codersrevolution.com/> > > > > On Tue, Aug 9, 2022 at 9:05 PM Xuelei Fan <mailto:xuele...@gmail.com>> wrote: > If we have a look from

Re: Post handshake client verification with TLSv1.3

2022-08-09 Thread Xuelei Fan
If we have a look from the viewpoint of HTTP/2, how applications could meet the requirements in HTTP/2? Did you have a plan to have the application works with HTTP/2 in the future? Xuelei > On Aug 9, 2022, at 12:29 PM, Brad Wood wrote: > > I have some questions about this ticket > https://

Re: [Internet]Re: Re: Re: JEP Review Request: TLS Certificate Compression

2022-08-02 Thread Xuelei Fan
> On Aug 2, 2022, at 2:55 PM, Bradford Wetmore > wrote: > > Hi Xuelei, > > Sean wrote: > >> I haven't had time to look at this in detail yet. I would like a >> couple more weeks to review the draft. > > We've been looking closely at RFC 8879 and your proposal to add support into > JSSE. I

Re: Case-sensitive Keystore for PKCS#12

2022-07-20 Thread Xuelei Fan
it is something that could be contributed to the JDK, >> or do you suggest this should be taken up as an external provider? >> From: Ravi Patel8 <mailto:ravi.pat...@ibm.com> >> Sent: Thursday, July 14, 2022 6:26 PM >> To: Xuelei Fan <mailto:xuele...@gmail.com&

Re: Case-sensitive Keystore for PKCS#12

2022-07-13 Thread Xuelei Fan
> On Jul 13, 2022, at 2:20 PM, Michael StJohns wrote: > > On 7/13/2022 3:26 PM, Xuelei Fan wrote: >> Is it possible make it in the application layer? For example, mapping >> case-sensitive name to case-in-sensitive name before calling into the >> standard KeyStor

Re: Case-sensitive Keystore for PKCS#12

2022-07-13 Thread Xuelei Fan
Is it possible make it in the application layer? For example, mapping case-sensitive name to case-in-sensitive name before calling into the standard KeyStore APIs. It may be not good to break the standards for corner cases? Xuelei > On Jul 13, 2022, at 4:38 AM, Ravi Patel8 wrote: > > We hav