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

Kenneth Lundin kenneth.lundin@REDACTED
Tue Apr 16 10:05:28 CEST 2013


In the ASN.1 specs relevant to this standard there is an information object
set which defines the supported Attribute and Type combinations.
For a given Object Identifier there is a certain type of value associated.
The value is encoded as an Open Type
which is an anonymous sequence of bytes. Given tha mapping these bytes can
be decoded in a second step.

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.
It happens to be some encoded ASN.1 data in thoose bytes but we cannot know
that.

For the other values in the rdnSequence there is a mapping between OID and
type of value and it is
typically the type X520name or some other type prefixed X520. The typical
for these types is that they are
CHOICE types like this:

X520name ::= CHOICE {
    teletexString TeletexString (SIZE (1..ub-name)),
    printableString PrintableString (SIZE (1..ub-name)),
...
}

This is why the tuple {printableString,"SomeString"} is returned, the
mapping of a CHOICE to Erlang terms is
a tuple with the choice alternative name , the value.

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.

If we just decode the Open Type we see the tag for PrintableString but we
don't know that it is a CHOICE.

/Kenneth, Erlang/OTP, Ericsson


On Tue, Apr 9, 2013 at 5:44 PM, Simon MacMullen <simon@REDACTED> wrote:

> 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
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130416/11a63bf9/attachment.htm>


More information about the erlang-questions mailing list