Tags não declaradas na entrada de um decodificador ASN.1 BER

Question

Tenho uma especificação para uma sintaxe ASN.1 que desejo modificar adicionando alguns campos. Se eu criar uma string codificada usando BER com os novos campos e tentar decodificar essa string usando um decodificador que não sabe sobre esses campos adicionais, qual deve ser o resultado? A decodificação falhará porque há campos que o decodificador não reconhece? O decodificador decodificará apenas os campos que poderá reconhecer e ignorar completamente os que não fazem? Isso é completamente um problema de implementação do decodificador, portanto, o resultado é possível, dependendo de como o decodificador é implementado?

No momento, estou usando um compilador/decodificador de código aberto ASN.1 e parece estar falhando completamente, mas não tenho certeza se isso é por causa da implementação ou porque as regras do ASN.1 ditam esse tipo de resultado?

Answer 1

Certamente não depende da implementação. Ou seja, se implementações diferentes estão lidando com isso de maneira diferente, uma delas está fazendo isso incorretamente. Se você for para decodificar campos desconhecidos usando um decodificador que não espera campos desconhecidos, a decodificação deve falhar. Não vai pular sobre campos desconhecidos.

Há, no entanto, uma maneira de fornecer campos adicionais antes mesmo de serem conhecidos. É para empregar o marcador de extensão ("..."). Digamos que desenvolvemos várias versões de uma especificação ASN.1. Vamos chamá -los de v1, v2, v3, etc. v1 é a especificação original, mas entendemos no momento em que projetamos v1 que é provável que teremos que modificá -lo em algum momento. Para permitir isso, em vez de algo como

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

nós declararíamos z como extensível assim

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

O marcador de extensão diz que, seguindo C, pode haver mais campos que ainda são desconhecidos. O decodificador deve tratar mensagens contendo esses campos, desde que sigam C, como válido. O decodificador não seria capaz de decodificá -los, pois não sabe o que deveria ser, mas sabe que eles são permitidos.

Digamos que atualizamos V1 para V2, inserindo dois novos campos como este

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

Nesse caso, a versão V1 pode interoperar com a versão V2. O codificador V1 não incluiria D ou E, enquanto o codificador V2 os incluiria. Do ponto de vista do decodificador, o decodificador V1 aceitaria (mas não decodificar) D e E, enquanto o decodificador V2 decodificaria d e e se forem encontrados. Portanto, um decodificador V1 aceitava as codificações V1 e V2, ignorando D e E sempre que forem encontradas; Um decodificador V2 também aceitaria as codificações V1 e V2, observando que uma codificação V1 não incluiria D ou E, mas permanece válida.

Podemos continuar isso através de versões adicionais, por exemplo,

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

onde v1, v2 e v3 podem interoperar.

Observe, no entanto, que, como estamos lidando com uma sequência, a ordem deve ser preservada. Você não poderia ter E sem D, nem G sem D, E e F.

A conclusão é, portanto, que, se sua definição de tipo incluir marcadores de extensão, você poderá adicionar novos campos, mas se não o fizer, você não poderá.

Answer 2

Tudo isso dependerá da especificação e da implementação. Em resumo - não há como contar. E depende da implementação. Algumas especificações para qualquer protocolo/formato utilizando o ASN.1 declaram explicitamente que elementos desconhecidos devem ser ignorados; nesse caso, a decodificação não deve falhar.

Mais comum, porém, os decodificadores rejeitarão qualquer entrada que não esteja estritamente em conformidade com a sintaxe do ASN.1, ele deve estar decodificando.