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). 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). 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. 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.
I am not very sure as to how the second extension will affect. But certainly
it cannot be anything more that premature anticipation of the tags of the
elements of the extension.
Regd.
Ramaswamy
[EMAIL PROTECTED] wrote:
DER decoding extensions in SEQUENCE
Hi,
I have written a simple Asn1 library that is used for
managing Asn1 structures and coding/decoding them. Lot of things should be
done still and one of them is handling extensions. This seems to me as a
great obstacle, so I decided to ask here.
Please let me outline the problem I see in (DER) decoding
of SEQUENCE:
My application knows the structure of SEQUENCE including
optional elemets and the "position" of possible extensions. See the example:
CommonCertificateAttributes ::= SEQUENCE {
iD Identifier,
authority BOOLEAN DEFAULT FALSE,
identifier CredentialIdentifier {{KeyIdentifiers}}
OPTIONAL,
certHash [0] OOBCertHash OPTIONAL,
...,
trustedUsage [1] Usage OPTIONAL,
identifiers [2] SEQUENCE OF CredentialIdentifier{{KeyIdentifiers}}
OPTIONAL,
implicitTrust [3] BOOLEAN DEFAULT FALSE
}
The aplication decodes the elements sequntialy. First
step of decoding is to check the Tag. If a mandatory element is awaited,
then the Tag must correspond, otherwise an error is reported.
If an optional element is awaited, then the Tag doesn't
have to correspond (since the element doesn't have to be present). If it
so, the application just shifts to the next possible element. If the tag
corresponds, the optional element is decoded.
Now the application knows that extensions can be present
in the following code. But it doesn't know the possible tag (or tags). If
the first element after the extensions is to be mandatory, then the application
could look for it's tag and could skip (or save) all preceeding elements
as extensions.
But as in the example, there can be optional elements
following the extension and thus the application would have to consider all
possible (all optional and first mandatory) following tags.
And if there is not a mandatory element anywhere in the
SEQUENCE after the extension (as in the example), the application would even
have to consider all possible tags following the sequence.
Finaly, if another extension would be present in these
following possible elements, than it is not feasible to collect all the possible
folowing tags.
I hope you understand my chaotic explanation :-)
My questions is, if I am right about considering all
the following tags and if yes, how to resolve the unambiguity with more extensions
with optional elements between them.
Regards
Vit Novak
--
Hi ,
Regds
Ram
"Any intelligent fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction." - Albert Einstein
Information contained and transmitted by this E-MAIL is proprietary to
Synergy Infotech Private Limited and is intended for use only by the
individual or entity to which it is addressed, and may contain information
that is privileged, confidential or exempt from disclosure under applicable
law. If this is a forwarded message, the content of this E-MAIL may not have
been sent with the authority of the Company. If you are not the intended
recipient, an agent of the intended recipient or a person responsible for
delivering the information to
