RFC4630 日本語訳
4630 Update to DirectoryString Processing in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL)Profile. R. Housley, S. Santesson. August 2006. (Format: TXT=12539 bytes) (Obsoleted by RFC5280) (Updates RFC3280) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group R. Housley
Request for Comments: 4630 Vigil Security
Updates: 3280 S. Santesson
Category: Standards Track Microsoft
August 2006
Housleyがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4630の不寝番セキュリティアップデート: 3280秒間Santessonカテゴリ: 標準化過程マイクロソフト2006年8月
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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.
このドキュメントはインターネットX.509公開鍵暗号基盤CertificateとCertificate Revocation List(CRL)プロフィールのDirectoryStringの取り扱いをアップデートします。(プロフィールはRFC3280で発表されます)。 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. 序論…2 2. 用語…2 3. RFC3280、セクション4.1.2に.4をアップデートしてください: 発行人…2 4. RFC3280、セクション4.1.2に.6をアップデートしてください: かけます。3 5. RFC3280、セクション4.2.1に.7をアップデートしてください: 対象の代替名…4 6. セキュリティ問題…4 7. 標準の参照…5
Housley & Santesson Standards Track [Page 1] RFC 4630 DirectoryString Update to RFC 3280 August 2006
RFC4630DirectoryStringが2006年8月にRFC3280にアップデートするHousley&Santesson標準化過程[1ページ]
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.
RFC3280[PKIX1]が発行された時に、国際的な人物セットがどのように支えられるべきであるかは、非常に不明瞭でした。 実装経験と展開経験で、画像ははるかにあいまいでなくなりました。 RFC3280へのこのアップデートは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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[STDWORDS]で説明されるように本書では解釈されることであるべきですか?
3. Update to RFC 3280, Section 4.1.2.4: Issuer
3. RFC3280、セクション4.1.2に.4をアップデートしてください: 発行人
In Section 4.1.2.4, RFC 3280 says:
セクション4.1.2では、.4、RFC3280は言います:
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の選択と定義されます。 [RFC2279]をコード化するUTF8Stringは都合のよいコード化と、すべて、2003年12月31日がDirectoryString(以下に述べられるのを除いた)のUTF8Stringコード化を使用しなければならなかった後に発行された証明書です。 それら自身のを含む分類名を作成するとき、その日付まで、CAsを従わせるのは以下のオプションから選ばれなければなりません:
(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として表されるかもしれません。 そして
(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)が満たされているなら、カリフォルニアは、UTF8Stringとしてストリングを表すのをまだ選んでいるかもしれません。
Housley & Santesson Standards Track [Page 2] RFC 4630 DirectoryString Update to RFC 3280 August 2006
RFC4630DirectoryStringが2006年8月にRFC3280にアップデートするHousley&Santesson標準化過程[2ページ]
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) CAsは、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、対象の分野がそうしなければならないと述べるように、非空の分類名がコード化にかかわらず対象のカリフォルニアによって発行されたすべての証明書の発行人分野のコンテンツに合っていて、居住されてください。
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は後方の互換性、およびSHOULD NOTのために含まれています。新しい対象のための証明書のために、使用されます。 しかしながら、これらのタイプは名前が以前に確立された証明書で使用されるかもしれません。 これらのタイプで証明書を受け取るために準備されていて、ユーザSHOULDを証明してください。
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.
さらに、多くのレガシー実装が、ISO8859-1文字集合(Latin1String)[ISO8859-1]でコード化された名前をサポートしますが、TeletexStringとしてそれらにタグ付けをします。 TeletexStringはISO8859-1より大きい文字集合をコード化しますが、それは何人かのキャラクタを異なってコード化します。 実装SHOULD、両方のencodingsを扱うように用意してください。
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の選択と定義されます。 このプロフィールに従うCAsは1つの例外があるDirectoryStringのPrintableStringかUTF8Stringコード化のどちらかを使用しなければなりません。 属性がコード化されている状態でCAsが以前にTeletexStringを使用することで発行人分野がある証明書を発行したとき、BMPString、またはUniversalString、カリフォルニアが、後方の互換性を保存するのにDirectoryStringのこれらのencodingsを使用し続けるかもしれません。
4. Update to RFC 3280, Section 4.1.2.6: Subject
4. RFC3280、セクション4.1.2に.6をアップデートしてください: 対象
In Section 4.1.2.6, RFC 3280 says:
セクション4.1.2では、.6、RFC3280は言います:
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タイプNameと定義されます。 この分野のための実装要件が発行人分野と定義されたものである、(セクション4.1 .2 .4)。 タイプDirectoryStringの属性値をコード化するとき、発行人分野への符号化規則を実装しなければなりません。
Housley & Santesson Standards Track [Page 3] RFC 4630 DirectoryString Update to RFC 3280 August 2006
RFC4630DirectoryStringが2006年8月にRFC3280にアップデートするHousley&Santesson標準化過程[3ページ]
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タイプNameと定義されます。 この分野のための実装要件が発行人分野と定義されたものである、(セクション4.1 .2 .4)。 このプロフィールに従うCAsは1つの例外があるDirectoryStringのPrintableStringかUTF8Stringコード化のどちらかを使用しなければなりません。 属性がコード化されている状態でCAsが以前にTeletexStringを使用することで対象の分野がある証明書を発行したとき、BMPString、またはUniversalString、カリフォルニアが、同じ対象が後方の互換性を保存するのに新しい証明書でDirectoryStringのこれらのencodingsを使用し続けるかもしれません。
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. RFC3280、セクション4.2.1に.7をアップデートしてください: 対象の代替名
In Section 4.2.1.7, RFC 3280 says:
セクション4.2.1では、.7、RFC3280は言います:
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 MUST。いつ、発行人名前欄によって定義されるようにもののカリフォルニアによって公認されたそれぞれの対象実体において、ユニークであってくださいか。 カリフォルニアは同じDNと共に同じ対象の実体に1通以上の証明書を発行するかもしれません。
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 MUST、発行人名前欄によって定義されるようにもののカリフォルニアによって公認されたそれぞれの対象の実体において、ユニークであってください。 カリフォルニアは同じDNと共に同じ対象の実体に1通以上の証明書を発行するかもしれません。
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
ストリングが内部の表現から視覚表現まで写像されるとき、2個の異なったストリングには時々、同じであるか同様の視覚表現があるでしょう。 これは多くの異なった理由で起こることができます、同様のglyphsの使用と落ち着いた性格の使用を含んでいて(e+としてのそのようなものは'U+00 9ユーロ、韓国人と等しいです'。
Housley & Santesson Standards Track [Page 4] RFC 4630 DirectoryString Update to RFC 3280 August 2006
RFC4630DirectoryStringが2006年8月にRFC3280にアップデートするHousley&Santesson標準化過程[4ページ]
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.
落ち着いた性格、およびある言語の子音結合の上の母音、) この状況の結果、間に異なった名前に目視比較をする人々は、事実上、同じでないときに、それらが同じであると考えるかもしれません。 また、人々は1個のストリングを別のものに間違えるかもしれません。 証明書と信用パーティーの発行人は、ともにこの状況を知る必要があります。
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.、ポーク、W.、フォード、W.、および一人で生活して、「インターネットX.509公開鍵暗号基盤証明書と証明書失効リスト(CRL)は輪郭を描く」D.、RFC3280(2002年4月)。
[STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[STDWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
Authors' Addresses
作者のアドレス
Russell Housley Vigil Security, LLC 918 Spring Knoll Drive Herndon, VA 20170 USA
ラッセルHousley不寝番セキュリティ、スプリング小山Driveハーンドン、LLC918ヴァージニア20170米国
EMail: housley@vigilsec.com
メール: housley@vigilsec.com
Stefan Santesson Microsoft Tuborg Boulevard 12 2900 Hellerup Denmark
ステファンSantessonマイクロソフトTuborg Boulevard12 2900Hellerupデンマーク
EMail: stefans@microsoft.com
メール: stefans@microsoft.com
Housley & Santesson Standards Track [Page 5] RFC 4630 DirectoryString Update to RFC 3280 August 2006
RFC4630DirectoryStringが2006年8月にRFC3280にアップデートするHousley&Santesson標準化過程[5ページ]
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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はこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Housley & Santesson Standards Track [Page 6]
Housley&Santesson標準化過程[6ページ]
一覧
スポンサーリンク
