summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc4630.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc4630.txt')
-rw-r--r--doc/rfc/rfc4630.txt339
1 files changed, 339 insertions, 0 deletions
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]
+