Case-sensitive Keystore for PKCS#12

[Michael StJohns]

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.

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.Patel8 at ibm.com>
> *Sent:* Thursday, July 14, 2022 6:26 PM
> *To:* Xuelei Fan <xuelei.f at gmail.com>; Michael StJohns 
> <mstjohns at comcast.net>
> *Cc:* security-dev at openjdk.org <security-dev at 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-retn at openjdk.org> on behalf of 
> Xuelei Fan <xuelei.f at gmail.com>
> *Sent:* Thursday, July 14, 2022 3:10 AM
> *To:* Michael StJohns <mstjohns at comcast.net>
> *Cc:* security-dev at openjdk.org <security-dev at openjdk.org>
> *Subject:* [EXTERNAL] Re: Case-sensitive Keystore for PKCS#12
>
>
> > On Jul 13, 2022, at 2:20 PM, Michael StJohns <mstjohns at 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.Patel8 at 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/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?
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220720/4dc147a2/attachment.htm>