idnits 2.17.1 draft-kent-trans-domain-validation-cert-checks-02.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-DV], [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. == 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: 5. validity: An EE certificate issued after July 1, 2012 MUST not contain a validity interval longer than 60 months. ([CABF-DV] establishes criteria in Section 9.4.1 that describe the circumstances under which EE certificates may be issued with validity intervals between 39 and 60 months. Since these criteria cannot be evaluated without external knowledge, this RFC adopts the 60-month limit for syntactic checking.) == 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 CA MUST include the certificatePolicies extension. It MAY or MAY NOT be marked CRITICAL. The policyQualifiers field MAY be present, and the policyQualifierId and/or the cPSuri fields may be populated, using the syntax specified in [RFC5280]. This requirement is derived from Appendix B, Section 3.A of [CABF-DV]. -- The document date (December 22, 2015) is 3041 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 112, but not defined == Missing Reference: 'CT-RFC' is mentioned on line 131, but not defined == Missing Reference: 'RC5280' is mentioned on line 152, but not defined == Missing Reference: 'RFC5280' is mentioned on line 356, but not defined == Missing Reference: 'RFC4055' is mentioned on line 250, but not defined == Missing Reference: 'RFC5480' is mentioned on line 250, but not defined == Missing Reference: 'RFC5758' is mentioned on line 250, but not defined == Unused Reference: 'I-D.ietf-trans-rfc6962-bis' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 483, but no explicit reference was found in the text == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-11 ** Downref: Normative reference to an Experimental draft: draft-ietf-trans-rfc6962-bis (ref. 'I-D.ietf-trans-rfc6962-bis') Summary: 3 errors (**), 0 flaws (~~), 15 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: June 24, 2016 Symantec 6 December 22, 2015 8 Syntactic and Semantic Checks for Domain Validation Certificates 9 draft-kent-trans-domain-validation-cert-checks-02 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-DV] 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 June 24, 2016. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 78 2. Syntactic Checks . . . . . . . . . . . . . . . . . . . . . . 3 79 2.1. DV Certificate Field Syntax Requirements . . . . . . . . 4 80 2.2. DV Certificate Extension Syntax Requirements . . . . . . 6 81 2.3. Certificate Public Key . . . . . . . . . . . . . . . . . 8 82 2.3.1. RSA Public Keys . . . . . . . . . . . . . . . . . . . 8 83 2.3.2. DSA Public Keys . . . . . . . . . . . . . . . . . . . 9 84 2.3.3. ECC Public Keys . . . . . . . . . . . . . . . . . . . 9 85 2.4. Certificate Signature . . . . . . . . . . . . . . . . . . 9 86 3. Semantic Verification of a DV Certificate . . . . . . . . . . 9 87 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 10 89 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 6.1. Informative References . . . . . . . . . . . . . . . . . 10 91 6.2. Normative References . . . . . . . . . . . . . . . . . . 11 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 94 1. Introduction 96 The following checks are extracted from the CA Browser Forum (CABF) 97 document "Baseline Requirements for the Issuance and Management of 98 Publicly-Trusted Certificates" version 1_2_3 [CABF-DV]. (If a new 99 version of the CABF guidelines is created that alters any of the 100 checks described below, a new CCID value MUST be assigned.) These 101 requirements are used to define what constitutes mis-issuance of a 102 certificate in the context of certificate transparency (CT) for Web 103 PKI certificates. The CABF guidelines from which these checks are 104 derived include many aspects of CA operation that are outside of the 105 scope of CT-based detection of certificate mis-issuance, i.e., they 106 impose requirements that could not be verified by a Monitor examining 107 certificate logs. Hence this document was created to provide an 108 enumeration of DV certificate checks for the Web PKI CT context. 110 The checks enumerated below are to be applied to any certificate 111 submitted to a log with the Certificate Class ID (CCID) value of 1 112 (see Section X of [CT RFC]). Note that "root" CA certificates are 113 not subject to verification against these criteria. Each log 114 maintains a list of the certificates of CAs (that MUST begin the 115 certificate validation path) for which it is willing to accept SCT 116 generation requests. This implies that the log operator has already 117 determined that these CAs, and their corresponding self-signed 118 certificates, are acceptable.) A subordinate CA certificate will be 119 checked only if it is submitted as the target of an SCT. If a 120 subordinate CA certificate appears as part of a chain submitted for 121 SCT generation, but is not the last certificate (the End-Entity or EE 122 certificate) in that chain, the checks enumerated below are applied 123 to the EE certificate but not the subordinate CA certificate. 125 [CABF-DV] describes both syntactic and semantic requirements for 126 certificate issuance. This document deals primarily with syntactic 127 checks, but also describes how semantic checks are to be performed. 128 A log MAY perform the syntactic checks enumerated below if a 129 certificate is submitted with a CCID value of 1. If a log performs 130 these syntactic checks, it adds the SSV value appropriate for the 131 outcome of the check (see Section Z of [CT-RFC]) to the SCT. 133 Monitors SHOULD perform both the syntactic and semantic checks 134 described below for all certificates that they protect, and which are 135 marked with a CCID value of 1. 137 2. Syntactic Checks 139 An X.509 certificate consists of a set of fields (all but two of 140 which are mandatory), a set of optional extensions, a public key and 141 a signature. This section defines the syntactic requirements imposed 142 on the certificate fields. The following sections deal with 143 extensions, public keys, and signatures. 145 2.1. DV Certificate Field Syntax Requirements 147 1. Version number: The certificate MUST be an X.509 v3 certificate. 148 This requirement is derived from Appendix B of [CABF-DV], where 149 it is explicitly stated for Root and Subordinate CA 150 certificates. Since other portions of [CABF-DV] mandate support 151 for extensions and only v3 certificates can contain extensions 152 [RC5280], this requirement is inferred to apply to EE 153 certificates as well. 155 2. serialNumber: No requirements beyond those imposed by [RFC5280] 156 are mandated by [CABF-DV]. Section 9.6 of [CABF-DV] suggests 157 that a serial number contain at least 20 bits of entropy so the 158 minimum serialNumber length should be 20 bits. 160 3. signature: For any certificate issued after December 31, 2010, 161 the allowed digest algorithms are: SHA-1, SHA-256, SHA-384 or 162 SHA-512. If RSA is used to sign the certificate, the minimum 163 modulus size is 2048 bits. (No requirement is imposed on the 164 public exponent.) If DSA is used to sign the certificate, the 165 following pairs of values are permitted: L= 2048, N= 224 or L= 166 2048, N=256). If the certificate signature is based on ECC 167 (presumably ECDSA), the allowed curves are NIST P-256, P-384 and 168 P-521. To verify that a certificate employs an accepted digest 169 and signature algorithm, one examines the OID contained in this 170 field. OIDs defined in the following RFCs are applicable here: 171 [RFC4055], [RFC5480], and [RFC5758]. (This set of checks does 172 not apply to certificates issued before the date cited above.) 174 4. issuer: The Issuer name MUST contain the countryName attribute 175 and it MUST contain an ISO-3166-1 country code. This 176 requirement is derived from section 9.1.4 of [CABF-DV]. The 177 Issuer name MUST contain the organizationName attribute. This 178 requirement is derived from section 9.1.3 of [CABF-DV]. 180 5. validity: An EE certificate issued after July 1, 2012 MUST not 181 contain a validity interval longer than 60 months. ([CABF-DV] 182 establishes criteria in Section 9.4.1 that describe the 183 circumstances under which EE certificates may be issued with 184 validity intervals between 39 and 60 months. Since these 185 criteria cannot be evaluated without external knowledge, this 186 RFC adopts the 60-month limit for syntactic checking.) 188 6. subject: A certificate MAY contain a NULL Subject name. If it 189 contains a non-null Subject name: 191 A. it MAY contain a commonName attribute. If this attribute is 192 present, it MUST contain a single IP address or Fully- 193 Qualified Domain Name that is one of the values contained in 194 the Certificate's subjectAltName extension. This 195 requirement is derived from section 9.2.2 of [CABF-DV]. 196 Thus verification of this attribute requires comparing 197 values in this attribute against the content of the 198 subjectAltName extension, which MUST be present (see below). 200 B. it MAY contain an organizationalUnitName attribute. This 201 requirement is derived from section 9.2.6 of [CABF-DV]. 203 C. if the name does not contain an organizationName attribute, 204 then the streetAddress attribute MUST NOT be present. If 205 the organizationName attribute is present, the streetAddress 206 attribute MAY be present. This requirement is derived from 207 section 9.2.4b of [CABF-DV]. 209 D. if the name does not contain an organizationName attribute, 210 then the localityName attribute MUST NOT be present. If the 211 organizationName attribute is present, the localityName 212 attribute MAY be present. This requirement is derived from 213 section 9.2.4c of [CABF-DV]. 215 E. if the name does not contain an organizationName attribute, 216 then the stateOrProvinceName attribute MUST NOT be present. 217 If the organizationName attribute is present, and the 218 localityName is absent, then the stateOrProvinceName 219 attribute MUST be present. If the organizationName 220 attribute is present, and the localityName is present, then 221 the stateOrProvinceName attribute MAY be present. This 222 requirement is derived from section 9.2.4d of [CABF-DV]. 224 F. if the name does not contain an organizationName attribute, 225 then the postalCode attribute MUST NOT be present. If the 226 name contains an organizationName attribute, then the 227 postalCode attribute MAY be present. This requirement is 228 derived from section 9.2.4e of [CABF-DV]. 230 G. if the name contains an organizationName attribute, then the 231 countryName attribute MUST be present. If the name does not 232 contain an organizationName attribute, then the countryName 233 attribute MAY be present. This requirement is derived from 234 section 9.2.5 of [CABF-DV]. 236 H. The Subject MAY contain other attributes as specified in 237 Appendix A of [RFC5280]. These attributes MUST NOT contain 238 metadata such as '.', '-', or ' ' (i.e. space) characters. 239 This requirement is derived from section 9.2.8 of [CABF-DV]. 241 7. subjectPublicKeyInfo: If this field contains an RSA public key 242 the minimum modulus size is 2048 bits. (No requirement is 243 imposed on the public exponent.) If it carries a DSA key, the 244 following pairs of values are permitted: L= 2048, N= 224 or L= 245 2048, N=256. If the field conveys an ECC (presumably ECDSA) 246 public key, the allowed curves are NIST P-256, P-384 and P-521. 247 To verify that a certificate employs an accepted digest and 248 signature algorithm, one examines the OID contained in this 249 field. OIDs defined in the following RFCs are applicable here: 250 [RFC4055], [RFC5480], and [RFC5758]. 252 8. issuerUniqueId: This is an optional field (a BIT STRING) in a v3 253 certificate. [CABF-DV] imposes no requirements on this field, 254 so no constraints beyond those in [RFC5280] are applicable. 256 9. subjectUniqueId: This is an optional field (a BIT STRING) in a 257 v3 certificate. [CABF-DV] imposes no requirements on this 258 field, so no constraints beyond those in [RFC5280] are 259 applicable. 261 10. signatureAlgorithm: This field MUST match the signature field 262 contained within the certificate (see # 3 above). 264 11. signatureValue: This field is verified using the public key 265 extracted from the certificate of the Issuer of this 266 certificate, and the algorithms specified in the preceding 267 field. 269 2.2. DV Certificate Extension Syntax Requirements 271 An X.509 v3 certificate may contain extensions. [CABF-DV] mandates 272 the presence of several extensions, and imposes requirements on their 273 content. 275 1. The certificate MUST contain the subjectAltName extension, and 276 that extension MUST contain at least one entry. Each entry MUST 277 be either a dNSName containing a Fully-Qualified Domain Name 278 (FQDN) or an iPAddress. Wildcard FQDNs are permitted. No other 279 entry types are permitted. This requirement is derived from 280 section 9.2.1 of [CABF-DV]. 282 2. A certificate issued to a CA MUST include the certificatePolicies 283 extension. It MAY or MAY NOT be marked CRITICAL. The 284 policyQualifiers field MAY be present, and the policyQualifierId 285 and/or the cPSuri fields may be populated, using the syntax 286 specified in [RFC5280]. This requirement is derived from 287 Appendix B, Section 3.A of [CABF-DV]. 289 A. If this extension contains the OID 2.23.140.1.2.1, then the 290 Subject field MUST NOT contain an organizationName, 291 streetAddress, localityName, stateOrProvinceName, or 292 postalCode attribute. This requirement is derived from 293 section 9.3.1 of [CABF-DV]. 295 B. If this extension contains the OID 2.23.140.1.2.2, then the 296 Subject field MUST contain organizationName, localityName, 297 and countryName attributes. This requirement is derived from 298 section 9.3.1 of [CABF-DV]. ([CABF-DV] also states that the 299 stateOrProvinceName attribute MUST be present, "if 300 applicable". Since the applicability of this attribute 301 cannot be readily determined, this Appendix views the 302 presence of this attribute as optional.) 304 3. The basicConstraints extension MUST be present, marked CRITICAL 305 and the cA flag MUST be set TRUE in a CA certificate. This 306 requirement is derived from Appendix B Section 2.D of [CABF-DV]. 307 The presence of this extension is optional for an EE certificate. 308 If the extension is present in an EE certificate it MUST have the 309 cA flag set to FALSE. (If a certificate does not contain this 310 extension it is presumed to be an EE certificate and MUST be 311 processed as such with regard to all other verification checks.) 313 4. The cRLDistributionPoints extension MUST be present in a CA 314 certificate. It MUST NOT be marked critical and it MUST contain 315 an HTTP URL. This extension is optional for EE certificates, but 316 if present the same syntactic constraints apply. This 317 requirement is derived from Appendix B, Sections 2.B and 3.B of 318 [CABF-DV]. 320 5. The keyUsage extension MUST be present in a CA certificate and it 321 MUST be marked critical. The keyCertSign and cRLSign bits MUST 322 be set. The digitalSignature bit MAY be set as well. The 323 keyUsage extension MAY be present in an EE certificate. If it is 324 present in an EE certificate, the keyCertSign and cRLSign bits 325 MUST NOT be set. These requirements are derived from Appendix B, 326 Section 2.E of [CABF-DV]. 328 6. The authorityInformationAccess extension MAY be present and, if 329 present, MUST NOT be marked CRITICAL and MUST contain 330 accessMethod 1.3.6.1.5.5.7.48.1 and MAY specify accessMethod 331 1.3.6.1.5.5.7.48.2. This requirement is derived from Appendix B, 332 Sections 2.C and 3.C of [CABF-DV]. 334 7. The extKeyUsage extension MAY be present in a CA certificate. If 335 present, it need not be marked CRITICAL. If the extension is 336 present in a CA certificate, and if the certificate contains the 337 nameConstraints extension, then the value id-kp-serverAuth MUST 338 be present. This requirement is derived from Section 9.7 and 339 Appendix B, Section 2.G of [CABF-DV]. The extKeyUsage extension 340 MUST be present in an EE certificate. Either the value id-kp- 341 serverAuth or id-kp-clientAuth or both values MUST be present. 342 id-kp-emailProtection MAY be present. This requirement is 343 derived from Appendix B, Section 3.F of [CABF-DV]. 345 8. The nameConstraints extension MAY appear in CA certificates and 346 need not be marked CRITICAL (contrary to [RFC5280]). If the 347 certificate also contains the extKeyUsage extension and that 348 extension contains the value id-kp-serverAuth, then that 349 extension MUST NOT contain the anyExtendedKeyUsage value in the 350 KeyPurposeId. Moreover, the nameConstraints extension MUST 351 impose constraints on dNSName, iPAddress and DirectoryName name 352 types. Both the permittedSubtrees and excludedSubtrees fields 353 MAY be employed. This requirement is derived from Section 9.7 354 and Appendix B, Section 2.F of [CABF-DV]. 356 9. Other extensions defined in [RFC5280] MAY be present and MUST be 357 marked with respect to criticality as specified therein. 359 2.3. Certificate Public Key 361 2.3.1. RSA Public Keys 363 1. If a subordinate CA certificate contains an RSA public key, and 364 the certificate has a validity period beginning on or before 31 365 Dec 2010 and ending on or before 31 Dec 2013, that key MUST have 366 a minimum modulus size of 1024 bits. If a subordinate CA 367 certificate contains an RSA public key, and the certificate has a 368 validity period beginning after 31 Dec 2010 or ending after 31 369 Dec 2013, that key MUST have a minimum modulus size of 2048 bits. 370 This requirement is derived from Appendix A (2) of [CABF-DV]. 372 2. If an EE certificate contains an RSA public key, and the 373 certificate has a validity period ending on or before 31 Dec 374 2013, that key MUST have a minimum modulus size of 1024 bits. If 375 an EE certificate contains an RSA public key, and the certificate 376 has a validity period ending after 31 Dec 2013, that key MUST 377 have a minimum modulus size of 2048 bits. This requirement is 378 derived from Appendix A (3) of [CABF-DV]. 380 3. The value of the public exponent of an RSA public key MUST be an 381 odd number equal to 3 or more. This requirement is derived from 382 Appendix A (4) of [CABF-DV]. 384 2.3.2. DSA Public Keys 386 1. If a certificate contains a DSA public key, the minimum modulus 387 and divisor size (in bits) MUST be L= 2048, N= 224 or L= 2048, N= 388 256. This requirement is derived from Appendix A (2) and (3) of 389 [CABF-DV]. 391 2. If a certificate contains a DSA public key, the public key MUST 392 include all domain parameters. This requirement is derived from 393 Appendix A (4) of [CABF-DV]. 395 2.3.3. ECC Public Keys 397 1. If a certificate contains an ECC public key, that key MUST employ 398 one of these curves: NIST P-256, P-384, or P-521. This 399 requirement is derived from Appendix A (2) and (3) of [CABF-DV]. 401 2.4. Certificate Signature 403 The certificate's signatureAlgorithm MUST be SHA-1, SHA-256, SHA-384 404 or SHA-512. This requirement is derived from Appendix A (2) and (3) 405 of [CABF-DV]. 407 3. Semantic Verification of a DV Certificate 409 The fundamental semantic check that a Monitor MUST perform is to 410 detect bogus certificates on behalf of its clients. A client of a 411 Monitor provides the Monitor with a set of certificates that have 412 been issued to the client. (Note that a client may have multiple 413 certificates issued to its name, and thus there is not a one-to-one 414 mapping between names and public keys.) These certificates MUST be 415 acquired in a secure fashion, not using certificate discovery 416 protocols or relying on databases operated by a CA or RA. Armed with 417 this information, a Monitor can examine every log entry to determine 418 if it contains the same Subject or subjectAltName as that of a 419 client. If a log entry matches either of these names, and if it 420 contains a public key other than the one(s) provided by the Subject, 421 this is evidence of mis-issuance. A Monitor SHOULD track activity in 422 all logs that are considered trustworthy by its clients. There is no 423 mechanism defined that allows a Monitor to know what logs belong to 424 this set. Thus it is RECOMMENDED that each Monitor make known the 425 set of logs that it tracks, and each client is advised to select a 426 Monitor that satisfies the client's criteria in this regard. If a 427 Monitor identifies what appears to be a bogus certificate, it 428 notifies the client. The means by which notification is effected is 429 not specified. 431 [CABF-DV] imposes a number of requirements on certificate issuance 432 that cannot be verified without access to reference information for 433 the certificate Subject, information about the CA hierarchy, or 434 information about internal procedures of the CA. Monitors are not 435 presumed to be able to perform such checks. Examples of such checks 436 appear in Sections 7.1, 9.1.3, 9.1.4, 9.2.4a, 9.2.6, 9.4.1 and 9.5 of 437 [CABF-DV]. 439 Additional semantic checks SHOULD be performed by a Monitor, if it 440 has access to the requisite information. These are enumerated below. 442 1. A certificate issued to a subordinate CA that is not an affiliate 443 of a "root" CA MUST NOT contain the anyPolicy policy identifier. 444 This requirement is derived from section 9.3.3 of [CABF-DV]. 445 Verification of this requirement requires knowledge of CA 446 organizational relationships and thus may not be available to all 447 Monitors. 449 2. A certificate issued to a subordinate CA that is an affiliate of 450 a "root" CA MAY include one or more explicit policy identifiers 451 (either 2.23.140.1.2.1 or 2.23.140.1.2.2 or policy identifiers 452 defined by the CA in its CP and/or CPS). It also MAY include the 453 anyPolicy OID. This requirement is derived from section 9.3.3 of 454 [CABF-DV]. If the extension contains any of the OIDs noted 455 explicitly above, it is acceptable. Verification of this 456 requirement requires knowledge of CA organizational relationships 457 and thus may not be available to all Monitors. 459 4. IANA Considerations 461 TBD 463 5. Security Considerations 465 TBD 467 6. References 469 6.1. Informative References 471 [CABF-DV] CA/Browser Forum, "Baseline Requirements for the Issuance 472 and Management of Publicly-Trusted Certificates, v.1.2.3", 473 October 2014, . 476 6.2. Normative References 478 [I-D.ietf-trans-rfc6962-bis] 479 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 480 Stradling, "Certificate Transparency", draft-ietf-trans- 481 rfc6962-bis-11 (work in progress), November 2015. 483 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 484 Requirement Levels", BCP 14, RFC 2119, 485 DOI 10.17487/RFC2119, March 1997, 486 . 488 Authors' Addresses 490 Stephen Kent 491 BBN Technologies 492 10 Moulton St. 493 Cambridge, MA 02138 494 US 496 Email: kent@bbn.com 498 Rick Andrews 499 Symantec 500 350 Ellis Street 501 Mountain View, CA 94043 502 US 504 Email: Rick_Andrews@symantec.com