[Trans] updated definition and attack analysis text

[Stephen Kent <[e-mail]>]

Ignoring (for the moment) the suggestion to not consider syntactic 
mis-issuance,
and the topic of whether logs might perform syntax checks on certs 
submitted to them,
I have revised the attack analysis text. It at least provides a sense of 
the style
and structure one wants in such text, and which is missing from 6962-bis.

I've expanded the definitions of mis-issuance based on the message exchanges
Ben and I had, to more clearly describe the cases of syntactic and semantic
mis-issuance that are outside of the scope for CT, or that may be 
detectable only
if a Subject operates its own Monitor. I also added structure to group 
the attack cases,
to make for easier reading. I' ve kept the "notes" style, but these 
could be folded into
the attack case analysis if desired. (It would just introduce some 
redundancy.)

Steve

------

1. Goals and Definitions

The goal of Certificate Transparency (CT) is to detect mis-issuance of 
certificates, in the Web PKI context. It is anticipated that CT will 
help deter mis-issuance, e.g., by providing information to an affected 
Subject to facilitate revocation of a mis-issued certificate. The Web 
PKI context refers to the use of a set of Certification Authorities 
(CAs) that issue X.509 certificates to web servers to enable 
TLS-protected access by clients [cite WPKOPS?].

A certificate is characterized as mis-issued if the certificate does not 
conform to the requirements established by CA Browser Forum (CABF) 
documents for "domain validation" (DV) or "extended validation" (EV) 
certificates [CABF-Baseline] and [CABF-EV], respectively. Mis-issuance 
takes two primary forms syntactic mis-issuance and semantic mis-issuance.

1.A certificate may fail to meet the syntactic constraints imposed by 
the CABF guidelines.

a.Most syntactic constraints from [CABF-Baseline] and [CABF-EV], can be 
checked via examination of a certificate chain, without reference to 
Subject-specific or CA-specific data.

b.A few syntactic constraints require access to data specific to a CA or 
the Subject in question.

2.A certificate may fail to meet the semantic constraints imposed by the 
CABF guidelines.

a.Most semantic constraints can be verified by comparing a certificate 
against one or more reference certificates for the Subject.

b.Some semantic constraints cannot be verified by examining a 
certificate, even with reference certificate information.

Most instances of the syntactic of mis-issuance can be detected by 
examining a certificate against a set of criteria extracted from the 
CABF guidelines. Based on whether a certificate purports to be a DV or 
an EV certificate, one can examine it against almost all of the 
syntactic constraints imposed by the guidelines. Appendix A, Section A.1 
enumerates the syntactic criteria to be used in this case. These checks 
can be performed by a log before issuing an SCT, and if a (pre-) 
certificate fails these checks, it should not be issued. This behavior 
is RECOMMENDED to provide feedback to CAs, to detect potential syntactic 
mis-issuance before the certificate is issued.

A few of the syntactic constraints cannot be verified in this fashion, 
e.g., because they require knowledge of the organizational relationships 
between "root" and subordinate CAs (see Section 9.3.3 of 
[CABF-Baseline].) Appendix A, Section A.2, notes these exception and 
notes that, in general, they cannot be checked by a Monitor or log, and 
thus there is no requirement to perform these checks. (A Monitor 
operated by a Subject on its own behalf has access to at least some of 
the data required to verify conformance to this latter set of syntactic 
constraints and thus SHOULD do so.)

Detection of semantic mis-issuance as described in 2a above requires 
access to "reference" certificates associated with a specified Subject. 
(For purposes of this discussion, a reference certificate is a valid 
certificate issued to a specified Subject, consistent with the CABF 
guidelines.) The primary concern addressed by detection of semantic 
mis-issuance is that a certificate has been issued to an entity that is 
not authorized to represent the host (web server) named in the 
certificate Subject field (or subjectAltName extension).

Other forms of semantic mis-issuance (2 b above) may arise due to 
procedural or operational violations of the CABF guidelines, but these 
may not be detectable by a third party, even with access to a reference 
certificate. For example, a Web PKI CA may fail to adhere to the audit 
procedures required in Section 15 of [CABF-Baseline]. CT elements (e.g., 
Monitors) are not able to detect these forms of mis-issuance because 
they are not externally visible.

<Discuss classes of adversaries, motivations, and capabilities>

1.Criminals

2.Hacktivists

3.Nation states (intelligence organizations)

4.Other?

2. Attack Model and Mitigation Mechanisms

Certificate mis-issuance may arise in one of several ways. The ways that 
CT enables a Subject (or others) to redress mis-issuance depends on the 
context of the mis-issuance, and thus it is appropriate to examine the 
context as part of an attack model

2.1 A non-malicious Web PKI CA

If the certificate is submitted to a log prior to issuance (a 
pre-certificate), the (generally) detectable forms of syntactic 
mis-issuance (Section 1, 1.a) will be detected, and the certificate will 
not be logged. Because the CA is non-malicious, it will remedy the 
syntactic problem and re-submit the (pre-) certificate to a log again. 
Thus syntactic mis-issuance of this type will be thwarted.

2.1.1 A CA may issue the certificate to an unauthorized party (Section 
1, 2.a), as a result of an error or because it was the victim of a 
social engineering attack. In this case the CA has a record of the 
certificate and it is prepared to revoke the bogus certificate once it 
has been convinced of its error. If the CA is submitting (pre-) 
certificates for logging, there will be evidence of the mis-issuance in 
one or more logs. If a Monitor is "protecting" the targeted Subject, it 
will detect the mis-issuance, and will alert the Subject. Because the CA 
has a record of the mis-issuance, it should revoke the bogus 
certificate, after investigating, based on the information provided by 
the legitimate certificate Subject. The presence of an embedded SCT in 
the bogus certificate, or an SCT accompanying the bogus certificate does 
not contribute to the mitigation. (See Note 1 below.)

2.1.2 A non-malicious Web PKI CA may be the victim of an undetected 
attack (c.f., DigiNotar) which results in semantic mis-issuance of one 
or more certificates. In this case the CA is not aware of the 
mis-issuance and may have no record of the certificate content.

2.1.2.1 The mis-issued certificate may have been submitted to one or 
more logs prior to issuance, to acquire an embedded SCT, or 
post-issuance to acquire a standalone SCT. In either case, a Monitor 
that is protecting the targeted Subject will detect the bogus 
certificate and alert the targeted Subject. The Subject, in turn, will 
request the CA to revoke the bogus certificate. In this case, the CA 
will depend on the certificate serial number provided via the log entry, 
to effect revocation. (See Notes 1 + 2 below.) If TLS clients reject a 
certificate when no SCT is present, this might motivate the attacker to 
log the bogus certificates, which helps justify such client behavior.

2.1.2.2 The bogus certificate may not have been submitted to any logs. 
In this case, Monitors will not detect the bogus certificate. If clients 
reject a certificate that lacks (or is not accompanied by) an SCT, the 
attacker will be thwarted in this case. (See Note 3 below.)

2.2 A Malicious Web PKI CA

2.2.1 If a certificate is submitted to a log prior to issuance (a 
pre-certificate), the (generally) detectable forms of syntactic 
mis-issuance (Section 1, 1.a) will be detected, and the certificate will 
not be logged. However, because the CA is presumed to be malicious, the 
certificate may be issued anyway. Thus checking for syntactic 
mis-issuance in this case does not, per se, prevent such mis-issuance. 
However, if clients reject a certificate that lacks (or is not 
accompanied by) an SCT, this form of mis-issuance will be thwarted in 
this case.

2.2.2 Because this CA is malicious, it may choose to not submit the 
certificate to a log. This avoids detection of syntactic mis-issuance by 
a log, but it also means there is no SCT for the certificate. However, 
if clients reject a certificate that lacks (or is not accompanied by) an 
SCT, this form of mis-issuance will be thwarted in this case.

2.2.3 The CA may submit the bogus certificate to one or more logs that 
collude with this CA, and thus do not perform syntactic checks. In this 
case the syntactic mis-issuance will not be detected by logs. Unless 
Monitors (or Auditors?) also perform syntactic checks, this form of 
mis-issuance will not be thwarted in this case.

2.2.4 The malicious CA may semantically mis-issue a certificate, that is 
syntactically valid. We will refer to such a certificate as "bogus". 
Because it is syntactically valid, logs will not reject the certificate. 
This situation might result because the CA was bribed or was compelled 
to issue the bogus certificate. (A CA might be compelled to issue a 
bogus certificate by a government agency or a criminal 
organization.)This CA might be one or more tiers below a trust anchor 
(aka root CA).

2.2.4.1 A bogus certificate may not have been submitted to any logs. In 
this case, Monitors will not detect the bogus certificate. If clients 
reject a certificate that lacks (or is not accompanied by) an SCT, the 
attacker will be thwarted in this case. (See Note 3 below.)

2.2.4.2 A bogus certificate may have been submitted to one or more logs 
prior to issuance, to acquire an embedded SCT, or post-issuance, to 
acquire a standalone SCT. In either case, a Monitor protecting the 
targeted Subject will detect a bogus certificate and alert the targeted 
subject. The Subject, in turn, will request the CA to revoke the bogus 
certificate. In this case, the CA may refuse, or substantially delay, to 
revoke the bogus certificate. (It could make excuses about inadequate 
proof that the certificate is bogus, or argue that it cannot quickly 
revoke the certificate because of local, legal concerns, etc.) In this 
case, the CT mechanisms have detected mis-issuance, but the information 
logged by CT does not help remedy the problem. (See Note 4 below.)

2.2.5 A bogus certificate may have been submitted to one or more 
conspiring logs. These logs will issue SCTs, but will hide the log 
entries from some or all Monitors. Any Monitor from which the log is 
hiding data will not detect the bogus certificate, even if it is 
protecting the target Subject. If a client accepts an SCT from a 
conspiring log, then the client will not reject the bogus certificate on 
the basis of a missing SCT. In this case CT will not detect the 
semantically mis-issued certificate. Auditors are intended to detect 
logs that conspire to suppress log entries, based on XXX. [is the 
unspecified gossip protocol need here? If so, then until we have this 
protocol, CT does not provide the necessary info to detect this form of 
mis-issuance.] If Auditors detect conspiring logs, Monitors and clients 
can be alerted to conspiring logs. This would cause clients to not 
accept SCTs generated by these logs, in the future. (See Note 5 below.)

Notes:

1.If a CA submits a bogus certificate to one or more logs, but these 
logs are not watched by a Monitor that is protecting the targeted 
Subject, CT will not mitigate this type of mis-issuance attack. It is 
not clear whether every Monitor MUST offer to track every Subject that 
requests protection. Absent such a guarantee, how do Subjects know which 
set of Monitors will provide "sufficient" coverage. Of course, if a 
Subject acts as its own Monitor, this problem is solved for that Subject.

2.A CA being presented with evidence of a bogus certificate probably 
will require more than the serial number of the bogus certificate. It 
will want to verify the Issuer and Subject (subjectAltname) to ensure 
that the certificate being revoked is not one that it has knowingly 
issued legitimately. Thus a Subject should not expect immediate 
revocation of a contested certificate in all cases. (The time frame in 
which a CA will respond to a revocation request usually is described in 
the CPS for the CA.) Other certificate fields and extensions may be of 
interest for forensic purposes, but are not required to effect 
revocation nor to verify that the certificate to be revoked is bogus, 
based on [CABF-Baseline] criteria. The SCT itself, because it contains a 
timestamp from a third party, is probably valuable for forensic purposes.

3.If a TLS client is to reject a certificate that lacks an embedded SCT, 
or is not accompanied by an SCT transported via the TLS handshake, this 
behavior needs to be defined in a way that is compatible with 
incremental deployment. Issuing a warning to a (human) user is probably 
insufficient, based on experience with warnings displayed for expired 
certificates, lack of certificate revocation status information, and 
similar errors that violate RFC 5280 path validation rules.

4.A targeted Subject might request the parent or the offending CA to 
revoke the certificate of the non-cooperative CA. However, a request of 
this sort may be rejected, e.g., because of the potential for 
significant collateral damage. A browser might be configured to reject 
all certificates issued by the malicious CA, e.g., using a CA hot list 
distributed by a browser vendor. However, if the malicious CA has a 
sufficient number of legitimate clients, treating all of them as bogus 
still represents serious collateral damage. If one can configure a 
browser to reject the specific, bogus certificate identified by a 
Monitor, then the bogus certificate could be rejected in that fashion. 
Moreover, this calls for communication between Monitors and browsers, or 
between Monitors and browser vendors. Such communication is not 
specified. There are no standard ways to configure a browser to reject 
individual bogus certificates. Moreover, a malicious CA could easily 
issue new bogus certificates for the targeted Subject, which would have 
to be detected and rejected in this (as yet unspecified) fashion. Thus, 
for now, CT does not seem to provide a way to mitigate this form of 
attack, even though it provides a basis for detecting such attacks.

5.The combination of a malicious CA and one or more conspiring logs 
motivates the use of Auditors, to detect conspiring logs. If a Monitor 
protecting s Subject does not see mis-issued certificates, it cannot 
alert the Subject. If one or mlore SCTs are present in a certificate, or 
passed via the TLS handshake, a client has no way to know that the 
logged certificate is not visible to Monitors. Only if clients reject 
certificates that contains SCTs from conspiring logs will CT be able to 
deter use of such logs. Thus the means by which Auditors detect such 
logs, and inform TLS clients must be specified. Moreover, if a 
certificate (or TLS handshake) contains more than one SCT, the client 
MUST verify all of them if it is to counter the threat posed by 
conspiring logs.

Absent a "gossip" protocol that enables Auditors to verify that data 
from logs are reported in a consistent fashion to many (all?) Monitors, 
CT does not provide protection against logs that may conspire with, or 
be victims of, attackers effecting certificate mis-issuance. When a 
gossip protocol is defined and deployed, it will be necessary to 
describe how the CT system will deal with a mis-behaving or compromised 
log. For example, will there be a mechanism to alert all TLS clients to 
reject SCTs issued by such a log. Absent a description of a mitigation 
strategy to deal with mis-behaving or compromised logs, CT cannot ensure 
detection of mis-issuance.

Monitors play the critical role in detecting semantic certificate 
mis-issuance, for Subjects that have requested monitoring of their 
certificates. Thus Monitors represent another target for adversaries who 
wish to effect certificate mis-issuance. If a Monitor is compromised by, 
or conspires with, an attacker, it will fail to alert a Subject to a 
mis-issued certificate targeting that Subject. This suggests that a 
Subject SHOULD request certificate monitoring from multiple sources to 
guard against such failures. Operation of a Monitor by a Subject, on its 
own behalf, avoids dependence on third party Monitors, but the burden of 
Monitor operation may be viewed as to great for many web sites, and thus 
this mode of operation ought not be assumed to be universal when 
evaluating protection against Monitor compromise.