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.pat...@ibm.com>
*Sent:* Thursday, July 14, 2022 6:26 PM
*To:* Xuelei Fan <xuele...@gmail.com>; Michael StJohns
<mstjo...@comcast.net>
*Cc:* security-dev@openjdk.org <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> on behalf of
Xuelei Fan <xuele...@gmail.com>
*Sent:* Thursday, July 14, 2022 3:10 AM
*To:* Michael StJohns <mstjo...@comcast.net>
*Cc:* security-dev@openjdk.org <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>
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> 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?
>
>
