> From: owner-openssl-us...@openssl.org On Behalf Of Pica Pica Contact > Sent: Monday, 30 July, 2012 13:47
> Look at this example: <snip> > This certificate was signed by "openssl ca" without changing subject, > and "openssl req" did not use BMPString and UCS-2 in this > case. CN string contains Georgian letters but numbers are in > ASCII so it is UTF-8 in fact. > You're probably right. (To be positive, I'd check the req directly, not the x509 into which it is copied, because the copy *could* change the encoding as long as it doesn't change the canonical value. But I'd be surprised if it did. OTOH I've been surprised before.) On rechecking I am reminded there *is* an ASN.1 type UTF8String, which I had forgotten when I answered before. Sorry for the misstatement. > So why "openssl ca" decides to use BMPString format? Looks > like 1-byte code strings can be used without violating ASN.1 standard > So that is a valid question. (Well, pedantically UTF8 is a variable-byte code, not a 1-byte code, but it's clear what you mean.) I've definitely looked at some code, but I don't remember exactly where (or when), that chooses based on the chars needed, something like: if all are printable use PrintableString, else if all are 1-byte use GeneralString, else if all are 2-byte/BMP use BMPString, else use UniversalString. I'm guessing logic like that was used, and it wouldn't choose UTF8 even though UTF8 can represent all Unicode. You'll probably have to read the source or debug, unless someone else chips in. If you don't need all the features of 'ca', like database and CRLs, you could try 'x509 -req -CA*' and see if it's different on this point. That is a separate implementation of nearly-identical function. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
