Le 16/12/2011 19:07, Jakob Bohm a écrit :
On 12/16/2011 6:47 PM, Erwann Abalea wrote:
Le 16/12/2011 16:29, Jakob Bohm a écrit :
On 12/16/2011 3:22 PM, Erwann Abalea wrote:
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.
I understand, but does OpenSSL implement that?
In the API, yes. At least in 1.0.0 branch, which passes the NIST PKITS
suite.
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.
As you quote it (I don't have a copy), this sounds like using 0x23
and 0x24 should not be done when encoding, but should be accepted
when decoding.
Yes, and that also means those characters cannot be obtained with "7-bit
T.61", contrary to the table found in RFC1345.
In fact, there's no "7-bit T.61" set, so I don't really know how RFC1345
should be treated.
- 0x7F and 0xFF are not defined, and are not defined as "not used".
RFC1345 seems to indicate that 0x7F maps to U+007F DEL
This mapping (0x7F - DEL) is only presented in Annex E, discussing the
greek primary character set. But the Table 2, which exhaustively lists
the codes, avoids 0x7F (07/15, really).
Some PKI toolkits use T.61 to encode ISO8859-1 characters, and ISO8859-1
defines 0x7F as "DEL".
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.
Most of those would be inapplicable to the encoding of X.500 strings,
configurable
character sets sounds like an ISO-2022 like mechanism useful for
encoding an even
larger subset of UNICODE, as do graphical characters.
However none of those features were mentioned in the still available
secondary
references I looked at (RFC1345 and Wikipedia), so they are unlikely
to be
accepted nor emitted by any current implementations of T.61.
Sure. But those are valid T.61 sequences anyway.
As you said, RFC1345 lists historic character sets, and T.61 is one of
them (if predates Unicode).
T.61 was ambiguous, was defined for a now obsolete system (Teletex), was
more than a simple character set (you could redefine graphical
characters, and specify formatting), and is now withdrawn since nearly 2
decades. It's time to avoid it :)
--
Erwann ABALEA
-----
préhibernoluthidolichospasmes: sanglots longs des violons de l'automne,
phénomène météomusical aux propriétés homéoanémicardiomutilatoires, décrit pour
la première fois par Verlaine en 1866
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
