updated to reflect dropping TLS client behavior specs, no gossip 
protocol yet defined,
and no stand-alone Auditors.

comments welcome, but I'm abut to head off on vacation, so I won't be 
able to respond immediately

Steve
------

*XX*. Attack Model and Discussion of Detection and Mitigation Options

Certificate mis-issuance may arise in one of several ways. The ways that 
CT enables a Subject (or others) to detect and redress mis-issuance 
depends on the context and the entities involved in the mis-issuance. 
This attack model applies to the Web PKI context. If CT is applied to 
other contexts, each will require its own attack model, although most of 
the model described here is likely to be applicable.

Certificates are issued by CAs, so the top level differentiation is 
whether the CA that mis-issued a certificate did so maliciously or not. 
If not, then the next point of differentiation is whether the 
mis-issuance was the result of an error, an attack, or malicious 
behavior by a CA. In the case of an attack or malicious behavior by a 
CA, it is necessary to consider whether the certificate was logged. If 
the certificate was logged, it is necessary to consider whether the 
log(s) may have conspired with the attacker. Finally, one must consider 
the possibility that a third party Monitor might collude with an 
attacker (or a malicious CA). Here’s an taxonomy of attacks and 
assumptions about the attack environment:

1.CA

a.Non-malicious CA

i.Error

ii.Attack victim

1.Certificate logged

a.Benign log

                 i.Self-monitor

ii.Benign 3^rd party Monitor

iii.Conspiring 3^rd party Monitor

b.Conspiring log

2.Certificate not logged

b.Malicious CA

i.Certificate logged

1.Benign log

a.Self-monitor

b.Benign 3^rd party Monitor

c.Conspiring 3^rd party Monitor

2.Conspiring log

            ii.Certificate not logged

The following sections examine each of these cases, for both syntactic 
and semantic mis-issuance. As noted above, the focus here is on the Web 
PKI context, although most of the analysis is applicable to other PKI 
contexts.

*XX*.1 Non-malicious Web PKI CA context

If a pre-certificate is submitted to a log, prior to issuance of a 
certificate, syntactic mis-issuance can (optionally) be detected, and 
noted. This will happen only if the log performs syntactic checks in 
general, and if the log is capable of performing the checks applicable 
to the submitted (pre-) certificate. (A pre-certificate will be logged 
even if it fails syntactic validation, thus logging takes precedence 
over detection of syntactic mis-issuance.) If syntactic validation 
fails, this will be noted in the SCT returned to the CA. Because this 
case assumes a non-malicious CA, the CA will remedy the syntactic 
problem and re-submit the pre-certificate to a log. In this case 
syntactic checking by a log helps avoid issuance of a malformed certificate.

If a certificate is submitted by its Subject, we assume that the Subject 
will contact the issuer and request a new certificate if a log indicates 
that the certificate failed the applicable syntactic check. Here too 
syntactic checking by a log enables a Subject to be informed that its 
certificate is malformed and thus may hasten issuance of a replacement 
certificate.

If the certificate was submitted by a third party, that party might 
contact the Subject or the issuer, but because the party is not the 
Subject of the certificate it is not clear how the issuer will respond.

Bottom line: Syntactic mis-issuance of a certificate can be avoided by a 
CA if it makes use of logs that are capable of performing these checks 
for the types of certificates that are submitted, and if the CA acts on 
the feedback it receives. If a CA uses a log that does not perform such 
checks, or if the CA requests checking relative to criteria not 
supported by the log, then syntactic mis-issuance will not be detected 
or avoided by this mechanism. Syntactic mis-issuance can be remedied if 
a Subject submits a certificate to a log that performs syntactic checks, 
and if the Subject requests the issuer to fix problems detected by the 
log. (The issuer is presumed to be willing to re-issue the certificate, 
correcting any problems, because the CA is not malicious.)

*XX*.1.1 A CA may issue the certificate to an unauthorized party 
(semantic mis-issuance), as a result of an error or because it was the 
victim of a social engineering attack. We will refer to such a 
certificate as “bogus”. In this case the CA has a record of the bogus 
certificate and it is prepared to revoke the bogus certificate once it 
has confirmed 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 affected Subject, it will detect the 
mis-issuance, and will alert the Subject. Because the CA has a record of 
the mis-issuance, it should be able to 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 is irrelevant 
to the mitigation procedure in this case. (See Note 1 below.) Because 
the mis-issuance was not malicious, there is no notion of a log operator 
or a Monitor conspiring with the CA.

*XX*.1.2 A non-malicious Web PKI CA may be the victim of an undetected 
attack (c.f., DigiNotar [cite]) which results in semantic mis-issuance 
of a certificate. In this case the CA is not aware of the mis-issuance 
and may have no record of the certificate content.

*XX*.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 can alert the Subject. The Subject, in turn, will 
request the CA to revoke the bogus certificate. In this case, the CA 
will make use of the log entry (supplied by the Subject) to determine 
the serial number of the mis-issued certificate, and revoke it (after 
investigation). (See Notes 1 + 2.) _Since there is no requirement for a 
TLS client to reject a certificate when no SCT is provided, the 
preferred strategy for an attacker is to not log bogus certificates_. 
(See XX.1.2.2 and Note 3.)

*XX*.1.2.2 The bogus certificate may not have been submitted to any 
logs. In this case, Monitors will not detect the bogus certificate. 
_Since TLS clients are not required to reject a certificate that lacks 
(or is not accompanied by) an SCT, or even to notify a user in such 
situations, the attacker will not be thwarted in this case._ (See Note 3.)

XX.1.2.3 The bogus certificate may have been submitted to logs that are 
conspiring with the attacker. In this case, Monitors will not detect the 
bogus certificate because the logs will suppress a bogus certificate log 
entry. TLS clients will not reject a bogus certificate in this case, 
because it is accompanied by an SCT. In this scenario, unless Monitors 
“gossip” to detect conspiring logs, the bogus certificate will not be 
detected. _Because there are no requirements for such gossiping, an 
attack of this sort can succeed based on the current CT design._

__

XX.1.2.4 If a semantically bogus certificate is submitted to 
non-conspiring logs, a Subject performing self-monitoring will be able 
to detect the bogus certificate and request revocation. If a Subject 
relies on a third-party Monitor, and that Monitor conspires with the 
attacker, the Subject will not be alerted and thus will not request 
revocation.

*XX*.2 Malicious Web PKI CA context

*XX*.2.1 If a (pre-) certificate is submitted to a (non-conspiring) log, 
syntactic mis-issuance can be detected, and noted. This will happen only 
if the log performs syntactic checks in general, and if the log is 
capable of performing the checks applicable to the submitted 
certificate. A (pre-) certificate will be logged even if it fails 
syntactic validation, thus logging takes precedence over detection of 
syntactic mis-issuance.

Because the CA is presumed to be malicious, the CA may cause the log to 
not perform checks, in one of several ways.

1.The CA may assert that the certificate is being issued w/o regard to 
any guidelines (the “no guidelines” reserved CCID).

2.The CA may assert a CCID that has not been registered, and thus no log 
will be able to perform a check.

3.the CA may check to see which CCIDs a log declares it can check, and 
chose a registered CCID that is not checked by the log in question. In 
this fashion the CA can prevent the log from performing checks, and the 
SCT and log entry will not contain an indication of a failed check.

4.The CA may submit a (pre-) certificate to a log that is known to not 
perform any syntactic checks, and thus avoid syntactic checking.

_Since there is no requirement that a TLS client can be configured to 
reject a certificate that has not been syntactically checked (as 
indicated by the SCT), a malicious CA need not worry about failing a 
log-based check. Similarly, _

_since there is no requirement for a TLS client to reject a certificate 
that was logged by an operator that does not perform syntactic checks, 
the fourth approach noted above will succeed as well_. If a client were 
configured to know which versions of certificate types are applicable to 
its use of a certificate, the second and third strategies noted above 
could be thwarted.

*XX*.2.2 Because the CA is presumed malicious, it may choose to not 
submit a 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. _Since there is no requirement for a TLS client to reject a 
certificate that lacks (or is not accompanied by) an SCT, this form of 
mis-issuance will succeed. (See Note 3.)_

*XX*.2.3 A malicious CA may submit a certificate to one or more logs 
that collude with this CA to not perform syntactic checks, even though 
they claim to do so. In this case syntactic mis-issuance will not be 
detected by logs. The log entry and the SCT for a syntactically invalid 
certificate will assert that the certificate syntax was verified. Unless 
Monitors also perform syntactic checks, this form of mis-issuance will 
not be thwarted. TLS clients will believe that the certificate has been 
syntactically verified.

*XX*.2.4 A malicious CA may semantically mis-issue a certificate that is 
syntactically valid. Because it is syntactically valid, logs will not 
mark the bogus certificate as failing a syntax check. The semantically 
bogus certificate may have been issued because the CA was bribed or was 
compelled to issue the 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).

*XX*.2.4.1 A bogus certificate may not have been submitted to any logs. 
In this case, Monitors will not detect the bogus certificate. _Since 
there is no requirement for a TLS client to reject a certificate that 
lacks (or is not accompanied by) an SCT, there is no motivation for an 
attacker to submit the certificate in this case. (See Note 3.)_

*XX*.2.4.2 A bogus pre-certificate may have been submitted to one or 
more logs, to acquire an embedded SCT, a certificate may have been 
submitted post-issuance (to acquire a standalone SCT). In either case, a 
(non-conspiring) Monitor protecting the targeted Subject will detect a 
bogus certificate and alert that 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.)

*XX*.2.4.3 If a third-party Monitor conspires with the malicious CA, 
then it will not notify the targeted Subject when a bogus certificate is 
logged. If a Subject performs self-monitoring this sort of attack will 
be avoided.

*XX*.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 (even a self-Monitor) 
from which the log is hiding data will not detect the bogus certificate, 
even if it is trying to protect the targeted 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 bogus certificate.

The audit function is intended to detect logs that conspire to suppress 
log entries, based on consistency checking of logs and use of a “gossip” 
protocol. It is assumed that Monitors will perform the audit functions 
described in Section <*insert #*>.

A Monitor performing an audit function could alert its clients if the 
Monitor detects evidence of malfeasant log operation. This would cause 
Monitors to avoid using such a log, and clients would reject SCTs 
generated by such a log. _Because there is no defined gossip protocol, 
CT does not provide the necessary info to detect this form of 
mis-issuance. _(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? If a Subject acts as 
its own Monitor, this problem is solved for that Subject. It also is not 
clear how a Monitor becomes aware of all (relevant?) logs, including 
newly created logs. The means by which Monitors become aware of new logs 
MUST accommodate self-monitoring by a potentially very large number of 
web site operators.

2.A CA being presented with evidence of a bogus certificate, in the form 
of a log entry, will need to examine its records to determine if it has 
knowledge of the certificate in question. It also will likely require 
the targeted Subject to provide assurances that it is the authorized 
entity representing the Subject name (subjectAltname) in question. Thus 
a Subject should not expect immediate revocation of a contested 
certificate. 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 applicable criteria. The SCT and log 
entry, because each contains a timestamp from a third party, is probably 
valuable for forensic purposes (assuming a non-conspiring log operator).

3.If a TLS client were 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. _Until a 
mechanism is defined that accommodates incremental deployment of this 
capability, attackers probably will avoid submitting bogus certificates 
to (non-conspiring) logs as a means of evading detection._

4.A targeted Subject might request the parent of a malicious 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 this specification were 
to require that a browser can be configured to reject a specific, bogus 
certificate identified by a Monitor, then the bogus certificate could be 
rejected in that fashion. This mitigation strategy calls for 
communication between Monitors and browsers, or between Monitors and 
browser vendors. Such communication has not been specified, i.e., there 
are no standard ways to configure a browser to reject individual bogus 
certificates based on info provided by an external entity such as a 
Monitor. Moreover, the same or another malicious CA could 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 definition of an audit function, to detect conspiring 
logs. If a Monitor protecting s Subject does not see mis-issued 
certificates, it cannot alert the Subject. If one or more 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 Monitors and clients reject certificates that contains SCTs from 
conspiring logs (based on info from an audit) will CT be able to deter 
use of such logs. Thus the means by which a Monitor performing an audit 
function detect such logs, and inform TLS clients must be specified for 
this to be effective. Moreover, if a certificate (or TLS handshake) 
contains more than one SCT, unless the client verifies all of them if it 
is to counter the threat posed by conspiring logs.

Absent a “gossip” protocol that enables Monitors to verify that data 
from logs are reported in a consistent fashion, CT does not provide 
protection against logs that may conspire with, or are 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 a critical role in detecting semantic certificate 
mis-issuance, for Subjects that have requested monitoring of their 
certificates. A monitor (including a Subject performing self-monitoring) 
examines logs for certificates associated with one or more Subjects. It 
must obtain a list valid certificates for the Subject being monitored, 
in a secure manner.

Note: A Monitor must not rely on a CA or RA database for this 
information or use certificate discovery protocols; this information 
must be acquired by the Monitor based on reference certificates provided 
by a Subject. If a Monitor were to rely on a CA or RA database (for the 
CA that issued a targeted certificate), the Monitor would not detect 
mis-issuance due to malfeasance on the part of that CA or the RA, or due 
to compromise of the CA or the RA.  If a CA or RA database is used, it 
does detect mis-issuance by an unauthorized CA.  A Monitor must not rely 
on certificate discovery mechanisms to build the list of valid 
certificates since such mechanisms might result in mis-issued 
certificates being added to the list.

As noted above, 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, as noted above. It is 
RECOMMENDED that a Subject 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. 
However, the burden of Monitor operation may be viewed as too great for 
many web sites, and thus this mode of operation ought not be assumed to 
be universal when evaluating protection against Monitor compromise.

A final note: Now that certificate pinning has been approved as a 
standard (currently in the RFC Editor’s queue), it is appropriate to 
factor in its use by TLS clients. It would appear that pinning will 
dramatically reduce the set of TLS clients that are vulnerable to 
mis-issuance; a client that pins a certificate for a web site would 
reject a bogus certificate without use of any CT mechanisms. The 
security considerations section of 6962-bis needs to note this, since 
deployment of pinning appears to reduces the need for CT in the Web PKI 
context.