Steve, I read 6962-bis saying submission of certificate chain.
Why not add path validation to the list of rules you defined below. That would be good given the wide variance in how browsers process chains. This gives us another opportunity at log level to have correct logic for path validation. Note that if one follows CABF, unlike RFC 5280 and X.509, EKU is processed somewhat akin to certificate policy (less policy mapping). On a side note, I fail to see CABF requirement with respect to interaction between name constraints and EKU. From: Trans [mailto:[email protected]] On Behalf Of Stephen Kent Sent: Thursday, September 25, 2014 4:16 PM To: [email protected] Subject: [Trans] defining "mis-issuance" As I promised last week, I have taken an initial cut at defining mis-issuance in the broader sense that Ben seemed to imply in his comments on my initial threat and attack model. I used the CABF Guidelines for Dv and Ev certs as the basis for this, so that mis-issuance is defined objectively (unlike art and porn, which are distinguishable only in the eye of the beholder). The CABF Guidelines establish a lot of requirements that are purely syntactic and thus could be checked by a log operator, before agreeing to issue an SCT. I want to suggest we consider that as a possible change to the current design. A goal of CT is to discourage acceptance of mis-issued certs by TLS clients, and part of the plan is to have clients (eventually) reject certs without SCTs. So if we have a set of well- defined, syntactic checks that logs can apply before issuing an SCT, we can provide immediate feedback to CAs (and/or Subjects) when problems are detected with certs, before the certs sent to clients, maybe even before they are issued. If we adopt this approach, then Monitors can focus on "protecting" specific Subjects, based on having received certs (or equivalent data) from those clients. Anyway, based on my review of the CABF Guidelines, almost all of the cert fields have to be covered by an SCT, as do several common extensions. Amusingly, these Guidelines don't have a readily testable requirement for a cert serial number, so the need to include a serial number in an SCT is driven exclusively by the need to provide that number to a CA for revocation, under attack scenario #2 in my attack analysis. I hope CABF experts will be able to review the text I am providing below, to any errors/omissions due to my misunderstanding of those docs. It took a little effort to translate some sections of the docs into (more) straightforward requirements language. I have not written the EV cert syntactic requirements part of the doc yet. Since there is considerable overlap with DV cert requirements I anticipate it will be easier. There are some comments in bold in the text, noting some unresolved issues. Have a nice weekend, Steve -------- Appendix A - Specification and Verification of Certificate Issuance Requirements (Normative) The following requirements are extracted from the CA Browser Forum (CABF) document "Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates" version 1.1.9 [CABF- Baseline] and "Guidelines For The Issuance And Management Of Extended Validation Certificates" version 1.5.1 [CABF-EV]. These requirements are used to define what constitutes mis-issuance of a certificate in the context certificate transparency (CT). The CABF specifications from which these requirements are derived include many aspects of CA operation that are outside of the scope of CT-based detection of certificate mis-issuance, i.e., they impose requirements that could not be verified by a Monitor examining certificate logs. Hence this appendix was created to provide a concise enumeration of certificate issuance verification requirements relevant to CT. The Appendix is divided into two parts: requirements for so-called "domain validation" certificates and requirement for "extended validation" certificates. This organization parallels the CABF guidelines cited above. The verification criteria enumerated below are to be applied to any certificate for which an SCT has been (or will be?) created. Note that "root" CA certificates are not subject to verification against these criteria. Each log maintains a list of the root CAs for which it is willing to accept SCT generation requests. This implies that the log operator has already determined that these CAs, and their corresponding self-signed certificates, are acceptable. A subordinate CA certificate will be checked against the criteria below only if it is submitted as the target of an SCT. (If a subordinate CA certificate appears as part of a chain submitted for SCT generation, but is not the last certificate in that chain, it is not checked.) The CABF documents cited above describe both syntactic and semantic requirements for certificate issuance. This Appendix deals primarily with syntactic checks. The vast majority of syntactic checks can be performed without access to external information about the Issuer or the Subject of a certificate. A.1 Syntactic Verification of a Domain Validation Certificate An X.509 certificate consists of a set of fields (all but two of which are mandatory), plus a set of optional extensions. This section of the Appendix defines the syntactic requirements imposed on the certificate fields. The next section deals with extensions. The CABF guidelines for DV and EV certificates differ. To determine which set of guidelines are applicable, one must first determine which type of certificate is being examined. A certificate is marked as an EV certificate based on the Certificate Policy OID contained in the certificatePolicies extension. Each CA that issues EV certificates defines one or more policy OIDs that represent EV certificate policies. A Monitor performing syntactic checks first acquires a current list of EV certificate policy OIDs to use in determining whether a given certificate is an EV certificate. One such list is available from (http://en.wikipedia.org/wiki/Extended_Validation_Certificate). (Is there a better reference for EV certificate policy OIDs?) 1. Version number: The certificates MUST be an X.509 v3 certificate. This requirement is derived from Appendix B of [CABF-Baseline], where it is explicitly stated for Subordinate CA certificates. Since other portions of [CABF-Baseline] mandate support for extensions and only v3 certificates can contain extensions [RC5280], this requirement is inferred to apply to Subscriber (EE) certificates as well. 2. serialNumber: No requirements beyond those imposed by [RFC5280] are mandated by [CABF-Baseline]. ([CABF-Baseline] requires that a serial number contan at least 20 bits of entropy (see Section 9.6, but it not clear how this can be verified through syntactic examination of a certificate.) 3. signature: For any certificate issued after December 31, 2010, the allowed digest algorithms are: SHA-1, SHA-256, SHA-384 or SHA-512. If RSA is used to sign the certificate, the minimum modulus size is 2048 bits. (No requirement is imposed on the public exponent.) If DSA is used to sign the certificate, the following pairs of values are permitted: L= 2048, N= 224 or L= 2048, N=256, L= 2048, N= 224 or L= 2048, N=256. If the certificate signature is based on ECC (presumably ECDSA), the allowed curves are NIST P-256, P-384 and P-521. To verify that a certificate employs an accepted digest and signature algorithm, one examines the OID contained in this field. OIDs defined in the following RFCs are applicable here: [RFC4055], [RFC5480], and [RFC5758]. (Do we want to enumerate the specific OID strings applicable to certificate signatures?) 4. issuer: The Issuer name MUST contain the countryName attribute and it MUST contain an ISO-3166-1 country code This requirement is derived from section 9.1.4 of [CABF-Baseline]. The Issuer name MUST contain the organizationName attribute. This requirement is derived from section 9.1.3 of [CABF-Baseline] 5. validity: A Subscriber certificate issued after July 1, 2012 MUST not contain a validity interval longer than 60 months. ([CABF-Baseline] establishes criteria in Section 9.4.1 that describe the circumstances under which Subscriber certificates may be issued with validity intervals between 39 and 60 months. Since these criteria cannot be evaluated without external knowledge, this Appendix adopts the 60-month limit for syntactic checking.) 6. subject: A certificate MAY contain a NULL Subject name If it contains a non-null Subject name: A. it MAY contain a commonName attribute. If this attribute is present, it MUST contain a single IP address or Fully-Qualified Domain Name that is one of the values contained in the Certificate's subjectAltName extension. Thus verification of this attribute requires comparing values in this attribute against the content of the subjectAltname extension, which MUST be present (see below). B. it MAY contain an organizationalUnitName attribute. This requirement is derived from section 9.2.6 of [CABF-Baseline]. C. if the name does not contain an organizationName attribute, then the streetAddress attribute MUST NOT be present. If the organizationName attribute is present, the streetAddress attribute MAY be present. This requirement is derived from section 9.2.4b of [CABF-Baseline]. D. if the name does not contain an organizationName attribute, then the localityName attribute MUST NOT be present. If the organizationName attribute is present, the localityName attribute MAY be present. This requirement is derived from section 9.2.4c of [CABF-Baseline]. E. if the name does not contain an organizationName attribute, then the stateOrProvinceName attribute MUST NOT be present. If the organizationName attribute is present, and the localityName is absent, then the stateOrProvinceName attribute MUST be present. If the organizationName attribute is present, and the localityName is present, then the stateOrProvinceName attribute MAY be present. This requirement is derived from section 9.2.4d of [CABF-Baseline]. 1. the stateOrProvinceName attribute MUST NOT be present if the organizationName attribute is missing 2. the stateOrProvinceName attribute MUST be present if the organizationName attribute is present and the localityName is absent F. if the name does not contain an organizationName attribute, then the postalCode attribute MUST NOT be present. If the name contains an organizationName attribute, then the postalCode attribute MAY be present. This requirement is derived from section 9.2.4e of [CABF-Baseline]. G. if the name contains an organizationName attribute, then the countryName attribute MUST be present. if the name does not contain an organizationName attribute, then the countryName attribute MAY be present. This requirement is derived from section 9.2.5 of [CABF-Baseline]. H. The Subject MAY contain other attributes as specified in Appendix A of [RFC5280]. These attributes MUST NOT contain metadata such as '.', '-', or ' ' (i.e. space) characters. This requirement is derived from section 9.2.8 of [CABF-Baseline]. 7. subjectPublicKeyInfo: If this field contains an RSA public key the minimum modulus size is 2048 bits. (No requirement is imposed on the public exponent.) If it carries a DSA key, the following pairs of values are permitted: L= 2048, N= 224 or L= 2048, N=256, L= 2048, N= 224 or L= 2048, N=256. If the field conveys an ECC (presumably ECDSA) public key, the allowed curves are NIST P-256, P-384 and P-521. To verify that a certificate employs an accepted digest and signature algorithm, one examines the OID contained in this field. OIDs defined in the following RFCs are applicable here: [RFC4055], [RFC5480], and [RFC5758]. (Do we want to enumerate the specific OID strings applicable to certificate signatures?) 8. issuerUniqueId: This is an optional field (a BIT STRING) in a v3 certificate. [CABF-Basline] imposes no requirements on this field, so no constraints beyond those in [RFC5280] are applicable. 9. subjectUniqueId: : This is an optional field (a BIT STRING) in a v3 certificate. [CABF-Basline] imposes no requirements on this field, so no constraints beyond those in [RFC5280] are applicable. 10. signatureAlgorithm: This field MUST match the signature field contained within the certificate (see # 3 above). 11. signatureValue: This field is verified using the public key extracted from the certificate of the Issuer of this certificate, and the algorithms specified in the preceding field. A.1.2 An X.509 v3 certificate may contain extensions. [CABF-baseline] mandates the presence of several extensions, and imposes requirements on their content. 1. The certificate MUST contain the subjectAltName extension, and that extension MUST contain at least one entry. Each entry MUST be either a dNSName containing a Fully-Qualified Domain Name (FQDN) or an iPAddress. Wildcard FQDNs are permitted. No other entry types are permitted. This requirement is derived from section 9.2.1 of [CABF-Baseline]. 2. A certificate issued to a CA MUST include the certificatePolcies extension. It may r 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 2.A of [CABF-Baseline]. A. If this extension contains the OID 2.23.140.1.2.1, then the Subject field MUST NOT contain an organizationalName, streetAddress, localityName, stateOrProvinceName, or postalCode attribute. This requirement is derived from section 9.3.1 of [CABF-Baseline]. B. If this extension contains the OID 2.23.140.1.2.2, then the Subject field MUST contain organizationName, C. localityName, stateOrProvinceName (if applicable), and countryName attributes. This requirement is derived from section 9.3.1 of [CABF-Baseline]. (How does one know whether the stateOrProvinceName is applicable?) 3. The basicConstraints extension MUST be present, marked CRITICAL and the cA flag MUST be set TRUE in a CA certificate. This requirement is derived from Appendix A Section 2.D of [CABF-Baseline]. The presence of this extension is optional for an EE certificates. If the extension is present in a Subscriber certificate it MUST have the cA flag set FALSE. (If a certificate does not contain this extension it is presumed to be a Subscriber certificate and MUST be processed as such with regard to all other verification checks.) 4. The cRLDistributinPoints extension MUST be present in a CA certificate. It MUST NOT be marked critical and it MUST contain an HTTP URL. This extension is optional for Subscriber certificates, but if present the same syntactic constraints apply. This requirement is derived from Appendix B, Sections 2.B and 3.B of [CABF-Baseline]. 5. The keyUsage extension MUST be present in a CA certificate and it MUST be marked critical. The keyCertSign and cRLSign bits MUST be set TRUE. The digitalSignature bit MAY be set TRUE as well. This requirement is derived from Appendix B, Section 2.E of [CABF-Baseline]. 6. The authorityInformatinAccess extension MAY be present and, if present, MUST NOT be marked CRITICAL. It MUST specify accessMethod 1.3.6.1.5.5.7.48.1 and MAY specify accessMethod 1.3.6.1.5.5.7.48.2. This requirement is derived from Appendix B, Sections 2.C and 3.C of [CABF-Baseline]. 7. The extendedKeyusage extension MAY be present in a CA certificate. If present, it need not be marked CRITICAL. If the extension is present in a CA certificate, and if the certificate contains the nameConstraints extension, then the value id-kp-serverAuth MUST be present. The extendedKeyusage extension MUST be present in a Subscriber certificate. Either the value id-kp-serverAuth or id-kp-clientAuth or both values MUST be present. id-kp-emailProtection MAY be present. This requirement is derived from Appendix B, Sections 2.G and 3.F of [CABF-Baseline]. 8. The nameConstraints extension MAY appear in CA certificates and need not be marked CRITICAL (contrary to [RCC5280]). If the certificate also contains the extendedKeyusage extension and that extension contains the value id-kp-serverAuth, then that extension MUST NOT contain the anyExtendedKeyusage value in the KeyPurposeID. Moreover the nameConstrants extension MUST impose constraints on dNSName, iPAddress and DirectoryName name types. Both the permittedSubtrees and excludedsubtrees fields MAY be employed. This requirement is derived from Appendix B, Section 2.F and Section 9.7 of [CABF-Baseline]. 9. Other extensions defined in [RFC5280] MAY be present and MUST be marked with respect to criticality as specified therein. A.2 Semantic Verification of a Certificate 1. [CABF-Baseline] imposes a number of requirements on certificate issuance that cannot be verified without access to reference information for the certificate Subject, or information about the CA hierarchy. For example: 1. The CA must verify that the Subject has the right to use or control of, all Domain Names and/or IP Addresses listed in the Subject field and/or the subjectAltName extension in the certificate. This requirement is derived from Section 7.1 of [CABF-Baseline]. 2. The Issuer name MUST contain a "meaningful" identifier of the CA that issued the certificate, in the organizationName attribute of the Issuer name. This requirement is derived from section 9.1.3 of [CABF-Baseline]. 3. The Issuer name MUST contain the countryName attribute corresponding to the country on which the Issuer's place of business is located. This requirement is derived from Section 9.1.4 of [CABF-Baseline]. 4. If the Subject is non-null, it MUST contain either the (verified) Subject's name or DBA. The CA MUST verify the streetAddress, localityName, stateOrProvinceName, postalCode, countryName, and organizationalUnitName attributes, if present. This requirement is derived from Section 9.2.4a of [CABF-Baseline]. 2. A certificate issued to a subordinate CA that is not an affiliate of a "root" CA MUST NOT contain the anyPolicy policy identifier. This requirement is derived from section 9.3.3 of [CABF-Baseline]. (How would a Monitor know whether the subordinate CA is affiliated with the root CA?) 3. A certificate issued to a subordinate CA that is an affiliate of a "root" CA MAY include one or more explicit policy identifiers (either 2.23.140.1.2.1 or 2.23.140.1.2.2 or policy identifiers defined by the CA in its CP and/or CPS). It also MAY include the anyPolicy OID. This requirement is derived from section 9.3.3 of [CABF-Baseline]. If the extension contains any of the OIDs noted explicitly above, it is acceptable. (How would a Monitor know whether the subordinate CA is affiliated with the root CA?) 4. A Subscriber certificate issued after April 1, 2015 MUST not contain a validity interval longer than 39 months, unless the issuer asserts that the certificate meets all of the criteria described in Section 9.4.1 of [CABF-Baseline], from which this requirement is derived. (How would a Monitor determine that a certificate with a validity interval between 39 and 60 months is acceptable, based on Section 9.4.1 of [CABF-Baseline]?) A Monitor cannot, in general determine if these requirements have been met; it lacks knowledge of the processes employed by the CA to verify the Subject name, and it may not be able to determine whether the CA is "meaningfully" identified by the Issuer name. A Monitor may not be able to determine the organizational relationships between a "root" CA and subordinate CAs. Thus mis-issuance relative to these requirements cannot, in general, be detected by a Monitor. Nonetheless, a Monitor can "protect" specific Subjects, based on reference data provided by these Subjects. A Monitor trying to determine that a certificate has been issued to the "right" Subject can do so using the certificate(s) issued to the Subject, as a reference. For example, if a Monitor is providing "protection" for a Subject, it requires the name of the Subject (as it appears in the Subject field or subjectAltName extension) and the public key associated with that Subject. Armed with this information, a Monitor can examine every log entry to determine if it contains the same Subject or SubjectAltName. If a log entry matches either of these names, and if it contain a different public key, this is evidence of mis-issuance. A.3 Syntactic Verification of an Extended Validation Certificate coming soon ...
_______________________________________________ Trans mailing list [email protected] https://www.ietf.org/mailman/listinfo/trans
