ASN.1

Las recomendaciones ASN.1 proporcionan una serie de reglas de codificación predefinidas. Si ninguna de las reglas de codificación existentes resulta adecuada, la Notación de Control de Codificación (ECN, X.692) permite al usuario definir sus propias reglas de codificación personalizadas.

La codificación Privacy-Enhanced Mail (PEM) no guarda ninguna relación con ASN.1 ni con sus códecs, pero los datos ASN.1 codificados, que a menudo son binarios, suelen codificarse en PEM para que puedan transmitirse como datos de texto, por ejemplo, a través de relés SMTP o mediante búferes de copiar y pegar.

Este es un ejemplo de módulo ASN.1 que define los mensajes (estructuras de datos) de un protocolo Foo ficticio:

FooProtocol DEFINICIONES ::= INICIOFooQuestion ::= SEQUENCE { trackingNumber INTEGER , question IA5String }FooAnswer ::= SEQUENCE { questionNumber INTEGER , answer BOOLEAN }FIN

Podría tratarse de una especificación publicada por los creadores del Protocolo Foo. Los flujos de conversación, los intercambios de transacciones y los estados no están definidos en ASN.1, sino que se dejan a otras notaciones y a la descripción textual del protocolo.

ASN.1 admite restricciones en valores y tamaños, así como extensibilidad. La especificación anterior se puede modificar a:

FooProtocol DEFINICIONES ::= INICIOFooQuestion ::= SEQUENCE { trackingNumber INTEGER ( 0. . 199 ), question IA5String }FooAnswer ::= SEQUENCE { questionNumber INTEGER ( 10. . 20 ), answer BOOLEAN }FooHistory ::= SECUENCIA { preguntas SECUENCIA ( TAMAÑO ( 0. . 10 )) DE FooQuestion , respuestas SECUENCIA ( TAMAÑO ( 1. . 10 )) DE FooAnswer , unArray SECUENCIA ( TAMAÑO ( 100 )) DE ENTERO ( 0. . 1000 ), ... }FIN

Este cambio restringe que trackingNumbers tenga un valor entre 0 y 199 inclusive, y questionNumbers un valor entre 10 y 20 inclusive. El tamaño del array questions puede estar entre 0 y 10 elementos, y el array answers entre 1 y 10 elementos. El campo anArray es un array fijo de 100 elementos enteros que debe estar en el rango de 0 a 1000. El marcador de extensibilidad '...' significa que la especificación del mensaje FooHistory puede tener campos adicionales en futuras versiones de la especificación; los sistemas compatibles con una versión deberían poder recibir y transmitir transacciones de una versión posterior, aunque solo podrán procesar los campos especificados en la versión anterior. Los buenos compiladores ASN.1 generarán (en C, C++, Java, etc.) código fuente que comprobará automáticamente que las transacciones se ajusten a estas restricciones. Las transacciones que infrinjan las restricciones no deben aceptarse ni presentarse a la aplicación. La gestión de restricciones en esta capa simplifica significativamente la especificación del protocolo, ya que las aplicaciones estarán protegidas contra violaciones de restricciones, lo que reduce el riesgo y el coste.

Los ejemplos anteriores solo utilizan la sintaxis de X.680. No se utilizan las restricciones más avanzadas de X.682.

Suponiendo que se trata de un mensaje que cumple con el Protocolo Foo y que se enviará a la parte receptora, este mensaje en particular ( unidad de datos de protocolo (PDU)) es:

miPreguntaFooQuestion ::= { trackingNumber 5 , question "¿Hay alguien ahí? " }

Para enviar el mensaje myQuestion a través de la red, este se serializa (codifica) como una serie de bytes utilizando una de las reglas de codificación . La especificación del protocolo Foo debería indicar explícitamente un conjunto de reglas de codificación para que los usuarios sepan cuál deben usar y qué esperar.

Lo anterior es un ejemplo de X.681, específicamente de la construcción ObjectAssignment .

A continuación se muestra la estructura de datos que aparece arriba como myQuestion codificada en formato DER (todos los números están en hexadecimal):

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

DER es una codificación de tipo-longitud-valor , por lo que la secuencia anterior puede interpretarse, con referencia a los tipos estándar SEQUENCE, INTEGER e IA5String, de la siguiente manera:

30 — etiqueta de tipo que indica SECUENCIA 13 — longitud en octetos del valor que sigue 02 — etiqueta de tipo que indica ENTERO 01 — longitud en octetos del valor que sigue 05 — valor (5) 16 — etiqueta de tipo que indica IA5String (IA5 significa el conjunto completo de 7 bits ISO 646, incluidas las variantes, pero generalmente es US-ASCII) 0e — longitud en octetos del valor que sigue 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f — valor ("¿Hay alguien ahí?")

Como alternativa, es posible codificar la misma estructura de datos ASN.1 con las Reglas de Codificación XML (XER) para lograr una mayor legibilidad humana en la transmisión. En ese caso, aparecería como los siguientes 108 octetos (el recuento de espacios incluye los espacios utilizados para la indentación):

<FooQuestion> <trackingNumber> 5 </trackingNumber> <question> ¿Hay alguien ahí? </question> </FooQuestion>

Alternativamente, si se emplean las reglas de codificación empaquetada no alineadas, se producirán los siguientes 122 bits (16 octetos equivalen a 128 bits, pero aquí solo 122 bits contienen información y los últimos 6 bits son simplemente relleno):

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

En este formato, las etiquetas de tipo para los elementos requeridos no están codificadas, por lo que no se puede analizar sin conocer los esquemas esperados utilizados para la codificación. Además, los bytes para el valor de IA5String se empaquetan usando unidades de 7 bits en lugar de unidades de 8 bits, porque el codificador sabe que codificar un valor de byte IA5String requiere solo 7 bits. Sin embargo, los bytes de longitud todavía están codificados aquí, incluso para la primera etiqueta entera 01 (pero un empaquetador PER también podría omitirlo si sabe que el rango de valores permitidos cabe en 8 bits, e incluso podría compactar el byte de valor único 05 con menos de 8 bits, si sabe que los valores permitidos solo pueden caber en un rango más pequeño).

Los últimos 6 bits en el PER codificado se rellenan con bits nulos en los 6 bits menos significativos del último byte c0  : estos bits adicionales no se pueden transmitir ni utilizar para codificar otra cosa si esta secuencia se inserta como parte de una secuencia PER no alineada más larga.

Esto significa que los datos PER no alineados son esencialmente una secuencia ordenada de bits, y no una secuencia ordenada de bytes como con los datos PER alineados, y que su decodificación por software en procesadores convencionales será algo más compleja, ya que requerirá desplazamiento y enmascaramiento de bits contextuales adicionales, y no direccionamiento directo de bytes (aunque lo mismo se aplica a los procesadores modernos y a las unidades de memoria/almacenamiento cuya unidad mínima direccionable es mayor que 1 octeto). Sin embargo, los procesadores modernos y los procesadores de señales incluyen soporte de hardware para la decodificación interna rápida de secuencias de bits con manejo automático de unidades de cómputo que cruzan los límites de las unidades de almacenamiento direccionables (esto es necesario para un procesamiento eficiente en códecs de datos para compresión/descompresión o con algunos algoritmos de cifrado/descifrado).

En comparación, Packed Encoding Rules Aligned produce en su lugar:

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

Este formato está alineado a octetos. En este caso, cada octeto se rellena individualmente con bits nulos en sus bits más significativos no utilizados.

• Juego ASN1
• Herramienta web ASN1 (muy limitada)
• Zona de juegos ASN1 (sandbox)
• Decodificador JavaScript ASN.1

Algunas herramientas ASN.1 permiten la traducción entre ASN.1 y esquemas XML (XSD). Esta traducción está estandarizada por la UIT. Esto posibilita definir un protocolo en ASN.1 y, automáticamente, también en XSD. Por lo tanto, es posible (aunque quizás no recomendable) tener en un proyecto un esquema XSD compilado por herramientas ASN.1 que generen código fuente que serialice objetos a/desde formato JSON. Un uso más práctico consiste en permitir que otros subproyectos utilicen un esquema XSD en lugar de un esquema ASN.1, según la disponibilidad de herramientas para el lenguaje elegido por los subproyectos, utilizando XER como formato de protocolo.

OSS Nokalva ofrece una herramienta para convertir un objeto de datos JSON o un esquema JSON en una definición ASN.1. ^{[ 23 ]} Todavía no existe una herramienta para generar un esquema JSON que describa la estructura codificada en JER de una estructura de datos ASN.1.

OSS Nokalva también ofrece una herramienta para convertir un esquema de Protocol Buffers en una definición ASN.1. ^{[ 24 ]}

Muchos lenguajes de programación definen formatos de serialización específicos. Por ejemplo, el módulo "pickle" de Python y el módulo "Marshal" de Ruby. Estos formatos no requieren un esquema. Generalmente son específicos del lenguaje, lo que facilita su uso en escenarios de almacenamiento ad hoc, pero los hace inadecuados para protocolos de comunicación.

JSON y XML tampoco requieren un esquema, lo que facilita su uso. Además, ambos son estándares multiplataforma muy populares para protocolos de comunicación, especialmente cuando se combinan con un esquema JSON o XML .

ASN.1 es visualmente similar a la forma aumentada de Backus-Naur (ABNF), que se utiliza para definir muchos protocolos de Internet como HTTP y SMTP . Sin embargo, en la práctica son bastante diferentes: ASN.1 define una estructura de datos que puede codificarse de diversas maneras (por ejemplo, JSON, XML, binario). ABNF, en cambio, define la codificación ("sintaxis") al mismo tiempo que define la estructura de datos ("semántica"). ABNF tiende a usarse con mayor frecuencia para definir protocolos textuales legibles por humanos y, por lo general, no se utiliza para definir codificaciones de tipo-longitud-valor.

ASN.1 también es visualmente similar a CSN.1 . Sin embargo, CSN.1 también define la codificación de un objeto, específicamente a nivel de bits.