[英]Interpreting ASN.1 indefinite-lenght encoding with multiple encapsulated octet-strings
我有這樣的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結構時必須如何表現? 編碼中是否包含兩個OCTET STRING的標頭字節? 如果是,不定長度字節數據如何編碼? 當第二個OCTET STRING是例如INTEGER時,應用程序如何解釋標記為[0]的TLV字段的值?
我問這個問題,因為在CMS標准中,一個字段定義為單個OCTET STRING,但是在大多數BER編碼中,我總是看到其中兩個。 這僅是由於不確定長度編碼造成的嗎? 我想念什么嗎?
從ITU-T X.690:
8.1.4內容八位位組
內容八位位組應由零個,一個或多個八位位組組成,並應按照后續條款的規定對數據值進行編碼。
注–內容八位位組取決於數據值的類型; 隨后的子句遵循與ASN.1中類型定義相同的順序。
這是否意味着我可以放置所有構造的類型,並且應用程序必須僅解釋構造的TLV結構的值部分?
在不定長度模式下編碼原始OCTET STRING時,編碼器必須:
在另一端,解碼器從內部確定長度的OCTET STRING塊中提取V部分(刪除其TL標頭)。 然后,按照到達順序將外部框架的TL部分刪除的方式將V合並/合並在一起。
注意,無限長編碼技術背后的思想是編碼器和解碼器都可以發出/使用不完整的,可能超大的數據。
編碼器/應用程序根據數據可用性,內存狀況以及可能的解碼器緩沖能力估計來選擇塊大小。 我認為X.280 / X.680文件中提到了這一點。
不允許編碼器將不同ASN.1類型的塊放入任何單個不確定長度編碼的容器中。 換句話說,所有塊都必須與外部容器具有相同的類型。
這有望說明為什么您會在不定長編碼的BER / CER流中看到多個(取決於塊大小)OCTET STRING,而預期中只有一個OCTET STRING。
DER禁止無限長編碼,原因是相同數據的序列化表示可能會在重新編碼時發生變化(由於塊大小可能會發生變化)。
聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.