the DN handling in openssl seems to be a little uneven.
getting special characters in seems to be no problem when using the
interactive interface (at least when 'special' restricts itself to the
ASCII characters with special syntactic function).
but as soon as it comes to looking at the result, the output shows
interesting variety and ambiguity:
...> openssl req [...] -noout -text | grep Subject
Subject: C=DE, L=Berlin, O=Acme, Inc., CN=#1 test: a+b=c/d
...> openssl req [...] -noout -subject
subject=/C=DE/L=Berlin/O=Acme, Inc./CN=#1 test: a+b=c/d
in neither form are the delimiters escaped when they occur in the
attribute values, like the comma in the O or the slash in the CN.
the index.txt file uses the latter form.
i don't know whether this non-escaping causes any problems.
does it?
what i find problematic is that the input suffers from similar problems:
...> openssl req -new -key [...] -subj 'C=DE, L=Berlin, O=Acme, Inc, CN=#2 test:
a+b=c\\/d'
Subject Attribute Inc has no known NID, skipped
Subject Attribute d has no known NID, skipped
special characters cannot be escaped.
apart from that, the encoding is ...strange.
...> openssl req [...] -utf8 -subj '[...], CN=bäh'
leads to a commonName object with the T61String b\344h which according
to RFC 1345 is bĦh.
the encoding is wrong, but it is documented in the BUGS section.
(\344 is ä in ISO 8859-1.)
trying to get a non-ISO-8859-1 character (the EUR sign for example) in fails:
...> openssl req [...] -utf8 -subj '[...], CN=€'
problems making Certificate Request
28715:error:0D07A07C:asn1 encoding routines:ASN1_mbstring_copy:illegal
characters:a_mbstr.c:162:
doing it via the interactive prompts leads to:
...> openssl req -new [...] -utf8
[...]
Organizational Unit Name (eg, section) []:€
problems making Certificate Request
29035:error:0E06D06C:configuration file routines:NCONF_get_string:no
value:conf_lib.c:329:group=req_distinguished_name name=organizationalUnitName_min
29035:error:0E06D06C:configuration file routines:NCONF_get_string:no
value:conf_lib.c:329:group=req_distinguished_name name=organizationalUnitName_max
29035:error:0D07A07C:asn1 encoding routines:ASN1_mbstring_copy:illegal
characters:a_mbstr.c:162:
the SPKAC format is problematic too, it doesn't work with non-ASCII DN's
either.
what are the openssl team's intentions for DN handling?
keep it X.500 style which doesn't seem to define any string
representation or go the RFC 2253 way?
is there anybody working on this or would you like somebody to send
patches?
since 0.9.7 is frozen, i guess this will make it into 0.9.8 the
earliest?
rj
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
