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

[Ivan Shmakov]

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

 >>>> 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.

 > It looks like a corner case indeed.  I do not know what should be the
 > encoding in that case.

        I believe that the tags explicitly specified by an ASN.1
        “schema” have to take precedence.  (And Perl's Convert::ASN1
        seems to implement it just like that.)

 > Do you have any use-case that is affected by this behavior or it is a
 > test example?

        The practice of explicit tag assignment is, AIUI, discouraged by
        X.680, but my guess is that AUTOMATIC TAGS will lead to
        essentially the same behavior.

        One of the ASN.1 definitions I'm interested in is included
        below.  (I haven't tried it against Libtasn1 yet, but it's
        similar enough to the example being discussed.)

--cut: urn:uuid:29fb0a29-dbe3-4133-a2c6-f30e02ed71b0 --
SolidStat1 ::= SEQUENCE {
    -- FIXME: too many integers here
    inode                  [0]  INTEGER,
    links                  [1]  INTEGER         OPTIONAL,
    type                   [2]  INTEGER         OPTIONAL,
    ctime                  [3]  Time,
    mtime                  [4]  Time,
    uid                    [5]  INTEGER         OPTIONAL,
    gid                    [6]  INTEGER         OPTIONAL,
    mode                   [7]  INTEGER         OPTIONAL,
    size                   [8]  INTEGER,
    readlinkId             [9]  ObjectId        OPTIONAL
}
--cut: urn:uuid:29fb0a29-dbe3-4133-a2c6-f30e02ed71b0 --

        This definition is part of the FCCS schema (which is an
        alternative to mtree(1) I happen to develop), and isn't used
        that widely (I may be the only user for now), so it may be
        possible to change it for better compatibility with ASN.1
        implementations.  Unfortunately, I have no idea on how exactly
        to change it for such.

 >>> 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.)

 > Indeed.  Would you be interested into augmenting this application?

        I'll take a look at the code, at the least.

[…]

-- 
FSF associate member #7257