From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc4630.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc4630.txt (limited to 'doc/rfc/rfc4630.txt') diff --git a/doc/rfc/rfc4630.txt b/doc/rfc/rfc4630.txt new file mode 100644 index 0000000..1e62bc3 --- /dev/null +++ b/doc/rfc/rfc4630.txt @@ -0,0 +1,339 @@ + + + + + + +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 + +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. + +Copyright Notice + + Copyright (C) The Internet Society (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. + +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 + + + + + + + + + +Housley & Santesson Standards Track [Page 1] + +RFC 4630 DirectoryString Update to RFC 3280 August 2006 + + +1. Introduction + + 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. + + 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. + +2. Terminology + + 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]. + +3. Update to RFC 3280, Section 4.1.2.4: Issuer + + In Section 4.1.2.4, RFC 3280 says: + + 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: + + (a) if the character set is sufficient, the string MAY be + represented as a PrintableString; + + (b) failing (a), if the BMPString character set is sufficient + the string MAY be represented as a BMPString; and + + (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. + + + + + + + + + +Housley & Santesson Standards Track [Page 2] + +RFC 4630 DirectoryString Update to RFC 3280 August 2006 + + + Exceptions to the December 31, 2003 UTF8 encoding requirements + are as follows: + + (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. + + (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. + + 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. + + 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. + + 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. + +4. Update to RFC 3280, Section 4.1.2.6: Subject + + In Section 4.1.2.6, RFC 3280 says: + + 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. + + + + +Housley & Santesson Standards Track [Page 3] + +RFC 4630 DirectoryString Update to RFC 3280 August 2006 + + + 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. + + 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. + +5. Update to RFC 3280, Section 4.2.1.7: Subject Alternative Name + + In Section 4.2.1.7, RFC 3280 says: + + 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. + + 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. + +6. Security Considerations + + The use of consistent encoding for name components will ensure that + the name constraints specified in [PKIX1] work as expected. + + 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 + + + +Housley & Santesson Standards Track [Page 4] + +RFC 4630 DirectoryString Update to RFC 3280 August 2006 + + + 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. + +7. Normative References + + [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. + + [STDWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +Authors' Addresses + + Russell Housley + Vigil Security, LLC + 918 Spring Knoll Drive + Herndon, VA 20170 + USA + + EMail: housley@vigilsec.com + + + Stefan Santesson + Microsoft + Tuborg Boulevard 12 + 2900 Hellerup + Denmark + + EMail: stefans@microsoft.com + + + + + + + + + + + + + + + + +Housley & Santesson Standards Track [Page 5] + +RFC 4630 DirectoryString Update to RFC 3280 August 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (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. + + 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. + + 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. + + 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. + +Acknowledgement + + Funding for the RFC Editor function is provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Housley & Santesson Standards Track [Page 6] + -- cgit v1.2.3