Incorrect encoding of PKCS12 bag attributes

[Osipov, Michael (LDA IT PLM)]

Max,

indeed! I was looking too low-level while analyzing how stuff works. 
friendlyName is handled as expected. Thank you for the clarification and 
apoligies for the noise.

Regards,

Michael

Am 2021-08-01 um 03:54 schrieb 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenjdk%2Fjdk%2Fblob%2F6765f902505fbdd02f25b599f942437cd805cad1%2Fsrc%2Fjava.base%2Fshare%2Fclasses%2Fsun%2Fsecurity%2Fpkcs12%2FPKCS12KeyStore.java%23L1646&data=04%7C01%7C9d76b566-97f1-4355-9dbf-6dcc0e8868d3%40ad011.siemens.com%7C1747436d78464899aa7d08d9548f4e5b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637633796747677305%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JZcwDAqmzCbNmMSAaZiagdUpMNCCZxH59bs4a4avERo%3D&reserved=0
> 
> 
> 
>> 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%7C1747436d78464899aa7d08d9548f4e5b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637633796747677305%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=90U%2BMTFtF5WrEIYQGSK0AR3cc92J%2Bd1QZtHAmfvyii8%3D&reserved=0
>>>>
>>>> Regards,
>>>>
>>>> Michael
>>>>
>>
>