Incorrect encoding of PKCS12 bag attributes

[Wei-Jun Wang]

Hi Michael,

I’m not sure what exact problem you ran into, but looking at the implementation of PKCS12KeyStore at [1] the friendly name is hardcoded to be encoded in BMPString:

            bagAttr1.putOID(PKCS9FriendlyName_OID);
            DerOutputStream bagAttrContent1 = new DerOutputStream();
            DerOutputStream bagAttrValue1 = new DerOutputStream();
            bagAttrContent1.putBMPString(alias);

On line 2523 of the same file, it’s also always decoded as BMPString:

                    if (attrId.equals(PKCS9FriendlyName_OID)) {
                        alias = valSet[0].getBMPString();

I did try to create a PKCS12 keystore with `-alias acéü`, and the result is indeed BMPString:

    0000: 1E 08 00 61 00 63 00 E9   00 FC                    ...a.c....

—Max

[1] https://github.com/openjdk/jdk/blob/6765f902505fbdd02f25b599f942437cd805cad1/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java#L1646



> On Jul 30, 2021, at 11:26 AM, Osipov, Michael (LDA IT PLM) <michael.osipov at siemens.com> wrote:
> 
> Am 2021-07-29 um 16:05 schrieb Sean Mullan:
>> Are you calling the PKCS12Attribute(String, String) constructor from your code? That API currently specifies that String values are encoded as UTF-8, so we could not change the behavior without a specification change. Can you use the PKCS12Attribute(byte[]) constructor instead which takes a DER-encoded value?
> 
> Hi Sean,
> 
> I don't use this API. I interact with
>> KeyStore javaTrustStore = KeyStore.getInstance("PKCS12");
>> 			javaTrustStore.load(null, null);
> 
>> 		for (Rdn rdn : ldapName.getRdns()) {
>> 			if (rdn.getType().equalsIgnoreCase("CN"))
>> 				alias = (String) rdn.getValue();
>> 		}
> 
>> 		javaTrustStore .setCertificateEntry(alias, cert);
> 
> only. So I am using a high level API. But even if I'd use this API and pass the UCS-2 encoded byte array of that cert
>> CN=NetLock Arany (Class Gold) Főtanúsítvány,OU=Tanúsítványkiadók (Certification Services),O=NetLock Kft.,L=Budapest,C=HU
> 
> The ASN.1 tag would still be incorrect for friendlyName (1.2.840.113549.1.9.20) because it would OctetString and not BMPString.
> 
> It seems to be that the API, or ObjectIdentifier and KnownOIDs  classes miss to carry the ASN.1 tag for the actual value. Don't they?
> 
> Michael
> 
> PS: This CA
>> CN=E-Tugra Certification Authority,OU=E-Tugra Sertifikasyon Merkezi,O=E-Tuğra EBG Bilişim Teknolojileri ve Hizmetleri A.Ş.,L=Ankara,C=TR
> was smart enough to stick with US-ASCII only in the CN, but still single-byte != two-byte UCS-2
> 
> 
>> On 6/14/21 3:21 PM, Osipov, Michael (LDA IT PLM) wrote:
>>> Folks,
>>> 
>>> can someone confirm the following bug or tell me I am too stupid to read
>>> the RFCs:
>>> 
>>> I have recently created a PKCS12-based trust store and had one CA from
>>> Hungary with non-ASCII chars in the subject's CN RDN.
>>> 
>>> RFC 7292 for friendlyName refers to RFC 2985, section 5.5.1:
>>>> 
>>>>     friendlyName ATTRIBUTE ::= {
>>>>             WITH SYNTAX BMPString (SIZE(1..pkcs-9-ub-friendlyName))
>>>>             EQUALITY MATCHING RULE caseIgnoreMatch
>>>>             SINGLE VALUE TRUE
>>>>             ID pkcs-9-at-friendlyName
>>>>     }
>>> 
>>> So a BMPString -- which is UCS-2 encoding. Looking at [1] shows that
>>> Java ignores the RFC and always creates an UTF8String regardless of the
>>> attribute OID, thus breaking the semantics of friendlyName.
>>> 
>>> Who's wrong here?
>>> 
>>> For some strange reason OpenSSL does it in a similar fashion:
>>> In pkcs12.h.in:
>>>   > # define PKCS12_add_friendlyname PKCS12_add_friendlyname_utf8
>>> where the function contains:
>>>> if (X509at_add1_attr_by_NID(&bag->attrib, NID_friendlyName,
>>>>                                  MBSTRING_UTF8, (unsigned char *)name, namelen) != NULL)
>>> 
>>> 
>>> [1]
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F739769c8fc4b496f08a92225a12d07414537b6c0%2Fsrc%2Fjava.base%2Fshare%2Fclasses%2Fjava%2Fsecurity%2FPKCS12Attribute.java%23L230-L245&data=04%7C01%7C9d76b566-97f1-4355-9dbf-6dcc0e8868d3%40ad011.siemens.com%7Cc475c3e0ca4b4dffe9e308d9529a0987%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637631643594135158%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Yi0n7ZEXPHxas%2Fe17phd7ahX%2BXwlFXnCTJsYMqhLyZM%3D&reserved=0 
>>> 
>>> Regards,
>>> 
>>> Michael
>>> 
>