Re: asn1Decoding(1) fails to decode a CHOICE?

[Ivan Shmakov]

>>>>> Nikos Mavrogiannopoulos <address@hidden> writes:
>>>>> On 10/06/2012 03:58 PM, Ivan Shmakov wrote:

[…]

 >>>>             'Foo ::= CHOICE { bar [0] INTEGER, baz [1] INTEGER }' \

[…]

 >>> Is the structure you have correct?

 >> If it's the input data that's meant here, then I presume so.  I've
 >> generated it with Perl's Convert::ASN1 module, like:

[…]

 >> The integer is 42 decimal, or 2A hexadecimal, and it's stored as the
 >> third (and the last) octet of the sequence.

 > I don't see any integer there with "openssl asn1parse".

        AIUI, X.690 §8.1.2 specifies that there could only be one tag
        per value, and the CHOICE above uses “private” tags (PRIVATE 0,
        PRIVATE 1) to distinguish the members, instead of the
        “universal”, type-encoding tags (such as INTEGER = UNIVERSAL 2.)

        There isn't much choice here, actually, as the types of these
        CHOICE members just happen to coincide.

        OTOH, for Foo ::= CHOICE { bar INTEGER, baz OCTET STRING }:

$ printf '\x02\x01\x2a' \
      | openssl asn1parse -inform DER 
    0:d=0  hl=2 l=   1 prim: INTEGER           :2A
$ printf '\x02\x01\x2a' \
      | asn1Decoding \
            <(printf %s\\n \
                  'Example { } DEFINITIONS EXPLICIT TAGS ::=' \
                  BEGIN \
                  'Foo ::= CHOICE { bar INTEGER, baz OCTET STRING }' \
                  END) /dev/stdin Example.Foo 
Parse: done.

Decoding: SUCCESS

DECODING RESULT:
name:NULL  type:CHOICE
  name:bar  type:INTEGER  value:0x2a
$ 

        (Somehow, I've expected that asn1Decoding(1) would result in an
        output suitable for later asn1Coding(1), though.)

[…]

 > Could be but I've never needed that tool.  Maybe given its
 > limitations it is a good idea to even remove it.  When I need to
 > generate structures I use libtasn1 directly.

        Honestly, I'd hesitate to write C code when the task at hand
        could be accomplished with a higher-level language, such as
        Shell (or Perl), which seem to speak in favor of retaining such
        command-line tools.

        (I hope to check if these tools could be improved by some simple
        changes.)

-- 
FSF associate member #7257