Re: x509 certificate decoded string representation is wrong

Now its my turn to apologize for the late response. :)

I ran the tests again on 17.0 and the same issues exist.


Here is my cert generator crashing on a unicode string:

15> api_app:generate_cert_with_key(1024).
** exception error: no match of right hand side value {error,{asn1,badarg}}
     in function  pubkey_cert_records:transform/2 (pubkey_cert_records.erl,
line 59)
     in call from lists:map/2 (lists.erl, line 1237)
     in call from pubkey_cert_records:transform/2 (pubkey_cert_records.erl,
line 91)
     in call from pubkey_cert_records:encode_tbs/1
(pubkey_cert_records.erl, line 306)
     in call from public_key:pkix_encode/3 (public_key.erl, line 268)
     in call from public_key:pkix_sign/2 (public_key.erl, line 472)
     in call from api_app:generate_cert_with_key/1 (src/api_app.erl, line
128)


The part of the cert with the unicode string was...

    Subject = {rdnSequence, [
        [#'AttributeTypeAndValue'{
            type  = ?'id-at-commonName',
            value = {utf8String, [16#4e09|" string starting with a chinese
symbol"]}
            %% value = {utf8String, "embedded self-signed cert"}
        }]
    ]},

It works fine when I swap in the non-unicode string.





Here is a certificate and it's decode showing how the text is presented as
binaries instead of strings (lists).



goertzen@ubuntu64 ~/test
$ cat test.cert
-----BEGIN CERTIFICATE-----
MIIDXTCCAkWgAwIBAgIJALPOPyhAojyyMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV
BAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5ldCBX
aWRnaXRzIFB0eSBMdGQwHhcNMTQwNjA0MTQyNjEyWhcNMTcwNjAzMTQyNjEyWjBF
MQswCQYDVQQGEwJBVTETMBEGA1UECAwKU29tZS1TdGF0ZTEhMB8GA1UECgwYSW50
ZXJuZXQgV2lkZ2l0cyBQdHkgTHRkMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB
CgKCAQEA5M68fzYaR1Ef7DT1ooDw/QhwK2euedf7Lj1BugVawuhSGpHgsrVUorzP
UN4GXXWoavD0I9KMyIhY8Wzh5iI9xwjZ3RtQGLcSdWAiQME/7dPfs94MzcSKATgS
ZePunlOWFKxP9ie12GKKyvo4PtwRRZ/m50967DbYH8d+Tg+ASTWYA8EHrpBrlvox
dA9e5xkiLwt15+SnDhiR06czy7XQ/+4oJeoIwB66iah/LVe3PXnJU/+qYSqCSgYv
q41L+0FSYpTBqRbJ72WxT7l2lj0IsKHkT6ywuvwt6MCw5g96Wgvsyn71b9EUKA6K
lTllaA96iqVHVouvX58t4D4Zt8Ic+QIDAQABo1AwTjAdBgNVHQ4EFgQUeO5XkCL9
omKoM6uKWezYWCKcwoIwHwYDVR0jBBgwFoAUeO5XkCL9omKoM6uKWezYWCKcwoIw
DAYDVR0TBAUwAwEB/zANBgkqhkiG9w0BAQsFAAOCAQEAkFPuHkWUr3ZE0goNzs6R
uRnNZESffEFXtk8FMQXUV+9i8dJbE0ElK7MwVLbc4VS/nXoBVQbicSTOPq2LZe0g
b72YcrtQlMoWdwNCibjnuxdI0o76nfWShxvy6K1sJ0qQ/T3fsfvGgKn8qGDCAGmY
2PJaaXvpqSy3wIPIFxnhCGiuCrcVudZkJwVWnG27jYd5IE4i9st5oJnatMS0rCeG
InjWWg6aAo5hsdfgug0mMyX+87EixoGfUNm59TWWViWcFuLUksAKECmzseJZLBnT
1+bHXIGyV/NxZW90R8NC5ObBkP924kCdAGKPWVW6XruMCFlrmeU+P9RKhiwf/FX4
zg==
-----END CERTIFICATE-----
goertzen@ubuntu64 ~/test
$ erl
Erlang/OTP 17 [erts-6.0.1] [source-deacab9] [64-bit] [smp:3:3]
[async-threads:10] [hipe] [kernel-poll:false]

Eshell V6.0.1  (abort with ^G)
1> {ok, PemBin} = file:read_file("test.cert").
{ok,<<"-----BEGIN
CERTIFICATE-----\nMIIDXTCCAkWgAwIBAgIJALPOPyhAojyyMA0GCSqGSIb3DQEBCwUAMEUxCzAJBgNV\nBAYTAkFVMRMwEQY"...>>}
2> [{'Certificate',Cert,not_encrypted}] =  public_key:pem_decode(PemBin).
[{'Certificate',<<48,130,3,93,48,130,2,69,160,3,2,1,2,2,9,
                  0,179,206,63,40,64,162,60,178,48,13,...>>,
                not_encrypted}]
3> OTPCert = public_key:pkix_decode_cert(Cert, otp).
{'OTPCertificate',{'OTPTBSCertificate',v3,
                                       12956362620107111602,

{'SignatureAlgorithm',{1,2,840,113549,1,1,11},'NULL'},

{rdnSequence,[[{'AttributeTypeAndValue',{2,5,4,6},"AU"}],

[{'AttributeTypeAndValue',{2,5,4,8},

*{utf8String,<<"Some-State">>*}}],

[{'AttributeTypeAndValue',{2,5,4,10},

*{utf8String,<<"Internet Widgits Pty Ltd">>}*}]]},

{'Validity',{utcTime,"140604142612Z"},

{utcTime,"170603142612Z"}},

{rdnSequence,[[{'AttributeTypeAndValue',{2,5,4,6},"AU"}],

[{'AttributeTypeAndValue',{2,5,4,8},

{utf8String,<<"Some-State">>}}],

[{'AttributeTypeAndValue',{2,5,4,10},

{utf8String,<<"Internet Widgits Pty Ltd">>}}]]},

{'OTPSubjectPublicKeyInfo',{'PublicKeyAlgorithm',{1,2,840,

113549,1,1,1},

'NULL'},

{'RSAPublicKey',28884279009285790301669924467575946032489944489699263464818187209641451094053086029317223819905552232804663206681799701028265354352239301173419976030286993076554223850305834956052085323986279172838215343728630359816997644527827805951010425788227425209795979178217250409900809512057807966976585078052255837974497261381284713573904257439066194709912683930375930487604830660421775765930552658716300974673840116044766673767999239289293469792318108847067157652307614870531765029586512631237561271128048065184664689086457528061690000433623928374995254617336829376087731238998361247235770397685269871591203885794507056356601,

65537}},
                                       asn1_NOVALUE,asn1_NOVALUE,
                                       [{'Extension',{2,5,29,14},
                                                     false,

[120,238,87,144,34,253,162,98,168,51,171|...]},
                                        {'Extension',{2,5,29,35},
                                                     false,

{'AuthorityKeyIdentifier',[120,238,87,144,34,253,162,98|...],

asn1_NOVALUE,asn1_NOVALUE}},
                                        {'Extension',{2,5,29,19},
                                                     false,

{'BasicConstraints',true,asn1_NOVALUE}}]},
                  {'SignatureAlgorithm',{1,2,840,113549,1,1,11},'NULL'},
                  {0,
                   <<144,83,238,30,69,148,175,118,68,210,10,13,206,206,145,
                     185,25,205,100,68,159,124,65,...>>}}
4>


Dan.


On Thu, Jul 31, 2014 at 9:50 AM, Ingela Anderton Andin <
[email protected]> wrote:

> 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
>> [email protected]
>> http://erlang.org/mailman/listinfo/erlang-bugs
>>
>>
> _______________________________________________
> erlang-bugs mailing list
> [email protected]
> http://erlang.org/mailman/listinfo/erlang-bugs
>

_______________________________________________
erlang-bugs mailing list
[email protected]
http://erlang.org/mailman/listinfo/erlang-bugs