<div dir="ltr"><div>In the ASN.1 specs relevant to this standard there is an information object set which defines the supported Attribute and Type combinations.</div><div>For a given Object Identifier there is a certain type of value associated. The value is encoded as an Open Type</div>
<div>which is an anonymous sequence of bytes. Given tha mapping these bytes can be decoded in a second step.</div><div> </div><div>In this case the oid to type of value mapping is unknown so we can only return a number of bytes i.e a binary.</div>
<div>It happens to be some encoded ASN.1 data in thoose bytes but we cannot know that.</div><div> </div><div>For the other values in the rdnSequence there is a mapping between OID and type of value and it is</div><div>typically the type X520name or some other type prefixed X520. The typical for these types is that they are</div>
<div>CHOICE types like this:</div><div> </div><div>X520name ::= CHOICE {</div><div>    teletexString TeletexString (SIZE (1..ub-name)),</div><div>    printableString PrintableString (SIZE (1..ub-name)),</div><div>...</div>
<div>}</div><div> </div><div>This is why the tuple {printableString,"SomeString"} is returned, the mapping of a CHOICE to Erlang terms is</div><div>a tuple with the choice alternative name , the value.</div><div>
 </div><div>Without tha mapping between OID and type of value we have no chance of knowing that the Open Type should be interpreted as for example a X520Name, we could only guess and probably do this correct most of the times but not for sure.</div>
<div> </div><div>If we just decode the Open Type we see the tag for PrintableString but we don't know that it is a CHOICE.</div><div> </div><div>/Kenneth, Erlang/OTP, Ericsson</div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On Tue, Apr 9, 2013 at 5:44 PM, Simon MacMullen <span dir="ltr"><<a href="mailto:simon@rabbitmq.com" target="_blank">simon@rabbitmq.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
With the attached certificate (provided by a user, apparently generated by "Red Hat Certificate System 7.3") and R16B:<br>
<br>
1> rr(public_key).<br>
[...]<br>
<br>
2> {ok, File} = file:read_file("/path/to/cert.<u></u>pem").<br>
{ok,<<"-----BEGIN CERTIFICATE-----"...>>}<br>
<br>
3> [{'Certificate', Cert, _}] = public_key:pem_decode(File).<br>
[{'Certificate',<<48,130,3,<u></u>178,...>>, not_encrypted}]<br>
<br>
4> #'OTPCertificate'{<u></u>tbsCertificate = #'OTPTBSCertificate'{subject = Subject}} = public_key:pkix_decode_cert(<u></u>Cert, otp).<br>
#'OTPCertificate'{...}<br>
<br>
5> Subject.<br>
{rdnSequence,<br>
    [[#'AttributeTypeAndValue'{<u></u>type = {2,5,4,6},value = "ES"}],<br>
     [#'AttributeTypeAndValue'{<br>
          type = {2,5,4,10},<br>
          value = {printableString,"OMEL"}}],<br>
     [#'AttributeTypeAndValue'{<br>
          type = {2,5,4,11},<br>
          value = {printableString,"OM"}}],<br>
     [#'AttributeTypeAndValue'{<br>
          type = {2,5,4,3},<br>
          value = {printableString,"DSI PRUEBAS"}}],<br>
     [#'AttributeTypeAndValue'{<br>
          type = {0,9,2342,19200300,100,1,1},<br>
          value = <<19,9,68,83,73,83,79,70,84,<u></u>57,57>>}]]}<br>
<br>
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.<br>
<br>
So why does this value not get decoded?<br>
<br>
Cheers, Simon<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Simon MacMullen<br>
RabbitMQ, VMware<br>
</font></span><br>_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://erlang.org/mailman/listinfo/erlang-questions</a><br>
<br></blockquote></div><br></div>