[erlang-bugs] x509 certificate decoded string representation is wrong
Daniel Goertzen
daniel.goertzen@REDACTED
Wed Sep 3 23:00:18 CEST 2014
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@REDACTED ~/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@REDACTED ~/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 <
Ingela.Anderton.Andin@REDACTED> 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
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
>>
>>
> _______________________________________________
> erlang-bugs mailing list
> erlang-bugs@REDACTED
> http://erlang.org/mailman/listinfo/erlang-bugs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20140903/dac7f5d4/attachment.htm>
More information about the erlang-bugs
mailing list