> On Jul 20, 2022, at 7:00 AM, Michael StJohns <mstjo...@comcast.net> wrote: > > Hi Ravi - > > Not speaking for the openjdk folk, I would expect you would be better off > implementing this as an external KeyStore provider yourself as I would guess > there isn't a broad demand for something that meets your requirements at this > point. > +1.
Xuelei > Later, Mike > > > On 7/20/2022 6:39 AM, Ravi Patel8 wrote: >> Hi Mike and Xuelei, >> >> Thank you for the suggested solutions with an added attribute and a new >> provider. Do you think 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 <ravi.pat...@ibm.com> <mailto:ravi.pat...@ibm.com> >> Sent: Thursday, July 14, 2022 6:26 PM >> To: Xuelei Fan <xuele...@gmail.com> <mailto:xuele...@gmail.com>; Michael >> StJohns <mstjo...@comcast.net> <mailto:mstjo...@comcast.net> >> Cc: security-dev@openjdk.org <mailto:security-dev@openjdk.org> >> <security-dev@openjdk.org> <mailto:security-dev@openjdk.org> >> Subject: Re: [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12 >> >> Thank you for the suggested solutions with an added attribute and a new >> provider. Do you think it is something that could be contributed to the JDK, >> or do you suggest this should be taken up as an external provider? >> From: security-dev <security-dev-r...@openjdk.org> >> <mailto:security-dev-r...@openjdk.org> on behalf of Xuelei Fan >> <xuele...@gmail.com> <mailto:xuele...@gmail.com> >> Sent: Thursday, July 14, 2022 3:10 AM >> To: Michael StJohns <mstjo...@comcast.net> <mailto:mstjo...@comcast.net> >> Cc: security-dev@openjdk.org <mailto:security-dev@openjdk.org> >> <security-dev@openjdk.org> <mailto:security-dev@openjdk.org> >> Subject: [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12 >> >> >> >> > On Jul 13, 2022, at 2:20 PM, Michael StJohns <mstjo...@comcast.net> >> > <mailto:mstjo...@comcast.net> 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 KeyStore APIs. It may be not good to break the standards for >> >> corner cases? >> >> >> >> Xuelei >> > >> > Hi Xuelei - >> > >> > It wouldn't actually be breaking the PKCS12 spec - the addition of more >> > attributes is part of the standard. >> I agreed it could not break PKCS12 spec. I referred to the friendlyName >> spec in PKCS12. An additional attribute could be used for the >> case-in-sensitive name support. But there is a need to define and support >> the attribute in the KeyStore implementation, just as you described in your >> previous reply. >> >> >> > Nor, given the CaseExactJKS implementation, would it be breaking the JDK >> > spec AFAICT. There is this in the KeyStore javadoc: >> > >> >> Whether aliases are case sensitive is implementation dependent. In order >> >> to avoid problems, it is recommended not to use aliases in a KeyStore >> >> that only differ in case. >> > The approach you suggest wouldn't work, because you couldn't store one key >> > with "MikesKey" and another with "MIKESKEY" in the Keystore. >> > >> >> I did not meant to cover the case. It may be fine to use a map, in which >> “MikesKey” may be mapped to “mikeskkey-1000100”, and MIKESKEY to >> “mikeskkey-0000000”, or something else like you described below ("Mike" -> >> "04mike8”). >> >> Xuelei >> >> >> > Hmm - let me rephrase that slightly. You could use this approach, but not >> > in the way you suggested. Instead, you'd need a transform from a String >> > to a unique string that you could use inside the key store. The actual >> > alias within the keystore would be the unique string. >> > >> > One way of doing that: Lowercase the string. Prepend the string with a 2 >> > character length field. Post pend the string with a hex field of >> > CEIL(length/16) characters, each hex character representing 16 bits that >> > indicate the case of the string. >> > >> > e.g. "Mike" -> "04mike8" >> > >> > Just a thought - Mike >> > >> >> >> >>> On Jul 13, 2022, at 4:38 AM, Ravi Patel8 <ravi.pat...@ibm.com> >> >>> <mailto:ravi.pat...@ibm.com> wrote: >> >>> >> >>> We have a customer who is having a security requirement. He wants to >> >>> know, Is it possible to have case-sensitive support for PKCS#12? We >> >>> referred the RFCs for PKCS#12. We found that PKCS#12 uses a case >> >>> in-sensitive alias and the alias Name is mapped with friendlyName >> >>> attribute, which is specified as "caseIgnoreMatch" as below. >> >>> >> >>> friendlyName ATTRIBUTE ::= { >> >>> WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName)) >> >>> EQUALITY MATCHING RULE caseIgnoreMatch >> >>> SINGLE VALUE TRUE >> >>> ID pkcs-9-at-friendlyName >> >>> } >> >>> >> >>> The RFCs can be found here: >> >>> https://datatracker.ietf.org/doc/html/rfc7292 >> >>> <https://datatracker.ietf.org/doc/html/rfc7292> >> >>> https://datatracker.ietf.org/doc/html/rfc2985#page-19 >> >>> <https://datatracker.ietf.org/doc/html/rfc2985#page-19> >> >>> >> >>> The JKS key store(case in-sensitive alias) has a special version >> >>> (CaseExactJKS) that uses case sensitive aliases. >> >>> So similarly, Will it be acceptable to have a case sensitive version of >> >>> PKCS#12 as CaseExactPKCS12 which will use case sensitive aliases? >> > >> >
