idnits 2.17.1 draft-ietf-pkix-cert-utf8-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 220. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 229. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 236. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 242. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. -- The draft header indicates that this document updates RFC3280, but the abstract doesn't seem to directly say this. It does mention RFC3280 though, so this could be OK. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year (Using the creation date from RFC3280, updated by this document, for RFC5378 checks: 1999-10-26) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2006) is 6583 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC 2279' is mentioned on line 69, but not defined ** Obsolete undefined reference: RFC 2279 (Obsoleted by RFC 3629) == Missing Reference: 'ISO 8859-1' is mentioned on line 105, but not defined ** Obsolete normative reference: RFC 3280 (ref. 'PKIX1') (Obsoleted by RFC 5280) Summary: 7 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PKIX Working Group R. Housley (Vigil Security) 3 Updates: 3280 (once approved) S. Santesson (Microsoft) 4 Expires October 2006 April 2006 6 Update to DirectoryString Processing in the 7 Internet X.509 Public Key Infrastructure 8 Certificate and Certificate Revocation List (CRL) Profile 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than a "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/1id-abstracts.html 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html 34 Abstract 36 This document updates the handling of DirectoryString in the Internet 37 X.509 Public Key Infrastructure Certificate and Certificate 38 Revocation List (CRL) Profile, which is published in RFC 3280. The 39 use of UTF8String and PrintableString are the preferred encoding. 40 The requirement for exclusive use of UTF8String after December 31, 41 2003 is removed. 43 1. Introduction 45 At the time that RFC 3280 [PKIX1] was published, it was very unclear 46 how international character sets ought to be supported. 47 Implementation experience and deployment experience have made the 48 picture much less fuzzy. This update to RFC 3280 aligns the document 49 with this experience and the direction of the IETF PKIX Working 50 Group. 52 The use of UTF8String and PrintableString are the preferred encoding. 53 UTF8String provides support for international character sets, and 54 PrintableString preserves support for the vast bulk of the 55 certificates that have already been deployed. 57 2. Terminology 59 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 60 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 61 document are to be interpreted as described in RFC 2119 [STDWORDS]. 63 3. Update to RFC 3280, Section 4.1.2.4: Issuer 65 In section 4.1.2.4, RFC 3280 says: 67 | The DirectoryString type is defined as a choice of PrintableString, 68 | TeletexString, BMPString, UTF8String, and UniversalString. The 69 | UTF8String encoding [RFC 2279] is the preferred encoding, and all 70 | certificates issued after December 31, 2003 MUST use the UTF8String 71 | encoding of DirectoryString (except as noted below). Until that 72 | date, conforming CAs MUST choose from the following options when 73 | creating a distinguished name, including their own: 74 | 75 | (a) if the character set is sufficient, the string MAY be 76 | represented as a PrintableString; 77 | 78 | (b) failing (a), if the BMPString character set is sufficient the 79 | string MAY be represented as a BMPString; and 80 | 81 | (c) failing (a) and (b), the string MUST be represented as a 82 | UTF8String. If (a) or (b) is satisfied, the CA MAY still choose 83 | to represent the string as a UTF8String. 84 | 85 | Exceptions to the December 31, 2003 UTF8 encoding requirements are as 86 | follows: 87 | 88 | (a) CAs MAY issue "name rollover" certificates to support an 89 | orderly migration to UTF8String encoding. Such certificates would 90 | include the CA's UTF8String encoded name as issuer and the old 91 | name encoding as subject, or vice-versa. 92 | 93 | (b) As stated in section 4.1.2.6, the subject field MUST be 94 | populated with a non-empty distinguished name matching the 95 | contents of the issuer field in all certificates issued by the 96 | subject CA regardless of encoding. 97 | 98 | The TeletexString and UniversalString are included for backward 99 | compatibility, and SHOULD NOT be used for certificates for new 100 | subjects. However, these types MAY be used in certificates where the 101 | name was previously established. Certificate users SHOULD be 102 | prepared to receive certificates with these types. 103 | 104 | In addition, many legacy implementations support names encoded in the 105 | ISO 8859-1 character set (Latin1String) [ISO 8859-1] but tag them as 106 | TeletexString. TeletexString encodes a larger character set than ISO 107 | 8859-1, but it encodes some characters differently. Implementations 108 | SHOULD be prepared to handle both encodings. 110 This block of text is replaced with: 112 | The DirectoryString type is defined as a choice of PrintableString, 113 | TeletexString, BMPString, UTF8String, and UniversalString. CAs 114 | conforming to this profile MUST use either the PrintableString or 115 | UTF8String encoding of DirectoryString, with one exception. When 116 | CAs have previously issued certificates with issuer fields with 117 | attributes encoded using the TeletexString, BMPString, or 118 | UniversalString, then the CA MAY continue to use these encodings 119 | of the DirectoryString to preserve the backward compatibility. 121 4. Update to RFC 3280, Section 4.1.2.6: Subject 123 In section 4.1.2.6, RFC 3280 says: 125 | The subject name field is defined as the X.501 type Name. 126 | Implementation requirements for this field are those defined for the 127 | issuer field (section 4.1.2.4). When encoding attribute values of 128 | type DirectoryString, the encoding rules for the issuer field MUST be 129 | implemented. 131 This block of text is replaced with: 133 | The subject name field is defined as the X.501 type Name. 134 | Implementation requirements for this field are those defined 135 | for the issuer field (section 4.1.2.4). CAs conforming to 136 | this profile MUST use either the PrintableString or UTF8String 137 | encoding of DirectoryString, with one exception. When CAs 138 | have previously issued certificates with subject fields with 139 | with attributes encoded using the TeletexString, BMPString, or 140 | UniversalString, then the CA MAY continue to use these encodings 141 | of the DirectoryString in new certificates for the same subject 142 | to preserve backward compatibility. 143 | 144 | Since name comparison assumes that attribute values encoded in 145 | different types (e.g., PrintableString and UTF8String) are 146 | assumed to represent different strings, any name components that 147 | appear in both the subject field and the issuer field SHOULD 148 | use the same encoding throughout the certification path. 150 5. Update to RFC 3280, Section 4.2.1.7: Subject Alternative Name 152 In section 4.2.1.7, RFC 3280 says: 154 | When the subjectAltName extension contains a DN in the directoryName, 155 | the DN MUST be unique for each subject entity certified by the one CA 156 | as defined by the issuer name field. A CA MAY issue more than one 157 | certificate with the same DN to the same subject entity. 159 This block of text is replaced with: 161 | When the subjectAltName extension contains a DN in the directoryName, 162 | the same encoding preference as in 4.1.2.4. The DN MUST be unique 163 | for each subject entity certified by the one CA as defined by the 164 | issuer name field. A CA MAY issue more than one certificate with 165 | the same DN to the same subject entity. 167 6. Security Considerations 169 The replacement text is much clearer. The direction is much less 170 prone to implementation error. Also, the use of consistent encoding 171 for name components will ensure that name constraints work as 172 expected. 174 7. Normative References 176 [PKIX1] Housley, R., Polk, W., Ford, W. and D. Solo, "Internet 177 X.509 Public Key Infrastructure Certificate and 178 Certificate Revocation List (CRL) Profile", RFC 3280, 179 April 2002. 181 [STDWORDS] S. Bradner, "Key words for use in RFCs to Indicate 182 Requirement Levels", BCP 14, RFC 2119, March 1997. 184 8. IANA Considerations 186 None. Please remove this section prior to publication as an RFC. 188 Authors' Addresses 190 Russell Housley 191 Vigil Security, LLC 192 918 Spring Knoll Drive 193 Herndon, VA 20170 194 USA 196 EMail: housley(at)vigilsec.com 198 Stefan Santesson 199 Microsoft 200 Tuborg Boulevard 12 201 2900 Hellerup 202 Denmark 204 EMail: stefans(at)microsoft.com 206 Copyright Statement 208 Copyright (C) The Internet Society (2006). 210 This document is subject to the rights, licenses and restrictions 211 contained in BCP 78, and except as set forth therein, the authors 212 retain all their rights. 214 This document and the information contained herein are provided on an 215 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 216 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 217 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 218 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 219 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 220 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 222 The IETF takes no position regarding the validity or scope of any 223 Intellectual Property Rights or other rights that might be claimed to 224 pertain to the implementation or use of the technology described in 225 this document or the extent to which any license under such rights 226 might or might not be available; nor does it represent that it has 227 made any independent effort to identify any such rights. Information 228 on the procedures with respect to rights in RFC documents can be 229 found in BCP 78 and BCP 79. 231 Copies of IPR disclosures made to the IETF Secretariat and any 232 assurances of licenses to be made available, or the result of an 233 attempt made to obtain a general license or permission for the use of 234 such proprietary rights by implementers or users of this 235 specification can be obtained from the IETF on-line IPR repository at 236 http://www.ietf.org/ipr. 238 The IETF invites any interested party to bring to its attention any 239 copyrights, patents or patent applications, or other proprietary 240 rights that may cover technology that may be required to implement 241 this standard. Please address the information to the IETF at 242 ietf-ipr@ietf.org.