Case-sensitive Keystore for PKCS#12

Xuelei Fan xuelei.f at gmail.com
Wed Jul 20 14:04:37 UTC 2022



> On Jul 20, 2022, at 7:00 AM, Michael StJohns <mstjohns at 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.Patel8 at ibm.com> <mailto:Ravi.Patel8 at ibm.com>
>> Sent: Thursday, July 14, 2022 6:26 PM
>> To: Xuelei Fan <xuelei.f at gmail.com> <mailto:xuelei.f at gmail.com>; Michael StJohns <mstjohns at comcast.net> <mailto:mstjohns at comcast.net>
>> Cc: security-dev at openjdk.org <mailto:security-dev at openjdk.org> <security-dev at openjdk.org> <mailto: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> <mailto:security-dev-retn at openjdk.org> on behalf of Xuelei Fan <xuelei.f at gmail.com> <mailto:xuelei.f at gmail.com>
>> Sent: Thursday, July 14, 2022 3:10 AM
>> To: Michael StJohns <mstjohns at comcast.net> <mailto:mstjohns at comcast.net>
>> Cc: security-dev at openjdk.org <mailto:security-dev at openjdk.org> <security-dev at openjdk.org> <mailto: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> <mailto: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> <mailto: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/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?
>> > 
>> > 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20220720/0e876ab5/attachment.htm>


More information about the security-dev mailing list