Re: [ASN.1] DER decoding extensions in SEQUENCE

[Ramaswamy Ranganathan]

[EMAIL PROTECTED] wrote:

Thanks for reply,
 
>
> Hi,
>     If a SEQUENCE is extended then I understand that
> implication/impact of the OPTIONAL/DEFAULT keyword is for the
> encoder only. For that particular spec, the encoder will
> expect the mandatory elements following the extension
> (otherwise the specified value may be considered invalid -
> strictly).

I agree.

> It is possible that the sender complies to the
> same SEQUENCE but with no elements following the extension
> marker (the sender having a previous version of the
> specification). Hence as far as the decoder is concerned, it
> would have to consider all elements following the extension
> as OPTIONAL (of course not the individual elements of an
> extension group, when only the group itself would be
> optional).

Right. I don't know yet how to deal with this, but that's in the future:-)

> As for whether to decode the tag or not (for
> trailing elements after the last mandatory element- NOTE that
> elements following the extensions are considered non
> mandatory) will depend of the remaining length of the
> SEQUENCE value after decoding till the last mandatory
> element.

Yes, I didn't realize this.

> If in the spec an element of the extension addition
> is mandatory, then the decoder must assume the possibility of
> the absence of the same (remember that this mandatory nature
> applied to the encoder only). The remaining length (if kept
> tab on) will ward off the factor of no. of tags to be
> considered that was mentioned, or atleast limit it to the
> SEQUENCE at hand, which is leaves the problem bounded.

Yes, the problem is bounded in the SEQUENCE. But still... Look at the example:

If the decoder will have this structures:
S ::= SEQUENCE {
        a INTEGER,
        b BOOLEAN OPTIONAL, --version 1
        ...
        c C OPTIONAL
}

I suppose a double extention is intended here.

C ::= CHOICE {
        ca INTEGER,
        cb OCTET STRING,
}
 
Then, when it recieves new version:
S ::= SEQUENCE {
        a INTEGER,
        b BOOLEAN OPTIONAL,
        ...
        e ENUMERATED      -- version2
        ...
        c C OPTIONAL
}

As far as the decoding of the 1st sequence is concerned once it completes decoding a and b, anything whose tag does not correspond to elements of C are a part of the SEQUENCE's extension. Since in the new version, for any n.o. of additions the tag of element 'c' (considering is sub-elements too) cannot collide with that of  'e'. And yes, as you have mentioned below, the tags of elements of 'c' must be considered before considering the same for 'e'.

Then before skipping e, it must check the tag with tags of both - ca and cb.
And what if C could have extensions too?

C ::= CHOICE {
        ca INTEGER,
        cb OCTET STRING,
        ...
}

In my understanding it is incorrect, since after decoding a and b, if a tag that does not belong to 'c' appears in the stream, then we cannot decide if it belongs to the extension of the SEQUENCE or of the CHOICE. I am not sure of clause in the ASN.1 spec's that deals with this.

Is this incorrect for Asn1 or is there a way to handle such cases?
Thanks

Vit Novak