Network Working Group R. Housley
Request for Comments: 4630 Vigil Security
Updates: 3280 S. Santesson
Category: Standards Track Microsoft
August 2006
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
更新Internet 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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（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.
本文档更新了在RFC 3280中发布的Internet 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 ....................................................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
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]发布时，还不清楚应该如何支持国际字符集。实施经验和部署经验使情况变得不那么模糊。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保留了对已经部署的大量证书的支持。
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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[STDWORDS]中所述进行解释。
In Section 4.1.2.4, RFC 3280 says:
RFC 3280在第4.1.2.4节中指出：
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类型定义为可打印字符串、电传字符串、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) 如果字符集足够，字符串可以表示为可打印字符串；
(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），CA仍然可以选择将字符串表示为UTF8String。
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节所述，无论采用何种编码方式，必须使用与主体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.
TELETEXTSTRING和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字符集（拉丁字符串）[ISO 8859-1]编码的名称，但将其标记为TeletextString。TELETEXTSTRING编码的字符集比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类型定义为可打印字符串、电传字符串、BMPString、UTF8String和UniversalString的选择。符合此配置文件的CA必须使用DirectoryString的PrintableString或UTF8String编码，但有一个例外。当CA先前已颁发具有使用TeletextString、BMPString或UniversalString编码的属性的颁发者字段的证书时，CA可以继续使用DirectoryString的这些编码来保持向后兼容性。
In Section 4.1.2.6, RFC 3280 says:
RFC 3280在第4.1.2.6节中指出：
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类型的属性值进行编码时，必须实现issuer字段的编码规则。
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必须使用DirectoryString的PrintableString或UTF8String编码，但有一个例外。当CA先前颁发了具有使用TeletextString、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）表示不同的字符串，因此出现在subject字段和issuer字段中的任何名称组件应在整个认证路径中使用相同的编码。
In Section 4.2.1.7, RFC 3280 says:
RFC 3280在第4.2.1.7节中指出：
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时，对于每个由颁发者名称字段定义的CA认证的主题实体，DN必须是唯一的。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必须是唯一的，由发卡机构名称字段定义的一个CA认证。CA可以向同一主体实体颁发多个具有相同DN的证书。
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
当字符串从内部表示映射到视觉表示时，有时两个不同的字符串将具有相同或相似的视觉表示。这可能是由于许多不同的原因造成的，包括使用类似的字形和组合字符（例如，韩国语中的e+'等于U+00E9）
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.
在某些语言中，组合字符和元音位于辅音簇之上）。由于这种情况，人们在对不同的名字进行视觉比较时，可能会认为它们是相同的，而事实上并非如此。此外，人们可能会把一根绳子误认为另一根。证书的发行人和依赖方都需要了解这种情况。
[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公钥基础设施证书和证书撤销列表（CRL）配置文件”，RFC 32802002年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，弗吉尼亚州，邮编20170
EMail: housley@vigilsec.com
EMail: housley@vigilsec.com
Stefan Santesson Microsoft Tuborg Boulevard 12 2900 Hellerup Denmark
Stefan Santesson Microsoft Tuborg大道12 2900号Hellerup丹麦
EMail: stefans@microsoft.com
EMail: stefans@microsoft.com
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（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.
本文件受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秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/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邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。