Re: 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.osi...@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&amp;data=04%7C01%7C9d76b566-97f1-4355-9dbf-6dcc0e8868d3%40ad011.siemens.com%7C1747436d78464899aa7d08d9548f4e5b%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637633796747677305%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=90U%2BMTFtF5WrEIYQGSK0AR3cc92J%2Bd1QZtHAmfvyii8%3D&amp;reserved=0

Regards,

Michael