Since there was a suggestion that the current (-04) CT text contained an 
adequate
threat model, and if a better one were needed, I should offer text, I 
have done so.

Here is an initial cut at the sort of text I expect to see in an RFC 
dealing with
security mechanisms.

Steve
--------

Threat Model

Certificate Transparency (CT) is intended to detect and mitigate 
problems arising from mis-issuance of certificates, in the Web PKI 
context. 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 certificateis issued 
to an entity that is not authorized to represent the host (web server) 
named in the certificate Subject field or Subject Alternative Name 
extension. <do we want to focus exclusively on SAN vs. Subject?)

<Discuss classes of adversaries, motivations, and capabilities>

1.Criminals

2.Hacktivists

3.Nation states (intelligence organizations)

4.Other?

Attack Model and CT Mitigation Mechanisms

Certificate mis-issuance may arise in one of several ways. The ways that 
CT helps detect and remedy mis-issuance depends on the context of the 
mis-issuance.

1.A non-malicious Web PKI CA may mis-issue a certificate 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 the certificates it issues to one or more logs, 
there will be records of the bogus certificate. If one of Monitors to 
which the certificate was submitted is tracking the targeted Subject, it 
will detect the mis-issuance, and will alert the Subject. Because the CA 
has a record of the mis-issuance, the only data needed to identify the 
bogus certificate is the Subject (SAN) and public key, both of which are 
available from the log. The presence of an embed SCT in the bogus 
certificate, or an SCT accompanying the bogus certificate does not 
appear to contribute to the mitigation. (See Note 1 below.)

2.A non-malicious Web PKI CA may be the victim of an undetected attack 
(c.f., DigiNotar) which results in 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.

a.The bogus certificate(s) 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 to which the 
certificates had been submitted (and which is tracking the targeted 
Subject), would detect a bogus certificate and alert the targeted 
Subject. The Subject, in turn, would 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 rejects a certificate when no SCT is present, 
this might motivate the attacker to log the bogus certificates, thus 
justifying such client behavior. (However, such client behavior needs to 
be defined in a way that is compatible with incremental deployment.)

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

3.A malicious Web PKI CA may mis-issue a certificate as a result of 
being bribed or compelled to do so. (A CA might be compelled to issue a 
bogus certificate my a government agency or a criminal 
organization.)This CA might be one or more tiers below a trust anchor 
(aka root CA).

a.The bogus certificate(s) 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 tracking the 
targeted Subject would detect a bogus certificate and alert the targeted 
subject. The Subject, in turn, would 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 are not able to 
remedy the problem. (See Note 4 below.)

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

Notes:

1.If a CA submits the bogus certificate to logs, but these logs are not 
watched by a Monitor that is tracking the targeted Subject, CT will not 
mitigate a mis-issuance attack. It is not clear whether every Monitor 
MUST offer to track every Subject that requests its certificates be 
monitored. Absent such a guarantee, how do TLS clients and CAs know 
which set of Monitors will provide "sufficient" coverage. Unless these 
details are addressed, use of CT does not mitigation mis-issuance even 
when certificates are logged.

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 (SAN) to ensure that the 
certificate being revoked is not one that it has knowingly issued (which 
would fall under case #1). 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. 
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 a post-issuance SCT, 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.The 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.

As the analysis above shows, logs play a critical role in enabling 
detection of certificate mis-issuance, although they do not, per se, 
perform such detection. Thus logs represent another target for 
adversaries who wish to effect certificate mis-issuance. If a log 
generates SCTs for an attacker, but does not provide the log entries for 
these SCTs to all, or some, Monitors, CT will not detect mis-issuance. 
Thus it is critical that Monitors be able to compare the results of log 
data acquisition to detect mis-behaving logs.

Absent a protocol (a so-called "gossip" protocol) that enables Monitors 
to verify that data from logs are consistent, CT does not provide 
protection against logs that may conspire with, or be victims of, 
attackers effecting certificate mis-issuance. Even when a gossip 
protocol is deployed, it is 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, much less 
remediation, of mis-issuance.

Monitors also play a critical role in detecting 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 is complicit with, an attacker, it will fail to alert a Subject to a 
mis-issued certificate targeting the Subject. This raises the question 
of whether a Subject needs to request certificate monitoring from 
multiple sources to guard against such failures.