doc: Add RFC documents

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]
+