1.1 の

1.1 の
抽象構文記法 1
状態	有効。X.208およびX.209（1988）に取って代わる。
開始年	1984
最新バージョン	(02/21) ; 2021年2月
組織	国際電気通信連合
委員会	研究グループ17
基本基準	1.1 の
関連規格	X.208、X.209、X.409、X.509、X.680、X.681、X.682、X.683
ドメイン	暗号、電気通信
Webサイト	https://www.itu.int/rec/T-REC-X.680/

抽象構文記法1（ASN.1 ）は、クロスプラットフォームでシリアル化およびデシリアル化できるデータ構造を定義するための標準インターフェース記述言語（IDL）です。通信やコンピュータネットワーク、特に暗号化の分野で広く使用されています。^[1]

プロトコル開発者は、データ構造を ASN.1 モジュールで定義します。これは通常、ASN.1 言語で記述されたより広範な標準ドキュメントの一部です。利点は、データエンコーディングの ASN.1 記述が特定のコンピューターまたはプログラミング言語に依存しないことです。ASN.1 は人間が読み取り可能で、機械が読み取り可能なため、ASN.1 コンパイラーはモジュールをコードライブラリ(コーデック)にコンパイルして、データ構造をデコードまたはエンコードできます。一部の ASN.1 コンパイラーは、パック、 BER、XML などの複数のエンコーディングをエンコードまたはデコードするコードを生成できます。

ASN.1は、国際電気通信連合電気通信標準化部門（ITU-T）のITU-T研究グループ17と国際標準化機構/国際電気標準会議（ISO/IEC）の共同標準であり、1984年にCCITT X.409:1984の一部として最初に定義されました。^[2] 1988年、ASN.1は適用範囲が広いため、独自の標準であるX.208に移行しました。大幅に改訂された1995年版は、 X.680シリーズでカバーされています。^[3] X.680シリーズの推奨事項の最新改訂版は、2021年に発行された6.0版です。^[4]

言語サポート

ASN.1 は、データ型宣言表記法です。このような型の変数の操作方法は定義されていません。変数の操作は、実行可能モデリング用のSDL (仕様および記述言語) や適合性テスト用のTTCN-3 (テストおよびテスト制御表記法) などの他の言語で定義されています。これらの言語は両方とも、ASN.1 宣言をネイティブにサポートしています。ASN.1 モジュールをインポートし、モジュールで宣言された任意の ASN.1 型の変数を宣言することができます。

アプリケーション

ASN.1 は、多数のプロトコルを定義するために使用されます。最も広範囲に使用されているのは、電気通信、暗号化、生体認証です。

エンコーディング

ASN.1 は、データ構造を一連のバイトとして表現する方法を指定する一連のエンコード規則と密接に関連しています。標準の ASN.1 エンコード規則には次のものが含まれます。

エンコーディング制御表記

ASN.1 推奨事項では、定義済みのエンコードルールが多数提供されています。既存のエンコードルールがどれも適切でない場合は、Encoding Control Notation (ECN) を使用すると、ユーザーが独自のカスタマイズされたエンコードルールを定義できます。

プライバシー強化メール (PEM) エンコーディングとの関係

プライバシー強化メール (PEM)エンコーディングは ASN.1 およびそのコーデックとはまったく関係ありませんが、多くの場合バイナリであるエンコードされた ASN.1 データは、SMTP リレーやコピー/ペーストバッファなどを介してテキストデータとして送信できるように PEM でエンコードされることがよくあります。

例

これは、架空のFooプロトコルのメッセージ (データ構造) を定義する ASN.1 モジュールの例です。

FooProtocol定義::=開始   

    FooQuestion ::= SEQUENCE { trackingNumber INTEGER 、質問IA5String }   
         
               
    

    FooAnswer ::= SEQUENCE {質問番号INTEGER 、回答BOOLEAN }   
         
                 
    

終わり

これは、Foo プロトコルの作成者によって公開された仕様である可能性があります。会話フロー、トランザクション交換、および状態は ASN.1 では定義されておらず、プロトコルの他の表記法とテキストによる説明に委ねられています。

Foo プロトコルに準拠し、受信側に送信されるメッセージを想定すると、この特定のメッセージ (プロトコルデータユニット(PDU)) は次のようになります。

myQuestion FooQuestion ::= { trackingNumber 5 、question 「誰かいますか？」}

ASN.1は値とサイズの制約と拡張性をサポートしています。上記の仕様は次のように変更できます。

FooProtocol定義::=開始   

    FooQuestion ::= SEQUENCE { trackingNumber INTEGER ( 0. . 199 ), question IA5String }   
         
               
    

    FooAnswer ::= SEQUENCE {質問番号INTEGER ( 10. . 20 ),回答BOOLEAN }   
         
                 
    

    FooHistory ::= SEQUENCE { questions SEQUENCE ( SIZE ( 0. . 10 )) OF FooQuestion 、answers SEQUENCE ( SIZE ( 1. . 10 )) OF FooAnswer 、anArray SEQUENCE ( SIZE ( 100 )) OF INTEGER ( 0. . 1000 )、... }   
           
             
              
        
    

終わり

この変更により、trackingNumbers の値は 0 から 199 まで、questionNumbers の値は 10 から 20 までに制限されます。questions 配列のサイズは 0 から 10 要素まで、answers 配列のサイズは 1 から 10 要素までです。anArray フィールドは、0 から 1000 までの範囲の整数の固定長 100 要素配列です。拡張性マーカー「...」は、FooHistory メッセージ仕様に将来のバージョンの仕様でフィールドが追加される可能性があることを意味します。あるバージョンに準拠しているシステムは、以前のバージョンで指定されたフィールドのみを処理できますが、それ以降のバージョンのトランザクションを受信および送信できます。優れた ASN.1 コンパイラは、トランザクションがこれらの制約内に収まっているかどうかを自動的にチェックするソースコード (C、C++、Java など) を生成します。制約に違反するトランザクションは、アプリケーションから受け入れたり、アプリケーションに提示したりしないでください。このレイヤーでの制約管理により、アプリケーションが制約違反から保護され、リスクとコストが削減されるため、プロトコル仕様が大幅に簡素化されます。

myQuestion メッセージをネットワーク経由で送信するには、エンコードルールの 1つを使用して、メッセージを一連のバイトとしてシリアル化 (エンコード) します。Foo プロトコル仕様では、使用するエンコードルールのセットを明示的に指定する必要があります。これにより、Foo プロトコルのユーザーは、どのルールを使用すべきか、またどのルールを期待すべきかがわかります。

DERでエンコードされた例

以下は、上記の myQuestion をDER 形式でエンコードしたデータ構造です(すべての数字は 16 進数です)。

30 13 02 01 05 16 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

DER は型、長さ、値のエンコーディングであるため、上記のシーケンスは、標準の SEQUENCE、INTEGER、および IA5String 型を参照して次のように解釈できます。

30 — シーケンスを示すタイプタグ
13 — 後続の値のオクテット単位の長さ
  02 — INTEGERを示す型タグ
  01 — 後続の値のオクテット単位の長さ
    05 — 価値 (5)
  16 — IA5Stringを示す型タグ 
     （IA5は、バリアントを含む完全な7ビットISO 646セットを意味します。
      ただし、通常は US-ASCII です)
  0e — 後続の値のオクテット単位の長さ
    41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f — 値 ("誰かいますか?")

XER でエンコードされた例

あるいは、同じ ASN.1 データ構造をXML エンコードルール(XER) でエンコードして、ネットワーク上で人間が読みやすくすることもできます。その場合、次の 108 オクテットのようになります (スペース数にはインデントに使用されるスペースも含まれます)。

<FooQuestion> 
<trackingNumber> 5 </trackingNumber> <question>誰かいますか? </question> </FooQuestion>

PER でエンコードされた例 (非整列)

あるいは、パックされたエンコーディング規則が採用されている場合、次の 122 ビット (16 オクテットは 128 ビットになりますが、ここでは 122 ビットのみが情報を伝達し、最後の 6 ビットは単なるパディングです) が生成されます。

01 05 0e 83 bb ce 2d f9 3c a0 e9 a3 2f 2c af c0

この形式では、必要な要素の型タグはエンコードされないため、エンコードに使用される想定スキーマを知らなければ解析できません。また、IA5String の値のバイトは、8 ビット単位ではなく 7 ビット単位でパックされます。これは、エンコーダーが IA5String バイト値のエンコードには 7 ビットしか必要ないことを知っているためです。ただし、長さバイトは、最初の整数タグ 01 であっても、ここでエンコードされます (ただし、PER パッカーは、許容値の範囲が 8 ビットに収まることがわかっている場合はこれを省略することもできます。また、許容値がより狭い範囲にしか収まらないことがわかっている場合は、単一の値バイト 05 を 8 ビット未満に圧縮することもできます)。

エンコードされた PER の最後の 6 ビットは、最後のバイト c0 の最下位 6 ビットのヌルビットで埋め込まれます。このシーケンスがより長い非整列 PER シーケンスの一部として挿入される場合、これらの追加ビットは送信されず、他の何かをエンコードするためにも使用されません。

つまり、アラインされていない PER データは、本質的には、アラインされた PER のような順序付けられたバイトストリームではなく、順序付けられたビットストリームであり、通常のプロセッサでソフトウェアによってデコードするのは、直接的なバイトアドレス指定ではなく、追加のコンテキストビットシフトとマスキングが必要になるため、少し複雑になります (ただし、最小アドレス指定可能単位が 1 オクテットより大きい最新のプロセッサとメモリ/ストレージユニットでも同じことが言えます)。ただし、最新のプロセッサとシグナルプロセッサには、アドレス指定可能なストレージユニットの境界を越えるコンピューティングユニットを自動的に処理するビットストリームの高速内部デコードのハードウェアサポートが含まれています (これは、圧縮/解凍用データコーデックまたは一部の暗号化/復号化アルゴリズムでの効率的な処理に必要です)。

オクテット境界でのアライメントが必要な場合、アライメントされた PER エンコーダーは次を生成します。

01 05 0e 41 6e 79 62 6f 64 79 20 74 68 65 72 65 3f

(この場合、各オクテットの未使用の最上位ビットには、ヌルビットが個別に埋め込まれます)。

ツール

ASN.1 をサポートするツールのほとんどは、次のことを行います。

ASN.1ファイルを解析し、
プログラミング言語（CやC++など）で同等の宣言を生成します。
以前の宣言に基づいてエンコードおよびデコード関数を生成します。

ASN.1 をサポートするツールのリストは、ITU-T ツール Web ページにあります。

オンラインツール

ASN1 プレイ
ASN1 Web ツール (非常に制限あり)
ASN1 プレイグラウンド (サンドボックス)
ASN.1 JavaScript デコーダー

類似スキームとの比較

ASN.1 は、目的と用途において、クロスプラットフォームのデータシリアル化のためのインターフェース記述言語であるGoogle Protocol BuffersやApache Thriftに似ています。これらの言語と同様に、スキーマ (ASN.1 では「モジュール」と呼ばれます) と一連のエンコード (通常は型、長さ、値のエンコード) があります。これらの言語とは異なり、ASN.1 は単一のすぐに使用できるオープンソース実装を提供しておらず、サードパーティベンダーによって実装される仕様として公開されています。ただし、1984 年に定義された ASN.1 は、これらの言語より何年も前にさかのぼります。また、ASN.1 には、一部は廃止されている基本データ型を含む、より多様な基本データ型が含まれており、拡張性のためのオプションもより多くあります。1 つの ASN.1 メッセージには、複数の標準で定義された複数のモジュールのデータを含めることができます。標準が何年も離れて定義された場合でも同様です。

ASN.1 には、値とサイズに対する制約のサポートも組み込まれています。たとえば、モジュールは 0 ～ 100 の範囲でなければならない整数フィールドを指定できます。値のシーケンス (配列) の長さも、固定長または許容される長さの範囲として指定できます。制約は、基本制約のセットの論理的な組み合わせとして指定することもできます。

制約として使用される値は、PDU 仕様で使用されるリテラル、またはスキーマファイル内の他の場所で指定された ASN.1 値のいずれかです。一部の ASN.1 ツールでは、生成されたソースコードでプログラマーがこれらの ASN.1 値を利用できるようになります。定義されるプロトコルの定数として使用することで、開発者はプロトコルのロジック実装でこれらを使用できます。したがって、すべての PDU とプロトコル定数をスキーマで定義でき、サポートされている言語でのプロトコルのすべての実装でこれらの値が使用されます。これにより、開発者が実装のソースコードでプロトコル定数を手動でコーディングする必要がなくなります。これはプロトコル開発に大きく役立ちます。プロトコルの定数は ASN.1 スキーマで変更でき、すべての実装は再コンパイルするだけで更新されるため、迅速かつ低リスクの開発サイクルが促進されます。

ASN.1 ツールが生成されたソースコードに制約チェックを適切に実装すると、プログラム操作中にプロトコルデータが自動的に検証されます。通常、ASN.1 ツールには、生成されたシリアル化/デシリアル化ルーチンに制約チェックが組み込まれ、範囲外のデータが検出されるとエラーまたは例外が発生します。ASN.1 コンパイラで ASN.1 制約のすべての側面を実装するのは複雑です。すべてのツールが、考えられる制約式の全範囲をサポートしているわけではありません。XMLスキーマとJSON スキーマはどちらも同様の制約概念をサポートしています。ツールによる制約のサポートはさまざまです。Microsoft の xsd.exe コンパイラは制約を無視します。

ASN.1 は、 HTTPやSMTPなどの多くのインターネットプロトコルの定義に使用される拡張バッカスナウア形式(ABNF)と見た目が似ています。ただし、実際にはまったく異なります。ASN.1 は、さまざまな方法 (JSON、XML、バイナリなど) でエンコードできるデータ構造を定義します。一方、ABNF は、エンコード (「構文」) を定義すると同時に、データ構造 (「セマンティクス」) も定義します。ABNF は、テキスト形式の人間が読めるプロトコルの定義に使用されることが多く、一般に、型、長さ、値のエンコードの定義には使用されません。

多くのプログラミング言語では、言語固有のシリアル化形式が定義されています。たとえば、Python の「pickle」モジュールや Ruby の「Marshal」モジュールなどです。これらの形式は一般に言語固有です。また、スキーマを必要としないため、アドホックなストレージシナリオでは使いやすくなりますが、通信プロトコルには適していません。

JSONとXML も同様にスキーマを必要としないため、簡単に使用できます。また、どちらもクロスプラットフォーム標準であり、特にJSON スキーマまたはXML スキーマと組み合わせると、通信プロトコルとして広く普及しています。

一部の ASN.1 ツールは、ASN.1 と XML スキーマ (XSD) 間の変換が可能です。変換は ITU によって標準化されています。これにより、プロトコルを ASN.1 で定義し、XSD で自動的に定義することもできます。したがって、プロジェクトで XSD スキーマを ASN.1 ツールでコンパイルして、オブジェクトを JSON ワイヤフォーマットにシリアル化するソースコードを作成することは可能です (ただし、賢明ではないかもしれません)。より実用的な使用法は、他のサブプロジェクトが ASN.1 スキーマではなく XSD スキーマを使用できるようにすることです。これは、サブプロジェクトの言語の選択に適したツールの可用性に適しており、プロトコルワイヤフォーマットとして XER が使用されます。

詳細については、「データシリアル化形式の比較」を参照してください。

参照

参考文献

^ 「ASN.1の紹介」。ITU。2021年4月9日時点のオリジナルよりアーカイブ。2021年4月9日閲覧。
^ 「ITU-T 勧告データベース」. ITU 。2017 年 3 月 6 日に取得。
^ ITU-T X.680 - 基本表記法の仕様
^この記事は、2008 年 11 月 1 日より前の Free On-line Dictionary of Computing のASN.1 から取得した資料に基づいており、 GFDLバージョン 1.3 以降の「再ライセンス」条件に基づいて組み込まれています。
^ ITU-T X.690 - 基本符号化規則 (BER)
^ ITU-T X.690 - 識別符号化規則 (DER)
^ ITU-T X.690 - 標準エンコード規則 (CER)
^ abcd ITU-T X.691 - パック符号化規則 (PER)
^ abc ITU-T X.693 - XML エンコーディング規則 (XER)
^ ab ITU-T X.696 - オクテット符号化規則 (OER)
^ ITU-T X.697 - JavaScript オブジェクト表記エンコーディング規則 (JER)
^ RFC 3641 - 汎用文字列エンコーディング規則 (GSER)

外部リンク

ASN.1、BER、DER のサブセットに関する一般向けガイド。初心者向けの優れた入門書です。
ITU-T ウェブサイト - ASN.1 の概要
ASN.1 のビデオ紹介
ASN.1 チュートリアル ASN.1 の基本概念に関するチュートリアル
ASN.1 チュートリアル ASN.1 のチュートリアル
オープンソースの ASN.1->C++ コンパイラ。いくつかの ASN.1 仕様が含まれています。オンライン ASN.1->C++ コンパイラ
ASN.1 デコーダー ASN.1 でエンコードされたメッセージを XML 出力にデコードできます。
ASN.1 構文チェッカーおよびエンコーダー/デコーダー ASN.1 スキーマの構文をチェックし、メッセージをエンコード/デコードします。
3GPP メッセージの ASN.1 エンコーダー/デコーダー ASN.1 3GPP メッセージをエンコード/デコードし、これらのメッセージを簡単に編集できるようにします。
ASN.1に関する無料の書籍
IvmaiAsn プロジェクトの ASN.1 ツールのリスト
オクテット符号化規則 (OER) の概要
JSON エンコーディングルール (JER) の概要
ASN.1 メッセージを解析および検証するための Typescript ノードユーティリティ

[1] 「ASN.1の紹介」。ITU。2021年4月9日時点のオリジナルよりアーカイブ。2021年4月9日閲覧。

[2] 「ITU-T 勧告データベース」. ITU 。2017 年 3 月 6 日に取得。

[3] ITU-T X.680 - 基本表記法の仕様

[4] ^この記事は、2008 年 11 月 1 日より前の Free On-line Dictionary of Computing のASN.1 から取得した資料に基づいており、 GFDLバージョン 1.3 以降の「再ライセンス」条件に基づいて組み込まれています。

[5] ITU-T X.690 - 基本符号化規則 (BER)

[6] ITU-T X.690 - 識別符号化規則 (DER)

[7] ITU-T X.690 - 標準エンコード規則 (CER)

[:0-8] ITU-T X.691 - パック符号化規則 (PER)

[:1-9] ITU-T X.693 - XML エンコーディング規則 (XER)

[:2-10] ITU-T X.696 - オクテット符号化規則 (OER)

[11] ITU-T X.697 - JavaScript オブジェクト表記エンコーディング規則 (JER)

[12] RFC 3641 - 汎用文字列エンコーディング規則 (GSER)