[erlang-bugs] x509 certificate decoded string representation is wrong

[Ingela Anderton Andin]

Hi!

Sorry for the late answer. Was this pre 17.0 or 17.0 ?  There was a 
unicode fix in 17.0 the accidentally seems to have been lost in the 
release notes. If you still have problems could you please send us a 
sample cert that fails to speed up the process.

Regards Ingela Erlang/OTP team - Ericsson AB




On 06/12/2014 10:57 PM, Daniel Goertzen wrote:
> In the public_key application, decoding of attributes in x509
> certificates does not always decode to a string as indicated in the
> documentation.  The documentation says that the value of commonName (and
> several other attributes) should be:
>
> special_string() = {teletexString, string()} | {printableString,
> string()} | {universalString, string()} | {utf8String, string()} |
> {bmpString, string()}
>
> ... however when I decode a cert I see a utf8String coming out as a
> binary instead of a string()....
>
> [{'AttributeTypeAndValue',
>    {2,5,4,3},
>      {utf8String,<<"Daniel Goertzen">>}}],
>
> ... and typer shows several other non-string representations (unicode
> characters represented by 4-tuples):
>
> -spec dec_X520CommonName(_) ->
> {'bmpString',[byte() | {byte(),byte(),byte(),byte()}] | {byte(),binary()}} |
> {'printableString',[byte() | {byte(),byte(),byte(),byte()}] |
> {byte(),binary()}} |
> {'teletexString',[byte() | {byte(),byte(),byte(),byte()}] |
> {byte(),binary()}} |
> {'universalString',[byte() | {byte(),byte(),byte(),byte()}] |
> {byte(),binary()}} |
> {'utf8String',_}.
>
>
>
> Also, encoding does not accept unicode strings (list of chars).  The
> example below crashes.
>
>      Subject = {rdnSequence, [
>          [#'AttributeTypeAndValue'{
>              type  = ?'id-at-commonName',
>              value = {utf8String, [16#4e09|" string starting with a
> chinese symbol"]}
>          }]
>      ]},
>
>
>
> I assume that the documentation is right and the decoded representation
> should be "list of characters".  Instead internal representations are
> coming through.
>
>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>