2. General Considerations (一般的な考慮事項)
2. General Considerations (一般的な考慮事項)
テキストエンコーディングは, "-----BEGIN ", ラベル, および "-----" からなる行で始まり, "-----END ", ラベル, および "-----" からなる行で終わります。これらの行または "カプセル化境界" の間には, [RFC4648] のセクション4に従った base64 エンコードデータがあります。(PEM [RFC1421] はこのデータを "encapsulated text portion" と呼んでいました。) カプセル化境界の前のデータは許可され, パーサーはそのようなデータを処理する際に誤動作してはなりません (MUST NOT)。さらに, パーサーは空白文字やその他の非 base64 文字を無視すべきであり (SHOULD), 異なる改行規則を処理しなければなりません (MUST)。
エンコードされるデータのタイプは, "-----BEGIN " 行 (事前カプセル化境界) のタイプラベルに応じてラベル付けされます。例えば, その行は "-----BEGIN CERTIFICATE-----" であり, コンテンツが PKIX 証明書であることを示します (詳細は以下を参照)。ジェネレーターは "-----END " 行 (事後カプセル化境界) に対応する "-----BEGIN " 行と同じラベルを配置しなければなりません (MUST)。ラベルは形式的には大文字小文字を区別し, 大文字であり, 0個以上の文字で構成されます。連続するスペースやハイフンマイナスを含まず, どちらの端にもスペースやハイフンマイナスを含みません。パーサーは, ラベルの不一致があった場合にエラーを通知する代わりに, 事後カプセル化境界のラベルを無視してもかまいません (MAY)。一部の既存の実装ではラベルの一致を要求しますが, 他の実装では要求しません。
"BEGIN" または "END" とラベルの間には正確に1つのスペース文字 (SP) があります。カプセル化境界の両端には正確に5つのハイフンマイナス (ダッシュとも呼ばれる) 文字 ("-") があり, それ以上でも以下でもありません。
ラベルタイプは, エンコードされたデータが指定された構文に従うことを意味します。パーサーは非準拠データを適切に処理しなければなりません (MUST)。ただし, この文書以前のすべてのパーサーやジェネレーターが一貫して動作するわけではありません。準拠パーサーは内容を別のラベルタイプとして解釈してもかまいませんが (MAY), セキュリティに関する考慮事項セクションで議論されているセキュリティ上の影響に注意すべきです。この文書で説明されているラベルは, 特定の暗号アルゴリズムに特化していないコンテナフォーマットを識別します。これはアルゴリズムアジリティと一致する特性です。これらのフォーマットは [RFC5280] のセクション4.1.1.2で説明されているように ASN.1 AlgorithmIdentifier 構造を使用します。
レガシー PEM エンコーディング [RFC1421], OpenPGP ASCII armor, および OpenSSH key file format とは異なり, テキストエンコーディングはデータと共にエンコードされるヘッダーを定義または許可しません。事前カプセル化境界と base64 の間に空のスペースが現れることはできますが, ジェネレーターはそのようなスペースを出力すべきではありません (SHOULD NOT)。(この空の領域の規定は PEM へのフラッシュバックであり, PEM は "encapsulated header portion" を定義していました。)
実装者は, 既存のパーサーが空白文字の処理においてかなり異なることに注意する必要があります。この文書では, "whitespace" (空白文字) とは, タイポグラフィで水平または垂直スペースを表す任意の文字または一連の文字を意味します。US-ASCII では, 空白文字は HT (0x09), VT (0x0B), FF (0x0C), SP (0x20), CR (0x0D), および LF (0x0A) を意味します。"blank" (空白) は HT と SP を意味します。行は CRLF, CR, または LF で区切られます。一般的な ABNF プロダクション WSP は "blank" と一致します。新しいプロダクション W が "whitespace" に使用されます。セクション3の ABNF は US-ASCII に固有です。これらのテキストエンコーディングは多くの異なるシステムや, 紙や彫刻などの長期アーカイブストレージメディア上でも使用できるため, 実装者は厳密に US-ASCII に制限されない環境でこれらのフォーマットを生成または解析する際には, 規則の文字よりも精神を使用すべきです。
ほとんどの既存のパーサーは行末の空白を無視します。行頭の空白や base64 エンコードデータの途中にある空白は, はるかに互換性が低くなります。これらの観察は図1に成文化されています。最も緩やかなパーサー実装は全く行指向ではなく, カプセル化境界の外側の空白文字の任意の混合を受け入れます (図2参照)。このような緩やかな解析は, 意図されていないテキスト (例えば, テキストがスニペットやサンプルだったため) を受け入れるリスクがあります。
ジェネレーターは base64 エンコード行を折り返さなければならず (MUST), 各行が最終行を除いて正確に64文字で構成されるようにします。最終行はデータの残りを (64文字の行境界内で) エンコードし, 余分な空白文字を出力してはなりません (MUST NOT)。パーサーは他の行サイズを処理してもかまいません (MAY)。これらの要件は PEM [RFC1421] と一致しています。
ファイルには複数のテキストエンコーディングインスタンスが含まれる場合があります (MAY)。これは例えば, ファイルに複数の証明書が含まれている場合に使用されます。インスタンスが順序付けされているか順序なしかは, コンテキストに依存します。