Etiquetas no declaradas en la entrada a un decodificador ASN.1 BER

Question

Tengo una especificación para una sintaxis ASN.1 que deseo modificar agregando algunos campos. Si creo una cadena codificada usando BER con los nuevos campos y luego intento decodificar esa cadena usando un decodificador que no sabe sobre estos campos adicionales, ¿cuál debería ser el resultado? ¿Fallará la decodificación porque hay campos que el decodificador no reconoce? ¿El decodificador decodificará solo los campos que puede reconocer e ignorar por completo los que no? ¿Es esto completamente un problema de implementación del decodificador, por lo que cualquiera de los resultados es posible, dependiendo de cómo se implementa el decodificador?

En este momento, estoy usando un compilador/decodificador ASN.1 de código abierto y parece estar fallando por completo, pero no estoy seguro de si esto se debe a la implementación o porque las reglas ASN.1 dictan ese tipo de resultado.

Answer 1

Ciertamente no depende de la implementación. Es decir, si diferentes implementaciones lo manejan de manera diferente, una de ellas lo está haciendo incorrectamente. Si va a decodificar campos desconocidos usando un decodificador que no espera campos desconocidos, la decodificación debería fallar. No se saltará los campos desconocidos.

Sin embargo, hay una forma de proporcionar campos adicionales incluso antes de que se conozcan. Es emplear el marcador de extensión ("..."). Digamos que desarrollamos varias versiones de una especificación ASN.1. Llamémoslos V1, V2, V3, etc. V1 es la especificación original, pero entendemos en el momento en que diseñamos V1 que es probable que tengamos que modificarla en algún momento. Para permitir esto, en lugar de algo como

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

Declaramos que Z es extensible como este

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

El marcador de extensión dice que, después de C, puede haber más campos que aún son desconocidos. El decodificador debe tratar mensajes que contengan dichos campos, siempre que sigan C, como válido. El decodificador no podría decodificarlos ya que no sabe lo que deberían ser, pero sabe que están permitidos.

Digamos que actualizamos V1 a V2 insertando dos campos nuevos como este

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

En este caso, la versión V1 puede interoperar con la versión V2. El codificador V1 no incluiría D o E, mientras que el codificador V2 los incluiría. Desde el punto de vista del decodificador, el decodificador V1 aceptaría (pero no decodificar) D y E, mientras que el decodificador V2 decodificaría D y E si se encuentren. Entonces, un decodificador V1 aceptaría codificaciones V1 y V2, ignorando D y E cada vez que se encuentren; Un decodificador V2 también aceptaría codificaciones V1 y V2, señalando que una codificación V1 no incluiría D o E, pero sigue siendo válida.

Podemos continuar esto a través de versiones adicionales, por ejemplo,

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

donde V1, V2 y V3 pueden interoperar.

Tenga en cuenta, sin embargo, que, dado que estamos tratando con una secuencia, el orden debe preservarse. No podría tener E sin d, ni g sin d, e y f.

Por lo tanto, la conclusión es que si su definición de tipo incluye marcadores de extensión, puede agregar nuevos campos, pero si no lo hace, es posible que no.

Answer 2

Todo esto dependerá de la especificación y la implementación. En resumen, no hay forma de decirlo. Y depende de la implementación. Algunas especificaciones para cualquier protocolo/formato dado que utilice ASN.1 establecerá explícitamente que los elementos desconocidos deben ser ignorados, en cuyo caso la decodificación no debe fallar.

Sin embargo, más comunes, los decodificadores rechazarán cualquier entrada que no se ajuste estrictamente a la sintaxis ASN.1 se supone que está decodificando.