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 ...
_______________________________________________
Trans mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/trans
