balises non déclaré dans l'entrée d'un décodeur de BER ASN.1

Question

J'ai une spécification pour une syntaxe ASN.1 que je souhaite modifier en ajoutant des champs. Si je crée une chaîne codée en utilisant BER avec les nouveaux champs et ensuite tenter de décoder cette chaîne en utilisant un décodeur qui ne connaît pas ces champs supplémentaires, ce qui devrait être le résultat? Est-ce que le décodage échoue car il y a des champs que le décodeur ne reconnaît pas? Est-ce que le décodeur décoder uniquement les champs qu'il reconnaît et peut complètement ignorer ceux qu'il ne fonctionne pas? Est-ce un problème complètement décodeur soit mise en œuvre afin résultat est possible, en fonction de la façon dont le décodeur est mis en œuvre?

En ce moment, j'utilise un compilateur / décodeur ASN.1 open source et il semble être tout à fait défaut, mais je ne suis pas sûr que ce soit en raison de la mise en œuvre ou parce que les règles ASN.1 dictent ce genre de résultat?

Answer 1

Il ne certainement dépend pas de la mise en œuvre. Ainsi, si différentes implémentations traitent différemment, l'un d'entre eux le fait de manière incorrecte. Si vous allez à décoder les champs inconnus en utilisant un décodeur qui ne vous attendez pas à des champs inconnus, le décodage doit échouer. Il ne sera pas sauter sur les champs inconnus.

Il y a, cependant, un moyen de fournir des champs supplémentaires avant même qu'ils sont connus. Il est d'employer le marqueur d'extension ( « ... »). Disons que nous développons différentes versions d'une spécification ASN.1. Appelons-les V1, V2, V3, etc. V1 est la spécification originale, mais nous comprenons au moment où nous concevons V1 qu'il est probable que nous allons devoir le modifier à un moment donné. Pour permettre cela, au lieu de quelque chose comme

Z ::= SEQUENCE { a INTEGER,
                 b OCTET STRING,
                 c Message1
}

nous déclarons Z à être extensible comme ceci

Z ::= SEQUENCE { a INTEGER,
                 b OCTET STRING,
                 c Message1,
                 ...
}

Le marqueur d'extension indique que, à la suite c, il pourrait y avoir plus de champs qui sont encore inconnus. Le décodeur doit traiter les messages contenant de tels champs, aussi longtemps qu'ils suivent c, comme valide. Le décodeur ne serait pas en mesure de les décoder, car il ne sait pas ce qu'ils devraient être, mais il sait qu'ils sont admissibles.

Disons que nous mettons à jour V1 à V2 en insérant deux nouveaux champs un peu comme cela

Z ::= SEQUENCE { a INTEGER,            -- V1
                 b OCTET STRING,       -- V1
                 c Message1,           -- V1
                 ...,
             [[  d PrintableString,    -- V2
                 e BOOLEAN          ]] -- V2
}

Dans ce cas, la version V1 peut interopérer avec la version V2. Le codeur V1 ne comprendrait pas d ou e, tandis que le codeur V2 serait de les inclure. Du point de vue du décodeur, le décodeur V1 acceptera (mais pas décoder) d et e, tandis que le décodeur V2 décoderait d et e si elles se trouvent. Ainsi, un décodeur V1 acceptera les deux encodages V1 et V2, sans tenir compte d et e chaque fois qu'ils se trouvent; un décodeur V2 serait également accepter à la fois encodages V1 et V2, notant qu'un encodage V1 ne comprendrait pas d ou e, mais il reste valable.

Nous pouvons continuer ce grâce à des versions supplémentaires, par exemple,

Z ::= SEQUENCE { a INTEGER,            -- V1
                 b OCTET STRING,       -- V1
                 c Message1,           -- V1
                 ...,
             [[  d PrintableString,    -- V2
                 e BOOLEAN         ]], -- V2
             [[  f PrintableString,    -- V3
                 g ExtensionMessage]]  -- V3
}

V1, V2, V3 et peuvent tous interopérer.

Il faut toutefois noter que, puisque nous avons affaire à une SEQUENCE, doit être préservé l'ordre. Vous ne pourriez pas avoir d e sans, ni g sans d, e et f.

La conclusion est donc que si votre définition de type comprend des marqueurs d'extension, vous pouvez ajouter de nouveaux champs, mais si elle ne le fait pas, vous ne pouvez pas.

Answer 2

Tout dépendra de la spécification et la mise en œuvre. En bref - il n'y a aucun moyen de dire. et il est à la mise en œuvre. Certaines spécifications pour tout protocole / format utilisant ASN.1 donné énoncera de manière explicite que les éléments inconnus doivent être ignorés, auquel cas le décodage ne doit pas échouer.

Plus commune cependant, les décodeurs rejetteront toute entrée qui ne se conforme pas strictement à la syntaxe ASN.1 il est censé être le décodage.