Hi Alex, Hi all, 1. Could you please clarify what do you mean by FR#1702736 ?
It seems that when Name and OID are passed as utf8 it is the most general option, as ascii or hex representations do not change if treated as utf8? Also, what Windows stuff do you mean? 2. Do you think that it could be a benefit for something, if we change serialize/deserialize concept in a following way? Serialized data should contain (withing itself) a set of utf8/non-utf8 flags, one flag for each scalar constituent of the data. E.g.: HASH 347 32 u8 cert_subject_alt_name_choice_key SCALAR 5 n8 email 15 u8 cert_subject_OU SCALAR 0 where "u8" means that before serialization corresponding field (which goes after the flag) had utf8 flag set in perl, and "n8" means that before serialization corresponding field (which goes after the flag) had NOT utf8 flag set in perl. Sure deserialization should make use of u8/n8 flags when restoring data. All the best, Sergei ==================================================== FR#1702736: OID subject alternative names with non-UTF8 content. Currently, if the web interface is used to input a custom subject alternative name together with an OID, it is assumed that the content is in UTF8 and this is passed on to OpenSSL accordingly. It would be nice to support more than that (hex, for example) as it is apparently needed by some weird Windows stuff. ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ OpenXPKI-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openxpki-devel
