Subject: [Trans] defining "mis-issuance"

From: Stephen Kent <[email-masked]>
Date: Thu, 25 Sep 2014 16:15:31 -0400

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 ...

---

From: Rick Andrews <[email-masked]>
Date: Fri, 26 Sep 2014 11:45:34 -0700

Stephen,

Great work here. It's clear you've taken a lot of time and care to go through the documents with a fine-toothed comb. I have some answers/comments below:

> 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.

I think this idea has merit. In a separate thread, I asked Google to remove some of Symantec's roots from their log servers' trust store, because we have never and don't ever expect to issue EV certs from those roots (the current implementation of CT is required for EV only). I pointed out that by removing those roots, the log server could _prevent_ an unintended mis-isuance rather than just record it. Google didn't agree with me.
https://groups.google.com/a/chromium.org/forum/#!topic/ct-policy/DHf74DdO2rs

Also, although I like the idea of log servers rejecting syntactically-invalid certificates, that may create problems for CAs because the CABF requirements have changed over time and will likely change in the future. Any changes would have to be rolled out to log servers and browsers in time to prevent rejection of a valid certificate.
A.1 Syntactic Verification of a Domain Validation Certificate
(Is there a better reference for EV certificate policy OIDs?)
I might suggest Chrome's source code itself: https://code.google.com/p/chromium/codesearch#chromium/src/net/cert/ev_root_ca_metadata.cc&sq=package:chromium
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.)
[CABF-Baseline] says it's a SHOULD, not a must, although I agree that it can't clearly be verified, except at the extreme where the serial number is less than 20 bits long.
 6. subject: A certificate MAY contain a NULL Subject name If it contains a non-null Subject name:
There's a period missing before "If".
2. A certificate issued to a CA  MUST include the certificatePolcies extension. It may r MAY NOT be
Typo: "r" -> "or"

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?)

I think bullet point C is a copy and paste error, and should be removed. Your question, though, is relevant. This is an open question. At the last CA/Browser Forum face-to-face meeting, some CA attendees indicated that they had difficulty as there are many countries with no states/provinces, like "Bouvet Island", "British Virgin Islands", "Christmas Island", "Falkland Islands", "Faroe Islands", "French Guiana", "Gibraltar", "Guadeloupe", "Guam", "Guernsey", "Isle of Man", "Jersey", "Lebanon", "Macedonia", "Martinique", "Mayotte", "Montenegro", "Netherlands Antilles", "Niue", "Norfolk Island", "Palestinian Territory", "Pitcairn", "Reunion", "Serbia", "Singapore", "Slovenia", "South Georgia and the South Sandwich Islands", "Svalbard and Jan Mayen", "Western Sahara", "Vatican", Taiwan, etc. I expect we'll debate this further in the Forum and perhaps change [CABF-Baseline].
4. The cRLDistributinPoints extension MUST be present in a CA certificate. It MUST NOT be marked
Typo: "cRLDistributinPoints" -> "cRLDistributionPoints"
6. The authorityInformatinAccess extension MAY be present and, if present, MUST NOT be marked
Typo: "authorityInformatinAccess" -> "authorityInformationAccess"

A.2 Semantic Verification of a Certificate
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.
There's no requirement that a Subject be associated with a single public key. In some cases, web site owners generate a different key pair on each machine behind a load balancer, and apply for certificates with the same Subject name but different key.
I'm not sure if you've captured the type of mis-issuance that CT was originally intended to detect: when a hacked, faulty or rogue CA issues a certificate to a Subject without the Subject's knowledge. The Monitor alone cannot detect that. It can report to the Subject that a certificate was logged for the Subject, but only the Subject can tell if that was a valid issuance or mis-issuance.
-Rick

---

From: Santosh Chokhani <[email-masked]>
Date: Sun, 28 Sep 2014 02:31:54 +0000

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-masked]] On Behalf Of Stephen Kent
Sent: Thursday, September 25, 2014 4:16 PM
To: [email-masked]
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.

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.

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.)

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,

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.

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.

A.3 Syntactic Verification of an Extended Validation Certificate

    coming soon ...

---

From: Stephen Kent <[email-masked]>
Date: Mon, 29 Sep 2014 10:50:15 -0400

Rick,

Thanks for taking the time to review my initial cut at an Appendix.

I have made changes to reflect all of the typos you noted.

> Also, although I like the idea of log servers rejecting 
> syntactically-invalid certificates, that may create problems for CAs 
> because the CABF requirements have changed over time and will likely 
> change in the future. Any changes would have to be rolled out to log 
> servers and browsers in time to prevent rejection of a valid certificate.
>

Your observation about the need to coordinate CABF requirements changes 
with what log servers
would check gave me an idea. Why not have the add (pre-cert) chain to 
log request specify
whether the cert being added is to be checked against DV or EV specs, 
and note the version
of the DV/EV spec to be used? This would make it easy for the log to 
know which set of
checks to employ. Since each log needs to advertise a set of data about 
itself anyway
(e.g., what root CAs it supports), it could also advertise the set of 
specs against which
it is prepared to check submissions. This way a CA or Subject would know 
whether the log
was prepared to accept a chain for checking under the selected criteria. 
Note that a Monitor
could not perform checks as easily, because it does not interact 
directly with the entity
submitting the log request. I think that argues for logs performing 
these checks.
> 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.
>
> There's no requirement that a Subject be associated with a single 
> public key. In some cases, web site owners generate a different key 
> pair on each machine behind a load balancer, and apply for 
> certificates with the same Subject name but different key.
>
> I'm not sure if you've captured the type of mis-issuance that CT was 
> originally intended to detect: when a hacked, faulty or rogue CA 
> issues a certificate to a Subject without the Subject's knowledge. The 
> Monitor alone cannot detect that. It can report to the Subject that a 
> certificate was logged for the Subject, but only the Subject can tell 
> if that was a valid issuance or mis-issuance.
>
Your observation is correct; that's what I get for trying to write a 
quick description of
the algorithm for this.  Accommodating multiple keys per Subject is easy 
to fix.

    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(s) 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 public key other that the one(s) provided by the
    Subject, this is evidence of mis-issuance.

If the Subject provides a list of all o the keys associated with the 
Subject, perhaps in the form
of certs issued to the Subject (and currently valid) this would enable a 
Monitor to detect this form of mis-issuance, agreed?

A separate topic is issuance of a bogus cert for a Subject who doesn't 
have a cert issued legitimately.
In this case there is no reference cert to present to a Monitor. It may 
be hard for a Subject who
doesn't have a cert to convince a 3rd party Monitor to check for certs 
issued to the Subject name
in question. Should we classify this as mis-issuance as well?

Steve

Steve

---

From: Stephen Kent <[email-masked]>
Date: Mon, 29 Sep 2014 10:52:41 -0400

Santosh,
> 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.
>
I believe 6962-bit already requires a log operator to validate the cert 
chain to
one of the roots from which it accepts SCT requests, based on text in 
Section 3.1.
But I can add a specific reminder of the need to do that.
>
> Note that if one follows CABF, unlike RFC 5280 and X.509, EKU is 
> processed somewhat akin to certificate policy (less policy mapping).
Can you point to the CABF text that makes this clear? Also, I'd be 
thankful if you can
provide suggested changes to my text to highlight this.
>
> On a side note, I fail to see CABF requirement with respect to 
> interaction between name constraints and EKU.
I read Section**9.7 of the DV (1.1.9) spec as implying a linkage between 
the two, but
the wording is somewhat confusing to me.

Steve

---

From: Santosh Chokhani <[email-masked]>
Date: Mon, 29 Sep 2014 17:42:35 +0000

Steve,

See I will respond to the other thread you created for path validation.  That seems to be a more appropriate place.

I will be sure to include the EKU processing language there.

From: Trans [mailto:[email-masked]] On Behalf Of Stephen Kent
Sent: Monday, September 29, 2014 10:53 AM
To: [email-masked]
Subject: Re: [Trans] defining "mis-issuance"

Santosh,

Steve,

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.
I believe 6962-bit already requires a log operator to validate the cert chain to
one of the roots from which it accepts SCT requests, based on text in Section 3.1.
But I can add a specific reminder of the need to do that.

Note that if one follows CABF, unlike RFC 5280 and X.509, EKU is processed somewhat akin to certificate policy (less policy mapping).
Can you point to the CABF text that makes this clear? Also, I'd be thankful if you can
provide suggested changes to my text to highlight this.

On a side note, I fail to see CABF requirement with respect to interaction between name constraints and EKU.
I read Section 9.7 of the DV (1.1.9) spec as implying a linkage between the two, but
the wording is somewhat confusing to me.

Steve

---

From: Rick Andrews <[email-masked]>
Date: Mon, 29 Sep 2014 15:26:41 -0700

Stephen,

You said "Your observation about the need to coordinate CABF requirements changes with what log servers
would check gave me an idea. Why not have the add (pre-cert) chain to log request specify
whether the cert being added is to be checked against DV or EV specs, and note the version
of the DV/EV spec to be used? This would make it easy for the log to know which set of
checks to employ. Since each log needs to advertise a set of data about itself anyway
(e.g., what root CAs it supports), it could also advertise the set of specs against which
it is prepared to check submissions. This way a CA or Subject would know whether the log
was prepared to accept a chain for checking under the selected criteria. Note that a Monitor
could not perform checks as easily, because it does not interact directly with the entity
submitting the log request. I think that argues for logs performing these checks."

It's doable, but it still leaves the CA in a bind. What if the CA wants to start issuing certs according to new CABF docs, but finds that none of the existing log servers support that version? This is probably a moot point, isn't it, because Melinda has reminded us not to introduce any normative dependencies on CAB Forum documents or processes.

Your observation is correct; that's what I get for trying to write a quick description of
the algorithm for this.  Accommodating multiple keys per Subject is easy to fix.
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(s) 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 public key other that the one(s) provided by the Subject, this is evidence of mis-issuance.

If the Subject provides a list of all o the keys associated with the Subject, perhaps in the form
of certs issued to the Subject (and currently valid) this would enable a Monitor to detect this form of mis-issuance, agreed?
Agreed, but it puts a burden on the Subject. Before issuing any new legitimate certificate, the Subject would need to notify the Monitor of the new Subject name and/or public key. We've got some customers who issue thousands of certificates across their organization. IMO, the model might work better if the Monitor is simply a conduit, providing information found in log servers to the Subject, and then the Subject can decide if each new certificate was intentionally issued.

A separate topic is issuance of a bogus cert for a Subject who doesn't have a cert issued legitimately.
In this case there is no reference cert to present to a Monitor. It may be hard for a Subject who
doesn't have a cert to convince a 3rd party Monitor to check for certs issued to the Subject name
in question. Should we classify this as mis-issuance as well?
See my comment above. Must the Monitor be able to decide by itself what is legitimate and what is mis-issued, or is that the role of the Subject, with help from the Monitor? In other words, couldn't we say that it's mis-issuance if the Monitor finds a cert in a log, forwards it to the Subject, and the Subject determines that it's mis-issued?

-Rick