ASN.1

Les recommandations ASN.1 proposent plusieurs règles d'encodage prédéfinies. Si aucune de ces règles ne convient, la notation de contrôle d'encodage (ECN, X.692) permet à l'utilisateur de définir ses propres règles d'encodage personnalisées.

L'encodage Privacy-Enhanced Mail (PEM) est totalement indépendant de l'ASN.1 et de ses codecs, mais les données ASN.1 encodées, souvent binaires, sont souvent encodées en PEM afin de pouvoir être transmises sous forme de données textuelles, par exemple via des relais SMTP ou des tampons de copier/coller.

Voici un exemple de module ASN.1 définissant les messages (structures de données) d'un protocole Foo fictif :

Il pourrait s'agir d'une spécification publiée par les créateurs du protocole Foo. Les flux de conversation, les échanges de transactions et les états ne sont pas définis dans ASN.1, mais sont décrits dans d'autres notations et dans la description textuelle du protocole.

ASN.1 prend en charge les contraintes sur les valeurs et les tailles, ainsi que l'extensibilité. La spécification ci-dessus peut être modifiée comme suit :

Cette modification contraint trackingNumbers à prendre une valeur comprise entre 0 et 199 inclus, et questionNumbers à prendre une valeur comprise entre 10 et 20 inclus. La taille du tableau questions peut être comprise entre 0 et 10 éléments, et celle du tableau answers entre 1 et 10 éléments. Le champ anArray est un tableau d'entiers de longueur fixe (100 éléments) compris entre 0 et 1000. Le marqueur d'extensibilité « … » indique que la spécification du message FooHistory pourra comporter des champs supplémentaires dans les versions ultérieures. Les systèmes compatibles avec une version donnée doivent pouvoir recevoir et transmettre des transactions d'une version ultérieure, mais ne pourront traiter que les champs spécifiés dans la version précédente. Les bons compilateurs ASN.1 génèrent (en C, C++, Java, etc.) un code source qui vérifie automatiquement que les transactions respectent ces contraintes. Les transactions qui ne respectent pas ces contraintes ne doivent pas être acceptées ni présentées à l'application. La gestion des contraintes à ce niveau simplifie considérablement la spécification du protocole car les applications seront protégées contre les violations de contraintes, réduisant ainsi les risques et les coûts.

Les exemples ci-dessus n'utilisent que la syntaxe de X.680. Les contraintes plus avancées de X.682 ne sont pas utilisées.

En supposant qu'un message soit conforme au protocole Foo et qu'il soit envoyé au destinataire, ce message particulier ( unité de données de protocole (PDU)) est :

Pour transmettre le message myQuestion sur le réseau, celui-ci est sérialisé (encodé) sous forme d'une série d' octets selon l'une des règles d'encodage . La spécification du protocole Foo devrait indiquer explicitement l'ensemble de règles d'encodage à utiliser, afin que les utilisateurs du protocole sachent lequel employer et à quoi s'attendre.

Ce qui précède est un exemple de X.681, plus précisément de la construction ObjectAssignment .

Ci-dessous figure la structure de données présentée ci-dessus sous la forme myQuestion encodée au format DER (tous les nombres sont en hexadécimal) :

30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

DER est un encodage type-longueur-valeur , la séquence ci-dessus peut donc être interprétée, par rapport aux types standard SEQUENCE, INTEGER et IA5String, comme suit :

30 — type d'étiquette indiquant la SÉQUENCE 13 — longueur en octets de la valeur qui suit 02 — balise de type indiquant INTEGER 01 — longueur en octets de la valeur qui suit 05 — valeur (5) 16 — balise de type indiquant IA5String (IA5 désigne l'ensemble complet ISO 646 7 bits, y compris les variantes, mais il s'agit généralement de l'ASCII américain) 0e — longueur en octets de la valeur qui suit 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f — valeur (« Y a-t-il quelqu’un ? »)

Il est également possible d'encoder la même structure de données ASN.1 avec les règles d'encodage XML (XER) afin d'améliorer la lisibilité lors de la transmission. Elle se présenterait alors sous la forme de 108 octets (espacement compris, y compris les espaces d'indentation) :

En revanche, si les règles d'encodage compactées non alignées sont utilisées, les 122 bits suivants (16 octets équivalent à 128 bits, mais ici seuls 122 bits contiennent des informations et les 6 derniers bits ne sont que du remplissage) seront produits :

01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0

Dans ce format, les balises de type des éléments obligatoires ne sont pas encodées ; il est donc impossible de l’analyser sans connaître les schémas d’encodage attendus. De plus, les octets de la valeur IA5String sont compressés sur 7 bits au lieu de 8, car l’encodeur sait que l’encodage d’une valeur d’octet IA5String ne nécessite que 7 bits. Cependant, les octets de longueur sont toujours encodés, même pour la première balise entière 01 (mais un outil de compression PER pourrait les omettre s’il sait que la plage de valeurs autorisées tient sur 8 bits, et il pourrait même compresser l’octet de valeur unique 05 sur moins de 8 bits s’il sait que les valeurs autorisées ne peuvent tenir que dans une plage plus restreinte).

Les 6 derniers bits du PER encodé sont complétés par des bits nuls dans les 6 bits de poids faible du dernier octet c0 : ces bits supplémentaires ne peuvent pas être transmis ou utilisés pour encoder autre chose si cette séquence est insérée dans le cadre d'une séquence PER non alignée plus longue.

Cela signifie que les données PER non alignées constituent essentiellement un flux ordonné de bits, et non un flux ordonné d'octets comme pour les données PER alignées. Leur décodage logiciel sera donc plus complexe sur les processeurs classiques, car il nécessitera des décalages et des masquages ​​de bits contextuels supplémentaires, et non un adressage direct par octet (cette remarque reste toutefois valable pour les processeurs et les unités de mémoire/stockage modernes dont l'unité minimale d'adressage est supérieure à un octet). Néanmoins, les processeurs et processeurs de signaux modernes intègrent une prise en charge matérielle du décodage interne rapide des flux de bits, avec une gestion automatique des unités de calcul qui dépassent les limites des unités de stockage adressables (nécessaire pour un traitement efficace dans les codecs de données lors de la compression/décompression ou avec certains algorithmes de chiffrement/déchiffrement).

À titre de comparaison, l'alignement des règles d'encodage compactées produit :

01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

Ce format est aligné sur les octets. Dans ce cas, chaque octet est complété individuellement par des bits nuls sur ses bits de poids fort non utilisés.

• ASN1 Play
• Outil Web ASN1 (très limité)
• Terrain de jeu ASN1 (bac à sable)
• Décodeur JavaScript ASN.1