[Trans] defining "mis-issuance"

[Stephen Kent <[e-mail]>]

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 verificationagainst 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 
otherportions 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 attributeis missing

2.the stateOrProvinceName attribute MUST be present if the 
organizationName attributeis 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 namecontains 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 CAMUST 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 ...