X.690


X.690
X.690は、いくつかのASN.1エンコーディング形式を指定するITU-T標準です。
基本符号化規則(BER)
Canonical Encoding Rules(CER)
Distinguished Encoding Rules(DER)
基本符号化規則は、抽象的な情報を具体的なデータストリームに符号化するためにASN.1標準によって定められた元の規則でした。ASN.1用語では転送構文と総称されるルールは、特定のデータ項目をエンコードするために使用される正確なオクテットシーケンスを指定します。構文は、基本データ型の表現、長さ情報の構造、およびよりプリミティブな型に基づいて複合型または複合型を定義するための手段などの要素を定義します。BER構文は、BERの2つのサブセット(Canonical EncodingRulesとDistinguishedEncoding Rules)とともに、ASN.1ドキュメントシリーズの一部であるITU-TのX.690標準ドキュメントによって定義されています。

コンテンツ
1 BERエンコーディング
1.1 エンコーディング構造 1.2 識別子オクテット
1.2.1 タイプ
1.2.2 エンコーディング
1.2.3 長い形式
1.3 長さオクテット
1.3.1 明確な形
1.3.2 不定形
1.4 内容オクテット
2 CERエンコーディング
3 DERエンコーディング
4 BER、CER、DERの比較
4.1 BERエンコーディングに対する批判
5 使用法
6 も参照してください
7 参考文献
8 外部リンク

BERエンコーディング
基本符号化規則の形式は、ASN.1データ構造をエンコードするための自己記述型および自己区切り型の形式を指定します。各データ要素は、タイプ識別子、長さの説明、実際のデータ要素、および必要に応じてコンテンツの終わりマーカーとしてエンコードされます。これらのタイプのエンコーディングは、一般にtype-length-valueまたはTLVエンコーディングと呼ばれます。このフォーマットにより、受信者は、データのサイズ、コンテンツ、またはセマンティックな意味についての事前の知識を必要とせずに、不完全なストリームからASN.1情報をデコードできます。

エンコーディング構造
データのエンコードは通常、次の順序で表示される4つのコンポーネントで構成されます。
識別子オクテットタイプ 長さオクテット長さ 内容オクテット値 コンテンツの終わりのオクテット
コンテンツの終わりのオクテットはオプションであり、長さが不定の形式が使用されている場合にのみ使用されます。NULLタイプのようにエンコードするコンテンツがない場合は、コンテンツオクテットを省略できます。
識別子オクテット編集

タイプ
データ(特にシーケンスとセットおよび選択肢のメンバー)は、そのデータを他のメンバーと区別するために、一意のタグ番号(ASN.1の角括弧[]内に表示)でタグ付けできます。このようなタグは、暗黙的(TLVタグとして基本型を使用する代わりに値のTLVタグとしてエンコードされる場合)または明示的(基本型TLVをラップする構築されたTLVでタグが使用される場合)にすることができます。ASN.1モジュールレベルで暗黙的に設定されていない限り、デフォルトのタグ付けスタイルは明示的です。このようなタグには、コンテキスト固有のデフォルトクラスがありますが、タグの前にクラス名を使用することでオーバーライドできます。
選択値のエンコードは、選択したタイプの値のエンコードと同じです。エンコーディングは、選択したタイプに応じて、プリミティブまたは構築されます。識別子オクテットで使用されるタグは、選択されたタイプのASN.1定義で指定されているように、選択されたタイプのタグです。
次のタグはASN.1にネイティブです。
タイプ、ユニバーサルクラス
名前 許可された建設 タグ番号
10進数 16進数
コンテンツの終わり(EOC) 原生的 0 0
ブール 原生的 1 1
整数 原生的 2 2
ビット文字列 両方 3 3
オクテット文字列 両方 4 4
ヌル 原生的 5 5
オブジェクト識別子 原生的 6 6
オブジェクト記述子 両方 7 7
外部の 構築された 8 8
REAL(浮動小数点) 原生的 9 9
列挙 原生的 10 組み込みPDV 構築された 11 UTF8String 両方 12 相対OID 原生的 13 時間 原生的 14 E
予約済み
15 シーケンスとシーケンス 構築された 16 10
SETおよびSETOF 構築された 17 11
NumericString 両方 18 12
PrintableString 両方 19 13
T61String 両方 20 14
VideotexString 両方 21 15
IA5String 両方 22 16
UTCTime 両方 23 17
GeneralizedTime 両方 24 18
GraphicString 両方 25 19
VisibleString 両方 26 1A
GeneralString 両方 27 1B
UniversalString 両方 28 1C
文字列 構築された 29 1D
BMPString 両方 30 1E
日にち 原生的 31 1F
時刻 原生的 32 20
日付時刻 原生的 33 21
間隔 原生的 34 22
OID-IRI 原生的 35 23
RELATIVE-OID-IRI 原生的 36 24
ユニバーサルクラスのタグ割り当てのリストは、RecにITU-T X.680、条項8、表1。

エンコーディング
識別子オクテットは、要素タイプをクラスと番号で構成されるASN.1タグとしてエンコードし、コンテンツオクテットが構築された値を表すかプリミティブ値を表すかを示します。一部のタイプは、プリミティブまたは構築されたエンコーディングのいずれかの値を持つことができることに注意して1つ以上のオクテットとしてエンコードされます。
オクテット1 オクテット2以降8 7 6 5 4 3 2
1 87 6 5 4 3 2 1
タグクラス P / C タグ番号(0〜30) 該当なし
31 もっと タグ番号
最初のオクテットでは、ビット6はタイプがプリミティブであるか構築されているかをエンコードし、ビット7〜8はタイプのクラスをエンコードし、ビット1〜5はタグ番号をエンコードします。次の値が可能です。
クラス 価値 説明
ユニバーサル 0 タイプはASN.1にネイティブです
応用 1 タイプは1つの特定のアプリケーションにのみ有効です
コンテキスト固有 2 このタイプの意味は、コンテキスト(シーケンス、セット、または選択内など)によって異なります。
プライベート 3 プライベート仕様で定義
P / C 価値 説明
プリミティブ(P) 0 コンテンツオクテットは、要素値を直接エンコードします。
構築された(C) 1 コンテンツオクテットには、0、1、またはそれ以上の要素エンコーディングが含まれています。

長い形式
タグ番号が5ビットのタグフィールドに対して大きすぎる場合は、さらにオクテットでエンコードする必要が
最初のオクテットはクラスとプリミティブ/構築されたものを以前と同じようにエンコードし、ビット1〜5は1です。タグ番号は次のオクテットでエンコードされます。オクテットが多い場合はそれぞれのビット8が1になり、ビット1〜7がエンコードされます。タグ番号。結合されたタグ番号ビット、ビッグエンディアンは、タグ番号をエンコードします。次のオクテットの最小数をエンコードする必要がつまり、次の最初のオクテットのビット1〜7がすべて0であってはなりません。

長さオクテット
長さオクテットには、確定形式と不確定形式の2つの形式が
最初の長さのオクテット
形 ビット8 7 6 5 4 3 2 1
確かに短い 0 長さ(0〜127)
不定 1 0
確かに長い 1 次のオクテットの数(1〜126)
予約済み 1 127

明確な形
これはコンテンツオクテットの数をエンコードし、タイプがプリミティブまたは構築されており、データがすぐに利用できる場合に常に使用されます。短い形式と長い形式があり、さまざまな範囲の長さをエンコードできます。数値データは符号なし整数としてエンコードされ、最下位ビットが常に最初(右側)になります。
ショートフォームは、オクテットの数として0であり、ビット1-7(0でもよい)の長さを符号化する8ビットた単一オクテットで構成されています。
長い形態1つの初期オクテットで構成さは、長さを含む、1つの以上の後続のオクテットが続きます。最初のオクテットでは、ビット8は1であり、ビット1〜7(値0と127を除く)は、後続のオクテットの数をエンコードします。次のオクテットは、長さ(0の場合もあります)をビッグエンディアンとしてオクテットの数としてエンコードします。
長い形式の例、長さ435
オクテット1 オクテット2 オクテット31 0 0 0 0 0 1
0 00 0 0 0 0 0
1 10 1 1 0 0 1 1
長い形式 2つの長さのオクテット 435コンテンツオクテット

不定形
これは長さをまったくエンコードしませんが、コンテンツオクテットはマーカーオクテットで終了します。これは構築されたタイプに適用され、通常、コンテンツがエンコード時にすぐに利用できない場合に使用されます。
これは、ビット8が1、ビット1〜7が0の単一オクテットで構成されます。次に、2つのコンテンツ終了オクテットがコンテンツオクテットを終了する必要が

内容オクテット
内容オクテットは、要素データ値をエンコードします。
ASN.1オブジェクトの存在、またはその空性のみに注意する場合は、コンテンツオクテットがない可能性があることに注意してください(したがって、要素の長さは0です)。たとえば、これはASN.1NULL値の場合です。

CERエンコーディング
CER(Canonical Encoding Rules)は、ASN.1で記述されたデータ構造の明確な転送構文を生成するためのBERの制限付きバリアントです。BERはデータ値のエンコード方法を選択できますが、CER(DERと共に)は、基本エンコード規則で許可されているエンコードから1つだけ選択し、残りのオプションを削除します。CERは、エンコーディングを保持する必要がある場合に役立ちます。たとえば、証券取引所で。

DERエンコーディング
DER(Distinguished Encoding Rules)は、ASN.1で記述されたデータ構造の明確な転送構文を生成するためのBERの制限付きバリアントです。CERと同様に、DERエンコーディングは有効なBERエンコーディングです。DERはBERと同じですが、1つの送信者のオプションを除いてすべて削除されています。
DERはBERのサブセットであり、ASN.1値をエンコードするための1つの方法を提供します。DERは、暗号化など、一意のエンコーディングが必要な状況を対象としており、デジタル署名が必要なデータ構造が一意のシリアル化された表現を生成することを保証します。DERは、BERの標準形と見なすことができます。たとえば、BERではブール値trueを255の非ゼロバイト値のいずれかとしてエンコードできますが、DERではブール値trueをエンコードする1つの方法が
最も重要なDERエンコーディングの制約は次のとおりです。
長さエンコーディングは明確な形式を使用する必要があります
さらに、可能な限り短い長さのエンコーディングを使用する必要があります
ビット文字列、オクテット文字列、および制限付き文字列は、プリミティブエンコーディングを使用する必要があります
セットの要素は、タグ値に基づいてソートされた順序でエンコードされます
DERは、X.509などのデジタル証明書に広く使用されています。

BER、CER、DERの比較
BER形式とCERまたはDER形式の主な違いは、基本符号化規則によって提供される柔軟性です。上で説明したように、BERは、ASN.1データ構造の転送のためにITU-TX.690によって与えられたエンコーディングルールの基本セットです。送信者に送信したいデータ構造をエンコードするための明確なルールを提供するだけでなく、送信者にいくつかのエンコードの選択肢を残します。X.690標準で述べられているように、「代替エンコーディングは、送信者のオプションとして基本エンコーディング規則によって許可されます。基本エンコーディング規則への準拠を主張する受信者は、すべての代替をサポートするものとします」。
受信者は、BER準拠を合法的に主張するために、すべての正当なエンコーディングを受け入れる準備をする必要が対照的に、CERとDERはどちらも、使用可能な長さの仕様を1つのオプションに制限します。そのため、CERとDERはBERの制限された形式であり、BER標準を明確にするのに役立ちます。
CERとDERは、送信者に課す一連の制限が異なります。CERとDERの基本的な違いは、正確に定義されたいくつかのケースでは、DERは確定的な長さの形式を使用し、CERは不確定な長さの形式を使用することです。つまり、DERには常に先頭の長さ情報がありますが、CERは、エンコードされたデータの長さを提供する代わりに、コンテンツの終わりのオクテットを使用します。このため、CERはエンコードされた大きな値に対して必要なメタデータが少なくなりますが、DERは小さな値に対してメタデータを実行します。
エンコーディングルール間の選択を容易にするために、X.690標準ドキュメントは次のガイダンスを提供します。
エンコードされた値が使用可能なメモリに収まるほど小さく、ネストされた値をすばやくスキップする必要がある場合は、標準のエンコード規則よりも識別されたエンコード規則の方が適しています。使用可能なメモリに容易に収まらないほど大きい値をエンコードする必要がある場合、または値全体の前に値の一部をエンコードして送信する必要がある場合は、正規のエンコード規則が識別されたエンコード規則よりも適しています。利用可能です。基本符号化規則は、符号化に設定値または値のセットが含まれ、正規および識別符号化規則が課す制限の必要がない場合、正規符号化規則または識別符号化規則よりも適しています。

BERエンコーディングに対する批判
代替のエンコーディングルールと比較して、BERは「非効率的」であるという一般的な認識がこの認識は主に不十分な実装によるものであり、必ずしもエンコーディングルールに固有の欠陥があるとは限らないと主張する人もいます。これらの実装は、実装が容易なエンコードロジックを使用するためにBERが提供する柔軟性に依存していますが、必要以上にエンコードされたデータストリームが大きくなります。この非効率性が現実であろうと知覚であろうと、BERのパフォーマンスとサイズを改善しようとするパックドエンコーディングルールなど、多くの代替エンコーディングスキームにつながりました。
BERの柔軟性を提供しながら、代替のエンコード方式を使用する他の代替フォーマットルールも開発されています。これらの中で最も人気のあるは、次のようなXMLベースの代替、あるXMLエンコーディング規則及びASN.1 SOAP。さらに、XMLスキーマをASN.1スキーマに変換するための標準マッピングがASN.1スキーマは、BERを使用してエンコードできます。

使用法
認識されている問題にもかかわらず、BERは、特に異なるネイティブデータエンコーディングを使用するシステムで、データを送信するための一般的な形式です。
SNMPとLDAPプロトコルは、必要なエンコード方式としてBERでASN.1を指定します。
クレジットカードとデビットカードのEMV標準では、BERを使用してデータをカードにエンコードします
デジタル署名標準PKCS#7は、暗号化されたメッセージとそのデジタル署名またはデジタルエンベロープをエンコードするためにBERを使用したASN.1も指定しています。
ISDN、無料通話ルーティング、ほとんどの携帯電話サービスなどの多くの通信システムは、ネットワークを介して制御メッセージを送信するために、ある程度BERを備えたASN.1を使用します。
GSM TAP(転送されたアカウント手順)、NRTRDE(ほぼリアルタイムのローミングデータ交換)ファイルは、BERを使用してエンコードされます。
比較すると、より明確なDERエンコーディングは、X.509などのデジタル証明書を転送するために広く使用されています。

も参照してください Kerberos パックされたエンコーディングルール(PER、X.691)
プレゼンテーション層
構造化データ交換フォーマット(SDXF)
シリアル化

参考文献
は、2008年11月1日より前にFree Online Dictionary of Computingから取得され、GFDLバージョン1.3以降の「再ライセンス」条件に基づいて組み込まれた資料に基づいています。
^ 情報技術– ASN.1エンコーディングルール:基本エンコーディングルール(BER)、標準エンコーディングルール(CER)、および識別エンコーディングルール(DER)の仕様、ITU-T X6.90、2002年7月
^ http://itu.int/ITU-T/X.680 ^ リン、ホアイ-アン。「ASN.1 / BER転送構文の最適なパフォーマンスの見積もり」。ACMコンピュータコミュニケーションレビュー。7月93、45-58。
^ ITU-TRec。X.892、ISO / IEC 24824-2 ^ ITU-T X.694、ISO / IEC ISO / IEC 8825-5

外部リンク
RSAの「ASN.1、BER、およびDERのサブセットに関するレイマンズガイド」
ITU-T X.690、ISO / IEC 8825-1
ITU-T X.892、ISO / IEC 24824-2
ITU-T X.694、ISO / IEC ISO / IEC 8825-5 PKCS#7 beanitによるjASN1オープンソースJavaASN.1 BER / DERコーディングライブラリ
PHPASN1 PHP ASN.1 githubのBERエンコーディング/デコーディングライブラリ、GPLライセンス
ASN1js JavaScript ASN.1 BERエンコーディング/デコーディングライブラリ(github、GPLライセンス)
PeterGutmannの「X.509スタイルガイド」