Le 16/12/2011 16:29, Jakob Bohm a écrit :
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).
Fair.
I personally use the openssl command line tools to have a quick CA, not
a full-featured one. The API is complete and allows to code this.
But you're right, it would be fair to have consistent behaviour.
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.
That's what X.509 and X.520 impose. An algorithm is described in X.520
for name comparisons.
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.
I'm not finished with the reading of T.61 (1988 edition), but here's
what I found:
- 0xA6 is the '#' character, 0xA8 is the '¤' character (generic
currency), but those characters can also be obtained with 0x23 and 0x24,
respectively (Figure 2, note 4). Later in the same document, 0x23 and
0x24 are declared as "not used". This is both ambiguous and not
bidirectional.
- 0x7F and 0xFF are not defined, and are not defined as "not used".
- 0xC9 was the umlaut diacritical mark in the 1980 edition, which is
still tolerated in the 1988 edition, but the tables don't clearly define
0xC9 (and again, don't define it as "not used"). 0xC8 is declared as
"diaresis or umlaut mark". As I don't have the 1980 edition, I don't
know if it was already the case.
- nothing is said if a diacritical mark is encoded without a base
character.
These are ambiguities.
Annexes define control sequences (longer that 2 bytes), graphical
characters, configurable character sets, presentation functions
(selection of page format, character sizes and attributes
(bold/italic/underline), line settings (vertical and horizontal
spacing)). I doubt everything can be mapped to UTF8.
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).
I think only a subset of T.61 is taken into consideration. But I haven't
looked at the hinted files.
--
Erwann ABALEA
-----
D'abord, on est sur le web, pas sur ce usenet dont on nous rabbache les
oreilles et qui n'est qu'une abstraction.
-+- JP in http://neuneu.ctw.cc - Neuneu en abstract mode -+-
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
