RFC 4630 - Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc4630
タイトル : RFC 4630 - インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルのDirectoryString処理の更新
翻訳編集 : 自動生成

[要約] RFC 4630は、X.509公開鍵基盤証明書と証明書失効リスト（CRL）プロファイルのDirectoryString処理の更新を提供しています。このRFCの目的は、DirectoryStringデータ型の処理方法を改善し、証明書とCRLの相互運用性を向上させることです。

Network Working Group                                         R. Housley
Request for Comments: 4630                                Vigil Security
Updates: 3280                                               S. Santesson
Category: Standards Track                                      Microsoft
                                                             August 2006

Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile

インターネットX.509公開鍵インフラストラクチャ証明書および証明書失効リスト（CRL）プロファイルのDirectoryString処理の更新

Status of This Memo

本文書の状態

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

Abstract

概要

This document updates the handling of DirectoryString in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile, which is published in RFC 3280. The use of UTF8String and PrintableString are the preferred encoding. The requirement for exclusive use of UTF8String after December 31, 2003 is removed.

このドキュメントでは、RFC 3280で公開されているインターネットX.509公開キー基盤の証明書と証明書失効リスト（CRL）プロファイルのDirectoryStringの処理を更新します。UTF8StringとPrintableStringを使用することをお勧めします。 2003年12月31日以降、UTF8Stringを排他的に使用する必要はなくなりました。

Table of Contents

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Update to RFC 3280, Section 4.1.2.4: Issuer .....................2
   4. Update to RFC 3280, Section 4.1.2.6: Subject ....................3
   5. Update to RFC 3280, Section 4.2.1.7: Subject
      Alternative Name ................................................4
   6. Security Considerations .........................................4
   7. Normative References ............................................5

1. Introduction

1. はじめに

At the time that RFC 3280 [PKIX1] was published, it was very unclear how international character sets ought to be supported. Implementation experience and deployment experience have made the picture much less fuzzy. This update to RFC 3280 aligns the document with this experience and the direction of the IETF PKIX Working Group.

RFC 3280 [PKIX1]が公開された時点では、国際文字セットがどのようにサポートされるべきかは非常に不明確でした。実装の経験と展開の経験により、状況ははるかに曖昧ではなくなりました。 RFC 3280に対するこの更新では、ドキュメントをこの経験とIETF PKIXワーキンググループの方向性に合わせています。

The use of UTF8String and PrintableString are the preferred encoding. UTF8String provides support for international character sets, and PrintableString preserves support for the vast bulk of the certificates that have already been deployed.

UTF8StringとPrintableStringを使用することをお勧めします。 UTF8Stringは国際的な文字セットのサポートを提供し、PrintableStringはすでに展開されている証明書の大部分のサポートを保持します。

2. Terminology

2. 用語

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 RFC 2119 [STDWORDS].

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

3. Update to RFC 3280, Section 4.1.2.4: Issuer

3. RFC 3280のセクション4.1.2.4への更新：発行者

In Section 4.1.2.4, RFC 3280 says:

セクション4.1.2.4では、RFC 3280は次のように述べています。

The DirectoryString type is defined as a choice of PrintableString, TeletexString, BMPString, UTF8String, and UniversalString. The UTF8String encoding [RFC 2279] is the preferred encoding, and all certificates issued after December 31, 2003 MUST use the UTF8String encoding of DirectoryString (except as noted below). Until that date, conforming CAs MUST choose from the following options when creating a distinguished name, including their own:

DirectoryStringタイプは、PrintableString、TeletexString、BMPString、UTF8String、およびUniversalStringの選択肢として定義されます。 UTF8Stringエンコーディング[RFC 2279]が推奨されるエンコーディングであり、2003年12月31日以降に発行されたすべての証明書は、DirectoryStringのUTF8Stringエンコーディングを使用する必要があります（下記を除く）。その日まで、準拠するCAは、識別名を作成するときに、次のオプションから選択する必要があります。

(a) if the character set is sufficient, the string MAY be represented as a PrintableString;

（a）文字セットが十分である場合、文字列はPrintableStringとして表すことができます。

(b) failing (a), if the BMPString character set is sufficient the string MAY be represented as a BMPString; and

（b）失敗（a）、BMPString文字セットで十分な場合は、文字列をBMPStringとして表現できます（MAY）。そして

(c) failing (a) and (b), the string MUST be represented as a UTF8String. If (a) or (b) is satisfied, the CA MAY still choose to represent the string as a UTF8String.

（c）（a）および（b）に失敗した場合、文字列はUTF8Stringとして表現する必要があります。（a）または（b）が満たされている場合でも、CAは文字列をUTF8Stringとして表すことを選択できます（MAY）。

Exceptions to the December 31, 2003 UTF8 encoding requirements are as follows:

2003年12月31日のUTF8エンコーディング要件の例外は次のとおりです。

(a) CAs MAY issue "name rollover" certificates to support an orderly migration to UTF8String encoding. Such certificates would include the CA's UTF8String encoded name as issuer and the old name encoding as subject, or vice-versa.

（a）CAは、UTF8Stringエンコーディングへの正常な移行をサポートするために「名前のロールオーバー」証明書を発行する場合があります。このような証明書には、発行者としてCAのUTF8Stringエンコードされた名前、サブジェクトとして古い名前のエンコード、またはその逆が含まれます。

(b) As stated in section 4.1.2.6, the subject field MUST be populated with a non-empty distinguished name matching the contents of the issuer field in all certificates issued by the subject CA regardless of encoding.

（b）セクション4.1.2.6で述べたように、サブジェクトフィールドには、エンコーディングに関係なく、サブジェクトCAによって発行されたすべての証明書の発行者フィールドの内容と一致する空でない識別名を入力する必要があります。

The TeletexString and UniversalString are included for backward compatibility, and SHOULD NOT be used for certificates for new subjects. However, these types MAY be used in certificates where the name was previously established. Certificate users SHOULD be prepared to receive certificates with these types.

TeletexStringとUniversalStringは下位互換性のために含まれており、新しいサブジェクトの証明書には使用しないでください。ただし、これらのタイプは、名前が以前に確立されている証明書で使用される場合があります。証明書ユーザーは、これらのタイプの証明書を受け取る準備ができている必要があります。

In addition, many legacy implementations support names encoded in the ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as TeletexString. TeletexString encodes a larger character set than ISO 8859-1, but it encodes some characters differently. Implementations SHOULD be prepared to handle both encodings.

さらに、多くの従来の実装では、ISO 8859-1文字セット（Latin1String）[ISO 8859-1]でエンコードされた名前をサポートしていますが、TeletexStringとしてタグ付けしています。 TeletexStringはISO 8859-1よりも大きな文字セットをエンコードしますが、一部の文字は異なる方法でエンコードします。実装は、両方のエンコーディングを処理できるように準備する必要があります。

This block of text is replaced with the following:

このテキストブロックは、次のものに置き換えられます。

The DirectoryString type is defined as a choice of PrintableString, TeletexString, BMPString, UTF8String, and UniversalString. CAs conforming to this profile MUST use either the PrintableString or UTF8String encoding of DirectoryString, with one exception. When CAs have previously issued certificates with issuer fields with attributes encoded using the TeletexString, BMPString, or UniversalString, the CA MAY continue to use these encodings of the DirectoryString to preserve the backward compatibility.

DirectoryStringタイプは、PrintableString、TeletexString、BMPString、UTF8String、およびUniversalStringの選択肢として定義されます。このプロファイルに準拠するCAは、1つの例外を除いて、DirectoryStringのPrintableStringまたはUTF8Stringエンコーディングを使用する必要があります。 CAが以前に、TeletexString、BMPString、またはUniversalStringを使用してエンコードされた属性を持つ発行者フィールドを持つ証明書を発行した場合、CAは下位互換性を維持するためにDirectoryStringのこれらのエンコーディングを引き続き使用できます。

4. Update to RFC 3280, Section 4.1.2.6: Subject

4. RFC 3280のセクション4.1.2.6への更新：件名

In Section 4.1.2.6, RFC 3280 says:

セクション4.1.2.6では、RFC 3280は次のように述べています。

The subject name field is defined as the X.501 type Name. Implementation requirements for this field are those defined for the issuer field (section 4.1.2.4). When encoding attribute values of type DirectoryString, the encoding rules for the issuer field MUST be implemented.

サブジェクト名フィールドは、X.501タイプの名前として定義されます。このフィールドの実装要件は、発行者フィールドに対して定義されたものです（セクション4.1.2.4）。タイプDirectoryStringの属性値をエンコードする場合、発行者フィールドのエンコードルールを実装する必要があります。

This block of text is replaced with the following:

このテキストブロックは、次のものに置き換えられます。

The subject name field is defined as the X.501 type Name. Implementation requirements for this field are those defined for the issuer field (Section 4.1.2.4). CAs conforming to this profile MUST use either the PrintableString or UTF8String encoding of DirectoryString, with one exception. When CAs have previously issued certificates with subject fields with attributes encoded using the TeletexString, BMPString, or UniversalString, the CA MAY continue to use these encodings of the DirectoryString in new certificates for the same subject to preserve backward compatibility.

サブジェクト名フィールドは、X.501タイプの名前として定義されます。このフィールドの実装要件は、発行者フィールド（セクション4.1.2.4）に対して定義されたものです。このプロファイルに準拠するCAは、1つの例外を除いて、DirectoryStringのPrintableStringまたはUTF8Stringエンコーディングを使用する必要があります。 CAが以前に、TeletexString、BMPString、またはUniversalStringを使用してエンコードされた属性を持つサブジェクトフィールドを持つ証明書を発行した場合、CAは下位互換性を維持するために、同じサブジェクトのDirectoryStringのこれらのエンコーディングを引き続き使用できます。

Since name comparison assumes that attribute values encoded in different types (e.g., PrintableString and UTF8String) are assumed to represent different strings, any name components that appear in both the subject field and the issuer field SHOULD use the same encoding throughout the certification path.

名前の比較では、異なる型（PrintableStringやUTF8Stringなど）でエンコードされた属性値は異なる文字列を表すと想定されているため、サブジェクトフィールドと発行者フィールドの両方に表示される名前コンポーネントは、証明書パス全体で同じエンコードを使用する必要があります（SHOULD）。

5. Update to RFC 3280, Section 4.2.1.7: Subject Alternative Name

5. RFC 3280のセクション4.2.1.7への更新：サブジェクトの別名

In Section 4.2.1.7, RFC 3280 says:

セクション4.2.1.7では、RFC 3280は次のように述べています。

When the subjectAltName extension contains a DN in the directoryName, the DN MUST be unique for each subject entity certified by the one CA as defined by the issuer name field. A CA MAY issue more than one certificate with the same DN to the same subject entity.

subjectAltName拡張のdirectoryNameにDNが含まれている場合、DNは、発行者名フィールドで定義されている1つのCAによって認証された各サブジェクトエンティティに対して一意である必要があります。 CAは、同じサブジェクトエンティティに対して同じDNを持つ複数の証明書を発行する場合があります。

This block of text is replaced with the following:

このテキストブロックは、次のものに置き換えられます。

When the subjectAltName extension contains a DN in the directoryName, the encoding preference is defined in Section 4.1.2.4. The DN MUST be unique for each subject entity certified by the one CA as defined by the issuer name field. A CA MAY issue more than one certificate with the same DN to the same subject entity.

subjectAltName拡張機能がdirectoryNameにDNを含む場合、エンコーディング設定はセクション4.1.2.4で定義されます。 DNは、発行者名フィールドで定義されているように、1つのCAによって認証されたサブジェクトエンティティごとに一意である必要があります。 CAは、同じサブジェクトエンティティに対して同じDNを持つ複数の証明書を発行する場合があります。

6. Security Considerations

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

The use of consistent encoding for name components will ensure that the name constraints specified in [PKIX1] work as expected.

名前コンポーネントに一貫したエンコーディングを使用すると、[PKIX1]で指定された名前の制約が期待どおりに機能することが保証されます。

When strings are mapped from internal representations to visual representations, sometimes two different strings will have the same or similar visual representations. This can happen for many different reasons, including the use of similar glyphs and use of composed characters (such as e + ' equaling U+00E9, the Korean composed characters, and vowels above consonant clusters in certain languages). As a result of this situation, people doing visual comparisons between to different names may think they are the same when in fact they are not. Also, people may mistake one string for another. Issuers of certificates and relying parties both need to be aware of this situation.

文字列が内部表現から視覚表現にマッピングされると、2つの異なる文字列が同じまたは類似の視覚表現を持つ場合があります。これは、類似したグリフの使用や、合成文字の使用（e + 'がU + 00E9に等しい、韓国語の合成文字、特定の言語の子音クラスタの上の母音など）など、さまざまな理由で発生します。この状況の結果として、異なる名前を視覚的に比較している人は、実際は同じではないのに、同じものだと思うかもしれません。また、人々はある文字列を別の文字列と間違えるかもしれません。証明書の発行者と証明書利用者の両方がこの状況を認識する必要があります。

7. Normative References

7. 引用文献

[PKIX1] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.

[PKIX1] Housley、R.、Polk、W.、Ford、W。、およびD. Solo、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile」、RFC 3280、2002年4月。

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

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

Authors' Addresses

著者のアドレス

Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA

Russell Housley Vigil Security、LLC 918 Spring Knoll Drive Herndon、VA 20170アメリカ

   EMail: housley@vigilsec.com

Stefan Santesson Microsoft Tuborg Boulevard 12 2900 Hellerup Denmark

Stefan Santesson Microsoft Tuborg Boulevard 12 2900 Hellerupデンマーク

   EMail: stefans@microsoft.com

Full Copyright Statement

完全な著作権表示

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

このドキュメントは、BCP 78に含まれる権利、ライセンス、および制限の対象であり、そこに記載されている場合を除き、著者はすべての権利を保持します。

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。

Intellectual Property

知的財産

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).

RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。