RFC 5967 - The application/pkcs10 Media Type 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc5967
タイトル : RFC 5967 - アプリケーション/PKCS10メディアタイプ
翻訳編集 : 自動生成

[要約] RFC 5967は、"The application/pkcs10 Media Type"に関する文書で、PKCS #10形式の証明書署名要求（CSR: Certificate Signing Request）を表すためのメディアタイプ`application/pkcs10`を定義しています。このメディアタイプは、公開鍵インフラストラクチャ（PKI）内で証明書の発行を要求する際に使用されます。目的は、CSRの交換を標準化し、互換性を高めることです。関連するRFCには、PKCS #10の仕様を定義するRFC 2986などがあります。

Internet Engineering Task Force (IETF)                         S. Turner
Request for Comments: 5967                                          IECA
Updates: 2986                                                August 2010
Category: Informational
ISSN: 2070-1721

The application/pkcs10 Media Type

アプリケーション/PKCS10メディアタイプ

Abstract

概要

This document specifies a media type used to carry PKCS #10 certification requests as defined in RFC 2986. It carries over the original specification from RFC 2311, which recently has been moved to Historic status, and properly links it to RFC 2986.

このドキュメントは、RFC 2986で定義されているPKCS＃10認証要求を携帯するために使用されるメディアタイプを指定します。最近歴史的なステータスに移動されたRFC 2311からの元の仕様を引き継ぎ、RFC 2986に適切にリンクします。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。

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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc5967.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5967で取得できます。

著作権表示

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ドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、単純化されたBSDライセンスで説明されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。

This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.

このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。

1. Introduction

1. はじめに

[RFC2311] first defined the application/pkcs10 media type. When [RFC2633] was published, the application/pkcs10 section was dropped, but for some reason the text was not incorporated into the PKCS #10 document [RFC2986]. [RFC2311] was moved to Historic status by [RFC5751]. To ensure the IANA media type registration points to a non-Historic document, this document updates [RFC2986] with the definition of the application/pkcs10 media type and an IANA registration based on [RFC4288].

[RFC2311]は、最初にアプリケーション/PKCS10メディアタイプを定義しました。[RFC2633]が公開されたとき、アプリケーション/PKCS10セクションが削除されましたが、何らかの理由でテキストはPKCS＃10ドキュメント[RFC2986]に組み込まれませんでした。[RFC2311]は[RFC5751]によって歴史的地位に移動されました。IANAメディアタイプの登録が非歴史的ドキュメントを確実に指していることを確認するために、このドキュメントは、[RFC4288]に基づくアプリケーション/PKCS10メディアタイプとIANA登録の定義で[RFC2986]を更新します。

The text for Section 2 is adapted from Section 3.7 of [RFC2311].

セクション2のテキストは、[RFC2311]のセクション3.7から採用されています。

1.1. Requirements Terminology

1.1. 要件用語

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

「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。

2. Creating a Certification Request

2. 認定リクエストの作成

A typical application that allows a user to generate cryptographic information has to submit that information to a Certification Authority (CA), who transforms it into a certificate. PKCS #10 [RFC2986] describes a syntax for certification requests.

ユーザーが暗号化情報を生成できるようにする典型的なアプリケーションは、その情報を認証機関（CA）に提出する必要があります。PKCS＃10 [RFC2986]は、認証要求の構文を説明しています。

The details of certification requests and the process of obtaining a certificate are beyond the scope of this memo. Instead, only the format of data used in application/pkcs10 is defined.

認証要求の詳細と証明書を取得するプロセスは、このメモの範囲を超えています。代わりに、アプリケーション/PKCS10で使用されるデータの形式のみが定義されています。

2.1. Format of the application/pkcs10 Body

2.1. アプリケーション/PKCS10ボディの形式

PKCS #10 defines the ASN.1 type CertificationRequest for use in submitting a certification request. For transfer to a CA, this abstract syntax needs to be encoded and identified in a unique manner. When the media type application/pkcs10 is used, the body MUST be a CertificationRequest.

PKCS＃10は、認定リクエストの送信に使用するためのASN.1タイプの認定Requestを定義します。CAに転送するには、この抽象的な構文をユニークな方法でエンコードして識別する必要があります。メディアタイプのアプリケーション/PKCS10を使用する場合、ボディは認定リケストでなければなりません。

A robust application SHOULD output Distinguished Encoding Rules (DER), but allow Basic Encoding Rules (BER) or DER on input.

堅牢なアプリケーションは、識別ルール（der）を出力する必要がありますが、入力に基本的なエンコードルール（BER）またはderを許可します。

Data produced by BER or DER is 8-bit, but some transports are limited to 7-bit data. In such cases, a suitable 7-bit transfer encoding MUST be applied; in MIME-compatible transports, the base64 encoding [RFC4648] SHOULD be used with application/pkcs10, although any 7-bit transfer encoding may work.

BERまたはDERによって作成されたデータは8ビットですが、一部のトランスポートは7ビットデータに制限されています。そのような場合、適切な7ビット転送エンコードを適用する必要があります。MIME互換トランスポートでは、7ビット転送エンコードは機能しますが、Application/PKCS10でエンコード[RFC4648]を使用する必要があります。

2.2. Sending and Receiving an application/pkcs10 Body Part

2.2. アプリケーション/PKCS10ボディパーツの送信と受信

For sending a certificate-signing request, the application/pkcs10 message format MUST be used to convey a PKCS #10 certificate-signing request. Note that for sending certificates and Certificate Revocation Lists (CRLs) without any signed content, the application/pkcs7-mime message format MUST be used to convey a degenerate PKCS #7 signedData "certs-only" message [RFC5751].

証明書署名要求を送信するには、PKCS＃10証明書署名リクエストを伝えるために、アプリケーション/PKCS10メッセージ形式を使用する必要があります。署名されたコンテンツなしで証明書と証明書の取り消しリスト（CRL）を送信するには、アプリケーション/PKCS7-MIMEメッセージ形式を使用して、縮退したPKCS＃7 SignedData "CERTS-ONLY"メッセージ[RFC5751]を伝える必要があることに注意してください。

To send an application/pkcs10 body, the application generates the cryptographic information for the user. The details of the cryptographic information are beyond the scope of this memo.

アプリケーション/PKCS10本体を送信するには、アプリケーションがユーザーの暗号化情報を生成します。暗号化情報の詳細は、このメモの範囲を超えています。

Step 1. The cryptographic information is placed within a PKCS #10 CertificationRequest.

ステップ1.暗号化情報は、PKCS＃10認定Request内に配置されます。

Step 2. The CertificationRequest is encoded according to BER or DER (preferred, DER).

ステップ2.認証Requestは、BERまたはDER（優先、DER）に従ってエンコードされます。

Step 3. As a typical step, the encoded CertificationRequest is also base64 encoded so that it is 7-bit data suitable for transfer in ESMTP. This then becomes the body of an application/pkcs10 body part.

ステップ3.典型的なステップとして、エンコードされた認証Requestもbase64エンコードされているため、ESMTPでの転送に適した7ビットデータです。これは、アプリケーション/PKCS10ボディの部分の本体になります。

The result might look like this:

結果は次のようになるかもしれません：

      Content-Type: application/pkcs10; name=smime.p10
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename=smime.p10

rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6 7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 0GhIGfHfQbnj756YT64V

A typical application only needs to send a certification request. It is a Certification Authority that has to receive and process the request. The steps for recovering the CertificationRequest from the message are straightforward but are not presented here. The procedures for processing the certification request are beyond the scope of this document.

一般的なアプリケーションは、認定リクエストを送信するだけです。これは、リクエストを受信して処理する必要がある認証当局です。メッセージから認定リケストを回復する手順は簡単ですが、ここでは示されていません。認証要求を処理する手順は、このドキュメントの範囲を超えています。

3. IANA Considerations

3. IANAの考慮事項

IANA has updated the registration for the application/pkcs10 media subtype in the Application Media Types registry using the filled-in template from BCP 13 [RFC4288] given below.

IANAは、以下に示すBCP 13 [RFC4288]の埋め合わせテンプレートを使用して、アプリケーションメディアタイプレジストリのアプリケーション/PKCS10メディアサブタイプの登録を更新しました。

3.1. Registration of Media Subtype application/pkcs10

3.1. メディアサブタイプアプリケーション/PKCS10の登録

The media subtype for a PKCS #10 certification request is application/pkcs10.

PKCS＃10認定要求のメディアサブタイプはApplication/PKCS10です。

Type name: application

タイプ名：アプリケーション

Subtype name: pkcs10

サブタイプ名：PKCS10

Required parameters: None

必要なパラメーター：なし

Optional parameters: None

オプションのパラメーター：なし

Encoding considerations: binary; see Section 2.

考慮事項のエンコード：バイナリ;セクション2を参照してください。

Security considerations:

セキュリティ上の考慮事項：

Clients use a certification request to request that a Certification Authority certify a public key. The certification request is digitally signed. Also, see Section 6.

クライアントは認定リクエストを使用して、認定機関が公開鍵を認定することを要求します。認定リクエストはデジタル署名されています。また、セクション6を参照してください。

Interoperability considerations: See Section 2.

相互運用性の考慮事項：セクション2を参照してください。

Published specification: This specification.

公開された仕様：この仕様。

Applications which use this media type:

このメディアタイプを使用するアプリケーション：

Applications that support PKCS #10 certification requests [RFC2986].

PKCS＃10認定要求をサポートするアプリケーション[RFC2986]。

Additional information:

追加情報：

Magic number(s): None File extension(s): .p10 Macintosh File Type Code(s):

マジック番号：なしファイル拡張子：.p10 Macintoshファイルタイプコード：.p10：

      Person & email address to contact for further information:
        Sean Turner <turners@ieca.com>

Restrictions on usage: none

使用に関する制限：なし

      Author: Sean Turner <turners@ieca.com>

Intended usage: COMMON

意図された使用法：共通

Change controller: The IESG

Change Controller：IESG

4. Security Considerations

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

The security considerations of [RFC2986] and [RFC5751] apply; no new security considerations are introduced by this document.

[RFC2986]および[RFC5751]のセキュリティ上の考慮事項が適用されます。このドキュメントでは、新しいセキュリティ上の考慮事項は紹介されていません。

5. Acknowledgements

5. 謝辞

I wish to thank the authors of RFC 2311, Steve Dusse, Paul Hoffman, Blake Ramsdell, Laurence Lundblade, and Lisa Repka.

RFC 2311、Steve Dusse、Paul Hoffman、Blake Ramsdell、Laurence Lundblade、Lisa Repkaの著者に感謝したいと思います。

I would also like to thank Bjoern Hoehrmann for his review of the media subtype application.

また、メディアサブタイプアプリケーションのレビューについてBjoern Hoehrmannに感謝します。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC2986] Nystrom, M. and B. Kaliski, "PKCS #10: Certification Request Syntax Specification Version 1.7", RFC 2986, November 2000.

[RFC2986] Nystrom、M。およびB. Kaliski、「PKCS＃10：認定要求構文仕様バージョン1.7」、RFC 2986、2000年11月。

[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.

[RFC4288] Freed、N。およびJ. Klensin、「メディアタイプの仕様と登録手順」、BCP 13、RFC 4288、2005年12月。

[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, October 2006.

[RFC4648] Josefsson、S。、「Base16、Base32、およびBase64データエンコーディング」、RFC 4648、2006年10月。

[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.

[RFC5751] Ramsdell、B。およびS. Turner、「Secure/Multipurpose Internet Mail Extensions（S/MIME）バージョン3.2メッセージ仕様」、RFC 5751、2010年1月。

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

[X.690] ITU-T推奨X.690（2002）|ISO/IEC 8825-1：2002。情報技術-ASN.1エンコーディングルール：基本エンコードルール（BER）、標準エンコーディングルール（CER）、および区別エンコードルール（DER）の仕様。

6.2. Informative References

6.2. 参考引用

[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, March 1998.

[RFC2311] Dusse、S.、Hoffman、P.、Ramsdell、B.、Lundblade、L。、およびL. Repka、「S/Mimeバージョン2メッセージ仕様」、RFC 2311、1998年3月。

[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message Specification", RFC 2633, June 1999.

[RFC2633] Ramsdell、B.、ed。、「S/Mimeバージョン3メッセージ仕様」、RFC 2633、1999年6月。

Author's Address

著者の連絡先

Sean Turner IECA, Inc. 3057 Nutley Street, Suite 106 Fairfax, VA 22031 USA

Sean Turner IECA、Inc。3057 Nutley Street、Suite 106 Fairfax、VA 22031 USA

   EMail: turners@ieca.com