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?
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).
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.
--
Erwann ABALEA
-----
yétiscopique: relatif à certaines vapeurs des sommets himalayens
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
