У меня есть такая структура BER...
$ openssl asn1parse -inform der -in test.der -i -dump
????:d=4 hl=2 l=inf cons: cont [ 0 ]
????:d=5 hl=3 l= 240 prim: OCTET STRING
0000 - AABBCCDD
????:d=5 hl=2 l= 8 prim: OCTET STRING
0000 - EEFF
????:d=5 hl=2 l= 0 prim: EOC
...или в стиле der2ascii...
[0] `80`
OCTET_STRING { `AABBCCDD` }
OCTET_STRING { `EEFF` }
`0000`
Что я знаю: кодирование неопределенной длины должно содержать сконструированный тип, потому что примитивные типы могут вносить неоднозначность, например. при содержании 0x0000. Что я хочу знать: как декодер должен вести себя при анализе этой структуры BER? Включены ли в кодировку байты заголовка обеих цепочек октетов? Если да, то как кодируются байтовые данные неопределенной длины? Как приложение интерпретирует значение поля TLV с тегом [0], когда вторая СТРОКА ОКТЕТОВ, например, ЦЕЛОЕ ЧИСЛО?
Я задаю этот вопрос, потому что в стандарте CMS поле определяется как одна ОКТЕТНАЯ СТРОКА, но в большинстве кодировок BER я всегда вижу две из них. Это только из-за кодирования неопределенной длины? Я что-то пропустил?
Из МСЭ-Т X.690:
8.1.4 Октеты содержимого
Октеты содержимого должны состоять из нуля, одного или нескольких октетов и должны кодировать значение данных, как указано в последующих пунктах.
ПРИМЕЧАНИЕ. – Октеты содержимого зависят от типа значения данных; последующие пункты следуют той же последовательности, что и определение типов в ASN.1.
Означает ли это, что я могу поместить любой сконструированный тип, а приложение должно интерпретировать только часть значения сконструированной структуры TLV?
