idnits 2.17.00 (12 Aug 2021) /tmp/idnits53928/draft-ietf-pkix-rfc5280-clarifications-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5280, updated by this document, for RFC5378 checks: 2005-04-15) -- 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 (October 31, 2012) is 3482 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT P. Yee 3 Intended Status: Proposed Standard AKAYLA 4 Updates: 5280 (if approved) October 31, 2012 5 Expires: May 4, 2013 7 Updates to the Internet X.509 Public Key Infrastructure 8 Certificate and Certificate Revocation List (CRL) Profile 9 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as 19 Internet-Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/1id-abstracts.html 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html 32 Copyright and License Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Abstract 49 This document updates RFC 5280, the Internet X.509 Public Key 50 Infrastructure Certificate and Certificate Revocation List (CRL) 51 Profile. This document changes the set of acceptable encoding 52 methods for the explicitText field of the user notice policy 53 qualifier and clarifies the rules for converting internationalized 54 domain name labels to ASCII. This document also provides some 55 clarifications on the use of self-signed certificates, trust anchors, 56 and some updated security considerations. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Update to RFC 5280, Section 3.2: Certification Paths and 63 Trust . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 3. Update to RFC 5280, Section 4.2.1.4: Certificate Policies . . 3 65 4. Update to RFC 5280, Section 6.2: Using the Path Validation 66 Algorithm . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 5. Update to RFC 5280, Section 7.3: Internationalized Domain 68 Names in Distinguished Names . . . . . . . . . . . . . . . . . 5 69 6. Security Considerations . . . . . . . . . . . . . . . . . . . 5 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 7 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 7 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 75 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 77 1. Introduction 79 This document updates the Internet X.509 Public Key Infrastructure 80 Certificate and Certificate Revocation List (CRL) Profile [RFC5280]. 82 This document makes a recommendation that self-signed certificates 83 used to convey trust anchor data be marked as CA certificates, which 84 is not always current practice. 86 The use of self-signed certificates as trust anchors in Section 6.2 87 is clarified. While it is optional to use additional information in 88 these certificates in the path validation process, [RFC5937] is noted 89 as providing guidance in that regard. 91 The acceptable and unacceptable encodings for the explicitText field 92 of the user notice policy qualifier are updated to bring them in line 93 with existing practice. 95 The Section 7.3 rules for ASCII encoding of Internationalized Domain 96 Names (IDN) as Distinguished Names are aligned with the rules in 97 Section 7.2 which govern IDN encoding as GeneralNames. 99 In light of some observed attacks [Prins], the Security 100 Considerations now give added depth to the consequences of CA key 101 compromise. This section additionally notes that collision 102 resistance is not a required property of one-way hash functions when 103 used to generate key identifiers. 105 1.1. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 2. Update to RFC 5280, Section 3.2: Certification Paths and Trust 113 Add the following paragraph to the end of RFC 5280, Section 3.2: 115 | Consistent with Section 3.4.61 of X.509 (11/2008) [X.509] we note 116 | that use of self-issued certificates and self-signed certificates 117 | issued by other than CAs are outside the scope of this specification. 118 | Thus, for example, a web server or client might generate a self- 119 | signed certificate to identify itself. These certificates, and how a 120 | relying party uses them to authenticate asserted identities, are 121 | both outside the scope of RFC 5280. 123 3. Update to RFC 5280, Section 4.2.1.4: Certificate Policies 125 RFC 5280, Section 4.2.1.4, the tenth paragraph says: 127 | An explicitText field includes the textual statement directly in 128 | the certificate. The explicitText field is a string with a 129 | maximum size of 200 characters. Conforming CAs SHOULD use the 130 | UTF8String encoding for explicitText, but MAY use IA5String. 131 | Conforming CAs MUST NOT encode explicitText as VisibleString or 132 | BMPString. The explicitText string SHOULD NOT include any control 133 | characters (e.g., U+0000 to U+001F and U+007F to U+009F). When 134 | the UTF8String encoding is used, all character sequences SHOULD be 135 | normalized according to Unicode normalization form C (NFC) [NFC]. 137 This paragraph is replaced with: 139 | An explicitText field includes the textual statement directly in 140 | the certificate. The explicitText field is a string with a 141 | maximum size of 200 characters. Conforming CAs SHOULD use the 142 | UTF8String encoding for explicitText. VisibleString or BMPString 143 | are acceptable but less preferred alternatives. Conforming CAs 144 | MUST NOT encode explicitText as IA5String. The explicitText 145 | string SHOULD NOT include any control characters (e.g., U+0000 to 146 | U+001F and U+007F to U+009F). When the UTF8String or BMPString 147 | encoding is used, all character sequences SHOULD be normalized 148 | according to Unicode normalization form C (NFC) [NFC]. 150 4. Update to RFC 5280, Section 6.2: Using the Path Validation Algorithm 152 RFC 5280, Section 6.2, the third paragraph says: 154 | Where a CA distributes self-signed certificates to specify trust 155 | anchor information, certificate extensions can be used to specify 156 | recommended inputs to path validation. For example, a policy 157 | constraints extension could be included in the self-signed 158 | certificate to indicate that paths beginning with this trust anchor 159 | should be trusted only for the specified policies. Similarly, a name 160 | constraints extension could be included to indicate that paths 161 | beginning with this trust anchor should be trusted only for the 162 | specified name spaces. The path validation algorithm presented in 163 | Section 6.1 does not assume that trust anchor information is provided 164 | in self-signed certificates and does not specify processing rules for 165 | additional information included in such certificates. 166 | Implementations that use self-signed certificates to specify trust 167 | anchor information are free to process or ignore such information. 169 This paragraph is replaced with: 171 | Where a CA distributes self-signed certificates to specify trust 172 | anchor information, certificate extensions can be used to specify 173 | recommended inputs to path validation. For example, a policy 174 | constraints extension could be included in the self-signed 175 | certificate to indicate that paths beginning with this trust anchor 176 | should be trusted only for the specified policies. Similarly, a name 177 | constraints extension could be included to indicate that paths 178 | beginning with this trust anchor should be trusted only for the 179 | specified name spaces. The path validation algorithm presented 180 | in Section 6.1 does not assume that trust anchor information is 181 | provided in self-signed certificates and does not specify processing 182 | rules for additional information included in such certificates. 183 | However, [RFC5914] defines several formats for representing trust 184 | anchor information, including self-signed certificates, and [RFC5937] 185 | provides an example of how such information may be used to initialize 186 | the path validation inputs. Implementations are free to make use of 187 | any additional information that is included in a trust anchor 188 | representation, or to ignore such information. 190 5. Update to RFC 5280, Section 7.3: Internationalized Domain Names in 191 Distinguished Names 193 RFC 5280, Section 7.3, the first paragraph says: 195 | Domain Names may also be represented as distinguished names using 196 | domain components in the subject field, the issuer field, the 197 | subjectAltName extension, or the issuerAltName extension. As with 198 | the dNSName in the GeneralName type, the value of this attribute is 199 | defined as an IA5String. Each domainComponent attribute represents a 200 | single label. To represent a label from an IDN in the distinguished 201 | name, the implementation MUST perform the "ToASCII" label conversion 202 | specified in Section 4.1 of RFC 3490. The label SHALL be considered 203 | a "stored string". That is, the AllowUnassigned flag SHALL NOT be 204 | set. 206 This paragraph is replaced with: 208 | Domain Names may also be represented as distinguished names using 209 | domain components in the subject field, the issuer field, the 210 | subjectAltName extension, or the issuerAltName extension. As with 211 | the dNSName in the GeneralName type, the value of this attribute is 212 | defined as an IA5String. Each domainComponent attribute represents a 213 | single label. To represent a label from an IDN in the distinguished 214 | name, the implementation MUST perform the "ToASCII" label conversion 215 | specified in Section 4.1 of RFC 3490 with the UseSTD3ASCIIRules flag 216 | set. The label SHALL be considered a "stored string". That is, the 217 | AllowUnassigned flag SHALL NOT be set. The conversion process is the 218 | same as is performed in step 4 in Section 7.2. 220 6. Security Considerations 222 This document modifies the Security Considerations section of RFC 223 5280 as follows. The fifth paragraph of the Security Considerations 224 section of RFC 5280 says: 226 | The protection afforded private keys is a critical security factor. 227 | On a small scale, failure of users to protect their private keys will 228 | permit an attacker to masquerade as them or decrypt their personal 229 | information. On a larger scale, compromise of a CA's private signing 230 | key may have a catastrophic effect. If an attacker obtains the 231 | private key unnoticed, the attacker may issue bogus certificates and 232 | CRLs. Existence of bogus certificates and CRLs will undermine 233 | confidence in the system. If such a compromise is detected, all 234 | certificates issued to the compromised CA MUST be revoked, preventing 235 | services between its users and users of other CAs. Rebuilding after 236 | such a compromise will be problematic, so CAs are advised to 237 | implement a combination of strong technical measures (e.g., tamper- 238 | resistant cryptographic modules) and appropriate management 239 | procedures (e.g., separation of duties) to avoid such an incident. 241 This paragraph is replaced with: 243 | The protection afforded private keys is a critical security factor. 244 | On a small scale, failure of users to protect their private keys will 245 | permit an attacker to masquerade as them or decrypt their personal 246 | information. On a larger scale, compromise of a CA's private signing 247 | key may have a catastrophic effect. 248 | 249 | If an attacker obtains the private key of a CA unnoticed, the 250 | attacker may issue bogus certificates and CRLs. Even if an attacker 251 | is unable to obtain a copy of a CA's private key, the attacker may be 252 | able to issue bogus certificates and CRLs by making unauthorized use 253 | of the CA's workstation or of an RA's workstation. Such an attack 254 | may be the result of an attacker obtaining unauthorized access to the 255 | workstation, either locally or remotely, or may be the result of 256 | inappropriate activity by an insider. Existence of bogus 257 | certificates and CRLs will undermine confidence in the system. Among 258 | many other possible attacks, the attacker may issue bogus 259 | certificates that have the same subject names as legitimate 260 | certificates in order impersonate legitimate certificate subjects. 261 | This could include bogus CA certificates in which the subject names 262 | in the bogus certificates match the names under which legitimate CAs 263 | issue certificates and CRLs. This would allow the attacker to issue 264 | bogus certificates and CRLs that have the same issuer names, and 265 | possibly the same serial numbers, as certificates and CRLs issued by 266 | legitimate CAs. 268 The following text is added to the end of the Security Considerations 269 section of 5280: 271 One-way hash functions are commonly used to generate key identifier 272 values (AKI and SKI), e.g., as described in Sections 4.1.1 and 4.1.2. 273 However, none of the security properties of such functions are required 274 for this context. 276 7. IANA Considerations 278 This document has no actions for IANA. 280 8. References 282 8.1. Normative References 284 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 285 Requirement Levels", BCP 14, RFC 2119, March 1997. 287 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 288 Housley, R., and W. Polk, "Internet X.509 Public Key 289 Infrastructure Certificate and Certificate Revocation 290 List (CRL) Profile", RFC 5280, May 2008. 292 [RFC5914] Housley, R., Ashmore, S., and C. Wallace, "Trust Anchor 293 Format", RFC 5914, June 2010. 295 [X.509] ITU-T Recommendation X.509 (2008) | ISO/IEC 9594-8:2008, 296 Information Technology - Open systems interconnection - 297 The Directory: Public-key and attribute certificate 298 frameworks 300 8.2. Informative References 302 [RFC5937] Ashmore, S. and C. Wallace, "Using Trust Anchor 303 Constraints during Certification Path Processing", 304 RFC 5937, August 2010. 306 [Prins] Prins, J. R., "DigiNotar Certificate Authority breach 307 'Operation Black Tulip'", September, 2011, 308 312 [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-1:2002, 313 Information Technology - Abstract Syntax Notation One 314 (ASN.1): Specification of basic notation. 316 [NFC] Davis, M. and M. Duerst, "Unicode Standard Annex #15: 317 Unicode Normalization Forms", October 2006, 318 . 320 9. Acknowledgements 322 David Cooper is acknowledged for his fine work in editing previous 323 versions of this document. 325 Author's Address 327 Peter E. Yee 328 AKAYLA 329 7150 Moorland Drive 330 Clarksville, MD 21029 331 USA 332 EMail: peter@akayla.com