RFC 7468 - Textual Encodings of PKIX, PKCS, and CMS Structures 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7468
タイトル : RFC 7468 - PKIX、PKCS、およびCMS構造のテキストエンコーディング
翻訳編集 : 自動生成

[要約] RFC 7468は、PKIX、PKCS、およびCMS構造のテキストエンコーディングに関する仕様です。このRFCの目的は、これらの構造をテキスト形式で表現するためのエンコーディング方法を提供することです。

Internet Engineering Task Force (IETF)                      S. Josefsson
Request for Comments: 7468                                        SJD AB
Category: Standards Track                                     S. Leonard
ISSN: 2070-1721                                            Penango, Inc.
                                                              April 2015

Textual Encodings of PKIX, PKCS, and CMS Structures

PKIX、PKCS、およびCMS構造のテキストエンコーディング

Abstract

概要

This document describes and discusses the textual encodings of the Public-Key Infrastructure X.509 (PKIX), Public-Key Cryptography Standards (PKCS), and Cryptographic Message Syntax (CMS). The textual encodings are well-known, are implemented by several applications and libraries, and are widely deployed. This document articulates the de facto rules by which existing implementations operate and defines them so that future implementations can interoperate.

このドキュメントでは、公開鍵インフラストラクチャX.509（PKIX）、公開鍵暗号化標準（PKCS）、および暗号化メッセージ構文（CMS）のテキストエンコーディングについて説明および説明します。テキストエンコーディングはよく知られており、いくつかのアプリケーションとライブラリによって実装され、広く展開されています。このドキュメントは、既存の実装が動作する事実上のルールを明確に示し、将来の実装が相互運用できるようにそれらを定義します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7468.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7468で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  General Considerations  . . . . . . . . . . . . . . . . . . .   3
   3.  ABNF  . . . . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Textual Encoding of Certificates  . . . . . . . . . . . . . .   8
     5.1.  Encoding  . . . . . . . . . . . . . . . . . . . . . . . .   8
     5.2.  Explanatory Text  . . . . . . . . . . . . . . . . . . . .   9
     5.3.  File Extension  . . . . . . . . . . . . . . . . . . . . .   9
   6.  Textual Encoding of Certificate Revocation Lists  . . . . . .  10
   7.  Textual Encoding of PKCS #10 Certification Request Syntax . .  11
   8.  Textual Encoding of PKCS #7 Cryptographic Message Syntax  . .  11
   9.  Textual Encoding of Cryptographic Message Syntax  . . . . . .  12
   10. One Asymmetric Key and the Textual Encoding of PKCS #8
       Private Key Info  . . . . . . . . . . . . . . . . . . . . . .  12
   11. Textual Encoding of PKCS #8 Encrypted Private Key Info  . . .  13
   12. Textual Encoding of Attribute Certificates  . . . . . . . . .  13
   13. Textual Encoding of Subject Public Key Info . . . . . . . . .  14
   14. Security Considerations . . . . . . . . . . . . . . . . . . .  14
   15. References  . . . . . . . . . . . . . . . . . . . . . . . . .  14
     15.1.  Normative References . . . . . . . . . . . . . . . . . .  14
     15.2.  Informative References . . . . . . . . . . . . . . . . .  15
   Appendix A.  Non-conforming Examples  . . . . . . . . . . . . . .  17
   Appendix B.  DER Expectations . . . . . . . . . . . . . . . . . .  18
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1. Introduction

1. はじめに

Several security-related standards used on the Internet define ASN.1 data formats that are normally encoded using the Basic Encoding Rules (BER) or Distinguished Encoding Rules (DER) [X.690], which are binary, octet-oriented encodings. This document is about the textual encodings of the following formats:

インターネットで使用されているいくつかのセキュリティ関連の規格では、ASN.1データ形式を定義しています。これらのデータ形式は、通常、基本エンコーディングルール（BER）またはDistinguished Encoding Rules（DER）[X.690]を使用してエンコードされます。これらはバイナリのオクテット指向のエンコーディングです。このドキュメントは、次の形式のテキストエンコーディングに関するものです。

1. Certificates, Certificate Revocation Lists (CRLs), and Subject Public Key Info structures in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile [RFC5280].

1. 証明書、証明書失効リスト（CRL）、およびインターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイル[RFC5280]のサブジェクト公開鍵情報構造。

2. PKCS #10: Certification Request Syntax [RFC2986].

2. PKCS＃10：認証要求構文[RFC2986]。

3. PKCS #7: Cryptographic Message Syntax [RFC2315].

3. PKCS＃7：暗号メッセージ構文[RFC2315]。

4. Cryptographic Message Syntax [RFC5652].

4. 暗号化メッセージ構文[RFC5652]。

5. PKCS #8: Private-Key Information Syntax [RFC5208], renamed to One Asymmetric Key in Asymmetric Key Package [RFC5958], and Encrypted Private-Key Information Syntax in the same documents.

5. PKCS＃8：秘密鍵情報構文[RFC5208]、非対称鍵パッケージ[RFC5958]で1つの非対称鍵に名前変更、および同じドキュメントの暗号化された秘密鍵情報構文。

6. Attribute Certificates in An Internet Attribute Certificate Profile for Authorization [RFC5755].

6. 承認用のインターネット属性証明書プロファイルの属性証明書[RFC5755]。

A disadvantage of a binary data format is that it cannot be interchanged in textual transports, such as email or text documents. One advantage with text-based encodings is that they are easy to modify using common text editors; for example, a user may concatenate several certificates to form a certificate chain with copy-and-paste operations.

バイナリデータ形式の欠点は、電子メールやテキストドキュメントなどのテキスト転送では交換できないことです。テキストベースのエンコーディングの利点の1つは、一般的なテキストエディタを使用して簡単に変更できることです。たとえば、ユーザーは複数の証明書を連結して、コピーアンドペースト操作で証明書チェーンを形成できます。

The tradition within the RFC series can be traced back to Privacy-Enhanced Mail (PEM) [RFC1421], based on a proposal by Marshall Rose in Message Encapsulation [RFC934]. Originally called "PEM encapsulation mechanism", "encapsulated PEM message", or (arguably) "PEM printable encoding", today the format is sometimes referred to as "PEM encoding". Variations include OpenPGP ASCII armor [RFC4880] and OpenSSH key file format [RFC4716].

RFCシリーズ内の伝統は、Marshall Roseによるメッセージカプセル化[RFC934]の提案に基づいて、プライバシー強化メール（PEM）[RFC1421]まで遡ることができます。元々は「PEMカプセル化メカニズム」、「カプセル化されたPEMメッセージ」、または（おそらく）「PEM印刷可能なエンコーディング」と呼ばれていましたが、現在の形式は「PEMエンコーディング」と呼ばれることもあります。バリエーションには、OpenPGP ASCIIアーマー[RFC4880]とOpenSSHキーファイル形式[RFC4716]が含まれます。

For reasons that basically boil down to non-coordination or inattention, many PKIX, PKCS, and CMS libraries implement a text-based encoding that is similar to -- but not identical with -- PEM encoding. This document specifies the _textual encoding_ format, articulates the de facto rules that most implementations operate by, and provides recommendations that will promote interoperability going forward. This document also provides common nomenclature for syntax elements, reflecting the evolution of this de facto standard format. Peter Gutmann's "X.509 Style Guide" [X.509SG] contains a section "base64 Encoding" that describes the formats and contains suggestions similar to what is in this document. All figures are real, functional examples, with key lengths and inner contents chosen to be as small as practicable.

基本的に非調整または不注意に要約される理由により、多くのPKIX、PKCS、およびCMSライブラリは、PEMエンコーディングに似ていますが、同一ではないテキストベースのエンコーディングを実装しています。このドキュメントでは、_textual encoding_形式を指定し、ほとんどの実装で使用されるデファクトルールを明確にし、今後の相互運用性を促進する推奨事項を提供します。このドキュメントは、この事実上の標準形式の進化を反映して、構文要素の一般的な命名法も提供します。 Peter Gutmannの「X.509スタイルガイド」[X.509SG]には、フォーマットを説明するセクション「base64エンコーディング」が含まれており、このドキュメントと同様の提案が含まれています。すべての数字は実際の機能的な例であり、キーの長さと内部の内容は可能な限り小さく選択されています。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの "は、RFC 2119 [RFC2119]で説明されているように解釈されます。

2. General Considerations

2. 一般的な考慮事項

   Textual encoding begins with a line comprising "-----BEGIN ", a
   label, and "-----", and ends with a line comprising "-----END ", a
   label, and "-----".  Between these lines, or "encapsulation
   boundaries", are base64-encoded data according to Section 4 of
   [RFC4648].  (PEM [RFC1421] referred to this data as the "encapsulated
   text portion".)  Data before the encapsulation boundaries are
   permitted, and parsers MUST NOT malfunction when processing such
   data.  Furthermore, parsers SHOULD ignore whitespace and other non-
   base64 characters and MUST handle different newline conventions.

   The type of data encoded is labeled depending on the type label in
   the "-----BEGIN " line (pre-encapsulation boundary).  For example,
   the line may be "-----BEGIN CERTIFICATE-----" to indicate that the
   content is a PKIX certificate (see further below).  Generators MUST
   put the same label on the "-----END " line (post-encapsulation
   boundary) as the corresponding "-----BEGIN " line.  Labels are
   formally case-sensitive, uppercase, and comprised of zero or more
   characters; they do not contain consecutive spaces or hyphen-minuses,
   nor do they contain spaces or hyphen-minuses at either end.  Parsers
   MAY disregard the label in the post-encapsulation boundary instead of
   signaling an error if there is a label mismatch: some extant
   implementations require the labels to match; others do not.

There is exactly one space character (SP) separating the "BEGIN" or "END" from the label. There are exactly five hyphen-minus (also known as dash) characters ("-") on both ends of the encapsulation boundaries, no more, no less.

「BEGIN」または「END」とラベルを区切るスペース文字（SP）は1つだけです。カプセル化の境界の両端には、正確に5つのハイフンマイナス（ダッシュとも呼ばれます）文字（ "-"）があります。

The label type implies that the encoded data follows the specified syntax. Parsers MUST handle non-conforming data gracefully. However, not all parsers or generators prior to this document behave consistently. A conforming parser MAY interpret the contents as another label type but ought to be aware of the security implications discussed in the Security Considerations section. The labels described in this document identify container formats that are not specific to any particular cryptographic algorithm, a property consistent with algorithm agility. These formats use the ASN.1 AlgorithmIdentifier structure as described in Section 4.1.1.2 of [RFC5280].

ラベルタイプは、エンコードされたデータが指定された構文に従うことを意味します。パーサーは、非準拠データを適切に処理する必要があります。ただし、このドキュメントより前のすべてのパーサーまたはジェネレーターが一貫して動作するとは限りません。適合パーサーは、コンテンツを別のラベルタイプとして解釈してもかまいませんが、「セキュリティに関する考慮事項」セクションで説明されているセキュリティへの影響に注意する必要があります。このドキュメントで説明するラベルは、特定の暗号化アルゴリズムに固有ではないコンテナー形式を識別します。これは、アルゴリズムの俊敏性と一致する特性です。これらの形式は、[RFC5280]のセクション4.1.1.2で説明されているASN.1 AlgorithmIdentifier構造を使用します。

Unlike legacy PEM encoding [RFC1421], OpenPGP ASCII armor, and the OpenSSH key file format, textual encoding does *not* define or permit headers to be encoded alongside the data. Empty space can appear between the pre-encapsulation boundary and the base64, but generators SHOULD NOT emit such any such spacing. (The provision for this empty area is a throwback to PEM, which defined an "encapsulated header portion".)

従来のPEMエンコーディング[RFC1421]、OpenPGP ASCIIアーマー、およびOpenSSHキーファイル形式とは異なり、テキストエンコーディングでは、ヘッダーをデータと一緒にエンコードすることは定義または許可されていません。カプセル化前の境界とbase64の間に空のスペースが表示される可能性がありますが、ジェネレータはそのようなスペースを生成してはなりません（SHOULD NOT）。（この空の領域の規定は、「カプセル化されたヘッダー部分」を定義したPEMへの逆戻りです。）

Implementers need to be aware that extant parsers diverge considerably on the handling of whitespace. In this document, "whitespace" means any character or series of characters that represent horizontal or vertical space in typography. In US-ASCII, whitespace means HT (0x09), VT (0x0B), FF (0x0C), SP (0x20), CR (0x0D), and LF (0x0A); "blank" means HT and SP; lines are divided with CRLF, CR, or LF. The common ABNF production WSP is congruent with "blank"; a new production W is used for "whitespace". The ABNF in Section 3 is specific to US-ASCII. As these textual encodings can be used on many different systems as well as on long-term archival storage media such as paper or engravings, an implementer ought to use the spirit rather than the letter of the rules when generating or parsing these formats in environments that are not strictly limited to US-ASCII.

実装者は、現存するパーサーが空白の処理に関してかなり分岐していることを認識する必要があります。このドキュメントでは、「空白」とは、タイポグラフィで水平または垂直のスペースを表す任意の文字または一連の文字を意味します。 US-ASCIIでは、空白はHT（0x09）、VT（0x0B）、FF（0x0C）、SP（0x20）、CR（0x0D）、およびLF（0x0A）を意味します。「空白」はHTとSPを意味します。行はCRLF、CR、またはLFで分割されます。一般的なABNFプロダクションWSPは「空白」と一致しています。新しいプロダクションWは「空白」に使用されます。セクション3のABNFはUS-ASCIIに固有です。これらのテキストエンコーディングは、多くの異なるシステムや紙や彫刻などの長期のアーカイブストレージメディアで使用できるため、実装者は、環境でこれらの形式を生成または解析するときに、ルールの文字ではなく精神を使用する必要があります。厳密にUS-ASCIIに限定されません。

Most extant parsers ignore blanks at the ends of lines; blanks at the beginnings of lines or in the middle of the base64-encoded data are far less compatible. These observations are codified in Figure 1. The most lax parser implementations are not line-oriented at all and will accept any mixture of whitespace outside of the encapsulation boundaries (see Figure 2). Such lax parsing may run the risk of accepting text that was not intended to be accepted in the first place (e.g., because the text was a snippet or sample).

ほとんどの現存するパーサーは行末の空白を無視します。行の先頭またはbase64でエンコードされたデータの途中の空白は、互換性がはるかに低くなります。これらの観察は図1に体系化されています。ほとんどの緩いパーサー実装は行指向ではなく、カプセル化境界の外側の空白の混合を受け入れます（図2を参照）。そのような緩い解析は、最初から受け入れられるように意図されていなかったテキストを受け入れるリスクを冒す可能性があります（たとえば、テキストがスニペットまたはサンプルだったため）。

Generators MUST wrap the base64-encoded lines so that each line consists of exactly 64 characters except for the final line, which will encode the remainder of the data (within the 64-character line boundary), and they MUST NOT emit extraneous whitespace. Parsers MAY handle other line sizes. These requirements are consistent with PEM [RFC1421].

ジェネレーターは、base64でエンコードされた行をラップして、各行が最後の行を除いて正確に64文字で構成され、残りのデータ（64文字の行境界内）をエンコードする必要があり、無関係な空白を出力してはなりません（MUST）。パーサーは他の行サイズを処理できます（MAY）。これらの要件はPEM [RFC1421]と一致しています。

Files MAY contain multiple textual encoding instances. This is used, for example, when a file contains several certificates. Whether the instances are ordered or unordered depends on the context.

ファイルには、複数のテキストエンコーディングインスタンスが含まれる場合があります。これは、たとえば、ファイルに複数の証明書が含まれている場合に使用されます。インスタンスが順序付けされているか、順序付けされていないかは、コンテキストによって異なります。

3. ABNF

The ABNF [RFC5234] of the textual encoding is:

テキストエンコーディングのABNF [RFC5234]は次のとおりです。

textualmsg = preeb *WSP eol *eolWSP base64text posteb *WSP [eol]

textualmsg = preeb * WSP eol * eolWSP base64text post * WSP [eol]

  preeb      = "-----BEGIN " label "-----" ; unlike [RFC1421] (A)BNF,
                                           ; eol is not required (but
  posteb     = "-----END " label "-----"   ; see [RFC1421], Section 4.4)

  base64char = ALPHA / DIGIT / "+" / "/"

base64pad = "="

  base64line = 1*base64char *WSP eol
  base64finl = *base64char (base64pad *WSP eol base64pad /
                            *2base64pad) *WSP eol
                       ; ...AB= <EOL> = <EOL> is not good, but is valid

  base64text = *base64line base64finl
         ; we could also use <encbinbody> from RFC 1421, which requires
         ; 16 groups of 4 chars, which means exactly 64 chars per
         ; line, except the final line, but this is more accurate

  labelchar  = %x21-2C / %x2E-7E    ; any printable character,
                                    ; except hyphen-minus

  label      = [ labelchar *( ["-" / SP] labelchar ) ]       ; empty ok

  eol        = CRLF / CR / LF

  eolWSP     = WSP / CR / LF                        ; compare with LWSP

Figure 1: ABNF (Standard)

図1：ABNF（標準）

   laxtextualmsg    = *W preeb
                      laxbase64text
                      posteb *W

   W                = WSP / CR / LF / %x0B / %x0C           ; whitespace

   laxbase64text    = *(W / base64char) [base64pad *W [base64pad *W]]

Figure 2: ABNF (Lax)

図2：ABNF（緩い）

stricttextualmsg = preeb eol strictbase64text posteb eol

   strictbase64finl = *15(4base64char) (4base64char / 3base64char
                        base64pad / 2base64char 2base64pad) eol

   base64fullline   = 64base64char eol

   strictbase64text = *base64fullline strictbase64finl

Figure 3: ABNF (Strict)

図3：ABNF（厳密）

New implementations SHOULD emit the strict format (Figure 3) specified above. The choice of parsing strategy depends on the context of use.

新しい実装は、上記で指定された厳密な形式（図3）を発行する必要があります（SHOULD）。解析戦略の選択は、使用のコンテキストに依存します。

4. Guide

4. ガイド

For convenience, these figures summarize the structures, encodings, and references in the following sections:

便宜上、これらの図は、以下のセクションの構造、エンコード、および参照を要約しています。

Sec. Label                  ASN.1 Type              Reference Module
----+----------------------+-----------------------+---------+----------
  5  CERTIFICATE            Certificate             [RFC5280] id-pkix1-e
  6  X509 CRL               CertificateList         [RFC5280] id-pkix1-e
  7  CERTIFICATE REQUEST    CertificationRequest    [RFC2986] id-pkcs10
  8  PKCS7                  ContentInfo             [RFC2315] id-pkcs7*
  9  CMS                    ContentInfo             [RFC5652] id-cms2004
 10  PRIVATE KEY            PrivateKeyInfo ::=      [RFC5208] id-pkcs8
                            OneAsymmetricKey        [RFC5958] id-aKPV1
 11  ENCRYPTED PRIVATE KEY  EncryptedPrivateKeyInfo [RFC5958] id-aKPV1
 12  ATTRIBUTE CERTIFICATE  AttributeCertificate    [RFC5755] id-acv2
 13  PUBLIC KEY             SubjectPublicKeyInfo    [RFC5280] id-pkix1-e

Figure 4: Convenience Guide

図4：便利ガイド

 -----------------------------------------------------------------------
 id-pkixmod OBJECT IDENTIFIER ::= {iso(1) identified-organization(3)
            dod(6) internet(1) security(5) mechanisms(5) pkix(7) mod(0)}
 id-pkix1-e OBJECT IDENTIFIER ::= {id-pkixmod pkix1-explicit(18)}
 id-acv2    OBJECT IDENTIFIER ::= {id-pkixmod mod-attribute-cert-v2(61)}
 id-pkcs    OBJECT IDENTIFIER ::= {iso(1) member-body(2) us(840)
                                   rsadsi(113549) pkcs(1)}
 id-pkcs10  OBJECT IDENTIFIER ::= {id-pkcs 10 modules(1) pkcs-10(1)}
 id-pkcs7   OBJECT IDENTIFIER ::= {id-pkcs 7 modules(0) pkcs-7(1)}
 id-pkcs8   OBJECT IDENTIFIER ::= {id-pkcs 8 modules(1) pkcs-8(1)}
 id-sm-mod  OBJECT IDENTIFIER ::= {id-pkcs 9 smime(16) modules(0)}
 id-aKPV1   OBJECT IDENTIFIER ::= {id-sm-mod mod-asymmetricKeyPkgV1(50)}
 id-cms2004 OBJECT IDENTIFIER ::= {id-sm-mod cms-2004(24)}

* This OID does not actually appear in PKCS #7 v1.5 [RFC2315]. It was defined in the ASN.1 module to PKCS #7 v1.6 [P7v1.6], and has been carried forward through PKCS #12 [RFC7292].

* このOIDは、実際にはPKCS＃7 v1.5 [RFC2315]には表示されません。これは、ASN.1モジュールでPKCS＃7 v1.6 [P7v1.6]に定義されており、PKCS＃12 [RFC7292]を通じて引き継がれています。

Figure 5: ASN.1 Module Object Identifier Value Assignments

図5：ASN.1モジュールオブジェクト識別子の値の割り当て

5. Textual Encoding of Certificates

5. 証明書のテキストエンコーディング

5.1. Encoding

5.1. エンコーディング

Public-key certificates are encoded using the "CERTIFICATE" label. The encoded data MUST be a BER (DER strongly preferred; see Appendix B) encoded ASN.1 Certificate structure as described in Section 4 of [RFC5280].

公開鍵証明書は、「CERTIFICATE」ラベルを使用してエンコードされます。 [RFC5280]のセクション4で説明されているように、エンコードされたデータは、BER（DERを強く推奨、付録Bを参照）でエンコードされたASN.1証明書の構造である必要があります。

Figure 6: Certificate Example

図6：証明書の例

Historically, the label "X509 CERTIFICATE" and also less commonly "X.509 CERTIFICATE" have been used. Generators conforming to this document MUST generate "CERTIFICATE" labels and MUST NOT generate "X509 CERTIFICATE" or "X.509 CERTIFICATE" labels. Parsers SHOULD NOT treat "X509 CERTIFICATE" or "X.509 CERTIFICATE" as equivalent to "CERTIFICATE", but a valid exception may be for backwards compatibility (potentially together with a warning).

従来、「X509 CERTIFICATE」というラベルと、あまり一般的ではない「X.509 CERTIFICATE」というラベルが使用されてきました。このドキュメントに準拠するジェネレータは、「CERTIFICATE」ラベルを生成する必要があり、「X509 CERTIFICATE」または「X.509 CERTIFICATE」ラベルを生成してはなりません。パーサーは「X509 CERTIFICATE」または「X.509 CERTIFICATE」を「CERTIFICATE」と同等として扱わないでください（SHOULD NOT）。ただし、有効な例外は、下位互換性のために（場合によっては警告とともに）あります。

5.2. Explanatory Text

5.2. 説明文

Many tools are known to emit explanatory text before the BEGIN and after the END lines for PKIX certificates, more than any other type. If emitted, such text SHOULD be related to the certificate, such as providing a textual representation of key data elements in the certificate.

他のタイプよりも多くのツールが、PKIX証明書のBEGIN行の前とEND行の後に説明テキストを出力することが知られています。発行された場合、そのようなテキストは、証明書の主要なデータ要素のテキスト表現を提供するなど、証明書に関連する必要があります（SHOULD）。

Subject: CN=Atlantis
Issuer: CN=Atlantis
Validity: from 7/9/2012 3:10:38 AM UTC to 7/9/2013 3:10:37 AM UTC
-----BEGIN CERTIFICATE-----
MIIBmTCCAUegAwIBAgIBKjAJBgUrDgMCHQUAMBMxETAPBgNVBAMTCEF0bGFudGlz
MB4XDTEyMDcwOTAzMTAzOFoXDTEzMDcwOTAzMTAzN1owEzERMA8GA1UEAxMIQXRs
YW50aXMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAu+BXo+miabDIHHx+yquqzqNh
Ryn/XtkJIIHVcYtHvIX+S1x5ErgMoHehycpoxbErZmVR4GCq1S2diNmRFZCRtQID
AQABo4GJMIGGMAwGA1UdEwEB/wQCMAAwIAYDVR0EAQH/BBYwFDAOMAwGCisGAQQB
gjcCARUDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDAzA1BgNVHQEE
LjAsgBA0jOnSSuIHYmnVryHAdywMoRUwEzERMA8GA1UEAxMIQXRsYW50aXOCASow
CQYFKw4DAh0FAANBAKi6HRBaNEL5R0n56nvfclQNaXiDT174uf+lojzA4lhVInc0
ILwpnZ1izL4MlI9eCSHhVQBHEp2uQdXJB+d5Byg=
-----END CERTIFICATE-----

Figure 7: Certificate Example with Explanatory Text

図7：説明テキストを含む証明書の例

5.3. File Extension

5.3. ファイル拡張子

Although textual encodings of PKIX structures can occur anywhere, many tools are known to offer an option to output this encoding when serializing PKIX structures. To promote interoperability and to separate DER encodings from textual encodings, the extension ".crt" SHOULD be used for the textual encoding of a certificate. Implementations should be aware that in spite of this recommendation, many tools still default to encode certificates in this textual encoding with the extension ".cer".

PKIX構造のテキストエンコーディングはどこでも発生する可能性がありますが、PKIX構造をシリアル化するときにこのエンコーディングを出力するオプションを提供する多くのツールが知られています。相互運用性を促進し、DERエンコードをテキストエンコードから分離するには、証明書のテキストエンコードに拡張子「.crt」を使用する必要があります（SHOULD）。実装では、この推奨事項にもかかわらず、多くのツールがデフォルトでこのテキストエンコーディングで拡張子「.cer」を使用して証明書をエンコードすることを認識しておく必要があります。

This section does not disturb the official application/pkix-cert registration [RFC2585] in any way (which states that "each '.cer' file contains exactly one certificate, encoded in DER format"), but merely articulates a widespread, de facto alternative.

このセクションは、公式のapplication / pkix-cert登録[RFC2585]を妨害することはありません（「各「.cer」ファイルには、DER形式でエンコードされた証明書が1つだけ含まれている」と記載されています）。代替。

6. Textual Encoding of Certificate Revocation Lists

6. 証明書失効リストのテキストエンコーディング

Certificate Revocation Lists (CRLs) are encoded using the "X509 CRL" label. The encoded data MUST be a BER (DER strongly preferred; see Appendix B) encoded ASN.1 CertificateList structure as described in Section 5 of [RFC5280].

証明書失効リスト（CRL）は、「X509 CRL」ラベルを使用してエンコードされます。 [RFC5280]のセクション5で説明されているように、エンコードされたデータは、BER（DERを強く推奨、付録Bを参照）でエンコードされたASN.1 CertificateList構造である必要があります。

Figure 8: CRL Example

図8：CRLの例

Historically, the label "CRL" has rarely been used. Today, it is not common and many popular tools do not understand the label. Therefore, this document standardizes "X509 CRL" in order to promote interoperability and backwards-compatibility. Generators conforming to this document MUST generate "X509 CRL" labels and MUST NOT generate "CRL" labels. Parsers SHOULD NOT treat "CRL" as equivalent to "X509 CRL".

従来、「CRL」というラベルはほとんど使用されていませんでした。今日では一般的ではなく、多くの一般的なツールはラベルを理解していません。したがって、このドキュメントでは、相互運用性と下位互換性を促進するために「X509 CRL」を標準化しています。このドキュメントに準拠するジェネレータは、「X509 CRL」ラベルを生成する必要があり、「CRL」ラベルを生成してはなりません。パーサーは「CRL」を「X509 CRL」と同等のものとして扱わないでください。

7. Textual Encoding of PKCS #10 Certification Request Syntax

7. PKCS＃10認証要求構文のテキストエンコーディング

PKCS #10 Certification Requests are encoded using the "CERTIFICATE REQUEST" label. The encoded data MUST be a BER (DER strongly preferred; see Appendix B) encoded ASN.1 CertificationRequest structure as described in [RFC2986].

PKCS＃10証明書リクエストは、「CERTIFICATE REQUEST」ラベルを使用してエンコードされます。エンコードされたデータは、[RFC2986]で説明されているように、BER（DERを強く推奨。付録Bを参照）エンコードされたASN.1 CertificationRequest構造である必要があります。

Figure 9: PKCS #10 Example

図9：PKCS＃10の例

The label "NEW CERTIFICATE REQUEST" is also in wide use. Generators conforming to this document MUST generate "CERTIFICATE REQUEST" labels. Parsers MAY treat "NEW CERTIFICATE REQUEST" as equivalent to "CERTIFICATE REQUEST".

「NEW CERTIFICATE REQUEST」のラベルも広く使用されています。このドキュメントに準拠するジェネレータは、「証明書要求」ラベルを生成する必要があります。パーサーは、「NEW CERTIFICATE REQUEST」を「CERTIFICATE REQUEST」と同等のものとして扱うことができます。

8. Textual Encoding of PKCS #7 Cryptographic Message Syntax

8. PKCS＃7暗号メッセージ構文のテキストエンコーディング

PKCS #7 Cryptographic Message Syntax structures are encoded using the "PKCS7" label. The encoded data MUST be a BER-encoded ASN.1 ContentInfo structure as described in [RFC2315].

PKCS＃7暗号メッセージ構文構造は、「PKCS7」ラベルを使用してエンコードされます。エンコードされたデータは、[RFC2315]で説明されているように、BERエンコードされたASN.1 ContentInfo構造である必要があります。

Figure 10: PKCS #7 Example

図10：PKCS＃7の例

The label "CERTIFICATE CHAIN" has been in use to denote a degenerate PKCS #7 structure that contains only a list of certificates (see Section 9 of [RFC2315]). Several modern tools do not support this label. Generators MUST NOT generate the "CERTIFICATE CHAIN" label. Parsers SHOULD NOT treat "CERTIFICATE CHAIN" as equivalent to "PKCS7".

ラベル「CERTIFICATE CHAIN」は、証明書のリストのみを含む縮退したPKCS＃7構造を示すために使用されています（[RFC2315]のセクション9を参照）。いくつかの最新のツールはこのラベルをサポートしていません。ジェネレータは、「証明書チェーン」ラベルを生成してはなりません。パーサーは「CERTIFICATE CHAIN」を「PKCS7」と同等のものとして扱わないでください。

PKCS #7 is an old specification that has long been superseded by CMS [RFC5652]. Implementations SHOULD NOT generate PKCS #7 when CMS is an alternative.

PKCS＃7は、CMS [RFC5652]に長い間取って代わられた古い仕様です。 CMSが代替である場合、実装ではPKCS＃7を生成しないでください。

9. Textual Encoding of Cryptographic Message Syntax

9. 暗号化メッセージ構文のテキストエンコーディング

Cryptographic Message Syntax structures are encoded using the "CMS" label. The encoded data MUST be a BER-encoded ASN.1 ContentInfo structure as described in [RFC5652].

暗号メッセージ構文構造は、「CMS」ラベルを使用してエンコードされます。エンコードされたデータは、[RFC5652]で説明されているように、BERエンコードされたASN.1 ContentInfo構造である必要があります。

-----BEGIN CMS-----
MIGDBgsqhkiG9w0BCRABCaB0MHICAQAwDQYLKoZIhvcNAQkQAwgwXgYJKoZIhvcN
AQcBoFEET3icc87PK0nNK9ENqSxItVIoSa0o0S/ISczMs1ZIzkgsKk4tsQ0N1nUM
dvb05OXi5XLPLEtViMwvLVLwSE0sKlFIVHAqSk3MBkkBAJv0Fx0=
-----END CMS-----

Figure 11: CMS Example

図11：CMSの例

CMS is the IETF successor to PKCS #7. Section 1.1.1 of [RFC5652] describes the changes since PKCS #7 v1.5. Implementations SHOULD generate CMS when it is an alternative, promoting interoperability and forwards-compatibility.

CMSは、PKCS＃7の後継IETFです。 [RFC5652]のセクション1.1.1は、PKCS＃7 v1.5以降の変更について説明しています。実装は、代替である場合にCMSを生成して、相互運用性と前方互換性を促進する必要があります（SHOULD）。

10. One Asymmetric Key and the Textual Encoding of PKCS #8 Private Key Info

10. 1つの非対称鍵とPKCS＃8秘密鍵情報のテキストエンコーディング

Unencrypted PKCS #8 Private Key Information Syntax structures (PrivateKeyInfo), renamed to Asymmetric Key Packages (OneAsymmetricKey), are encoded using the "PRIVATE KEY" label. The encoded data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1 PrivateKeyInfo structure as described in PKCS #8 [RFC5208], or a OneAsymmetricKey structure as described in [RFC5958]. The two are semantically identical and can be distinguished by version number.

暗号化されていないPKCS＃8秘密鍵情報構文構造（PrivateKeyInfo）は、非対称鍵パッケージ（OneAsymmetricKey）に名前が変更され、「秘密鍵」ラベルを使用してエンコードされます。エンコードされたデータは、PKCS＃8 [RFC5208]で説明されているように、BER（DER優先、付録Bを参照）でエンコードされたASN.1 PrivateKeyInfo構造、または[RFC5958]で説明されているOneAsymmetricKey構造である必要があります。 2つは意味的に同一であり、バージョン番号で区別できます。

Figure 12: PKCS #8 PrivateKeyInfo (OneAsymmetricKey) Example

図12：PKCS＃8 PrivateKeyInfo（OneAsymmetricKey）の例

11. Textual Encoding of PKCS #8 Encrypted Private Key Info

11. PKCS＃8暗号化秘密鍵情報のテキストエンコーディング

Encrypted PKCS #8 Private Key Information Syntax structures (EncryptedPrivateKeyInfo), called the same in [RFC5958], are encoded using the "ENCRYPTED PRIVATE KEY" label. The encoded data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1 EncryptedPrivateKeyInfo structure as described in PKCS #8 [RFC5208] and [RFC5958].

暗号化されたPKCS＃8秘密鍵情報構文構造（EncryptedPrivateKeyInfo）は、[RFC5958]で同じと呼ばれ、「暗号化されたプライベートキー」ラベルを使用してエンコードされます。エンコードされたデータは、PKCS＃8 [RFC5208]および[RFC5958]で説明されているように、BER（DER優先、付録Bを参照）エンコードされたASN.1 EncryptedPrivateKeyInfo構造でなければなりません。

Figure 13: PKCS #8 EncryptedPrivateKeyInfo Example

図13：PKCS＃8 EncryptedPrivateKeyInfoの例

12. Textual Encoding of Attribute Certificates

12. 属性証明書のテキストエンコーディング

Attribute certificates are encoded using the "ATTRIBUTE CERTIFICATE" label. The encoded data MUST be a BER (DER strongly preferred; see Appendix B) encoded ASN.1 AttributeCertificate structure as described in [RFC5755].

属性証明書は、「ATTRIBUTE CERTIFICATE」ラベルを使用してエンコードされます。 [RFC5755]で説明されているように、エンコードされたデータはBER（DERを強く推奨、付録Bを参照）エンコードされたASN.1 AttributeCertificate構造でなければなりません（MUST）。

-----BEGIN ATTRIBUTE CERTIFICATE-----
MIICKzCCAZQCAQEwgZeggZQwgYmkgYYwgYMxCzAJBgNVBAYTAlVTMREwDwYDVQQI
DAhOZXcgWW9yazEUMBIGA1UEBwwLU3RvbnkgQnJvb2sxDzANBgNVBAoMBkNTRTU5
MjE6MDgGA1UEAwwxU2NvdHQgU3RhbGxlci9lbWFpbEFkZHJlc3M9c3N0YWxsZXJA
aWMuc3VueXNiLmVkdQIGARWrgUUSoIGMMIGJpIGGMIGDMQswCQYDVQQGEwJVUzER
MA8GA1UECAwITmV3IFlvcmsxFDASBgNVBAcMC1N0b255IEJyb29rMQ8wDQYDVQQK
DAZDU0U1OTIxOjA4BgNVBAMMMVNjb3R0IFN0YWxsZXIvZW1haWxBZGRyZXNzPXNz
dGFsbGVyQGljLnN1bnlzYi5lZHUwDQYJKoZIhvcNAQEFBQACBgEVq4FFSjAiGA8z
OTA3MDIwMTA1MDAwMFoYDzM5MTEwMTMxMDUwMDAwWjArMCkGA1UYSDEiMCCGHmh0
dHA6Ly9pZGVyYXNobi5vcmcvaW5kZXguaHRtbDANBgkqhkiG9w0BAQUFAAOBgQAV
M9axFPXXozEFcer06bj9MCBBCQLtAM7ZXcZjcxyva7xCBDmtZXPYUluHf5OcWPJz
5XPus/xS9wBgtlM3fldIKNyNO8RsMp6Ocx+PGlICc7zpZiGmCYLl64lAEGPO/bsw
Smluak1aZIttePeTAHeJJs8izNJ5aR3Wcd3A5gLztQ==
-----END ATTRIBUTE CERTIFICATE-----

Figure 14: Attribute Certificate Example

図14：属性証明書の例

13. Textual Encoding of Subject Public Key Info

13. サブジェクト公開鍵情報のテキストエンコーディング

Public keys are encoded using the "PUBLIC KEY" label. The encoded data MUST be a BER (DER preferred; see Appendix B) encoded ASN.1 SubjectPublicKeyInfo structure as described in Section 4.1.2.7 of [RFC5280].

公開鍵は「PUBLIC KEY」ラベルを使用してエンコードされます。 [RFC5280]のセクション4.1.2.7で説明されているように、エンコードされたデータは、BER（DER優先、付録Bを参照）でエンコードされたASN.1 SubjectPublicKeyInfo構造である必要があります。

Figure 15: Subject Public Key Info Example

図15：サブジェクトの公開鍵情報の例

14. Security Considerations

14. セキュリティに関する考慮事項

Data in this format often originates from untrusted sources, thus parsers must be prepared to handle unexpected data without causing security vulnerabilities.

この形式のデータは、多くの場合、信頼できないソースからのものであるため、パーサーは、セキュリティの脆弱性を引き起こさずに予期しないデータを処理できるように準備する必要があります。

Implementers building implementations that rely on canonical representation or the ability to fingerprint a particular data object need to understand that this document does not define canonical encodings. The first ambiguity is introduced by permitting the text-encoded representation instead of the binary BER or DER encodings, but further ambiguities arise when multiple labels are treated as similar. Variations of whitespace and non-base64 alphabetic characters can create further ambiguities. Data encoding ambiguities also create opportunities for side channels. If canonical encodings are desired, the encoded structure must be decoded and processed into a canonical form (namely, DER encoding).

正規表現または特定のデータオブジェクトをフィンガープリントする機能に依存する実装を構築する実装者は、このドキュメントが正規エンコーディングを定義していないことを理解する必要があります。最初のあいまいさは、バイナリBERまたはDERエンコードの代わりにテキストエンコード表現を許可することによって導入されますが、複数のラベルが同様に扱われると、さらにあいまいさが生じます。空白とbase64以外のアルファベット文字のバリエーションにより、さらにあいまいさが生じる可能性があります。データエンコードのあいまいさもサイドチャネルの機会を生み出します。正規エンコーディングが必要な場合は、エンコードされた構造をデコードして、正規形式（つまり、DERエンコーディング）に処理する必要があります。

15. References

15. 参考文献

15.1. Normative References

15.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月、<http://www.rfc-editor.org/info/rfc2119>。

[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998, <http://www.rfc-editor.org/info/rfc2315>.

[RFC2315] Kaliski、B。、「PKCS＃7：Cryptographic Message Syntax Version 1.5」、RFC 2315、1998年3月、<http://www.rfc-editor.org/info/rfc2315>。

[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000, <http://www.rfc-editor.org/info/rfc2986>.

[RFC2986] Nystrom、M。、およびB. Kaliski、「PKCS＃10：Certification Request Syntax Specification Version 1.7」、RFC 2986、2000年11月、<http://www.rfc-editor.org/info/rfc2986>。

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006, <http://www.rfc-editor.org/info/rfc4648>.

[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月、<http://www.rfc-editor.org/info/rfc4648>。

[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, May 2008, <http://www.rfc-editor.org/info/rfc5280>.

[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、2008年5月、<http://www.rfc-editor.org/info/rfc5280>。

[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.

[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、2008年1月、<http://www.rfc-editor.org/info/rfc5234>。

[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, RFC 5652, September 2009, <http://www.rfc-editor.org/info/rfc5652>.

[RFC5652] Housley、R。、「Cryptographic Message Syntax（CMS）」、STD 70、RFC 5652、2009年9月、<http://www.rfc-editor.org/info/rfc5652>。

[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet Attribute Certificate Profile for Authorization", RFC 5755, January 2010, <http://www.rfc-editor.org/info/rfc5755>.

[RFC5755] Farrell、S.、Housley、R。、およびS. Turner、「承認用のインターネット属性証明書プロファイル」、RFC 5755、2010年1月、<http://www.rfc-editor.org/info/rfc5755 >。

[RFC5958] Turner, S., "Asymmetric Key Packages", RFC 5958, August 2010, <http://www.rfc-editor.org/info/rfc5958>.

[RFC5958]ターナー、S。、「非対称鍵パッケージ」、RFC 5958、2010年8月、<http://www.rfc-editor.org/info/rfc5958>。

[X.690] International Telecommunications Union, "Information Technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)", ITU-T Recommendation X.690, ISO/IEC 8825-1:2008, November 2008.

[X.690] International Telecommunications Union、「Information Technology-ASN.1 encoding rules：Specification of Basic Encoding Rules（BER）、Canonical Encoding Rules（CER）and Distinguished Encoding Rules（DER）」、ITU-T勧告X.690 、ISO / IEC 8825-1：2008、2008年11月。

15.2. Informative References

15.2. 参考引用

[RFC934] Rose, M. and E. Stefferud, "Proposed standard for message encapsulation", RFC 934, January 1985, <http://www.rfc-editor.org/info/rfc934>.

[RFC934] Rose、M。およびE. Stefferud、「Proposed standard for message encapsulation」、RFC 934、1985年1月、<http://www.rfc-editor.org/info/rfc934>。

[RFC1421] Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encryption and Authentication Procedures", RFC 1421, February 1993, <http://www.rfc-editor.org/info/rfc1421>.

[RFC1421] Linn、J.、「インターネット電子メールのプライバシー強化：パートI：メッセージの暗号化と認証手順」、RFC 1421、1993年2月、<http://www.rfc-editor.org/info/rfc1421>。

[RFC2585] Housley, R. and P. Hoffman, "Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP", RFC 2585, May 1999, <http://www.rfc-editor.org/info/rfc2585>.

[RFC2585] Housley、R。およびP. Hoffman、「Internet X.509 Public Key Infrastructure Operational Protocols：FTP and HTTP」、RFC 2585、1999年5月、<http://www.rfc-editor.org/info/rfc2585 >。

[RFC4716] Galbraith, J. and R. Thayer, "The Secure Shell (SSH) Public Key File Format", RFC 4716, November 2006, <http://www.rfc-editor.org/info/rfc4716>.

[RFC4716] Galbraith、J。およびR. Thayer、「The Secure Shell（SSH）Public Key File Format」、RFC 4716、2006年11月、<http://www.rfc-editor.org/info/rfc4716>。

[RFC4880] Callas, J., Donnerhacke, L., Finney, H., Shaw, D., and R. Thayer, "OpenPGP Message Format", RFC 4880, November 2007, <http://www.rfc-editor.org/info/rfc4880>.

[RFC4880] Callas、J.、Donnerhacke、L.、Finney、H.、Shaw、D。、およびR. Thayer、「OpenPGP Message Format」、RFC 4880、2007年11月、<http：//www.rfc-editor .org / info / rfc4880>。

[RFC5208] Kaliski, B., "Public-Key Cryptography Standards (PKCS) #8: Private-Key Information Syntax Specification Version 1.2", RFC 5208, May 2008, <http://www.rfc-editor.org/info/rfc5208>.

[RFC5208] Kaliski、B。、「Public-Key Cryptography Standards（PKCS）＃8：Private-Key Information Syntax Specification Version 1.2」、RFC 5208、2008年5月、<http://www.rfc-editor.org/info / rfc5208>。

[RFC7292] Moriarty, K., Ed., Nystrom, M., Parkinson, S., Rusch, A., and M. Scott, "PKCS #12: Personal Information Exchange Syntax v1.1", RFC 7292, July 2014, <http://www.rfc-editor.org/info/rfc7292>.

[RFC7292] Moriarty、K.、Ed。、Nystrom、M.、Parkinson、S.、Rusch、A。、およびM. Scott、「PKCS＃12：Personal Information Exchange Syntax v1.1」、RFC 7292、2014年7月、<http://www.rfc-editor.org/info/rfc7292>。

[P7v1.6] Kaliski, B. and K. Kingdon, "Extensions and Revisions to PKCS #7 (Version 1.6 Bulletin)", May 1997, <http://www.emc.com/emc-plus/rsa-labs/ standards-initiatives/pkcs-7-cryptographic-message-syntax-standar.htm>.

[P7v1.6] Kaliski、B。およびK. Kingdon、「Extensions and Revisions to PKCS＃7（Version 1.6 Bulletin）」、1997年5月、<http://www.emc.com/emc-plus/rsa-labs /standards-initiatives/pkcs-7-cryptographic-message-syntax-standar.htm>。

[X.509SG] Gutmann, P., "X.509 Style Guide", October 2000, <http://www.cs.auckland.ac.nz/~pgut001/pubs/ x509guide.txt>.

[X.509SG] Gutmann、P。、「X.509スタイルガイド」、2000年10月、<http://www.cs.auckland.ac.nz/~pgut001/pubs/ x509guide.txt>。

Appendix A. Non-conforming Examples

付録A.不適合の例

This appendix contains examples for the non-recommended label variants described earlier in this document. As discussed earlier, supporting these is not required and is sometimes discouraged. Still, they can be useful for interoperability testing and for easy reference.

この付録には、このドキュメントで前述した非推奨のラベルバリアントの例が含まれています。前述したように、これらのサポートは必須ではなく、場合によっては推奨されません。それでも、相互運用性のテストや簡単な参照に役立ちます。

Figure 16: Non-standard 'X509' Certificate Example

図16：非標準の「X509」証明書の例

-----BEGIN X.509 CERTIFICATE-----
MIIBHDCBxaADAgECAgIcxzAJBgcqhkjOPQQBMBAxDjAMBgNVBAMUBVBLSVghMB4X
DTE0MDkxNDA2MTU1MFoXDTI0MDkxNDA2MTU1MFowEDEOMAwGA1UEAxQFUEtJWCEw
WTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATwoQSr863QrR0PoRIYQ96H7WykDePH
Wa0eVAE24bth43wCNc+U5aZ761dhGhSSJkVWRgVH5+prLIr+nzfIq+X4oxAwDjAM
BgNVHRMBAf8EAjAAMAkGByqGSM49BAEDRwAwRAIfMdKS5F63lMnWVhi7uaKJzKCs
NnY/OKgBex6MIEAv2AIhAI2GdvfL+mGvhyPZE+JxRxWChmggb5/9eHdUcmW/jkOH
-----END X.509 CERTIFICATE-----

Figure 17: Non-standard 'X.509' Certificate Example

図17：非標準の「X.509」証明書の例

-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBWDCCAQcCAQAwTjELMAkGA1UEBhMCU0UxJzAlBgNVBAoTHlNpbW9uIEpvc2Vm
c3NvbiBEYXRha29uc3VsdCBBQjEWMBQGA1UEAxMNam9zZWZzc29uLm9yZzBOMBAG
ByqGSM49AgEGBSuBBAAhAzoABLLPSkuXY0l66MbxVJ3Mot5FCFuqQfn6dTs+9/CM
EOlSwVej77tj56kj9R/j9Q+LfysX8FO9I5p3oGIwYAYJKoZIhvcNAQkOMVMwUTAY
BgNVHREEETAPgg1qb3NlZnNzb24ub3JnMAwGA1UdEwEB/wQCMAAwDwYDVR0PAQH/
BAUDAwegADAWBgNVHSUBAf8EDDAKBggrBgEFBQcDATAKBggqhkjOPQQDAgM/ADA8
AhxBvfhxPFfbBbsE1NoFmCUczOFApEuQVUw3ZP69AhwWXk3dgSUsKnuwL5g/ftAY
dEQc8B8jAcnuOrfU
-----END NEW CERTIFICATE REQUEST-----

Figure 18: Non-standard 'NEW' PKCS #10 Example

図18：非標準の「新しい」PKCS＃10の例

Figure 19: Non-standard 'CERTIFICATE CHAIN' Example

図19：非標準の「CERTIFICATE CHAIN」の例

Appendix B. DER Expectations

付録B. DERの期待

This appendix is informative. Consult the respective standards for the normative rules.

この付録は参考情報です。規範的なルールについては、それぞれの規格を参照してください。

DER is a restricted profile of BER [X.690]; thus, all DER encodings of data values are BER encodings, but just one of the BER encodings is the DER encoding for a data value. Canonical encoding matters when performing cryptographic operations; additionally, canonical encoding has certain efficiency advantages for parsers. There are three principal reasons to encode with DER:

DERは、BER [X.690]の制限付きプロファイルです。したがって、データ値のすべてのDERエンコードはBERエンコードですが、BERエンコードの1つだけがデータ値のDERエンコードです。暗号化操作を実行する場合、正規エンコーディングが重要です。さらに、正規エンコーディングには、パーサーにとって特定の効率上の利点があります。 DERでエンコードする主な理由は3つあります。

1. A digital signature is (supposed to be) computed over the DER encoding of the semantic content, so providing anything other than the DER encoding is senseless. (In practice, an implementer might choose to have an implementation parse and digest the data as is, but this practice amounts to guesswork.)

1. デジタル署名は、セマンティックコンテンツのDERエンコーディングで計算される（想定される）ため、DERエンコーディング以外のものを提供しても意味がありません。（実際には、実装者は実装にデータをそのまま解析およびダイジェストすることを選択する場合がありますが、これは当て推量になります。）

2. In practice, cryptographic hashes are computed over the DER encoding for identification.

2. 実際には、暗号化ハッシュは、識別のためにDERエンコーディングで計算されます。

3. In practice, the content is small. DER always encodes data values in definite-length form (where the length is stated at the beginning of the encoding); thus, a parser can anticipate memory or resource usage up front.

3. 実際には、内容は小さいです。 DERは常にデータ長を明確な長さの形式でエンコードします（長さはエンコードの最初に示されています）。したがって、パーサーはメモリまたはリソースの使用量を事前に予測できます。

Figure 20 matches the structures in this document with the particular reasons for DER encoding:

図20は、このドキュメントの構造と、DERエンコーディングの特定の理由を示しています。

                    Sec. Label                  Reasons
                    ----+----------------------+-------
                      5  CERTIFICATE            1  2 ~3
                      6  X509 CRL               1
                      7  CERTIFICATE REQUEST    1    ~3
                      8  PKCS7                  *
                      9  CMS                    *
                     10  PRIVATE KEY                  3
                     11  ENCRYPTED PRIVATE KEY        3
                     12  ATTRIBUTE CERTIFICATE  1    ~3
                     13  PUBLIC KEY                2  3

Figure 20: Guide for DER Encoding

図20：DERエンコードのガイド

* Cryptographic Message Syntax is designed for content of any length; indefinite-length encoding enables one-pass processing (streaming) when generating the encoding. Only certain parts -- namely, signed and authenticated attributes -- need to be DER encoded.

* 暗号メッセージ構文は、任意の長さのコンテンツ用に設計されています。不定長エンコーディングは、エンコーディングの生成時にワンパス処理（ストリーミング）を可能にします。 DERエンコードする必要があるのは、特定の部分（つまり、署名された属性と認証された属性）だけです。

~ Although not always "small", these encoded structures should not be particularly "large" (e.g., more than 16 kilobytes). The parser ought to be informed of large things up front in any event; this is yet another reason to DER encode these things in the first place.

〜常に「小さい」とは限りませんが、これらのエンコードされた構造は、特に「大きい」（たとえば、16キロバイトを超える）ものであってはなりません。パーサーは、どんなイベントでも大きなことを事前に通知されるべきです。これは、そもそもこれらのものをDERエンコードするもう1つの理由です。

Figure 20: Guide for DER Encoding

図20：DERエンコードのガイド

Acknowledgements

謝辞

Peter Gutmann suggested to document labels for Attribute Certificates and PKCS #7 messages, and to add examples for the non-standard variants. Dr. Stephen Henson suggested distinguishing when BER versus DER is appropriate or necessary.

Peter Gutmannは、属性証明書とPKCS＃7メッセージのラベルを文書化し、非標準のバリアントの例を追加することを提案しました。スティーブンヘンソン博士は、BER対DERが適切または必要な場合を区別することを提案しました。

Authors' Addresses

著者のアドレス

Simon Josefsson SJD AB Johan Olof Wallins Vaeg 13 Solna 171 64 Sweden

Simon Josefsson SJD AB Johan Olof Wallins Vaeg 13 Solna 171 64スウェーデン

   EMail: simon@josefsson.org
   URI:   http://josefsson.org/

Sean Leonard Penango, Inc. 5900 Wilshire Boulevard 21st Floor Los Angeles, CA 90036 United States

Sean Leonard Penango、Inc. 5900 Wilshire Boulevard 21st Floor Los Angeles、CA 90036アメリカ

   EMail: dev+ietf@seantek.com
   URI:   http://www.penango.com/