[erlang-questions] Unrecognised OID -> fail to decode printableString

Simon MacMullen simon@REDACTED
Wed Apr 10 18:40:52 CEST 2013


Hi, thanks.

It doesn't know about this OID, certainly (maybe it should, I don't 
think it's that uncommon?) But I thought ASN.1 was self-describing 
enough that it could continue to recurse and unpack even in the face of 
unrecognised OIDs?

Cheers, Simon

On 10/04/13 10:32, Ingela Andin wrote:
> Hi!
>
> The "otp" strategy decodes as much as possible of the certificate that
> it recognizes
> it recurses and decodes "manually" more than the standard ASN-1
> decoding "pkix" mode does. But proably it does not know about this
> oid. Maybe the ASN-1 compiler could
> behave differently but someone else needs to answer that.
>
> Regards Ingela Erlang/OTP team - Ericsson AB
>
>
> 2013/4/9, Simon MacMullen <simon@REDACTED>:
>> With the attached certificate (provided by a user, apparently generated
>> by "Red Hat Certificate System 7.3") and R16B:
>>
>> 1> rr(public_key).
>> [...]
>>
>> 2> {ok, File} = file:read_file("/path/to/cert.pem").
>> {ok,<<"-----BEGIN CERTIFICATE-----"...>>}
>>
>> 3> [{'Certificate', Cert, _}] = public_key:pem_decode(File).
>> [{'Certificate',<<48,130,3,178,...>>, not_encrypted}]
>>
>> 4> #'OTPCertificate'{tbsCertificate = #'OTPTBSCertificate'{subject =
>> Subject}} = public_key:pkix_decode_cert(Cert, otp).
>> #'OTPCertificate'{...}
>>
>> 5> Subject.
>> {rdnSequence,
>>       [[#'AttributeTypeAndValue'{type = {2,5,4,6},value = "ES"}],
>>        [#'AttributeTypeAndValue'{
>>             type = {2,5,4,10},
>>             value = {printableString,"OMEL"}}],
>>        [#'AttributeTypeAndValue'{
>>             type = {2,5,4,11},
>>             value = {printableString,"OM"}}],
>>        [#'AttributeTypeAndValue'{
>>             type = {2,5,4,3},
>>             value = {printableString,"DSI PRUEBAS"}}],
>>        [#'AttributeTypeAndValue'{
>>             type = {0,9,2342,19200300,100,1,1},
>>             value = <<19,9,68,83,73,83,79,70,84,57,57>>}]]}
>>
>> Umm, why has the last value not been decoded? According to my very very
>> slack knowledge of BER, 19 = printableString, 9 is the length, and the
>> rest is the string. And decoding it by hand gives the expected result.
>>
>> So why does this value not get decoded?
>>
>> Cheers, Simon
>>
>> --
>> Simon MacMullen
>> RabbitMQ, VMware
>>


-- 
Simon MacMullen
RabbitMQ, VMware



More information about the erlang-questions mailing list