draft-ietf-trans-threat-analysis-04.txt   draft-ietf-trans-threat-analysis-05.txt 
Public Notary Transparency S. Kent Public Notary Transparency S. Kent
Internet Draft BBN Technologies Internet Draft BBN Technologies
Expires: July 2016 January 30, 2016 Expires: October 2016 April 7, 2016
Intended Status: Informational Intended Status: Informational
Attack Model and Threat for Certificate Transparency Attack Model and Threat for Certificate Transparency
draft-ietf-trans-threat-analysis-04 draft-ietf-trans-threat-analysis-05
Abstract Abstract
This document describes an attack model and discusses threats for This document describes an attack model and discusses threats for
the Web PKI context in which security mechanisms to detect mis- the Web PKI context in which security mechanisms to detect mis-
issuance of web site certificates are being developed. The model issuance of web site certificates are being developed. The model
provides an analysis of detection and remediation mechanisms for provides an analysis of detection and remediation mechanisms for
both syntactic and semantic mis-issuance. The model introduces an both syntactic and semantic mis-issuance. The model introduces an
outline of attacks to organize the discussion. The model also outline of attacks to organize the discussion. The model also
describes the roles played by the elements of the Certificate describes the roles played by the elements of the Certificate
skipping to change at page 1, line 42 skipping to change at page 1, line 42
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on July 30, 2016. This Internet-Draft will expire on October 7, 2016.
Table of Contents Table of Contents
1. Introduction....................................................... 3 1. Introduction....................................................... 3
2. Threats............................................................ 8 2. Threats............................................................ 8
3. Semantic mis-issuance.............................................. 9 3. Semantic mis-issuance............................................. 10
3.1. Non-malicious Web PKI CA context ............................... 9 3.1. Non-malicious Web PKI CA context .............................. 10
3.1.1. Certificate logged ........................................ 10 3.1.1. Certificate logged ........................................ 10
3.1.1.1. Benign log............................................. 10 3.1.1.1. Benign log............................................. 10
3.1.1.1.1. Self-monitoring Subject ............................ 10 3.1.1.1.1. Self-monitoring Subject ............................ 10
3.1.1.1.2. Benign third party Monitor ......................... 10 3.1.1.1.2. Benign third party Monitor ......................... 11
3.1.1.2. Misbehaving log........................................ 10 3.1.1.2. Misbehaving log........................................ 11
3.1.1.2.1. Self-monitoring Subject ............................ 11 3.1.1.2.1. Self-monitoring Subject ............................ 11
3.1.1.2.2. Benign third party Monitor ......................... 11 3.1.1.2.2. Benign third party Monitor ......................... 11
3.1.1.3. Misbehaving third party Monitor........................ 12 3.1.1.3. Misbehaving third party Monitor........................ 12
3.1.2. Certificate not logged .................................... 12 3.1.2. Certificate not logged .................................... 12
3.1.2.1. Self-monitoring Subject................................ 12 3.1.2.1. Self-monitoring Subject................................ 13
3.1.2.2. CT-enabled browser..................................... 12 3.1.2.2. CT-enabled browser..................................... 13
3.2. Malicious Web PKI CA context .................................. 13 3.2. Malicious Web PKI CA context .................................. 13
3.2.1. Certificate logged ........................................ 13 3.2.1. Certificate logged ........................................ 13
3.2.1.1. Benign log............................................. 13 3.2.1.1. Benign log............................................. 13
3.2.1.1.1. Self-monitoring Subject ............................ 13 3.2.1.1.1. Self-monitoring Subject ............................ 14
3.2.1.1.2. Benign third party Monitor ......................... 13 3.2.1.1.2. Benign third party Monitor ......................... 14
3.2.1.2. Misbehaving log........................................ 14 3.2.1.2. Misbehaving log........................................ 14
3.2.1.2.1. Monitors - third party and self .................... 14 3.2.1.2.1. Monitors - third party and self .................... 14
3.2.1.3. Misbehaving third party Monitor........................ 14 3.2.1.3. Misbehaving third party Monitor........................ 15
3.2.2. Certificate not logged .................................... 14 3.2.2. Certificate not logged .................................... 15
3.2.2.1. CT-aware browser....................................... 15 3.2.2.1. CT-aware browser....................................... 15
4. Syntactic mis-issuance............................................ 15 3.3. Malicious, Colluding CAs ...................................... 16
4.1. Non-malicious Web PKI CA context .............................. 15 3.3.1. Revocation of the Bogus Certificate ....................... 17
4.1.1. Certificate logged ........................................ 15 3.3.2. Revocation of the Colluding CA Certificate ................ 18
4.1.1.1. Benign log............................................. 15 3.4. Undetected Compromise of CAs or Logs .......................... 18
4.1.1.2. Misbehaving log or third party Monitor................. 16 3.4.1. Compromised CA, Benign Log ................................ 19
4.1.1.3. Self-monitoring Subject and Benign third party Monitor. 17 3.4.2. Benign CA, Compromised Log ................................ 20
4.1.1.4. CT-enabled browser..................................... 17 3.4.3. Compromised CA, Compromised Log ........................... 20
4.1.2. Certificate not logged .................................... 17 4. Syntactic mis-issuance............................................ 21
4.2. Malicious Web PKI CA context .................................. 17 4.1. Non-malicious Web PKI CA context .............................. 21
4.2.1. Certificate logged ........................................ 18 4.1.1. Certificate logged ........................................ 21
4.2.1.1. Benign log............................................. 18 4.1.1.1. Benign log............................................. 21
4.2.1.2. Misbehaving log or third party Monitor................. 18 4.1.1.2. Misbehaving log or third party Monitor................. 22
4.2.1.3. Self-monitoring Subject and Benign third party Monitor. 18 4.1.1.3. Self-monitoring Subject and Benign third party Monitor. 23
4.2.1.4. CT-enabled browser..................................... 18 4.1.1.4. CT-enabled browser..................................... 23
4.2.2. Certificate is not logged ................................. 19 4.1.2. Certificate not logged .................................... 24
5. Issues Applicable to Sections 3 and 4............................. 19 4.2. Malicious Web PKI CA context .................................. 24
5.1. How does a Subject know which Monitor(s) to use? .............. 19 4.2.1. Certificate logged ........................................ 24
5.2. How does a Monitor discover new logs? ......................... 19 4.2.1.1. Benign log............................................. 24
5.3. CA response to report of a bogus or erroneous certificate ..... 20 4.2.1.2. Misbehaving log or third party Monitor................. 24
5.4. Browser behavior .............................................. 20 4.2.1.3. Self-monitoring Subject and Benign third party Monitor. 25
5.5. Remediation for a malicious CA ................................ 20 4.2.1.4. CT-enabled browser..................................... 25
5.6. Auditing - detecting misbehaving logs ......................... 21 4.2.2. Certificate is not logged ................................. 25
6. Security Considerations........................................... 22 5. Issues Applicable to Sections 3 and 4............................. 25
7. IANA Considerations............................................... 22 5.1. How does a Subject know which Monitor(s) to use? .............. 25
8. Acknowledgments................................................... 23 5.2. How does a Monitor discover new logs? ......................... 26
9. References........................................................ 24 5.3. CA response to report of a bogus or erroneous certificate ..... 26
9.1. Normative References .......................................... 24 5.4. Browser behavior .............................................. 26
9.2. Informative References ........................................ 24 5.5. Remediation for a malicious CA ................................ 27
Author's Addresses................................................... 24 5.6. Auditing - detecting misbehaving logs ......................... 27
Copyright Statement.................................................. 25 6. Security Considerations........................................... 29
7. IANA Considerations............................................... 29
8. Acknowledgments................................................... 29
9. References........................................................ 30
9.1. Normative References .......................................... 30
9.2. Informative References ........................................ 30
Author's Addresses................................................... 30
Copyright Statement.................................................. 31
1. Introduction 1. Introduction
Certificate transparency (CT) is a set of mechanisms designed to Certificate transparency (CT) is a set of mechanisms designed to
detect, deter, and facilitate remediation of certificate mis- detect, deter, and facilitate remediation of certificate mis-
issuance. The term certificate mis-issuance is defined here to issuance. The term certificate mis-issuance is defined here to
encompass violations of either semantic or syntactic constraints. encompass violations of either semantic or syntactic constraints.
The fundamental semantic constraint for a certificate is that it was The fundamental semantic constraint for a certificate is that it was
issued to an entity that is authorized to represent the Subject (or issued to an entity that is authorized to represent the Subject (or
Subject Alternative) named in the certificate. (It is also assumed Subject Alternative) named in the certificate. (It is also assumed
skipping to change at page 4, line 30 skipping to change at page 4, line 36
certificates that have been mis-issued in the name of that Subject. certificates that have been mis-issued in the name of that Subject.
A Subject learns of a bogus certificate (issued in its name), via A Subject learns of a bogus certificate (issued in its name), via
the Monitor function of CT. The Monitor function may be provided by the Monitor function of CT. The Monitor function may be provided by
the Subject itself, i.e., self-monitoring, or by a third party the Subject itself, i.e., self-monitoring, or by a third party
trusted by the Subject. When a Subject is informed of certificate trusted by the Subject. When a Subject is informed of certificate
mis-issuance by a Monitor, the Subject is expected to request/demand mis-issuance by a Monitor, the Subject is expected to request/demand
revocation of the bogus certificate. Revocation of a bogus revocation of the bogus certificate. Revocation of a bogus
certificate is the primary means of remedying mis-issuance. certificate is the primary means of remedying mis-issuance.
Certificate Revocations Lists (CRLs) [RFC5280] are the primary means Certificate Revocations Lists (CRLs) [RFC5280] are the primary means
of certificate revocation established by IETF (and ISO) standards. of certificate revocation established by IETF standards.
Unfortunately, most browsers do not make use of CRLs to check the Unfortunately, most browsers do not make use of CRLs to check the
revocation status of certificates presented by a TLS Server revocation status of certificates presented by a TLS Server
(Subject). Some browsers make use of Online Certificate Status (Subject). Some browsers make use of Online Certificate Status
Protocol(OCSP) data [RFC4366] as a standards-based alternative to Protocol (OCSP) data [RFC6960] as a standards-based alternative to
CRLs. Also, most browser vendors employ proprietary means of CRLs. If a certificate contains an Authority Information Access
revoking certificates, e.g., via a "blacklist" or a bad-CA-list. (AIA) extension [RFC5280], it directs a replying party to an OCSP
Such capabilities enable a browser vendor to cause browsers to server to which a request can be directed. This extension also may
reject any certificates on the blacklist or for which the issuing CA be used by a browser to request OCSP responses from a TLS server
is on the bad-CA-list. This approach also remedies mis-issuance. with which it is communicating [RFC6066, RFC6961].
Throughout the remainder of this document references to certificate
revocation as a remedy encompass this and analogous forms of browser RFC 5280 does not require inclusion of an AIA extension in
behavior, if available. Note: there are no IETF standards defining a certificates, so a browser cannot assume that this extension will be
browser blacklist capability.) present. The Certification Authority and Browser Forum (CABF)
baseline requirements and extended validation guidelines do mandate
inclusion of this extension in EE certificates (in conjunction with
their certificate policies). (See https://cabforum.org for the most
recent versions of these policies.)
In addition to the revocation status data dissemination mechanisms
specified by IETF standards, most browser vendors employ proprietary
means of conveying certificate revocation status information to
their products, e.g., via a blacklist that enumerates revoked
certificates (EE or CA). Such capabilities enable a browser vendor
to cause browsers to reject any certificates on the blacklist. This
approach also can be employed to remedy mis-issuance. Throughout the
remainder of this document references to certificate revocation as a
remedy encompass this and analogous forms of browser behavior, if
available. Note: there are no IETF standards defining a browser
blacklist capability.
Note that a Subject can benefit from the Monitor function of CT even Note that a Subject can benefit from the Monitor function of CT even
if the Subject's certificate has not been logged. Monitoring of logs if the Subject's certificate has not been logged. Monitoring of logs
for certificates issued in the Subject's name suffices to detect for certificates issued in the Subject's name suffices to detect
mis-issuance targeting the Subject, if the bogus/erroneous mis-issuance targeting the Subject, if the bogus/erroneous
certificate is logged. certificate is logged.
A relying party (e.g., browser) benefits from CT if it rejects a A relying party (e.g., browser) benefits from CT if it rejects a
bogus certificate, i.e., treats it as invalid. An RP is protected bogus certificate, i.e., treats it as invalid. An RP is protected
from accepting a bogus certificate if that certificate is revoked, from accepting a bogus certificate if that certificate is revoked,
skipping to change at page 13, line 42 skipping to change at page 14, line 18
submitted and is performing self-monitoring, it will be able to submitted and is performing self-monitoring, it will be able to
detect the bogus certificate and will request revocation. The CA may detect the bogus certificate and will request revocation. The CA may
refuse to revoke, or may substantially delay revoking, the bogus refuse to revoke, or may substantially delay revoking, the bogus
certificate. For example, the CA could make excuses about inadequate certificate. For example, the CA could make excuses about inadequate
proof that the certificate is bogus, or argue that it cannot quickly proof that the certificate is bogus, or argue that it cannot quickly
revoke the certificate because of legal concerns, etc. In this case, revoke the certificate because of legal concerns, etc. In this case,
the CT mechanisms will have detected mis-issuance, but the the CT mechanisms will have detected mis-issuance, but the
information logged by CT does not help remedy the problem. (See information logged by CT does not help remedy the problem. (See
Sections 4 and 6.) Sections 4 and 6.)
A malicious CA might revoke a bogus certificate to avoid having
browser vendors take punitive action against the CA and/or to
persuade them to not enter the bogus certificate on a vendor-
maintained blacklist. However, the CA might provide a ''good'' OCSP
response (from a server it operates) to a targeted browser instance
as a way to circumvent the remediation nominally offered by
revocation. No component of CT is tasked with detecting this sort of
misbehavior by a CA. (The misbehavior is analogous to a log offering
split views to different clients. The Audit element of CT is tasked
with detecting this sort of attack.)
3.2.1.1.2. Benign third party Monitor 3.2.1.1.2. Benign third party Monitor
If a benign third party monitor is checking the logs to which a If a benign third party monitor is checking the logs to which a
certificate was submitted and is protecting the targeted Subject, it certificate was submitted and is protecting the targeted Subject, it
will detect the bogus certificate and will alert the Subject. The will detect the bogus certificate and will alert the Subject. The
Subject will then ask the CA to revoke the bogus certificate. As in Subject will then ask the CA to revoke the bogus certificate. As in
3.2.1.1.1, the CA may or may not revoke the certificate. 3.2.1.1.1, the CA may or may not revoke the certificate and it might
revoke the certificate but provide "good" OCSP responses to a
targeted browser instance.
3.2.1.2. Misbehaving log 3.2.1.2. Misbehaving log
A bogus (pre-)certificate may have been submitted to one or more A bogus (pre-)certificate may have been submitted to one or more
logs that are misbehaving, e.g., conspiring with an attacker. These logs that are misbehaving, e.g., conspiring with an attacker. These
logs may or may not issue SCTs, but will hide the log entries from logs may or may not issue SCTs, but will hide the log entries from
some or all Monitors. some or all Monitors.
3.2.1.2.1. Monitors - third party and self 3.2.1.2.1. Monitors - third party and self
skipping to change at page 15, line 17 skipping to change at page 16, line 5
If careful browsers reject certificates without SCTs, CAs may be If careful browsers reject certificates without SCTs, CAs may be
"encouraged" to log certificates (see section 5.4.) However, the CT "encouraged" to log certificates (see section 5.4.) However, the CT
architecture does not describe how such behavior by browsers can be architecture does not describe how such behavior by browsers can be
deployed incrementally throughout the Internet. As a result, this deployed incrementally throughout the Internet. As a result, this
attack model does not assume that browsers will reject a certificate attack model does not assume that browsers will reject a certificate
that is not accompanied by an SCT. Since certificates have to be that is not accompanied by an SCT. Since certificates have to be
logged to enable detection of mis-issuance by Monitors, and to logged to enable detection of mis-issuance by Monitors, and to
trigger subsequent revocation, the effectiveness of CT is diminished trigger subsequent revocation, the effectiveness of CT is diminished
in this context. in this context.
3.3. Malicious, Colluding CAs
Section 3.2 examined attacks in which a single CA might issue a
bogus certificate. There is also the potential that two or more CAs
might collude to issue a bogus certificate in a fashion designed to
foil the remediation (but not detection) safeguards envisioned by
CT. Their goal would be trick a CT-aware browser into accepting a
bogus certificate because it was accompanied by a valid SCT, while
evading certificate revocation status indications. This section
explores such scenarios.
In this attack two CAs that do not share a common path to a trust
anchor, collude to create a "doppelganger" (bogus) EE certificate.
The attack need not be initiated by trust anchors; any subordinate
pair of (not name-constrained) CAs can effect this attack without
the knowledge of superiors CAs (which are presumed to be benign).
The two CAs must have the same Subject name and the same public key
for the attack. (RFC 5280 doe not explicitly preclude the creation
of two CAs with the same name, so long as the parent CAs are
distinct. Requirements for Subject name uniqueness apply
individually to each CA but not across CA boundaries, as per Section
4.2.1.6. However, the Security Considerations section of RFC 5280
warns that name collisions could cause security problems.)
Because the two CAs have the same name and make use of the same key,
each can issue the (bogus) doppelganger certificates. One of the CAs
would log the certificate and acquire an SCT for it, while the other
would not.
Because the bogus certificate is logged, it is subject to detection
as such by a Monitor. Once the bogus certificate is detected it is
anticipated that action will be taken to render it invalid. The
bogus certificate itself might be revoked by the CA that issued and
logged it, an action that masks the malicious intent of that CA. A
browser vendor might add the bogus certificate to a blacklist
maintained by the vendor, e.g., because the CA failed to revoke the
bogus certificate.
If the CA that logged the bogus certificate is suspected of being
malicious, e.g., because it has a history of using bogus
certificates, the certificate of that CA might itself be revoked.
This revocation might be effected by the parent of that CA (which is
not complicit), or by a browser vendor using a blacklist. Whether
the proposed attack can achieve its goal depends on which revocation
mechanism is employed, and which certificate or certificates are
revoked.
3.3.1. Revocation of the Bogus Certificate
If the bogus (EE) certificate is revoked by the CA that issued and
logged it, browsers should treat that certificate as invalid.
However, a browser checking a CRL or OCSP response might not match
this revocation status data against the doppelganger issued by the
second CA. This is because revocation status checking is performed
in the context of a certification path (during path validation). The
doppelgangers have different certification paths and thus the
revocation status data for each might be acquired and managed
independently. (RFC 5280 does not provide implementation guidance
for management of revocation data. It is known that some relying
party implementations maintain such information on a per-certificate
path basis, but others might not.)
Even if the bogus certificates contain an AIA extension pointing to
an OCSP server the attack might still succeed. (As noted in the
Section 1, RFC 5280 does not mandate inclusion this extension, but
its presence is required by CABF requirements.) As noted in Section
3.2.1.1.1, a malicious CA could send a "good" OCSP response to a
targeted browser instance, even if other parties are provided with a
"revoked" response. Also note that a TLS server can supply an OCSP
response to a browser as part of the TLS handshake [RFC6961], if
requested by the browser. A TLS server posing as the entity named in
the bogus certificate could acquire a "good" OCSP response from the
colluding CAs to effect the attack. Only if the browser relies upon
a trusted, third-party OCSP responder, one not part of the
collusion, would the attack fail.
The analysis above also applies to the use of CRLs to disseminate
certificate revocation status data. The doppelganger certificate
could contain a CRL distribution point extension instead of an AIA
extension. In that case a site supplying CRLs for the colluding CAs
could supply different CRLs to different requestors, in an attempt
to hide the revocation status of the doppelganger from targeted
browsers instances. This is analogous to a split-view attack
effected by a CT log. However, as noted in Section 3.2.1.1 and
3.2.1.1.1, no element of CT is responsible for detecting
inconsistent reporting of certificate revocation status data.
(Monitoring in the CT context tracks log entries made by CAs or
Subjects. Auditing is designed to detect misbehavior by logs, not by
CAs per se.)
If the CA that logged the certificate does not revoke it, a browser
vendor might enter the bogus certificate into a "blacklist".
Unfortunately, there are no IETF standards for such blacklists. Thus
it is conceivable that the revocation status data also might be
managed in a path-specific fashion. If that were true, then the
attack could succeed. However, if a vendor maintains revocation
status data in a path-independent fashion, then the attack will
fail. For example, if revoked certificates are identified by CA name
and serial number, or a hash of the certificate, this attack would
fail.
3.3.2. Revocation of the Colluding CA Certificate
If the CA that logged the bogus certificate is viewed as acting
maliciously, its parent might revoke that CA's certificate. Even
though the two colluding CAs have the same name and use the same
public key, their certificates are distinct, e.g., they were issued
by different parents and almost certainly have different certificate
serial numbers. Thus revocation of the certificate of the CA that
logged the bogus certificate does not affect the certificate of its
colluding partner. In this case, the bogus EE certificate would be
treated as valid when it appears in a certification path involving
the second colluding CA. Thus revocation the certificate for the CA
that was detected as malicious does not prevent this attack from
succeeding.
A vendor also might choose to add the certificate of the CA that
issued the bogus certificate to its blacklist, e.g., if that CA
refuses to revoke the bogus certificate. This also may not prevent
the bogus certificate from being accepted by a browser. For example,
if the CA certificate blacklist entry is analogous to a CRL entry
(Subject name of the parent of the malicious CA and the serial
number of the malicious CA's certificate), the colluding CA's
certificate would still be valid in this case.
3.4. Undetected Compromise of CAs or Logs
Sections 3.1 and 3.2 examined attacks in the context of non-
malicious and malicious CAs, and benign and misbehaving logs.
Another class of attacks might occur in the context of a non-
malicious CA and/or a benign log. Specifically these CT elements
might be compromised and the compromise might go undetected.
Compromise of CAs and logs was noted in Section 2, as was coercion
of a CA. As noted there, a compromised CA is essentially a malicious
CA, and thus the discussions in Section 3.2 are applicable. The case
of an undetected compromise warrants some additional discussion,
since some relying parties may see signed objects issued by the
legitimate (non-malicious) CA, others may see signed objects from
its compromised counterpart, and some may see objects from both. In
the case of a compromised CA or log the adversary is presumed to
have access to the private key used by a CA to sign certificates, or
used by a log to sign SCTs and STHs. Because the compromise is
undetected, there will be no effort by a CA to have its certificate
revoked or by a log to shut down the log.
3.4.1. Compromised CA, Benign Log
In the case of a compromised (non-malicious) CA, an attacker uses
the purloined private key to generate a bogus certificate (that the
compromised CA would not issue). If this certificate is submitted to
a (benign) log, then it subject to detection by a Monitor, as
discussed in 3.1.1.1. If the bogus certificate is submitted to a
misbehaving log, then an SCT can be generated, but there will be no
entry for it, as discussed in 3.1.1.2. If the bogus certificate is
not logged, then there will be no SCT, and the implications are as
described in 3.1.2.
This sort of attack may be most effective if the CA that is the
victim of the attack has issued a certificate for the targeted
Subject. In this case the bogus certificate will then have the same
certification path as the legitimate certificate, which may help
hide the bogus certificate. However, means of remedying the attack
are independent of this aspect, i.e., revocation can be effected
irrespective of whether the targeted Subject received its
certificate from the compromised CA.
A compromised (non-malicious) CA may be able to revoke the bogus
certificate if it is detected by a Monitor, and the targeted Subject
has been notified. It can do so only when the serial number of the
bogus certificate is made known to this CA. Also, the bogus
certificate cannot have been issued with an Authority Information
Access (AIA) or CRL Distribution Point (CRL DP) extension that
enables only the malicious twin to revoke the certificate. (The AIA
extension in the bogus certificate could be used to direct relying
parties to an OCSP server controlled by the malicious twin. The CRL
DP extension could be used to direct relying parties to a CRL
controlled by the malicious twin.) If the bogus certificate
contains either extension, the compromised CA cannot effectively
revoke it, but it will also be apparent that the bogus certificate
was issued by the malicious twin. (The AIA or CRL DP extension would
provide a strong indication that the bogus certificate was not
generated by the compromised CA itself.)
If the serial number of the bogus certificate is the same as for a
valid, not-expired certificate issued by the CA (to the target or to
another Subject), then revocation poses a problem. This is because
revocation of the bogus certificate will also invalidate a
legitimate certificate. This problem may cause the compromised CA to
delay revocation, thus allowing the bogus certificate to remain a
danger for a longer time.
The compromised CA may not realize that the bogus certificate was
issued by a malicious twin; one occurrence of this sort might be
regarded as an error, and not cause the CA to transition to a new
key pair. (This assumes that the bogus certificate does not contain
an AIA or CRL DP extension that wrests control of revocation from
the compromised CA.) If the compromised CA does determine that its
private key has been stolen, it may take some time to transition to
a new key pair, and reissue certificates to all of its legitimate
Subjects. Thus an attack of this sort may take a while to be
remedied.
Also note that the malicious twin of the compromised CA may be
capable of issuing its own CRL or OCSP responses, without changing
any AIA/CRL DP data present in the targeted certificate. The
revocation status data from the evil twin will appear as valid as
those of the compromised CA. If the attacker has the ability to
control the sources of revocation status data available to a
targeted user (browser instance), then the user may not become aware
of the attack.
A bogus certificate issued by the malicious CA will not match the
SCT for the legitimate certificate, since they are not identical,
e.g., at a minimum the private keys do not match. Thus a CT-aware
browser that rejects certificates without SCTs (see 3.1.2.2) will
reject a bogus certificate created under these circumstances if it
is not logged. If the bogus certificate is detected and logged,
browsers that require an SCT will reject the bogus certificate.
3.4.2. Benign CA, Compromised Log
A benign CA does not issue bogus certificates, except as a result of
an accident or attack. So, in normal operation, it is not clear what
behavior by a compromised log would yield an attack. If a bogus
certificate is issued by a benign CA (under these circumstances) is
submitted to a compromised (non-malicious) log, then both an SCT and
a log entry will be created. Again, it is not clear what additional
adverse actions the compromised log would perform to further an
attack on CT.
3.4.3. Compromised CA, Compromised Log
As noted in 3.4.1, an evil twin CA may issue a bogus certificate
that contains the same Subject name as a legitimate certificate
issued by the compromised CA. Alternatively, the bogus certificate
may contain a different name but reuse a serial number from a valid,
not revoked certificate issued by that CA.
The evil twin CA might submit a bogus certificate to the evil twin
of a compromised log. The operator of the evil twin log can use the
purloined private key to generate SCTs for certificates that have
not been logged by its legitimate counterpart. These SCTs will
appear valid relative to the public key associated with the
legitimate log. However, an STH issued by the legitimate log will
not correspond to a tree containing these SCTs. Thus thorough
checking of the SCTs issued by the evil twin log will identify this
discrepancy.
An Auditor checking for log consistency might conclude that the
compromised log is acting maliciously, and is presenting a split
view to its clients. In this fashion the compromised log may be
shunned and forced to shut down. However, if an attacker targets a
set of TLS clients that do not have access to the legitimate log,
they may not be able to detect this inconsistency. In this case CT
would need to rely on a distributed gossiping audit mechanism to
detect the compromise (see Section 5.6).
In general, this sort of attack is analogous to a malicious CA
creating a bogus certificate and receiving an SCT (with no log
entry) from a misbehaving log (Section 4.2.1.2). The lack of a log
entry prevents detection of the bogus certificate by Monitors, and
the presence of the SCT prevents rejection by a CT-aware browser
that accepts SCTs from the compromised log.
4. Syntactic mis-issuance 4. Syntactic mis-issuance
4.1. Non-malicious Web PKI CA context 4.1. Non-malicious Web PKI CA context
This section analyzes the scenario in which the CA has no intent to This section analyzes the scenario in which the CA has no intent to
issue a syntactically incorrect certificate. As noted in Section 1, issue a syntactically incorrect certificate. As noted in Section 1,
we refer to a syntactically incorrect certificate as erroneous. we refer to a syntactically incorrect certificate as erroneous.
4.1.1. Certificate logged 4.1.1. Certificate logged
skipping to change at page 24, line 14 skipping to change at page 30, line 14
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[CTarch] Kent, S., Mandelberg, D., Seo, K., "Certificate [CTarch] Kent, S., Mandelberg, D., Seo, K., "Certificate
Transparency (CT) System Architecture", draft-kent-trans- Transparency (CT) System Architecture", draft-kent-trans-
architecture-00, (October 2015), work in progress. architecture-02, (January 2016), work in progress.
9.2. Informative References 9.2. Informative References
[TRANS] Laurie, B., Langley, A., Kasper, E., Messeri, E., [TRANS] Laurie, B., Langley, A., Kasper, E., Messeri, E.,
Stradling, R., "Certificate Transparency," draft-ietf- Stradling, R., "Certificate Transparency," draft-ietf-
trans-rfc6962-bis-07 (March 9, 2015), work in progress. trans-rfc6962-bis-13 (March 21, 2016), work in progress.
[DOMVAL] Kent, S., "Syntactic and Semantic Checks for Domain [DOMVAL] Kent, S., Andrews, R., "Syntactic and Semantic Checks for
Validation Certificates," draft-kent-trans-domain- Domain Validation Certificates," draft-kent-trans-domain-
validation-cert-checks-01, (December 2014), work in validation-cert-checks-02, (December 2015), work in
progress. progress.
[EXTVAL] Kent, S., "Syntactic and Semantic Checks for Extended [EXTVAL] Kent, S., Andrews, R., "Syntactic and Semantic Checks for
Validation Certificates," draft-kent-trans-extended- Extended Validation Certificates," draft-kent-trans-
validation-cert-checks-01 (December 2014), work in extended-validation-cert-checks-02 (December 2015), work
progress. in progress.
[gossip] Nordberg, L, Gillmore, D, "Gossiping in CT," draft-linus- [gossip] Nordberg, L., Gillmore, D., Ritter, T., "Gossiping in CT,"
trans-gossip-ct-01, (March 9, 2015), work in progress draft-ietf-trans-gossip-02, (March 21, 2016), work in
progress
[RFC5280] Cooper, D., Santession, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santession, S., Farrell, S., Boeyen, S.,
Housley, R., Polk, W., "Internet X.509 Public Key Housley, R., Polk, W., "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile," RFC 5280, May 2008. (CRL) Profile," RFC 5280, May 2008.
Author's Addresses Author's Addresses
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
 End of changes. 19 change blocks. 
66 lines changed or deleted 367 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/