Incorrect encoding of PKCS12 bag attributes

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

--Sean

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://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.base/share/classes/java/security/PKCS12Attribute.java#L230-L245
> 
> Regards,
> 
> Michael
>