idnits 2.17.1 draft-kent-trans-extended-validation-cert-checks-01.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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([CABF-EV], [RFC6962-bis]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: 2. A certificate issued to a Subscriber MUST include the certificatePolicies extension. It MAY or MAY NOT be marked CRITICAL. It MUST contain one or more policy identifiers associated with an extended validation policy of the Issuer. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 3. The Subject's Jurisdiction of Incorporation, Registration, or Place of Business MUST not be in any country with which the laws of the CA's jurisdiction prohibit doing business. This suggestion is derived from Section 11.12.2 (1) (B) of [CABF-EV]. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 7. The Subject Jurisdiction of Incorporation or Registration Fields MUST not contain information that is not relevant to the level of the Incorporating Agency or Registration Agency. This requirement is derived from Section 9.2.5 of [CABF-EV]. -- The document date (June 17, 2015) is 3229 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: 'RFC6962-bis' is mentioned on line 13, but not defined ** Obsolete undefined reference: RFC 6962 (Obsoleted by RFC 9162) == Missing Reference: 'CT RFC' is mentioned on line 109, but not defined == Missing Reference: 'CT-RFC' is mentioned on line 127, but not defined == Missing Reference: 'RFC-DV' is mentioned on line 145, but not defined == Missing Reference: 'RFC5280' is mentioned on line 269, but not defined == Unused Reference: 'I-D.ietf-trans-rfc6962-bis' is defined on line 374, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 379, but no explicit reference was found in the text == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-07 ** Downref: Normative reference to an Experimental draft: draft-ietf-trans-rfc6962-bis (ref. 'I-D.ietf-trans-rfc6962-bis') Summary: 3 errors (**), 0 flaws (~~), 13 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Public Notary Transparency S. Kent 3 Internet-Draft BBN Technologies 4 Intended status: Standards Track R. Andrews 5 Expires: December 19, 2015 Symantec 6 June 17, 2015 8 Syntactic and Semantic Checks for Extended Validation Certificates 9 draft-kent-trans-extended-validation-cert-checks-01 11 Abstract 13 Certificate Transparency (CT) [RFC6962-bis] is a system for publicly 14 logging the existence of X.509 certificates as they are issued or 15 observed. The logging mechanism allows anyone to audit certification 16 authority (CA) activity and detect the issuance of "suspect" 17 certificates. Detecting mis-issuance of certificates is a primary 18 goal of CT. 20 A certificate is considered to be mis-issued if it fails to meet 21 syntactic and/or semantic criteria associated with the type of 22 certificate being issued. Mis-issuance can be detected by CT log 23 servers, whose feedback to a CA could prompt the CA to not issue a 24 suspect certificate. (Preventing the mis-issuance of such a 25 certificate is preferable to issuing it and detecting it later.) 27 Compliant CT log servers could offer these checks to a CA submitting 28 a pre-certificate to be logged. These checks are intended to be used 29 in an environment in which CAs optionally assert the version of the 30 EV guidelines to which the submitted pre-certificate purportedly 31 conforms. Log servers would then perform the checks of supported 32 [CABF-EV] versions and include the CA's assertion and the log 33 server's result in its Signed Certificate Timestamp (SCT). 35 Monitors can also perform checks to detect suspect certificates on 36 behalf of certificate Subjects. Checks performed by a Monitor also 37 serve to double check log servers that claim to have checked a 38 certificate, to identify those that are not doing the checks 39 properly, e.g., because of errors, compromise, or conspiracy. This 40 provides Monitors and CT clients with additional information when 41 choosing which logs to use. 43 Status of This Memo 45 This Internet-Draft is submitted in full conformance with the 46 provisions of BCP 78 and BCP 79. 48 Internet-Drafts are working documents of the Internet Engineering 49 Task Force (IETF). Note that other groups may also distribute 50 working documents as Internet-Drafts. The list of current Internet- 51 Drafts is at http://datatracker.ietf.org/drafts/current/. 53 Internet-Drafts are draft documents valid for a maximum of six months 54 and may be updated, replaced, or obsoleted by other documents at any 55 time. It is inappropriate to use Internet-Drafts as reference 56 material or to cite them other than as "work in progress." 58 This Internet-Draft will expire on December 19, 2015. 60 Copyright Notice 62 Copyright (c) 2015 IETF Trust and the persons identified as the 63 document authors. All rights reserved. 65 This document is subject to BCP 78 and the IETF Trust's Legal 66 Provisions Relating to IETF Documents 67 (http://trustee.ietf.org/license-info) in effect on the date of 68 publication of this document. Please review these documents 69 carefully, as they describe your rights and restrictions with respect 70 to this document. Code Components extracted from this document must 71 include Simplified BSD License text as described in Section 4.e of 72 the Trust Legal Provisions and are provided without warranty as 73 described in the Simplified BSD License. 75 Table of Contents 77 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 78 2. Syntactic Checks . . . . . . . . . . . . . . . . . . . . . . 3 79 2.1. EV Certificate Field Syntax Requirements . . . . . . . . 4 80 2.2. Certificate Extension Syntax Requirements . . . . . . . . 5 81 2.3. Certificate Public Key: same as for DV certificates . . . 6 82 2.4. Certificate Signature: same as for DV certificates . . . 6 83 3. Semantic Verification of an EV Certificate . . . . . . . . . 6 84 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 85 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 86 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 87 6.1. Informative References . . . . . . . . . . . . . . . . . 8 88 6.2. Normative References . . . . . . . . . . . . . . . . . . 8 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 91 1. Introduction 93 The following checks are extracted from the CA Browser Forum (CABF) 94 document "Guidelines for the Issuance and Management of Extended 95 Validation Certificates" version 1.5.2 [CABF-EV]. (If a new version 96 of the CABF guidelines is created that alters any of the checks 97 described below, a new CCID value MUST be assigned.) These 98 requirements are used to define what constitutes mis-issuance of a 99 certificate in the context of certificate transparency (CT) for Web 100 PKI certificates. The CABF guidelines from which these checks are 101 derived include many aspects of CA operation that are outside of the 102 scope of CT-based detection of certificate mis-issuance, i.e., they 103 impose requirements that could not be verified by a Monitor examining 104 certificate logs. Hence this document was created to provide an 105 enumeration of EV certificate checks for the Web PKI CT context. 107 The checks enumerated below are to be applied to any certificate 108 submitted to a log with the Certificate Class ID (CCID) value of 2 109 (see Section X of [CT RFC]). Note that "root" CA certificates are 110 not subject to verification against these criteria. Each log 111 maintains a list of the root CAs for which it is willing to accept 112 SCT generation requests. This implies that the log operator has 113 already determined that these CAs, and their corresponding self- 114 signed certificates, are acceptable. A subordinate CA certificate 115 will be checked only if it is submitted as the target of an SCT. If 116 a subordinate CA certificate appears as part of a chain submitted for 117 SCT generation, but is not the last certificate (the End-Entity or EE 118 certificate) in that chain, the checks enumerated below should be 119 applied to the EE certificate but not the subordinate CA certificate. 121 [CABF-EV] describes both syntactic and semantic requirements for 122 certificate issuance. This document deals primarily with syntactic 123 checks, but also describes how semantic checks are to be performed. 124 A log MAY perform the syntactic checks enumerated below if a 125 certificate is submitted with a CCID value of 2. If a log performs 126 these syntactic checks, it adds the SSV value appropriate for the 127 outcome of the check (see Section Z of [CT-RFC]). 129 Monitors SHOULD perform both the syntactic and semantic checks 130 described below for all certificates that they protect, and which are 131 marked with a CCID value of 2. 133 2. Syntactic Checks 135 An X.509 certificate consists of a set of fields (all but two of 136 which are mandatory), a set of optional extensions, a public key and 137 a signature. This section defines the syntactic requirements imposed 138 on the certificate fields. The following sections deal with 139 extensions, public keys, and signatures. 141 2.1. EV Certificate Field Syntax Requirements 143 [CABF-EV] establishes syntactic requirements for EV certificates. 144 Many of these requirements are the same as for DV certificates. The 145 syntactic checks for DV certificates appear in [RFC-DV]. To avoid 146 possible inconsistency between that RFC and this one, when the 147 syntactic check for an EV certificate is the same as for a DV 148 certificate, the phrase "same as for DV certificates" is inserted. 150 1. Version number: same as for DV certificates 152 2. certificate serial number: same as for DV certificates (Note 153 that this is not the Subject Registration Number attribute 154 discussed below.) 156 3. signature: same as for DV certificates 158 4. issuer: same as for DV certificates 160 5. validity: The maximum validity interval is 27 months. 162 6. subject: A certificate MAY contain a NULL Subject name. If it 163 contains a non-null Subject name: 165 A. It MUST contain the organizationName attribute. This 166 requirement is derived from Section 9.2.1 of [CABF-EV]. 168 B. It MAY contain a commonName attribute. If this attribute is 169 present, it MUST contain a Fully-Qualified Domain Name (not 170 a wildcard name). This requirement is derived from 171 Section 9.2.3 of [CABF-EV]. 173 C. It MUST contain the businessCategory attribute, and the 174 value of that attribute must match one of the four allowed 175 values. This requirement is derived from Section 9.2.4 of 176 [CABF-EV]. 178 D. It MUST contain the jurisdictionCountryName attribute as 179 specified in [CABF-EV]. This requirement is derived from 180 Section 9.2.5 of [CABF-EV]. (Note that this attribute is 181 NOT defined in [RFC5280].) 183 E. It MAY contain the jurisdictionLocalityName as specified in 184 [CABF-EV]. This requirement is derived from Section 9.2.5 185 of [CABF-EV]. (Note that this attribute is NOT defined in 186 [RFC5280].) 188 F. It MAY contain the jurisdictionStateOrProvinceName as 189 specified in [CABF-EV]. This requirement is derived from 190 Section 9.2.5 of [CABF-EV]. (Note that this attribute is 191 NOT defined in [RFC5280].) 193 G. It MUST contain the Subject Registration Number (also known 194 as Subject:serialNumber) attribute. This requirement is 195 derived from Section 9.2.6 of [CABF-EV]. 197 H. The countryName, stateOrProvinceName and localityName MUST 198 be present and populated with values consistent with the 199 syntax defined in [RFC5280]. This requirement is derived 200 from Section 9.2.7 of [CABF-EV]. 202 I. The localityName, streetAddress, and postalCode attributes 203 MAY be present and if present, MUST be populated with values 204 consistent with the syntax defined in [RFC5280]. This 205 requirement is derived from Section 9.2.7 of [CABF-EV]. 207 J. Other Subject attributes, as specified in Appendix A of 208 [RFC5280], MAY appear. These attributes MUST NOT contain 209 metadata such as '.', '-', or ' ' (i.e. space) characters. 210 This requirement is derived from section 9.2.8 of [CABF-EV]. 212 7. subjectPublicKeyInfo: same as for DV certificates. 214 8. issuerUniqueId: same as for DV certificates. 216 9. subjectUniqueId: same as for DV certificates. 218 10. signatureAlgorithm: same as for DV certificates. 220 11. signatureValue: same as for DV certificates. 222 2.2. Certificate Extension Syntax Requirements 224 An X.509 v3 certificate may contain extensions. [CABF-EV] mandates 225 the presence of several extensions, and imposes requirements on their 226 content. 228 1. The subjectAltName extension: same requirements as for DV 229 certificates, except Wildcard FQDNs are not permitted. This 230 requirement is derived from Section 9.2.2 of [CABF-EV]. 232 2. A certificate issued to a Subscriber MUST include the 233 certificatePolicies extension. It MAY or MAY NOT be marked 234 CRITICAL. It MUST contain one or more policy identifiers 235 associated with an extended validation policy of the Issuer. 237 This requirement is derived from Section 9.3.2 and 9.3.5 of 238 [CABF-EV]. There are two commonly cited references for EV OIDs: 239 http://en.wikipedia.org/wiki/Extended_Validation_Certificate and 240 https://code.google.com/p/chromium/codesearch#chromium/src/net/ 241 cert/ev_root_ca_metadata.cc&sq=package:chromium 243 A log or Monitor checking a certificate that purports to be an EV 244 certificate SHOULD use these references to verify that it 245 contains an appropriate policy OID. 247 This extension MUST contain certificatePolicies:policyIdentifier, 248 certificatePolicies:policyQualifiers:policyQualifierId (id-qt 1) 249 and certificatePolicies:policyQualifiers:qualifier:cPSuri (the 250 URL for the CA's CPS). This requirement is derived from 251 Section 9.7 paragraph (3) of [CABF-EV]. 253 3. basicConstraints: same as for DV certificates. 255 4. The cRLDistributionPoints extension MUST be present in a CA 256 certificate. It MUST NOT be marked critical and it MUST contain 257 an HTTP URL. This extension MUST be present in a Subscriber 258 certificate if the certificate does not specify an OCSP responder 259 location in the authorityInformationAccess extension. 261 5. keyUsage extension: same as for DV certificates. 263 6. authorityInformationAccess extension: same as for DV certificates 265 7. extendedKeyUsage extension: same as for DV certificates. 267 8. nameConstraints extension: same as for DV certificates 269 9. Other extensions defined in [RFC5280]: same as for DV 270 certificates. 272 2.3. Certificate Public Key: same as for DV certificates 274 2.4. Certificate Signature: same as for DV certificates 276 3. Semantic Verification of an EV Certificate 278 The fundamental semantic check that a Monitor MUST perform is to 279 detect bogus certificates on behalf of its clients. A client of a 280 Monitor provides the Monitor with a set of certificates that have 281 been issued to the client. (Note that a client may have multiple 282 certificates issued to its name, and thus there is not a one-to-one 283 mapping between names and public keys.) These certificates MUST be 284 acquired in a secure fashion, not using certificate discovery 285 protocols or relying on databases operated by a CA or RA. Armed with 286 this information, a Monitor can examine every log entry to determine 287 if it contains the same Subject or subjectAltName as that of a 288 client. If a log entry matches either of these names, and if it 289 contains a public key distinct from the set of keys provided by the 290 Subject, this is evidence of mis-issuance. (Note that a Monitor 291 cannot rely on a log operated by a CA, to detect mis-issuance by that 292 CA.) If a Monitor identifies what appears to be a bogus certificate, 293 it notifies the client. The means by which notification is effected 294 is not specified. 296 [CABF-EV] imposes a number of requirements on certificate issuance 297 that cannot be verified without access to reference information for 298 the certificate Subject, information about the CA hierarchy, or 299 information about internal procedures of the CA. Monitors are not 300 presumed to be able to perform such checks. Examples of such checks 301 appear in Sections 7, 8, 9.1, and 9.2.4 of [CABF-EV]. 303 Additional semantic checks SHOULD be performed by a Monitor, if it 304 has access to the requisite information. These are enumerated below. 306 1. A certificate issued to a subordinate CA that is not controlled 307 by a Root CA MUST NOT contain the anyPolicy policy identifier. 308 This requirement is derived from section 9.3.4 (1) of [CABF-EV]. 309 Verification of this requirement requires knowledge of CA 310 organizational relationships and thus may not be available to all 311 Monitors. 313 2. A certificate issued to a subordinate CA that is not controlled 314 by the issuing CA MUST include one or more policy identifiers 315 defined by the issuing CA that explicitly identify the EV 316 Policies that are implemented by the Subordinate CA. This 317 requirement is derived from section 9.3.4 (1) of [CABF-EV]. If 318 the extension contains any of the OIDs noted explicitly above, it 319 is acceptable. Verification of this requirement requires 320 knowledge of CA organizational relationships and thus may not be 321 available to all Monitors. 323 3. The Subject's Jurisdiction of Incorporation, Registration, or 324 Place of Business MUST not be in any country with which the laws 325 of the CA's jurisdiction prohibit doing business. This 326 suggestion is derived from Section 11.12.2 (1) (B) of [CABF-EV]. 328 4. The Subject's organizationName attribute MUST contain the 329 Subject's full legal organization name as listed in the official 330 records of the Incorporating or Registration Agency in the 331 Subject's Jurisdiction of Incorporation or Registration, although 332 abbreviations are permitted. This requirement is derived from 333 Section 9.2.1 of [CABF-EV]. 335 5. The Domain Names in the subjectAltName extension MUST be owned or 336 controlled by the Subject, or MUST have been owned or controlled 337 by the Subject at the time of certificate issuance. This 338 requirement is derived from Section 9.2.2 of [CABF-EV]. 340 6. The Domain Name in the Subject Common Name field, if present, 341 MUST be owned or controlled by the Subject, MUST have been owned 342 or controlled by the Subject at the time of certificate issuance. 343 This requirement is derived from Section 9.2.2 of [CABF-EV]. 345 7. The Subject Jurisdiction of Incorporation or Registration Fields 346 MUST not contain information that is not relevant to the level of 347 the Incorporating Agency or Registration Agency. This 348 requirement is derived from Section 9.2.5 of [CABF-EV]. 350 8. The Subject Physical Address of Place of Business Fields MUST 351 contain the address of a physical location of the Subject's Place 352 of Business. This requirement is derived from Section 9.2.7 of 353 [CABF-EV]. 355 4. IANA Considerations 357 TBD 359 5. Security Considerations 361 TBD 363 6. References 365 6.1. Informative References 367 [CABF-EV] CA/Browser Forum, "Guidelines For The Issuance And 368 Management Of Extended Validation Certificates, Version 369 1.5.2", October 2014, . 372 6.2. Normative References 374 [I-D.ietf-trans-rfc6962-bis] 375 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 376 Stradling, "Certificate Transparency", draft-ietf-trans- 377 rfc6962-bis-07 (work in progress), March 2015. 379 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 380 Requirement Levels", BCP 14, RFC 2119, March 1997. 382 Authors' Addresses 384 Stephen Kent 385 BBN Technologies 386 10 Moulton St. 387 Cambridge, MA 02138 388 US 390 Email: kent@bbn.com 392 Rick Andrews 393 Symantec 394 350 Ellis Street 395 Mountain View, CA 94043 396 US 398 Email: Rick_Andrews@symantec.com