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 the named recipient, you are notified that any use, distribution, transmission, printing, copying or dissemination of this information in any way or in any manner is strictly prohibited. We have taken precautions to minimize the risk of transmitting software viruses, but we advise you to carry out your own virus checks on any attachment to this message. We cannot accept liability for any loss or damage caused by software viruses. If you have received this communication in error, please delete this mail & notify us immediately at mailto:[EMAIL PROTECTED]
