Incorrect encoding of PKCS12 bag attributes

[Osipov, Michael (LDA IT PLM)]

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
>>