On 12/16/2011 3:22 PM, Erwann Abalea wrote:
Le 16/12/2011 15:07, Jakob Bohm a écrit :
I think we may have a bug here, anyone from the core team
wish to comment on this.
The apparent bug:
When enforcing the "match" policy for a DN part, openssl reports an
error if the CSR has used a different string type for the field, but the
correct value (The naively expected behavior is to realize the strings
are identical and use the configured encoding for the resulting cert).
Do you expect the "openssl ca" tool to apply the complete X.520
comparison rules before checking the policy?
Not unless there are OpenSSL functions to do the work.
Otherwise I just expect it to apply the character set conversions it
uses for its
other operations (such as reading the config file/displaying DNs).
3. Validating a certificate whose issuing CA certificate specifies path
constraints where the issued certificate satisfies the path constraint
except for the exact choice of string type.
NameConstraints is a set of constraints imposed on the semantic value
of the name elements, not on their encoding (string type,
double-spacing, case differences, etc).
The question was how the OpenSSL code (library and command line) handle
the scenario, your answer seems to indicate that it is indeed supposed to
compare the semantic character sequence, not the encoding.
Technical note: All the defined string types have a well defined
mapping to and from 32 bit Unicode code points, with the following
one-way limitations:
BMPStrings can only represent U+0000 to U+10FFFF
(using UTF-16)
UTF8Strings can only represent U+0000 to U+7FFFFFFF
(allowing the possibility that some codepoints above U+10FFFF
may be assigned in the future, contrary to current policy).
(OpenSSL may or may not accept the CESU-8 and Java
Modified UTF-8 encoding variants and may or may not normalize
those to real UTF-8 before further processing).
PrintableString can only represent a specific small set of Unicode
code points
T61String can only represent a different specific small set.
T.61 has no "well defined" bidirectional mapping with UTF8.
That said, T.61 was withdrawn before 1993 (IIRC) and shouldn't be used.
According to RFC1345, T.61 has a well defined mapping to named
characters also found in UNICODE. Some of those are encoded
as two bytes in T.61 (using a modifier+base char scheme), the
rest as one byte. That is what I mean by a bidirectional mapping
to a small (sub)set of UNICODE, meaning that most UNICODE
code points cannot be mapped to T.61, but the rest have a
bidirectional mapping.
According to the same source, 7-bit T.61 appears to be a proper
subset of 8-bit T.61.
Constructing a mapping table from the data in RFC1345 or other
sources is left as an exercise for the reader (cheat hint: Maybe
IBM included such a table in ICU or unicode.org included one in
its data files).
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
