draft-ietf-trans-threat-analysis-06.txt   draft-ietf-trans-threat-analysis-07.txt 
Public Notary Transparency S. Kent
Internet Draft BBN Technologies
Expires: November 2016 May 31, 2016
Intended Status: Informational
Attack Model and Threat for Certificate Transparency Public Notary Transparency S. Kent
draft-ietf-trans-threat-analysis-06 Internet-Draft BBN Technologies
Intended status: Informational August 12, 2016
Expires: February 13, 2017
Attack Model and Threat for Certificate Transparency
draft-ietf-trans-threat-analysis-07
Abstract Abstract
This document describes an attack model and discusses threats for This document describes an attack model and discusses threats for the
the Web PKI context in which security mechanisms to detect mis- Web PKI context in which security mechanisms to detect mis-issuance
issuance of web site certificates are being developed. The model of web site certificates are being developed. The model provides an
provides an analysis of detection and remediation mechanisms for analysis of detection and remediation mechanisms for both syntactic
both syntactic and semantic mis-issuance. The model introduces an and semantic mis-issuance. The model introduces an outline of
outline of attacks to organize the discussion. The model also attacks to organize the discussion. The model also describes the
describes the roles played by the elements of the Certificate roles played by the elements of the Certificate Transparency (CT)
Transparency (CT) system, to establish a context for the model. system, to establish a context for the model.
Status of this Memo Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted in full conformance with the
the provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Internet-Drafts are draft documents valid for a maximum of six months
http://www.ietf.org/shadow.html and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 31, 2016. This Internet-Draft will expire on February 13, 2017.
Copyright Statement Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with carefully, as they describe your rights and restrictions with respect
respect to this document. Code Components extracted from this to this document. Code Components extracted from this document must
document must include Simplified BSD License text as described in include Simplified BSD License text as described in Section 4.e of
Section 4.e of the Trust Legal Provisions and are provided without the Trust Legal Provisions and are provided without warranty as
warranty as described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction.................................................... 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document........................... 9 1.1. Conventions used in this document . . . . . . . . . . . . 7
2. Threats......................................................... 9 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. Semantic mis-issuance.......................................... 11 3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 9
3.1. Non-malicious Web PKI CA context........................... 11 3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 9
3.1.1. Certificate logged..................................... 11 3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 9
3.1.1.1. Benign log......................................... 11 3.1.2. Certificate not logged . . . . . . . . . . . . . . . 11
3.1.1.1.1. Self-monitoring Subject........................ 11 3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12
3.1.1.1.2. Benign third party Monitor..................... 12 3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 12
3.1.1.2. Misbehaving log.................................... 12 3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14
3.1.1.2.1. Self-monitoring Subject & Benign third party 3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15
Monitor............................................. 12 3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 15
3.1.1.3. Misbehaving third party Monitor.................... 13 3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 17
3.1.2. Certificate not logged................................. 13 3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 17
3.1.2.1. Self-monitoring Subject............................ 14 3.4. Using an SCT for a revoked certificate . . . . . . . . . 18
3.1.2.2. CT-enabled browser................................. 14 3.4.1. Revocation of the Bogus Certificate . . . . . . . . . 20
3.2. Malicious Web PKI CA context............................... 14 3.4.2. Revocation of a CA Certificate . . . . . . . . . . . 21
3.2.1. Certificate logged..................................... 14 4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 22
3.2.1.1. Benign log......................................... 14 4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 22
3.2.1.1.1. Self-monitoring Subject........................ 15 4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 22
3.2.1.1.2. Benign third party Monitor..................... 15 4.1.2. Certificate not logged . . . . . . . . . . . . . . . 24
3.2.1.2. Misbehaving log.................................... 15 4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 24
3.2.1.2.1. Monitors - third party and self................ 16 4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 24
3.2.1.3. Misbehaving third party Monitor.................... 16 4.2.2. Certificate is not logged . . . . . . . . . . . . . . 26
3.2.2. Certificate not logged................................. 16 5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 26
3.2.2.1. CT-aware browser................................... 16 5.1. How does a Subject know which Monitor(s) to use? . . . . 26
3.3. Malicious, Colluding CAs................................... 17 5.2. How does a Monitor discover new logs? . . . . . . . . . . 26
3.3.1. Revocation of the Bogus Certificate.................... 18 5.3. CA response to report of a bogus or erroneous certificate 26
3.3.2. Revocation of the Colluding CA Certificate............. 19 5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 27
3.4. Undetected Compromise of CAs or Logs....................... 19 5.5. Remediation for a malicious CA . . . . . . . . . . . . . 27
3.4.1. Compromised CA, Benign Log............................. 20 5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 28
3.4.2. Benign CA, Compromised Log............................. 21 6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
3.4.3. Compromised CA, Compromised Log........................ 22 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
4. Syntactic mis-issuance......................................... 23 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
4.1. Non-malicious Web PKI CA context........................... 23 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.1.1. Certificate logged..................................... 23 9.1. Normative References . . . . . . . . . . . . . . . . . . 29
4.1.1.1. Benign log......................................... 23 9.2. Informative References . . . . . . . . . . . . . . . . . 30
4.1.1.2. Misbehaving log or third party Monitor............. 24 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
4.1.1.3. Self-monitoring Subject and Benign third party
Monitor............................................... 25
4.1.1.4. CT-enabled browser................................. 25
4.1.2. Certificate not logged................................. 25
4.2. Malicious Web PKI CA context............................... 26
4.2.1. Certificate logged..................................... 26
4.2.1.1. Benign log......................................... 26
4.2.1.2. Misbehaving log or third party Monitor............. 26
4.2.1.3. Self-monitoring Subject and Benign third party
Monitor............................................... 26
4.2.1.4. CT-enabled browser................................. 27
4.2.2. Certificate is not logged.............................. 27
5. Issues Applicable to Sections 3 and 4.......................... 27
5.1. How does a Subject know which Monitor(s) to use?........... 27
5.2. How does a Monitor discover new logs?...................... 28
5.3. CA response to report of a bogus or erroneous certificate.. 28
5.4. Browser behavior........................................... 28
5.5. Remediation for a malicious CA............................. 28
5.6. Auditing - detecting misbehaving logs...................... 29
6. IANA Considerations............................................ 30
7. Security Considerations........................................ 31
8. References..................................................... 31
8.1. Normative References....................................... 31
8.2. Informative References..................................... 31
Acknowledgments................................................... 32
Author's Addresses................................................ 32
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
that the entity requested the certificate from the CA that issued that the entity requested the certificate from the CA that issued
it.) Throughout the remainder of this document we refer to a it.) Throughout the remainder of this document we refer to a
semantically mis-issued certificate as "bogus." semantically mis-issued certificate as "bogus."
A certificate is characterized as syntactically mis-issued (aka A certificate is characterized as syntactically mis-issued (aka
erroneous) if it violates syntax constraints associated with the erroneous) if it violates syntax constraints associated with the
class of certificate that it purports to represent. Syntax class of certificate that it purports to represent. Syntax
constraints for certificates are established by certificate constraints for certificates are established by certificate profiles,
profiles, and typically are application-specific. For example, and typically are application-specific. For example, certificates
certificates used in the Web PKI environment might be characterized used in the Web PKI environment might be characterized as domain
as domain validation (DV) or extended validation (EV) certificates. validation (DV) or extended validation (EV) certificates.
Certificates used with applications such as IPsec or S/MIME have Certificates used with applications such as IPsec or S/MIME have
different syntactic constraints from those in the Web PKI context. different syntactic constraints from those in the Web PKI context.
There are three classes of beneficiaries of CT: certificate There are three classes of beneficiaries of CT: certificate Subjects,
Subjects, CAs, and relying parties (RPs). In the initial focus CAs, and relying parties (RPs). In the initial focus context of CT,
context of CT, the Web PKI, Subjects are web sites and RPs are the Web PKI, Subjects are web sites and RPs are browsers employing
browsers employing HTTPS to access these web sites. The CAs that HTTPS to access these web sites. Thee CAs that benefit are issuers
benefit are issuers of certificates used to authenticate web sites. of certificates used to authenticate web sites.
A certificate Subject benefits from CT because CT helps detect A certificate Subject benefits from CT because CT helps detect
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
the Monitor function of CT. The Monitor function may be provided by Monitor function of CT. The Monitor function may be provided by the
the Subject itself, i.e., self-monitoring, or by a third party Subject itself, i.e., self-monitoring, or by a third party trusted by
trusted by the Subject. When a Subject is informed of certificate the Subject. When a Subject is informed of certificate mis-issuance
mis-issuance by a Monitor, the Subject is expected to request/demand by a Monitor, the Subject is expected to request/demand revocation of
revocation of the bogus certificate. Revocation of a bogus the bogus certificate. Revocation of a bogus certificate is the
certificate is the primary means of remedying mis-issuance. 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 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 [RFC6960] as a standards-based alternative to Protocol (OCSP) data [RFC6960] as a standards-based alternative to
CRLs. If a certificate contains an Authority Information Access CRLs. If a certificate contains an Authority Information Access
(AIA) extension [RFC5280], it directs a relying party to an OCSP (AIA) extension [RFC5280], it directs a relying party to an OCSP
server to which a request can be directed. This extension also may server to which a request can be directed. This extension also may
be used by a browser to request OCSP responses from a TLS server be used by a browser to request OCSP responses from a TLS server with
with which it is communicating [RFC6066, RFC6961]. which it is communicating [RFC6066][RFC6961].
RFC 5280 does not require inclusion of an AIA extension in RFC 5280 does not require inclusion of an AIA extension in
certificates, so a browser cannot assume that this extension will be certificates, so a browser cannot assume that this extension will be
present. The Certification Authority and Browser Forum (CABF) present. The Certification Authority and Browser Forum (CABF)
baseline requirements and extended validation guidelines do mandate baseline requirements and extended validation guidelines do mandate
inclusion of this extension in EE certificates (in conjunction with inclusion of this extension in EE certificates (in conjunction with
their certificate policies). (See https://cabforum.org for the most their certificate policies). (See https://cabforum.org for the most
recent versions of these policies.) recent versions of these policies.)
In addition to the revocation status data dissemination mechanisms In addition to the revocation status data dissemination mechanisms
specified by IETF standards, most browser vendors employ proprietary specified by IETF standards, most browser vendors employ proprietary
means of conveying certificate revocation status information to means of conveying certificate revocation status information to their
their products, e.g., via a blacklist that enumerates revoked products, e.g., via a blacklist that enumerates revoked certificates
certificates (EE or CA). Such capabilities enable a browser vendor (EE or CA). Such capabilities enable a browser vendor to cause
to cause browsers to reject any certificates on the blacklist. This browsers to reject any certificates on the blacklist. This approach
approach also can be employed to remedy mis-issuance. Throughout the also can be employed to remedy mis-issuance. Throughout the
remainder of this document references to certificate revocation as a remainder of this document references to certificate revocation as a
remedy encompass this and analogous forms of browser behavior, if remedy encompass this and analogous forms of browser behavior, if
available. Note: there are no IETF standards defining a browser available. Note: there are no IETF standards defining a browser
blacklist capability. 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-
mis-issuance targeting the Subject, if the bogus/erroneous issuance targeting the Subject, if the bogus/erroneous certificate is
certificate is logged. 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,
and if the RP checks the revocation status of the certificate. (An and if the RP checks the revocation status of the certificate. (An
RP is also protected if a browser vendor "blacklists" a certificate RP is also protected if a browser vendor "blacklists" a certificate
or "bad-CA-lists" a CA as noted above.) An RP also may benefit from or "bad-CA-lists" a CA as noted above.) An RP also may benefit from
CT if the RP validates an SCT associated with a certificate, and CT if the RP validates an SCT associated with a certificate, and
rejects the certificate if the Signed certificate Timestamp (SCT) rejects the certificate if the Signed certificate Timestamp (SCT)
[TRANS] is invalid. If an RP verified that a certificate that claims [I-D.ietf-trans-rfc6962-bis] is invalid. If an RP verified that a
to have been logged has a valid log entry, the RP would have a certificate that claims to have been logged has a valid log entry,
higher degree of confidence that the certificate is genuine. the RP would have a higher degree of confidence that the certificate
However, checking logs in this fashion imposes a burden on RPs and is genuine. However, checking logs in this fashion imposes a burden
on logs. Moreover, the existence of a log entry does not ensure that on RPs and on logs. Moreover, the existence of a log entry does not
the certificate is not mis-issued. Unless the certificate Subject is ensure that the certificate is not mis-issued. Unless the
monitoring the log(s) in question, a bogus certificate will not be certificate Subject is monitoring the log(s) in question, a bogus
detected by CT mechanisms. Finally, if an RP were to check logs for certificate will not be detected by CT mechanisms. Finally, if an RP
individual certificates, that would disclose to logs the identity of were to check logs for individual certificates, that would disclose
web sites being visited by the RP, a privacy violation. Thus this to logs the identity of web sites being visited by the RP, a privacy
attack model does not assume that all RPs will check log entries. violation. Thus this attack model does not assume that all RPs will
check log entries.
A CA benefits from CT when it detects a (mis-issued) certificate A CA benefits from CT when it detects a (mis-issued) certificate that
that represents the same Subject name as a legitimate certificate represents the same Subject name as a legitimate certificate issued
issued by the CA. by the CA.
Note that all RPs may benefit from CT even if they do nothing with Note that all RPs may benefit from CT even if they do nothing with
SCTs. If Monitors inform Subjects of mis-issuance, and if a CA SCTs. If Monitors inform Subjects of mis-issuance, and if a CA
revokes a certificate in response to a request from the revokes a certificate in response to a request from the certificate's
certificate's legitimate Subject, then an RP benefits without having legitimate Subject, then an RP benefits without having to implement
to implement any CT-specific mechanisms. any CT-specific mechanisms.
Also note that one proposal for distributing Audit information (to Also note that one proposal [I-D.ietf-trans-gossip] for distributing
detect misbehaving logs) calls for a browser to send SCTs it Audit information (to detect misbehaving logs) calls for a browser to
receives to the corresponding website when visited by the browser. send SCTs it receives to the corresponding website when visited by
If a website acquires an inclusion proof from a log for each the browser. If a website acquires an inclusion proof from a log for
(unique) SCT it receives in this fashion, this would cause a bogus each (unique) SCT it receives in this fashion, this would cause a
SCT to be discovered, and, presumably, trigger a revocation request. bogus SCT to be discovered, and, presumably, trigger a revocation
request.
Logging [TRANS] is the central element of CT. Logging enables a Logging [I-D.ietf-trans-rfc6962-bis] is the central element of CT.
Monitor to detect a bogus certificate based on reference information Logging enables a Monitor to detect a bogus certificate based on
provided by the certificate Subject. Logging of certificates is reference information provided by the certificate Subject. Logging
intended to deter mis-issuance, by creating a publicly-accessible of certificates is intended to deter mis-issuance, by creating a
record that associates a CA with any certificates that it mis- publicly-accessible record that associates a CA with any certificates
issues. Logging does not remedy mis-issuance; but it does facilitate that it mis-issues. Logging does not remedy mis-issuance; but it
remediation by providing the information needed to enable detection does facilitate remediation by providing the information needed to
and consequently revocation of bogus certificates in some enable detection and consequently revocation of bogus certificates in
circumstances. some circumstances.
Auditing is a function employed by CT to detect misbehavior by logs Auditing is a function employed by CT to detect misbehavior by logs
and to deter mis-issuance that is abetted by misbehaving logs. and to deter mis-issuance that is abetted by misbehaving logs.
Auditing detects several types of log misbehavior, including Auditing detects several types of log misbehavior, including failures
failures to adhere to the advertised Maximum Merge Delay (MMD) and to adhere to the advertised Maximum Merge Delay (MMD) and Signed Tree
Signed Tree Head (STH) frequency count [TRANS] violating the append- Head (STH) frequency count [I-D.ietf-trans-rfc6962-bis] violating the
only property, and providing inconsistent views of the log to append-only property, and providing inconsistent views of the log to
different log clients. The first three of these are relatively easy different log clients. The first three of these are relatively easy
for an individual auditor to detect, but the last form of for an individual auditor to detect, but the last form of misbehavior
misbehavior requires communication among multiple log clients. requires communication among multiple log clients. Monitors ought
Monitors ought not trust logs that are detected misbehaving. Thus not trust logs that are detected misbehaving. Thus the Audit
the Audit function does not detect mis-issuance per se. The CT function does not detect mis-issuance per se. The CT design
design identifies audit functions designed to detect several types identifies audit functions designed to detect several types of
of misbehavior. However, mechanisms to detect some forms of log misbehavior. However, mechanisms to detect some forms of log
misbehavior are not yet standardized. misbehavior are not yet standardized.
Figure 1 (below) illustrates the data exchanges among the major Figure 1 (below) illustrates the data exchanges among the major
elements of the CT system, based on the log specification [TRANS] elements of the CT system, based on the log specification
and on the assumed behavior of other CT system elements as described
above. This Figure does not include the Audit function, because
there is not yet agreement on how that function will work in a
distributed, privacy-preserving fashion.
+----+ +---------+ +---------+ [I-D.ietf-trans-rfc6962-bis] and on the assumed behavior of other CT
| CA |---[ 1]-->| Log |<---[8]---| Monitor | system elements as described above. This Figure does not include the
| | | | | | Audit function, because there is not yet agreement on how that
| |<--[ 2]---| |----[9]-->| | function will work in a distributed, privacy-preserving fashion.
| | | | | |
| |---[ 3]-->| |<--[10]---| |
| | | | | |--------+
| |<--[ 4]---| |---[11]-->| | |
| | | | +---------+ |
| | | | |
| | | | +---------+ |
| | | |<--[8]----| Self- | |
| | | | | Monitor | |
| | | |---[9]--->|(Subject)| |
| | | | | | |
| | | |<--[10]---| | [12]
| | | | | | |
| | | |---[11]-->| | |
| | +---------+ +---------+ |
| | |
| | +---------+ +---------+ |
| |---[ 5]-->| Website |---[7]--->| Browser | |
| | |(Subject)| +---------+ |
| |<--[ 6]-->| |<----------------------------+
+----+ +---------+
[ 1] Retrieve accepted root certs +----+ +---------+ +---------+
[ 2] accepted root certs | CA |---[ 1]-->| Log | ---[8]---| Monitor |
[ 3] Add chain to log/add PreCertChain to log | | | | | |
[ 4] SCT | | --[ 2]---| |----[9]-->| |
[ 5] send cert + SCTs (or cert with embedded SCTs) | | | | | |
[ 6] Revocation request/response (in response to detected | |---[ 3]-->| | --[10]---| |
mis-issuance) | | | | | |--------+
[ 7] cert + SCTs (or cert with embedded SCTs) | | --[ 4]---| |---[11]-->| | |
[ 8] Retrieve entries from Log | | | | +---------+ |
[ 9] returned entries from log | | | | |
[10] Retrieve latest STH | | | | +---------+ |
[11] returned STH | | | | --[8]----| Self- | |
[12] bogus/erroneous cert notification | | | | | Monitor | |
| | | |---[9]--->|(Subject)| |
| | | | | | |
| | | | --[10]---| | [12]
| | | | | | |
| | | |---[11]-->| | |
| | +---------+ +---------+ |
| | |
| | +---------+ +---------+ |
| |---[ 5]-->| Website |---[7]--->| Browser | |
| | |(Subject)| +---------+ |
| | --[ 6]-->| | ----------------------------+
+----+ +---------+
Figure 1: Data Exchanges Between Major Elements of the CT System [ 1] Retrieve accepted root certs
[ 2] accepted root certs
[ 3] Add chain to log/add PreCertChain to log
[ 4] SCT
[ 5] send cert + SCTs (or cert with embedded SCTs)
[ 6] Revocation request/response (in response to detected
mis-issuance)
[ 7] cert + SCTs (or cert with embedded SCTs)
[ 8] Retrieve entries from Log
[ 9] returned entries from log
[10] Retrieve latest STH
[11] returned STH
[12] bogus/erroneous cert notification
Certificate mis-issuance may arise in one of several ways. The ways Figure 1: Data Exchanges Between Major Elements of the CT System
Certificate mis-issuance may arise in one of several ways. The ways
by which CT enables a Subject (or others) to detect and redress mis- by which CT enables a Subject (or others) to detect and redress mis-
issuance depends on the context and the entities involved in the issuance depends on the context and the entities involved in the mis-
mis-issuance. This attack model applies to use of CT in the Web PKI issuance. This attack model applies to use of CT in the Web PKI
context. If CT is extended to apply to other contexts, each context context. If CT is extended to apply to other contexts, each context
will require its own attack model, although most elements of the will require its own attack model, although most elements of the
model described here are likely to be applicable. model described here are likely to be applicable.
Because certificates are issued by CAs, the top level Because certificates are issued by CAs, the top level differentiation
differentiation in this analysis is whether the CA that mis-issued a in this analysis is whether the CA that mis-issued a certificate did
certificate did so maliciously or not. Next, for each scenario, the so maliciously or not. Next, for each scenario, the model considers
model considers whether or not the certificate was logged. Scenarios whether or not the certificate was logged. Scenarios are further
are further differentiated based on whether the logs and monitors differentiated based on whether the logs and monitors are benign or
are benign or malicious and whether a certificate's Subject is self- malicious and whether a certificate's Subject is self-monitoring or
monitoring or is using a third party Monitoring service. Finally, is using a third party Monitoring service. Finally, the analysis
the analysis considers whether a browser is performing checking considers whether a browser is performing checking relevant to CT.
relevant to CT. The scenarios are organized as illustrated by the The scenarios are organized as illustrated by the following outline:
following outline:
Web PKI CA - malicious vs non-malicious Web PKI CA - malicious vs non-malicious
Certificate - logged vs not logged Certificate - logged vs not logged
Log - benign vs malicious Log - benign vs malicious
Third party Monitor - benign vs malicious Third party Monitor - benign vs malicious
Certificate's Subject - self-monitoring (or not) Certificate's Subject - self-monitoring (or not)
Browser - CT-supporting (or not) Browser - CT-supporting (or not)
The next section of the document briefly discusses threats. The next section of the document briefly discusses threats.
Subsequent sections examine each of the cases described above. As Subsequent sections examine each of the cases described above. As
noted earlier, the focus here is on the Web PKI context, although noted earlier, the focus here is on the Web PKI context, although
most of the analysis is applicable to other PKI contexts. most of the analysis is applicable to other PKI contexts.
1.1. Conventions used in this document 1.1. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Threats 2. Threats
A threat is defined, traditionally, as a motivated, capable A threat is defined, traditionally, as a motivated, capable
adversary. An adversary who is not motivated to attack a system is adversary. An adversary who is not motivated to attack a system is
not a threat. An adversary who is motivated but not "capable" also not a threat. An adversary who is motivated but not "capable" also
is not a threat. Threats change over time; new classes of is not a threat. Threats change over time; new classes of
adversaries may arise, new motivations may come into play, and the adversaries may arise, new motivations may come into play, and the
capabilities of adversaries may change. Nonetheless, it is useful to capabilities of adversaries may change. Nonetheless, it is useful to
document perceived threats against a system to provide a context for document perceived threats against a system to provide a context for
understanding attacks. Even if the assumptions about adversaries understanding attacks. Even if the assumptions about adversaries
prove to be incorrect, documenting the assumptions is valuable. prove to be incorrect, documenting the assumptions is valuable.
As noted above, the goals of CT are to deter, detect, and facilitate As noted above, the goals of CT are to deter, detect, and facilitate
remediation of attacks on the web PKI. Such attacks can enable an remediation of attacks on the web PKI. Such attacks can enable an
attacker to spoof the identity of TLS-enabled web sites. Spoofing attacker to spoof the identity of TLS-enabled web sites. Spoofing
enables an adversary to perform many types of attacks, e.g., enables an adversary to perform many types of attacks, e.g., delivery
delivery of malware to a client, reporting bogus information, or of malware to a client, reporting bogus information, or acquiring
acquiring information that a client would not communicate if the information that a client would not communicate if the client were
client were aware of the spoofing. Such information may include aware of the spoofing. Such information may include personal
personal identification and authentication information and identification and authentication information and electronic payment
electronic payment authorization information. Because of the nature authorization information. Because of the nature of the information
of the information that may be divulged (or misinformation or that may be divulged (or misinformation or malware that may be
malware that may be delivered), the principal adversaries in the CT delivered), the principal adversaries in the CT context are perceived
context are perceived to be (cyber) criminals and nation states. to be (cyber) criminals and nation states. Both adversaries are
Both adversaries are motivated to acquire personal identification motivated to acquire personal identification and authentication
and authentication information. Criminals are also motivated to information. Criminals are also motivated to acquire electronic
acquire electronic payment authorization information. payment authorization information.
To make use of forged web site certificates, an adversary must be To make use of forged web site certificates, an adversary must be
able to direct a TLS client to a spoofed web site, so that it can able to direct a TLS client to a spoofed web site, so that it can
present the forged certificate during a TLS handshake. An adversary present the forged certificate during a TLS handshake. An adversary
may achieve this in various ways, e.g., by manipulation of the DNS may achieve this in various ways, e.g., by manipulation of the DNS
response sent to a TLS client or via a man-in-the-middle attack. The response sent to a TLS client or via a man-in-the-middle attack. The
former type of attack is well within the perceived capabilities of former type of attack is well within the perceived capabilities of
both classes of adversary. The latter attack may be possible for both classes of adversary. The latter attack may be possible for
criminals and is certainly a capability available to a nation state criminals and is certainly a capability available to a nation state
within its borders. Nation states also may be able to compromise DNS within its borders. Nation states also may be able to compromise DNS
servers outside their own jurisdiction. servers outside their own jurisdiction.
The elements of CT may themselves be targets of attacks, as The elements of CT may themselves be targets of attacks, as described
described below. A criminal organization might compromise a CA and below. A criminal organization might compromise a CA and cause it to
cause it to issue bogus certificates, or it may exert influence over issue bogus certificates, or it may exert influence over a CA (or CA
a CA (or CA staff) to do so, e.g., through extortion or physical staff) to do so, e.g., through extortion or physical threat. A CA
threat. A CA may be the victim of social engineering, causing it to may be the victim of social engineering, causing it to issue a
issue a certificate to an inappropriate Subject. (Even though the CA certificate to an inappropriate Subject. (Even though the CA is not
is not intentionally malicious in this case, the action is intentionally malicious in this case, the action is equivalent to a
equivalent to a malicious CA, hence the use of the term "bogus" malicious CA, hence the use of the term "bogus" here.) A nation
here.) A nation state may operate or influence a CA that is part of state may operate or influence a CA that is part of the large set of
the large set of "root CAs" in browsers. A CA, acting in this "root CAs" in browsers. A CA, acting in this fashion, is termed a
fashion, is termed a "malicious" CA. A nation state also might "malicious" CA. A nation state also might compromise a CA in another
compromise a CA in another country, to effect issuance of bogus country, to effect issuance of bogus certificates. In this case the
certificates. In this case the (non-malicious) CA, upon detecting (non-malicious) CA, upon detecting the compromise (perhaps because of
the compromise (perhaps because of CT) is expected to work with CT) is expected to work with Subjects to remedy the mis-issuance.
Subjects to remedy the mis-issuance.
A log also might be compromised by a suitably sophisticated criminal A log also might be compromised by a suitably sophisticated criminal
organization or by a nation state. Compromising a log would enable a organization or by a nation state. Compromising a log would enable a
compromised or rogue CA to acquire SCTs, but log entries would be compromised or rogue CA to acquire SCTs, but log entries would be
suppressed, either for all log clients or for targeted clients suppressed, either for all log clients or for targeted clients (e.g.,
(e.g., to selected Monitors or Auditors). It seems unlikely that a to selected Monitors or Auditors). It seems unlikely that a
compromised, non-malicious, log would persist in presenting multiple compromised, non-malicious, log would persist in presenting multiple
views of its data, but a malicious log would. views of its data, but a malicious log would.
Finally, note that a browser trust store may include a CA that is Finally, note that a browser trust store may include a CA that is
intended to issue certificates to enable monitoring of encrypted intended to issue certificates to enable monitoring of encrypted
browser sessions. The inclusion of a trust anchor for such a CA is browser sessions. The inclusion of a trust anchor for such a CA is
intended to facilitate monitoring encrypted content, via an intended to facilitate monitoring encrypted content, via an
authorized man-in-the-middle (MITM) attack. CT is not designed to authorized man-in-the-middle (MITM) attack. CT is not designed to
counter this type of locally-authorized interception. counter this type of locally-authorized interception.
3. Semantic mis-issuance 3. Semantic mis-issuance
3.1. Non-malicious Web PKI CA context 3.1. Non-malicious Web PKI CA context
In this section, we address the case where the CA has no intent to In this section, we address the case where the CA has no intent to
issue a bogus certificate. issue a bogus certificate.
A CA may have mis-issued a certificate as a result of an error or, A CA may have mis-issued a certificate as a result of an error or, in
in the case of a bogus certificate, because it was the victim of a the case of a bogus certificate, because it was the victim of a
social engineering attack or an attack such as the one that affected social engineering attack or an attack such as the one that affected
DigiNotar [VASCO]. In the case of an error, the CA should have a DigiNotar [https://www.vasco.com/company/about_vasco/press_room/
record of the erroneous certificate and be prepared to revoke this news_archive/2011/news_diginotar_reports_any security_incident.aspx
certificate once it has discovered and confirmed the error. In the ]. In the case of an error, the CA should have a record of the
event of an attack, a CA may have no record of a bogus certificate. erroneous certificate and be prepared to revoke this certificate once
it has discovered and confirmed the error. In the event of an
attack, a CA may have no record of a bogus certificate.
3.1.1. Certificate logged 3.1.1. Certificate logged
3.1.1.1. Benign log 3.1.1.1. Benign log
The log (or logs) is benign and thus is presumed to provide The log (or logs) is benign and thus is presumed to provide
consistent, accurate responses to requests from all clients. consistent, accurate responses to requests from all clients.
If a bogus (pre-)certificate has been submitted to one or more logs If a bogus (pre-)certificate has been submitted to one or more logs
prior to issuance to acquire an embedded SCT, or post-issuance to prior to issuance to acquire an embedded SCT, or post-issuance to
acquire a standalone SCT, detection of this mis-issuance is the acquire a standalone SCT, detection of this mis-issuance is the
responsibility of a Monitor. responsibility of a Monitor.
3.1.1.1.1. Self-monitoring Subject 3.1.1.1.1. Self-monitoring Subject
If a Subject is tracking the log(s) to which a certificate was If a Subject is tracking the log(s) to which a certificate was
submitted, and is performing self-monitoring, then it will be able submitted, and is performing self-monitoring, then it will be able to
to detect a bogus (pre-)certificate and request revocation. In this detect a bogus (pre-)certificate and request revocation. In this
case, the CA will make use of the log entry (supplied by the case, the CA will make use of the log entry (supplied by the Subject)
Subject) to determine the serial number of the bogus certificate, to determine the serial number of the bogus certificate, and
and investigate/revoke it. (See Sections 5.1, 5.2 and 5.3.) investigate/revoke it. (See Sections 5.1, 5.2 and 5.3.)
3.1.1.1.2. Benign third party Monitor 3.1.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 a bogus certificate and will alert the Subject. The will detect a bogus certificate and will alert the Subject. The
Subject, in turn, will ask the CA to revoke the bogus certificate. Subject, in turn, will ask the CA to revoke the bogus certificate.
In this case, the CA will make use of the log entry (supplied by the In this case, the CA will make use of the log entry (supplied by the
Subject) to determine the serial number of the bogus certificate, Subject) to determine the serial number of the bogus certificate, and
and revoke it (after investigation). (See Sections 5.1, 5.2 and revoke it (after investigation). (See Sections 5.1, 5.2 and 5.3.)
5.3.)
3.1.1.2. Misbehaving log 3.1.1.2. Misbehaving log
In this case, the bogus (pre-)certificate has been submitted to one In this case, the bogus (pre-)certificate has been submitted to one
or more logs, each of which generate an SCT for the submission. A or more logs, each of which generate an SCT for the submission. A
misbehaving log probably will suppress a bogus certificate log misbehaving log probably will suppress a bogus certificate log entry,
entry, or it may create an entry for the certificate but report it or it may create an entry for the certificate but report it
selectively. (A misbehaving log also could create and report entries selectively. (A misbehaving log also could create and report entries
for bogus certificates that have not been issued by the indicated CA for bogus certificates that have not been issued by the indicated CA
(hereafter called "fake"). Unless a Monitor validates the associated (hereafter called "fake"). Unless a Monitor validates the associated
certificate chains up to roots that it trusts, these fake bogus certificate chains up to roots that it trusts, these fake bogus
certificates could cause the Monitors to report non-existent certificates could cause the Monitors to report non-existent semantic
semantic problems to the Subject who would in turn report them to problems to the Subject who would in turn report them to the
the purported issuing CA. This might cause the CA to do needless purported issuing CA. This might cause the CA to do needless
investigative work or perhaps incorrectly revoke and re-issue the investigative work or perhaps incorrectly revoke and re-issue the
Subject's real certificate. Note that for every certificate Subject's real certificate. Note that for every certificate
submitted to a log, the log MUST verify a complete certificate chain submitted to a log, the log MUST verify a complete certificate chain
up to one of the roots it accepts. So creating a log entry for a up to one of the roots it accepts. So creating a log entry for a
fake bogus certificate marks the log as misbehaving. fake bogus certificate marks the log as misbehaving.
3.1.1.2.1. Self-monitoring Subject & Benign third party Monitor 3.1.1.2.1. Self-monitoring Subject & Benign third party Monitor
If a misbehaving log suppresses a bogus certificate log entry, a If a misbehaving log suppresses a bogus certificate log entry, a
Subject performing self-monitoring will not detect the bogus Subject performing self-monitoring will not detect the bogus
certificate. CT relies on an Audit mechanism to detect log certificate. CT relies on an Audit mechanism to detect log
misbehavior, as a deterrent. It is anticipated that logs that are misbehavior, as a deterrent. It is anticipated that logs that are
identified as persistently misbehaving will cease to be trusted by identified as persistently misbehaving will cease to be trusted by
Monitors, non-malicious CAs, and by browser vendors. This assumption Monitors, non-malicious CAs, and by browser vendors. This assumption
forms the basis for the perceived deterrent. It is not clear if forms the basis for the perceived deterrent. It is not clear if
mechanisms to detect this sort of log misbehavior will be viable. mechanisms to detect this sort of log misbehavior will be viable.
Similarly, when a misbehaving log suppresses a bogus certificate log Similarly, when a misbehaving log suppresses a bogus certificate log
entry (or report such entries inconsistently) a benign third party entry (or report such entries inconsistently) a benign third party
Monitor that is protecting the targeted Subject also will not detect Monitor that is protecting the targeted Subject also will not detect
a bogus certificate. In this scenario, CT relies on a distributed a bogus certificate. In this scenario, CT relies on a distributed
Auditing mechanism [gossip] to detect log misbehavior, as a Auditing mechanism [I-D.ietf-trans-gossip] to detect log misbehavior,
deterrent. (See Section 5.6 below.) However, a Monitor (third-party as a deterrent. (See Section 5.6 below.) However, a Monitor (third-
or self) must participate in the Audit mechanism in order to become party or self) must participate in the Audit mechanism in order to
aware of log misbehavior. become aware of log misbehavior.
If the misbehaving log has logged the bogus certificate when issuing If the misbehaving log has logged the bogus certificate when issuing
the associated SCT, it will try to hide this from the Subject (if the associated SCT, it will try to hide this from the Subject (if
self-monitoring) or from the Monitor protecting the Subject. It does self-monitoring) or from the Monitor protecting the Subject. It does
so by presenting them with a view of its log entries and STH that so by presenting them with a view of its log entries and STH that
does not contain the bogus certificate. To other entities, the log does not contain the bogus certificate. To other entities, the log
presents log entries and an STH that include the bogus certificate. presents log entries and an STH that include the bogus certificate.
This discrepancy can be detected if there is an exchange of This discrepancy can be detected if there is an exchange of
information about the log entries and STH between the entities information about the log entries and STH between the entities
receiving the view that excludes the bogus certificate and entities receiving the view that excludes the bogus certificate and entities
that receive a view that includes it, i.e., a distributed Audit that receive a view that includes it, i.e., a distributed Audit
mechanism. mechanism.
If a malicious log does not create an entry for a bogus certificate If a malicious log does not create an entry for a bogus certificate
(for which an SCT has been issued), then any Monitor/Auditor that (for which an SCT has been issued), then any Monitor/Auditor that
sees the bogus certificate will detect this when it checks with the sees the bogus certificate will detect this when it checks with the
log for log entries and STH (see Section 3.1.2.) log for log entries and STH (see Section 3.1.2.)
3.1.1.3. Misbehaving third party Monitor 3.1.1.3. Misbehaving third party Monitor
A third party Monitor that misbehaves will not notify the targeted A third party Monitor that misbehaves will not notify the targeted
Subject of a bogus certificate. This is true irrespective of whether Subject of a bogus certificate. This is true irrespective of whether
the Monitor checks the logs or whether the logs are benign or the Monitor checks the logs or whether the logs are benign or
malicious/conspiring. malicious/conspiring.
Note that independent of any mis-issuance on the part of the CA, a Note that independent of any mis-issuance on the part of the CA, a
misbehaving Monitor could issue false warnings to a Subject that it misbehaving Monitor could issue false warnings to a Subject that it
protects. These could cause the Subject to report non-existent protects. These could cause the Subject to report non-existent
semantic problems to the issuing CA and cause the CA to do needless semantic problems to the issuing CA and cause the CA to do needless
investigative work or perhaps incorrectly revoke and re-issue the investigative work or perhaps incorrectly revoke and re-issue the
Subject's certificate. Subject's certificate.
3.1.2. Certificate not logged 3.1.2. Certificate not logged
If the CA does not submit a pre-certificate to a log, whether a log If the CA does not submit a pre-certificate to a log, whether a log
is benign or misbehaving does not matter. The same is true if a is benign or misbehaving does not matter. The same is true if a
Subject is issued a certificate without an SCT and does not log the Subject is issued a certificate without an SCT and does not log the
certificate itself, to acquire an SCT. Also, since there is no log certificate itself, to acquire an SCT. Also, since there is no log
entry in this scenario, there is no difference in outcome between a entry in this scenario, there is no difference in outcome between a
benign and a misbehaving third party Monitor. In both cases, no benign and a misbehaving third party Monitor. In both cases, no
Monitor (self or third-party) will detect a bogus certificate based Monitor (self or third-party) will detect a bogus certificate based
on Monitor functions and there will be no consequent reporting of on Monitor functions and there will be no consequent reporting of the
the problem to the Subject or by the Subject to the CA based on problem to the Subject or by the Subject to the CA based on
examination of log entries. examination of log entries.
3.1.2.1. Self-monitoring Subject 3.1.2.1. Self-monitoring Subject
A Subject performing self-monitoring will be able to detect the lack A Subject performing self-monitoring will be able to detect the lack
of an embedded SCT in the certificate it received from the CA, or of an embedded SCT in the certificate it received from the CA, or the
the lack of an SCT supplied to the Subject via an out-of-band lack of an SCT supplied to the Subject via an out-of-band channel. A
channel. A Subject ought to notify the CA if the Subject expected Subject ought to notify the CA if the Subject expected that its
that its certificate was to be logged. (A Subject would expect its certificate was to be logged. (A Subject would expect its
certificate to be logged if there is an agreement between the certificate to be logged if there is an agreement between the Subject
Subject and the CA to do so, or because the CA advertises that it and the CA to do so, or because the CA advertises that it logs all of
logs all of the certificates that it issues.) If the certificate was the certificates that it issues.) If the certificate was supposed to
supposed to be logged, but was not, the CA can use the certificate be logged, but was not, the CA can use the certificate supplied by
supplied by the Subject to investigate and remedy the problem. In the Subject to investigate and remedy the problem. In the context of
the context of a benign CA, a failure to log the certificate might a benign CA, a failure to log the certificate might be the result of
be the result of an operations error, or evidence of an attack on an operations error, or evidence of an attack on the CA.
the CA.
3.1.2.2. CT-enabled browser 3.1.2.2. CT-enabled browser
If a browser rejects certificates without SCTs (see Section 5.4), If a browser rejects certificates without SCTs (see Section 5.4), CAs
CAs may be "encouraged" to log the certificates they issue. This, in may be "encouraged" to log the certificates they issue. This, in
turn, would make it easier for Monitors to detect bogus turn, would make it easier for Monitors to detect bogus certificates.
certificates. However, the CT architecture does not describe how However, the CT architecture does not describe how such behavior by
such behavior by browsers can be deployed incrementally throughout browsers can be deployed incrementally throughout the Internet. As a
the Internet. As a result, this attack model does not assume that result, this attack model does not assume that browsers will reject a
browsers will reject a certificate that is not accompanied by an certificate that is not accompanied by an SCT. In the CT
SCT. In the CT architecture certificates have to be logged to enable architecture certificates have to be logged to enable Monitors to
Monitors to detect mis-issuance, and to trigger subsequent detect mis-issuance, and to trigger subsequent revocation
revocation [CTarch]. Thus the effectiveness of CT is diminished in [I-D.kent-trans-architecture]. Thus the effectiveness of CT is
this context. diminished in this context.
3.2. Malicious Web PKI CA context 3.2. Malicious Web PKI CA context
In this section, we address the scenario in which the mis-issuance In this section, we address the scenario in which the mis-issuance is
is intentional, not due to error. The CA is not the victim but the intentional, not due to error. The CA is not the victim but the
attacker. attacker.
3.2.1. Certificate logged 3.2.1. Certificate logged
3.2.1.1. Benign log 3.2.1.1. Benign log
A bogus (pre-)certificate may be submitted to one or more benign A bogus (pre-)certificate may be submitted to one or more benign logs
logs prior to issuance, to acquire an embedded SCT, or post-issuance prior to issuance, to acquire an embedded SCT, or post-issuance to
to acquire a standalone SCT. The log (or logs) replies correctly to acquire a standalone SCT. The log (or logs) replies correctly to
requests from clients. requests from clients.
3.2.1.1.1. Self-monitoring Subject 3.2.1.1.1. Self-monitoring Subject
If a Subject is checking the logs to which a certificate was If a Subject is checking the logs to which a certificate was
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 may not suffice to remedy the problem. (See information logged by CT may not suffice to remedy the problem. (See
Sections 4 and 6.) Sections 4 and 6.)
A malicious CA might revoke a bogus certificate to avoid having A malicious CA might revoke a bogus certificate to avoid having
browser vendors take punitive action against the CA and/or to browser vendors take punitive action against the CA and/or to
persuade them to not enter the bogus certificate on a vendor- persuade them to not enter the bogus certificate on a vendor-
maintained blacklist. However, the CA might provide a "good" OCSP maintained blacklist. However, the CA might provide a "good" OCSP
response (from a server it operates) to a targeted browser instance response (from a server it operates) to a targeted browser instance
as a way to circumvent the remediation nominally offered by as a way to circumvent the remediation nominally offered by
revocation. No component of CT is tasked with detecting this sort of revocation. No component of CT is tasked with detecting this sort of
misbehavior by a CA. (The misbehavior is analogous to a log offering misbehavior by a CA. (The misbehavior is analogous to a log offering
split views to different clients, as discussed later. The Audit split views to different clients, as discussed later. The Audit
element of CT is tasked with detecting this sort of attack.) 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 and it might 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 revoke the certificate but provide "good" OCSP responses to a
targeted browser instance. 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
logs that are misbehaving, e.g., conspiring with an attacker. These that are misbehaving, e.g., conspiring with an attacker. These logs
logs may or may not issue SCTs, but will hide the log entries from may or may not issue SCTs, but will hide the log entries from some or
some or all Monitors. all Monitors.
3.2.1.2.1. Monitors - third party and self 3.2.1.2.1. Monitors - third party and self
If log entries are hidden from a Monitor (third party or self), the If log entries are hidden from a Monitor (third party or self), the
Monitor will not be able to detect issuance of a bogus certificate. Monitor will not be able to detect issuance of a bogus certificate.
The Audit function of CT is intended to detect logs that conspire to The Audit function of CT is intended to detect logs that conspire to
delay or suppress log entries (potentially selectively), based on delay or suppress log entries (potentially selectively), based on
consistency checking of logs. (See 3.1.1.2.1.) If a Monitor learns consistency checking of logs. (See 3.1.1.2.2.) If a Monitor learns
of misbehaving log operation, it alerts the Subjects that it is of misbehaving log operation, it alerts the Subjects that it is
protecting, so that they no longer acquire SCTs from that log. The protecting, so that they no longer acquire SCTs from that log. The
Monitor also avoids relying upon such a log in the future. However, Monitor also avoids relying upon such a log in the future. However,
unless a distributed Audit mechanism proves effective in detecting unless a distributed Audit mechanism proves effective in detecting
such misbehavior, CT cannot be relied upon to detect this form of such misbehavior, CT cannot be relied upon to detect this form of
mis-issuance. (See Section 5.6 below.) mis-issuance. (See Section 5.6 below.)
3.2.1.3. Misbehaving third party Monitor 3.2.1.3. Misbehaving third party Monitor
If the third party Monitor that is "protecting" the targeted Subject If the third party Monitor that is "protecting" the targeted Subject
is misbehaving, then it will not notify the targeted Subject of any is misbehaving, then it will not notify the targeted Subject of any
mis-issuance or of any malfeasant log behavior that it detects mis-issuance or of any malfeasant log behavior that it detects
irrespective of whether the logs it checks are benign or irrespective of whether the logs it checks are benign or malicious/
malicious/conspiring. The CT architecture does not include any conspiring. The CT architecture does not include any measures to
measures to detect misbehavior by third-party monitors. detect misbehavior by third-party monitors.
3.2.2. Certificate not logged 3.2.2. Certificate not logged
Because the CA is presumed malicious, it may choose to not submit a Because the CA is presumed malicious, it may choose to not submit a
(pre-)certificate to a log. This means there is no SCT for the (pre-)certificate to a log. This means there is no SCT for the
certificate. certificate.
When a CA does not submit a certificate to a log, whether a log is When a CA does not submit a certificate to a log, whether a log is
benign or misbehaving does not matter. Also, since there is no log benign or misbehaving does not matter. Also, since there is no log
entry, there is no difference in behavior between a benign and a entry, there is no difference in behavior between a benign and a
misbehaving third-party Monitor. Neither will report a problem to misbehaving third-party Monitor. Neither will report a problem to
the Subject. the Subject.
A bogus certificate would not be delivered to the legitimate A bogus certificate would not be delivered to the legitimate Subject.
Subject. So the Subject, acting as a self-Monitor, cannot detect the So the Subject, acting as a self-Monitor, cannot detect the issuance
issuance of a bogus certificate in this case. of a bogus certificate in this case.
3.2.2.1. CT-aware browser 3.2.2.1. CT-aware browser
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 3.3. Undetected Compromise of CAs or Logs
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 superior CAs (which are presumed to be benign).
(The following text refers to these as two CAs, because they might
be represented by entities that are organizationally distinct,
perhaps realized by different physical presences. However, because
they share the same name and key pair, one also might view them as
the same CA that appears in two cert paths terminating at different
TAs.) The two CAs must have the same Subject name and the same
public key for the attack. (RFC 5280 does 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- Sections 3.1 and 3.2 examined attacks in the context of non-malicious
malicious and malicious CAs, and benign and misbehaving logs. and malicious CAs, and benign and misbehaving logs. Another class of
Another class of attacks might occur in the context of a non- attacks might occur in the context of a non-malicious CA and/or a
malicious CA and/or a benign log. Specifically these CT elements benign log. Specifically these CT elements might be compromised and
might be compromised and the compromise might go undetected. 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. Section 3.3 explored the
undetected compromise of a CA in the context of attacks designed to
issue a bogus certificate that might avoid revocation (because the
certificate would appear on distinct certificate paths).
Compromise of CAs and logs was noted in Section 2, as was coercion The section focuses on undetected compromise of CAs. Such
of a CA. As noted there, a compromised CA is essentially a malicious compromises warrant some additional discussion, since some relying
CA, and thus the discussions in Section 3.2 are applicable. The case parties may see signed objects issued by the legitimate (non-
of an undetected compromise warrants some additional discussion, malicious) CA, others may see signed objects from its compromised
since some relying parties may see signed objects issued by the counterpart, and some may see objects from both. In the case of a
legitimate (non-malicious) CA, others may see signed objects from compromised CA or log the adversary is presumed to have access to the
its compromised counterpart, and some may see objects from both. In private key used by a CA to sign certificates, or used by a log to
the case of a compromised CA or log the adversary is presumed to sign SCTs and STHs. Because the compromise is undetected, there will
have access to the private key used by a CA to sign certificates, or be no effort by a CA to have its certificate revoked or by a log to
used by a log to sign SCTs and STHs. Because the compromise is shut down the log.
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 3.3.1. Compromised CA, Benign Log
In the case of a compromised (non-malicious) CA, an attacker uses In the case of a compromised (non-malicious) CA, an attacker uses the
the purloined private key to generate a bogus certificate (that the purloined private key to generate a bogus certificate (that the
compromised CA would not issue). If this certificate is submitted to compromised CA would not issue). If this certificate is submitted to
a (benign) log, then it subject to detection by a Monitor, as 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 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 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 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 not logged, then there will be no SCT, and the implications are as
described in 3.1.2. described in 3.1.2.
This sort of attack may be most effective if the CA that is the 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 victim of the attack has issued a certificate for the targeted
Subject. In this case the bogus certificate will then have the same Subject. In this case the bogus certificate will then have the same
certification path as the legitimate certificate, which may help certification path as the legitimate certificate, which may help hide
hide the bogus certificate. However, means of remedying the attack the bogus certificate. However, means of remedying the attack are
are independent of this aspect, i.e., revocation can be effected independent of this aspect, i.e., revocation can be effected
irrespective of whether the targeted Subject received its irrespective of whether the targeted Subject received its certificate
certificate from the compromised CA. from the compromised CA.
A compromised (non-malicious) CA may be able to revoke the bogus A compromised (non-malicious) CA may be able to revoke the bogus
certificate if it is detected by a Monitor, and the targeted Subject 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 has been notified. It can do so only when the serial number of the
bogus certificate is made known to this CA and assuming that the bogus certificate is made known to this CA and assuming that the
bogus certificate was not issued with an Authority Information bogus certificate was not issued with an Authority Information Access
Access (AIA) or CRL Distribution Point (CRL DP) extension that (AIA) or CRL Distribution Point (CRL DP) extension that enables only
enables only the malicious twin to revoke the certificate. (The AIA the malicious twin to revoke the certificate. (The AIA extension in
extension in the bogus certificate could be used to direct relying the bogus certificate could be used to direct relying parties to an
parties to an OCSP server controlled by the malicious twin. The CRL OCSP server controlled by the malicious twin. The CRL DP extension
DP extension could be used to direct relying parties to a CRL could be used to direct relying parties to a CRL controlled by the
controlled by the malicious twin.) If the bogus certificate malicious twin.) If the bogus certificate contains either extension,
contains either extension, the compromised CA cannot effectively the compromised CA cannot effectively revoke it. However, the
revoke it. However, the presence of either of these extensions presence of either of these extensions provides some evidence that an
provides some evidence that an entity other than the compromised CA entity other than the compromised CA issued the certificate in
issued the certificate in question. (If the extensions differ from question. (If the extensions differ from those in other certificates
those in other certificates issued by the compromised CA, that is issued by the compromised CA, that is suspicious.)
suspicious.)
If the serial number of the bogus certificate is the same as for a 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 valid, not-expired certificate issued by the CA (to the target or to
another Subject), then revocation poses a problem. This is because another Subject), then revocation poses a problem. This is because
revocation of the bogus certificate will also invalidate a revocation of the bogus certificate will also invalidate a legitimate
legitimate certificate. This problem may cause the compromised CA to certificate. This problem may cause the compromised CA to delay
delay revocation, thus allowing the bogus certificate to remain a revocation, thus allowing the bogus certificate to remain a danger
danger for a longer time. for a longer time.
The compromised CA may not realize that the bogus certificate was The compromised CA may not realize that the bogus certificate was
issued by a malicious twin; one occurrence of this sort might be 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 regarded as an error, and not cause the CA to transition to a new key
key pair. (This assumes that the bogus certificate does not contain pair. (This assumes that the bogus certificate does not contain an
an AIA or CRL DP extension that wrests control of revocation from AIA or CRL DP extension that wrests control of revocation from the
the compromised CA.) If the compromised CA does determine that its compromised CA.) If the compromised CA does determine that its
private key has been stolen, it may take some time to transition to private key has been stolen, it probably will take some time to
a new key pair, and reissue certificates to all of its legitimate transition to a new key pair, and reissue certificates to all of its
Subjects. Thus an attack of this sort may take a while to be legitimate Subjects. Thus an attack of this sort probably will take
remedied. a while to be remedied.
Also note that the malicious twin of the compromised CA may be Also note that the malicious twin of the compromised CA may be
capable of issuing its own CRL or OCSP responses, without changing capable of issuing its own CRL or OCSP responses, without changing
any AIA/CRL DP data present in the targeted certificate. The any AIA/CRL DP data present in the targeted certificate. The
revocation status data from the evil twin will appear as valid as revocation status data from the evil twin will appear as valid as
those of the compromised CA. If the attacker has the ability to those of the compromised CA. If the attacker has the ability to
control the sources of revocation status data available to a control the sources of revocation status data available to a targeted
targeted user (browser instance), then the user may not become aware user (browser instance), then the user may not become aware of the
of the attack. attack.
A bogus certificate issued by the malicious CA will not match the A bogus certificate issued by the malicious CA will not match the SCT
SCT for the legitimate certificate, since they are not identical, for the legitimate certificate, since they are not identical, e.g.,
e.g., at a minimum the private keys do not match. Thus a CT-aware at a minimum the private keys do not match. Thus a CT-aware browser
browser that rejects certificates without SCTs (see 3.1.2.2) will that rejects certificates without SCTs (see 3.1.2.2) will reject a
reject a bogus certificate created under these circumstances if it bogus certificate created under these circumstances if it is not
is not logged. If the bogus certificate is detected and logged, logged. If the bogus certificate is detected and logged, browsers
browsers that require an SCT will reject the bogus certificate. that require an SCT will reject the bogus certificate.
3.4.2. Benign CA, Compromised Log 3.3.2. Benign CA, Compromised Log
A benign CA does not issue bogus certificates, except as a result of 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 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 behavior by a compromised log would yield an attack. If a bogus
certificate is issued by a benign CA (under these circumstances) is certificate is issued by a benign CA (under these circumstances) is
submitted to a compromised (non-malicious) log, then both an SCT and 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 a log entry will be created. Again, it is not clear what additional
adverse actions the compromised log would perform to further an adverse actions the compromised log would perform to further an
attack on CT. attack on CT.
It is worth noting that if a benign CA was attacked and thus issued It is worth noting that if a benign CA was attacked and thus issued
one or more bogus certificates, then a malicious log might provide one or more bogus certificates, then a malicious log might provide
split views of its log to help conceal the bogus certificate from split views of its log to help conceal the bogus certificate from
targeted users. Specifically, the log would show an accurate set of targeted users. Specifically, the log would show an accurate set of
log entries (and STHs) to most clients, but would maintain a log entries (and STHs) to most clients, but would maintain a separate
separate log view for targeted users. This sort of attack motivates log view for targeted users. This sort of attack motivates the need
the need for Audit capabilities based on "gossiping" [gossip]. for Audit capabilities based on "gossiping" [I-D.ietf-trans-gossip].
However, even if such mechanisms are employed, they might be However, even if such mechanisms are employed, they might be thwarted
thwarted if a user is unable to exchange log information with if a user is unable to exchange log information with trustworthy
trustworthy partners. partners.
3.4.3. Compromised CA, Compromised Log 3.3.3. Compromised CA, Compromised Log
As noted in 3.4.1, an evil twin CA may issue a bogus certificate As noted in 3.4.1, an evil twin CA may issue a bogus certificate that
that contains the same Subject name as a legitimate certificate contains the same Subject name as a legitimate certificate issued by
issued by the compromised CA. Alternatively, the bogus certificate the compromised CA. Alternatively, the bogus certificate may contain
may contain a different name but reuse a serial number from a valid, a different name but reuse a serial number from a valid, not revoked
not revoked certificate issued by that CA. certificate issued by that CA.
An attacker who compromises a log might act in one of two ways. It An attacker who compromises a log might act in one of two ways. It
might use the private key of the log only to generate SCTs for a might use the private key of the log only to generate SCTs for a
malicious CA or the evil twin of a compromised CA. If a browser malicious CA or the evil twin of a compromised CA. If a browser
checks the signature on an SCT but does not contact a log to verify checks the signature on an SCT but does not contact a log to verify
that the certificate appears in the log, then this is an effective that the certificate appears in the log, then this is an effective
attack strategy. Alternatively, the attacker might not only generate attack strategy. Alternatively, the attacker might not only generate
SCTs, but also pose as the compromised log, at least with regard to SCTs, but also pose as the compromised log, at least with regard to
requests from targeted users. In the latter case, this "evil twin" requests from targeted users. In the latter case, this "evil twin"
log could respond to STH requests from targeted users, making appear log could respond to STH requests from targeted users, making appear
that the compromised log was offering a split view (thus acting as a that the compromised log was offering a split view (thus acting as a
malicious log). To detect this attack an Auditor needs to employ a malicious log). To detect this attack an Auditor needs to employ a
gossip mechanism that is able to acquire CT data from diverse gossip mechanism that is able to acquire CT data from diverse
sources, a feature not yet part of the base CT system. sources, a feature not yet part of the base CT system.
An evil twin CA might submit a bogus certificate to the evil twin of An evil twin CA might submit a bogus certificate to the evil twin of
a compromised log. (The same adversary may be controlling both.) The a compromised log. (The same adversary may be controlling both.)
operator of the evil twin log can use the purloined private key to The operator of the evil twin log can use the purloined private key
generate SCTs for certificates that have not been logged by its to generate SCTs for certificates that have not been logged by its
legitimate counterpart. These SCTs will appear valid relative to the legitimate counterpart. These SCTs will appear valid relative to the
public key associated with the legitimate log. However, an STH public key associated with the legitimate log. However, an STH
issued by the legitimate log will not correspond to a tree issued by the legitimate log will not correspond to a tree
(maintained by the compromised log) containing these SCTs. Thus (maintained by the compromised log) containing these SCTs. Thus
checking the SCTs issued by the evil twin log against STHs from the checking the SCTs issued by the evil twin log against STHs from the
compromised log will identify this discrepancy. As noted above, if compromised log will identify this discrepancy. As noted above, if
an attacker uses the key to generate log entries and respond to log an attacker uses the key to generate log entries and respond to log
queries, the effect is analogous to a malicious log.) queries, the effect is analogous to a malicious log.)
An Auditor checking for log consistency and with access to bogus An Auditor checking for log consistency and with access to bogus
SCTs, might conclude that the compromised log is acting maliciously, SCTs, might conclude that the compromised log is acting maliciously,
and is presenting a split view to its clients. In this fashion the 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 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 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 the legitimate log, they may not be able to detect this
inconsistency. In this case CT would need to rely on a distributed inconsistency. In this case CT would need to rely on a distributed
gossiping audit mechanism to detect the compromise (see Section gossiping audit mechanism to detect the compromise (see Section 5.6).
5.6).
In general, this sort of attack is analogous to a malicious CA 3.4. Using an SCT for a revoked certificate
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 In general, this class 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 3.2.1.2). In that case the lack of a
log entry prevented detection of the bogus certificate by Monitors,
and the presence of the SCT prevented rejection by a CT-aware browser
that accepts SCTs from the compromised log. A more insidious type of
attack calls for a bogus certificate to be issued and logged, but
tries to evade remediation by relying on the fact that some several
certificate revocation depend on the certificate path under which a
certificate has been revoked.
4.1. Non-malicious Web PKI CA context Section 3.2 examined attacks in which a single CA might issue a bogus
certificate. There is also the potential that two or more instances
of a CA might issue a bogus certificate in a fashion designed to foil
the remediation (but not detection) safeguards envisioned by CT. For
simplicity of exposition, we refer to these CA instances as CA-1 and
CA-2.
CA-1 and CA-2 may both be malicious and might even appear to be
distinct CAs based on registration information provided to the CAs
that issue certificates to them. This type of attack requires that
these CA instances have the same name and the same public key, but
during registration they might provide different contact information,
e.g., postal and e-mail addresses, phone numbers, etc. In this case
they would appear to be distinct CAs, even though they operate as one
CA.
RFC 5280 requires that no CA issue certificates with the same Subject
name to distinct entities (Section 4.2.1.6). However, if a CA is the
victim of an attack, it might not be aware that a certificate was
issued for CA-1 or CA-2. Also, if CA-1 and CA-2 acquire certificates
from different parent CAs, there is no requirement defined in 5280
that ensures these parents would detect the use of the same name and
public key by CA-1 and CA-2. (The Security Considerations section of
RFC 5280 warns that name collisions in certificates could cause
security problems, but it does not specify a means by which they can
be detected and avoided on a global basis.)
Once certificates have been issued to CA-1 and CA-2, they can issue a
bogus certificate that targets a Subject (call it X). For the attack
to succeed, the certificate for X must be identical, irrespective of
the CA instance under which it was issued. Note that these attacks
may take place without the knowledge or assistance of trust anchors;
any pair of intermediate CAs can effect this attack without the
knowledge of superior CAs (which are presumed to be benign).
This type of attack assumes that X is logged by CA-1 (without loss of
generality) and thus can be detected by a Monitor tracking
certificates issued in the name of X. It is assumed that CA-1 will
revoke the bogus certificate when the targeted Subject is notified of
that certificate's existence. CA-2 will not log the bogus
certificate nor will it revoke the certificate. The SCT for X is
independent of the CA instance under which it was issued. The
revocation of X by CA-1 may not cause X to be viewed as revoked when
it is encountered as part of the certificate path including CA-2,
depending on revocation mechanism employed (see 3.4.1).
It is not necessary for both CA-1 and CA-2 to be malicious. CA-1
could, be the victim of a compromise under which X is issued. An
adversary could then cause CA-2 to be created by registering it with
an unsuspecting CA, or by compromising another, different CA. Other
variations of the attack are possible, e.g., employing attacks on CAs
to create subordinate CAs representing CA-1 and CA-2. The only
requirements are that the CAs that are attacked are authorized to
issue subordinate CA certificates (pathLenConstraint of 1 or greater)
and that any name constraints imposed on these CAs do not prohibit
issuing a certificate to X.
If CA-1 was the victim of an attack, revocation of the bogus
certificate, e.g., via a CRL or via OCSP, is the expected response.
Additionally, a browser vendor might add the bogus certificate to a
blacklist maintained by the vendor, e.g., if CA-1 failed to revoke it
or maybe as a precautionary measure.
If CA-1 is suspected of being malicious, e.g., because it has a
history of using bogus certificates, its certificate might be
revoked. This revocation might be effected by the parent of that CA
(which is assumed to not be 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.4.1. Revocation of the Bogus Certificate
If the bogus certificate (X) is revoked by CA-1, 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 bogus certificate when it is encountered as under CA-2. This is
because revocation status checking is performed in the context of a
certification path (during path validation). The bogus certificate
(X) has two 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 certificate contains an AIA extension pointing to
an OCSP server the attack might still succeed. (As noted in the
Section 1 above, 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 a
malicious CA (e.g., CA-B) 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 bogus certificate could
contain a CRL distribution point extension instead of an AIA
extension. In that case a site supplying CRLs for CA-2 could supply
different CRLs to different requestors, in an attempt to hide the
revocation status of the bogus certificate from targeted browser
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 CA-1 (who 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.
The failure of a bogus certificate (X) to be detected as revoked (by
a browser) is not the fault of CT. In the class of attacks described
here, CT achieves its goal of detecting the bogus certificate when
that certificate is logged and a Monitor observes the log entry.
Detection is intended to trigger revocation, to effect remediation,
which is outside the scope of CT. However the SCT mechanism is
intended to assure a relying party that certificate has been logged,
is susceptible to being detected as bogus by a Monitor, and
presumably will be revoked if detected as such. In the context of
these attacks, because of the way revocation may be effected, the
assurance provided by the SCT may not have the anticipated effect.
3.4.2. Revocation of a CA Certificate
If CA-1 is viewed as acting maliciously, its parent might revoke that
CA's certificate. Even though CA-2 has the same name and uses the
same public key, its certificates is distinct from that of CA-A,
e.g., it was issued by a different parent and almost certainly has a
different certificate serial number. Thus revocation of the
certificate of CA-1 does not affect the certificate of CA-2. In this
case, the bogus EE certificate (X) would be treated as valid when it
appears in a certification path involving CA-2. Thus revocation the
certificate for CA-1 does not prevent this attack from succeeding.
A vendor also might choose to add the certificate of CA-1 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.
4. Syntactic mis-issuance
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
4.1.1.1. Benign log 4.1.1.1. Benign log
If a (pre-)certificate is submitted to a benign log, syntactic mis- If a (pre )certificate is submitted to a benign log, syntactic mis-
issuance can (optionally) be detected, and noted. This will happen issuance can (optionally) be detected, and noted. This will happen
only if the log performs syntactic checks in general, and if the log only if the log performs syntactic checks in general, and if the log
is capable of performing the checks applicable to the submitted is capable of performing the checks applicable to the submitted (pre
(pre-)certificate. (A (pre-)certificate SHOULD be logged even if it )certificate. (A (pre )certificate SHOULD be logged even if it fails
fails syntactic validation; logging takes precedence over detection syntactic validation; logging takes precedence over detection of
of syntactic mis-issuance.) If syntactic validation fails, this can syntactic mis-issuance.) If syntactic validation fails, this can be
be noted in an SCT extension returned to the submitter. noted in an SCT extension returned to the submitter.
If the (pre-)certificate is submitted by the non-malicious issuing If the (pre )certificate is submitted by the non-malicious issuing
CA, then the CA SHOULD remedy the syntactic problem and re-submit CA, then the CA SHOULD remedy the syntactic problem and re-submit the
the (pre-)certificate to a log or logs. If this is a pre-certificate (pre )certificate to a log or logs. If this is a pre-certificate
submitted prior to issuance, syntactic checking by a log helps avoid submitted prior to issuance, syntactic checking by a log helps avoid
issuance of an erroneous certificate. If the CA does not have a issuance of an erroneous certificate. If the CA does not have a
record of the certificate contents, then presumably it was a bogus record of the certificate contents, then presumably it was a bogus
certificate and the CA SHOULD revoke it. certificate and the CA SHOULD revoke it.
If a certificate is submitted by its Subject, and is deemed If a certificate is submitted by its Subject, and is deemed
erroneous, then the Subject SHOULD contact the issuing CA and erroneous, then the Subject SHOULD contact the issuing CA and request
request a new certificate. If the Subject is a legitimate subscriber a new certificate. If the Subject is a legitimate subscriber of the
of the CA, then the CA will either have a record of the certificate CA, then the CA will either have a record of the certificate content
content or can obtain a copy of the certificate from the Subject. or can obtain a copy of the certificate from the Subject. The CA
The CA will remedy the syntactic problem and either re-submit a will remedy the syntactic problem and either re-submit a corrected
corrected (pre-)certificate to a log and send it to the Subject or (pre-)certificate to a log and send it to the Subject or the Subject
the Subject will re-submit it to a log. Here too syntactic checking will re-submit it to a log. Here too syntactic checking by a log
by a log enables a Subject to be informed that its certificate is enables a Subject to be informed that its certificate is erroneous
erroneous and thus may hasten issuance of a replacement certificate. and thus may hasten issuance of a replacement certificate.
If a certificate is submitted by a third party, that party might If a certificate is submitted by a third party, that party might
contact the Subject or the issuing CA, but because the party is not contact the Subject or the issuing CA, but because the party is not
the Subject of the certificate it is not clear how the CA will the Subject of the certificate it is not clear how the CA will
respond. respond.
This analysis suggests that syntactic mis-issuance of a certificate This analysis suggests that syntactic mis-issuance of a certificate
can be avoided by a CA if it makes use of logs that are capable of 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 performing these checks for the types of certificates that are
submitted, and if the CA acts on the feedback it receives. If a CA 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 uses a log that does not perform such checks, or if the CA requests
checking relative to criteria not supported by the log, then checking relative to criteria not supported by the log, then
syntactic mis-issuance will not be detected or avoided by this syntactic mis-issuance will not be detected or avoided by this
mechanism. Similarly, syntactic mis-issuance can be remedied if a mechanism. Similarly, syntactic mis-issuance can be remedied if a
Subject submits a certificate to a log that performs syntactic Subject submits a certificate to a log that performs syntactic
checks, and if the Subject asks the issuing CA to fix problems checks, and if the Subject asks the issuing CA to fix problems
detected by the log. (The issuer is presumed to be willing to re- detected by the log. (The issuer is presumed to be willing to re-
issue the certificate, correcting any problems, because the issuing issue the certificate, correcting any problems, because the issuing
CA is not malicious.) CA is not malicious.)
4.1.1.2. Misbehaving log or third party Monitor 4.1.1.2. Misbehaving log or third party Monitor
A log or Monitor that is conspiring with the attacker or is A log or Monitor that is conspiring with the attacker or is
independently malicious, will either not perform syntactic checks, independently malicious, will either not perform syntactic checks,
even though it claims to do so, or simply not report errors. The log even though it claims to do so, or simply not report errors. The log
entry and the SCT for an erroneous certificate will assert that the entry and the SCT for an erroneous certificate will assert that the
certificate syntax was verified. certificate syntax was verified.
As with detection of semantic mis-issuance, a distributed Audit As with detection of semantic mis-issuance, a distributed Audit
mechanism could, in principle, detect misbehavior by logs or mechanism could, in principle, detect misbehavior by logs or Monitors
Monitors with respect to syntactic checking. For example, if for a with respect to syntactic checking. For example, if for a given
given certificate, some logs (or Monitors) are reporting syntactic certificate, some logs (or Monitors) are reporting syntactic errors
errors and some that claim to do syntactic checking, are not and some that claim to do syntactic checking, are not reporting these
reporting these errors, this is indicative of misbehavior by these errors, this is indicative of misbehavior by these logs and/or
logs and/or Monitors. Monitors.
Note that a malicious log (or Monitor) could report syntactic errors Note that a malicious log (or Monitor) could report syntactic errors
for a syntactically valid certificate. This could result in for a syntactically valid certificate. This could result in
reporting of non-existent syntactic problems to the issuing CA, reporting of non-existent syntactic problems to the issuing CA, which
which might cause the CA to do needless investigative work or might cause the CA to do needless investigative work or perhaps
perhaps incorrectly revoke and re-issue the Subject's certificate. incorrectly revoke and re-issue the Subject's certificate.
4.1.1.3. Self-monitoring Subject and Benign third party Monitor 4.1.1.3. Self-monitoring Subject and Benign third party Monitor
If a Subject or benign third party Monitor performs syntactic If a Subject or benign third party Monitor performs syntactic checks,
checks, it will detect the erroneous certificate and the issuing CA it will detect the erroneous certificate and the issuing CA will be
will be notified (by the Subject). If the Subject is a legitimate notified (by the Subject). If the Subject is a legitimate subscriber
subscriber of the CA, then the CA will either have a record of the of the CA, then the CA will either have a record of the certificate
certificate content or can obtain a copy of the certificate from the content or can obtain a copy of the certificate from the Subject.
Subject. The CA SHOULD revoke the erroneous certificate (after The CA SHOULD revoke the erroneous certificate (after investigation)
investigation) and remedy the syntactic problem. The CA SHOULD and remedy the syntactic problem. The CA SHOULD either re-submit the
either re-submit the corrected (pre-)certificate to one or more logs corrected (pre )certificate to one or more logs and then send the
and then send the result to the Subject, or send the corrected result to the Subject, or send the corrected certificate to the
certificate to the Subject, who will re-submit it to one or more Subject, who will re-submit it to one or more logs.
logs.
4.1.1.4. CT-enabled browser 4.1.1.4. CT-enabled browser
If a browser rejects an erroneous certificate and notifies the If a browser rejects an erroneous certificate and notifies the
Subject and/or the issuing CA, then syntactic mis-issuance will be Subject and/or the issuing CA, then syntactic mis-issuance will be
detected (see Section 5). Unfortunately, experience suggests that detected (see Section 5.) Unfortunately, experience suggests that
many browsers do not perform thorough syntactic checks on many browsers do not perform thorough syntactic checks on
certificates, and so it seems unlikely that browsers will be a certificates, and so it seems unlikely that browsers will be a
reliable way to detect erroneous certificates. Moreover, a protocol reliable way to detect erroneous certificates. Moreover, a protocol
used by a browser to notify a Subject and/or CA of an erroneous used by a browser to notify a Subject and/or CA of an erroneous
certificate represents a DoS potential, and thus may not be certificate represents a DoS potential, and thus may not be
appropriate. Additionally, if a browser directly contacts a CA when appropriate. Additionally, if a browser directly contacts a CA when
an erroneous certificate is detected, this is a potential privacy an erroneous certificate is detected, this is a potential privacy
violation, i.e., the CA learns that the browser user is visiting the violation, i.e., the CA learns that the browser user is visiting the
web site in question. These observations argue for syntactic web site in question. These observations argue for syntactic
checking to be performed by other elements of the CT system, e.g., checking to be performed by other elements of the CT system, e.g.,
logs and/or Monitors. logs and/or Monitors.
4.1.2. Certificate not logged 4.1.2. Certificate not logged
If a CA does not submit a certificate to a log, there can be no If a CA does not submit a certificate to a log, there can be no
syntactic checking by the log. Detection of syntactic errors will syntactic checking by the log. Detection of syntactic errors will
depend on a Subject performing the requisite checks when it receives depend on a Subject performing the requisite checks when it receives
its certificate from a CA. A Monitor that performs syntactic checks its certificate from a CA. A Monitor that performs syntactic checks
on behalf of a Subject also could detect such problems, but the CT on behalf of a Subject also could detect such problems, but the CT
architecture does not require Monitors to perform such checks. architecture does not require Monitors to perform such checks.
4.2. Malicious Web PKI CA context 4.2. Malicious Web PKI CA context
This section analyzes the scenario in which the CA's issuance of a This section analyzes the scenario in which the CA's issuance of a
syntactically incorrect certificate is intentional, not due to syntactically incorrect certificate is intentional, not due to error.
error. The CA is not the victim but the attacker. The CA is not the victim but the attacker.
4.2.1. Certificate logged 4.2.1. Certificate logged
4.2.1.1. Benign log 4.2.1.1. Benign log
Because the CA is presumed to be malicious, the CA may cause the log Because the CA is presumed to be malicious, the CA may cause the log
to not perform checks, in one of several ways. (See [DOMVAL] and to not perform checks, in one of several ways. (See
[EXTVAL] for more details on validation checks and CCIDs). [I-D.kent-trans-domain-validation-cert-checks] and
[I-D.kent-trans-extended-validation-cert-checks] for more details on
validation checks and CCIDs).
1. The CA may assert that the certificate is being issued w/o regard 1. The CA may assert that the certificate is being issued w/o regard
to any guidelines (the "no guidelines" reserved CCID). to any guidelines (the "no guidelines" reserved CCID).
2. The CA may assert a CCID that has not been registered, and thus 2. The CA may assert a CCID that has not been registered, and thus
no log will be able to perform a check. no log will be able to perform a check.
3. The CA may check to see which CCIDs a log declares it can 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 and chose a registered CCID that is not checked by the log in
question. question.
4. The CA may submit a (pre-) certificate to a log that is known to 4. The CA may submit a (pre-) certificate to a log that is known to
not perform any syntactic checks, and thus avoid syntactic not perform any syntactic checks, and thus avoid syntactic
checking. checking.
4.2.1.2. Misbehaving log or third party Monitor 4.2.1.2. Misbehaving log or third party Monitor
A misbehaving log or third party Monitor will either not perform A misbehaving log or third party Monitor will either not perform
syntactic checks or not report any problems that it discovers. (See syntactic checks or not report any problems that it discovers. (See
4.1.1.2 for further problems). Also, as noted above, the CT 4.1.1.2 for further problems). Also, as noted above, the CT
architecture includes no explicit provisions for detecting a architecture includes no explicit provisions for detecting a
misbehaving third-party Monitor. misbehaving third-party Monitor.
4.2.1.3. Self-monitoring Subject and Benign third party Monitor 4.2.1.3. Self-monitoring Subject and Benign third party Monitor
Irrespective of whether syntactic checks are performed by a log, a Irrespective of whether syntactic checks are performed by a log, a
malicious CA will acquire an embedded SCT, or post-issuance will malicious CA will acquire an embedded SCT, or post-issuance will
acquire a standalone SCT. If Subjects or Monitors perform syntactic acquire a standalone SCT. If Subjects or Monitors perform syntactic
checks that detect the syntactic mis-issuance and report the problem checks that detect the syntactic mis-issuance and report the problem
to the CA, a malicious CA may do nothing or may delay the action(s) to the CA, a malicious CA may do nothing or may delay the action(s)
needed to remedy the problem. needed to remedy the problem.
4.2.1.4. CT-enabled browser 4.2.1.4. CT-enabled browser
As noted above (4.1.1.4), most browsers fail to perform thorough As noted above (4.1.1.4), most browsers fail to perform thorough
syntax checks on certificates. Such browsers might benefit from syntax checks on certificates. Such browsers might benefit from
having syntax checks performed by a log and reported in the SCT, having syntax checks performed by a log and reported in the SCT,
although the pervasive nature of syntactically-defective although the pervasive nature of syntactically-defective certificates
certificates may limit the utility of such checks. (Remember, in may limit the utility of such checks. (Remember, in this scenario,
this scenario, the log is benign.) However, if a browser does not the log is benign.) However, if a browser does not discriminate
discriminate against certificates that do not contain SCTs (or that against certificates that do not contain SCTs (or that are not
are not accompanied by an SCT in the TLS handshake), only minimal accompanied by an SCT in the TLS handshake), only minimal benefits
benefits might accrue to the browser from syntax checks perform by might accrue to the browser from syntax checks perform by logs or
logs or Monitors. Monitors.
If a browser accepts certificates that do not appear to have been If a browser accepts certificates that do not appear to have been
syntactically checked by a log (as indicated by the SCT), a syntactically checked by a log (as indicated by the SCT), a malicious
malicious CA need not worry about failing a log-based check. CA need not worry about failing a log-based check. Similarly, if
Similarly, if there is no requirement for a browser to reject a there is no requirement for a browser to reject a certificate that
certificate that was logged by an operator that does not perform was logged by an operator that does not perform syntactic checks, the
syntactic checks, the fourth attack noted in 4.2.1.1 will succeed as fourth attack noted in 4.2.1.1 will succeed as well. If a browser
well. If a browser were configured to know which versions of were configured to know which versions of certificate types are
certificate types are applicable to its use of a certificate, the applicable to its use of a certificate, the second and third attack
second and third attack strategies noted above could be thwarted. strategies noted above could be thwarted.
4.2.2. Certificate is not logged 4.2.2. Certificate is not logged
Since certificates are not logged in this scenario, a Monitor Since certificates are not logged in this scenario, a Monitor (third-
(third-party or self) cannot detect the issuance of an erroneous party or self) cannot detect the issuance of an erroneous
certificate. Thus there is no difference between a benign or a certificate. Thus there is no difference between a benign or a
malicious/conspiring log or a benign or conspiring/malicious malicious/conspiring log or a benign or conspiring/malicious Monitor.
Monitor. (A Subject MAY detect a syntax error by examining the (A Subject MAY detect a syntax error by examining the certificate
certificate returned to it by the Issuer.) However, even if errors returned to it by the Issuer.) However, even if errors are detected
are detected and reported to the CA, a malicious/conspiring CA may and reported to the CA, a malicious/conspiring CA may do nothing to
do nothing to fix the problem or may delay action. fix the problem or may delay action.
5. Issues Applicable to Sections 3 and 4 5. Issues Applicable to Sections 3 and 4
5.1. How does a Subject know which Monitor(s) to use? 5.1. How does a Subject know which Monitor(s) to use?
If a CA submits a bogus certificate to one or more logs, but these If a CA submits a bogus certificate to one or more logs, but these
logs are not tracked by a Monitor that is protecting the targeted logs are not tracked by a Monitor that is protecting the targeted
Subject, CT will not remedy this type of mis-issuance attack. If Subject, CT will not remedy this type of mis-issuance attack. If
third-party Monitors advertise which logs they track, Subjects may third-party Monitors advertise which logs they track, Subjects may be
be able to use this information to select an appropriate Monitor (or able to use this information to select an appropriate Monitor (or set
set thereof). Also, it is not clear whether every third-party thereof). Also, it is not clear whether every third-party Monitor
Monitor MUST offer to track every Subject that requests protection. MUST offer to track every Subject that requests protection. If a
If a Subject acts as its own Monitor, this problem is solved for Subject acts as its own Monitor, this problem is solved for that
that Subject. Subject.
5.2. How does a Monitor discover new logs? 5.2. How does a Monitor discover new logs?
It is not clear how a (self-)Monitor becomes aware of all (relevant) It is not clear how a (self-)Monitor becomes aware of all (relevant)
logs, including newly created logs. The means by which Monitors logs, including newly created logs. The means by which Monitors
become aware of new logs MUST accommodate self-monitoring by a become aware of new logs MUST accommodate self-monitoring by a
potentially very large number of web site operators. If there are potentially very large number of web site operators. If there are
many logs, it may not be feasible for a (self-) Monitor to track all many logs, it may not be feasible for a (self-) Monitor to track all
of them, or to determine what set of logs suffice to ensure an of them, or to determine what set of logs suffice to ensure an
adequate level of coverage. adequate level of coverage.
5.3. CA response to report of a bogus or erroneous certificate 5.3. CA response to report of a bogus or erroneous certificate
A CA being presented with evidence of a bogus or erroneous A CA being presented with evidence of a bogus or erroneous
certificate, in the form of a log entry and/or SCT, will need to certificate, in the form of a log entry and/or SCT, will need to
examine its records to determine if it has knowledge of the examine its records to determine if it has knowledge of the
certificate in question. It also will likely require the targeted certificate in question. It also will likely require the targeted
Subject to provide assurances that it is the authorized entity Subject to provide assurances that it is the authorized entity
representing the Subject name (subjectAltname) in question. Thus a representing the Subject name (subjectAltname) in question. Thus a
Subject should not expect immediate revocation of a contested Subject should not expect immediate revocation of a contested
certificate. The time frame in which a CA will respond to a certificate. The time frame in which a CA will respond to a
revocation request usually is described in the CPS for the CA. Other revocation request usually is described in the CPS for the CA. Other
certificate fields and extensions may be of interest for forensic certificate fields and extensions may be of interest for forensic
purposes, but are not required to effect revocation nor to verify purposes, but are not required to effect revocation nor to verify
that the certificate to be revoked is bogus or erroneous, based on that the certificate to be revoked is bogus or erroneous, based on
applicable criteria. The SCT and log entry, because each contains a applicable criteria. The SCT and log entry, because each contains a
timestamp from a third party, is probably valuable for forensic timestamp from a third party, is probably valuable for forensic
purposes (assuming a non-conspiring log operator). purposes (assuming a non-conspiring log operator).
5.4. Browser behavior 5.4. Browser behavior
If a browser is to reject a certificate that lacks an embedded SCT, If a browser is to reject a certificate that lacks an embedded SCT,
or is not accompanied by an SCT transported via the TLS handshake, 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 this behavior needs to be defined in a way that is compatible with
incremental deployment. Issuing a warning to a (human) user is incremental deployment. Issuing a warning to a (human) user is
probably insufficient, based on experience with warnings displayed probably insufficient, based on experience with warnings displayed
for expired certificates, lack of certificate revocation status for expired certificates, lack of certificate revocation status
information, and similar errors that violate RFC 5280 path information, and similar errors that violate RFC 5280 path validation
validation rules [RFC5280]. Unless a mechanism is defined that rules [RFC5280]. Unless a mechanism is defined that accommodates
accommodates incremental deployment of this capability, attackers incremental deployment of this capability, attackers probably will
probably will avoid submitting bogus certificates to (benign) logs avoid submitting bogus certificates to (benign) logs as a means of
as a means of evading detection. evading detection.
5.5. Remediation for a malicious CA 5.5. Remediation for a malicious CA
A targeted Subject might ask the parent of a malicious CA to revoke A targeted Subject might ask the parent of a malicious CA to revoke
the certificate of the non-cooperative CA. However, a request of the certificate of the non-cooperative CA. However, a request of
this sort may be rejected, e.g., because of the potential for this sort may be rejected, e.g., because of the potential for
significant collateral damage. A browser might be configured to significant collateral damage. A browser might be configured to
reject all certificates issued by the malicious CA, e.g., using a reject all certificates issued by the malicious CA, e.g., using a
bad-CA-list distributed by a browser vendor. However, if the bad-CA-list distributed by a browser vendor. However, if the
malicious CA has a sufficient number of legitimate clients, treating malicious CA has a sufficient number of legitimate clients, treating
all of their certificates as bogus or erroneous still represents all of their certificates as bogus or erroneous still represents
serious collateral damage. If this specification were to require serious collateral damage. If this specification were to require
that a browser can be configured to reject a specific, bogus or that a browser can be configured to reject a specific, bogus or
erroneous certificate identified by a Monitor, then the bogus or erroneous certificate identified by a Monitor, then the bogus or
erroneous certificate could be rejected in that fashion. This erroneous certificate could be rejected in that fashion. This
remediation strategy calls for communication between Monitors and remediation strategy calls for communication between Monitors and
browsers, or between Monitors and browser vendors. Such browsers, or between Monitors and browser vendors. Such
communication has not been specified, i.e., there are no standard communication has not been specified, i.e., there are no standard
ways to configure a browser to reject individual bogus or erroneous ways to configure a browser to reject individual bogus or erroneous
certificates based on information provided by an external entity certificates based on information provided by an external entity such
such as a Monitor. Moreover, the same or another malicious CA could as a Monitor. Moreover, the same or another malicious CA could issue
issue new bogus or erroneous certificates for the targeted Subject, new bogus or erroneous certificates for the targeted Subject, which
which would have to be detected and rejected in this (as yet would have to be detected and rejected in this (as yet unspecified)
unspecified) fashion. Thus, for now, CT does not seem to provide a fashion. Thus, for now, CT does not seem to provide a way to
way to facilitate remediation of this form of attack, even though it facilitate remediation of this form of attack, even though it
provides a basis for detecting such attacks. provides a basis for detecting such attacks.
5.6. Auditing - detecting misbehaving logs 5.6. Auditing - detecting misbehaving logs
The combination of a malicious CA and one or more conspiring logs The combination of a malicious CA and one or more conspiring logs
motivates the definition of an audit function, to detect conspiring motivates the definition of an audit function, to detect conspiring
logs. If a Monitor protecting a Subject does not see bogus logs. If a Monitor protecting a Subject does not see bogus
certificates, it cannot alert the Subject. If one or more SCTs are certificates, it cannot alert the Subject. If one or more SCTs are
present in a certificate, or passed via the TLS handshake, a browser present in a certificate, or passed via the TLS handshake, a browser
has no way to know that the logged certificate is not visible to has no way to know that the logged certificate is not visible to
Monitors. Only if Monitors and browsers reject certificates that Monitors. Only if Monitors and browsers reject certificates that
contain SCTs from conspiring logs (based on information from an contain SCTs from conspiring logs (based on information from an
auditor) will CT be able to detect and deter use of such logs. Thus auditor) will CT be able to detect and deter use of such logs. Thus
the means by which a Monitor performing an audit function detects the means by which a Monitor performing an audit function detects
such logs, and informs browsers must be specified for CT to be such logs, and informs browsers must be specified for CT to be
effective in the context of misbehaving logs. effective in the context of misbehaving logs.
Absent a well-defined mechanism that enables Monitors to verify that Absent a well-defined mechanism that enables Monitors to verify that
data from logs are reported in a consistent fashion, CT cannot claim data from logs are reported in a consistent fashion, CT cannot claim
to provide protection against logs that are malicious or may to provide protection against logs that are malicious or may conspire
conspire with, or are victims of, attackers effecting certificate with, or are victims of, attackers effecting certificate mis-
mis-issuance. The mechanism needs to protect the privacy of users issuance. The mechanism needs to protect the privacy of users with
with respect to which web sites they visit. It needs to scale to respect to which web sites they visit. It needs to scale to
accommodate a potentially large number of self-monitoring Subjects accommodate a potentially large number of self-monitoring Subjects
and a vast number of browsers, if browsers are part of the and a vast number of browsers, if browsers are part of the mechanism.
mechanism. Even when an Audit mechanism is defined, it will be Even when an Audit mechanism is defined, it will be necessary to
necessary to describe how the CT system will deal with a misbehaving describe how the CT system will deal with a misbehaving or
or compromised log. For example, will there be a mechanism to alert compromised log. For example, will there be a mechanism to alert all
all browsers to reject SCTs issued by such a log? Absent a browsers to reject SCTs issued by such a log? Absent a description
description of a remediation strategy to deal with misbehaving or of a remediation strategy to deal with misbehaving or compromised
compromised logs, CT cannot ensure detection of mis-issuance in a logs, CT cannot ensure detection of mis-issuance in a wide range of
wide range of scenarios. scenarios.
Monitors play a critical role in detecting semantic certificate mis- Monitors play a critical role in detecting semantic certificate mis-
issuance, for Subjects that have requested monitoring of their issuance, for Subjects that have requested monitoring of their
certificates. A monitor (including a Subject performing self- certificates. A monitor (including a Subject performing self-
monitoring) examines logs for certificates associated with one or monitoring) examines logs for certificates associated with one or
more Subjects that are being "protected". A third-party Monitor must more Subjects that are being "protected". A third-party Monitor must
obtain a list of valid certificates for the Subject being monitored, obtain a list of valid certificates for the Subject being monitored,
in a secure manner, to use as a reference. It also must be able to in a secure manner, to use as a reference. It also must be able to
identify and track a potentially large number of logs on behalf of identify and track a potentially large number of logs on behalf of
its Subjects. This may be a daunting task for Subjects that elect to its Subjects. This may be a daunting task for Subjects that elect to
perform self-monitoring. perform self-monitoring.
Note: A Monitor must not rely on a CA or RA database for its Note: A Monitor must not rely on a CA or RA database for its
reference information or use certificate discovery protocols; this reference information or use certificate discovery protocols; this
information must be acquired by the Monitor based on reference information must be acquired by the Monitor based on reference
certificates provided by a Subject. If a Monitor were to rely on a 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), CA or RA database (for the CA that issued a targeted certificate),
the Monitor would not detect mis-issuance due to malfeasance on the 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 part of that CA or the RA, or due to compromise of the CA or the RA.
RA. If a CA or RA database is used, it would support detection of If a CA or RA database is used, it would support detection of mis-
mis-issuance by an unauthorized CA. A Monitor must not rely on issuance by an unauthorized CA. A Monitor must not rely on
certificate discovery mechanisms to build the list of valid certificate discovery mechanisms to build the list of valid
certificates since such mechanisms might result in bogus or certificates since such mechanisms might result in bogus or erroneous
erroneous certificates being added to the list. 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 bogus or erroneous certificate targeting that
Subject, as noted above. It is suggested 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.
6. IANA Considerations
None. 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 bogus or erroneous certificate targeting that Subject, as noted
above. It is suggested 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.
7. Security Considerations 6. Security Considerations
An attack and threat model is, by definition, a security-centric An attack and threat model is, by definition, a security-centric
document. Unlike a protocol description, a threat model does not document. Unlike a protocol description, a threat model does not
create security problems nor does it purport to address security create security problems nor does it purport to address security
problems. This model postulates a set of threats (i.e., motivated, problems. This model postulates a set of threats (i.e., motivated,
capable adversaries) and examines classes of attacks that these capable adversaries) and examines classes of attacks that these
threats are capable of effecting, based on the motivations ascribed threats are capable of effecting, based on the motivations ascribed
to the threats. It then analyses the ways in which the CT to the threats. It then analyses the ways in which the CT
architecture addresses these attacks. architecture addresses these attacks.
8. References 7. IANA Considerations
8.1. Normative References None.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 8. Acknowledgments
Requirement Levels," BCP 14, RFC 2119, March 1997.
[CTarch] Kent, S., Mandelberg, D., Seo, K., "Certificate The author would like to thank David Mandelberg and Karen Seo for
Transparency (CT) System Architecture", draft-kent- their assistance in reviewing and preparing this document, and other
trans-architecture-02, (January 2016), work in progress. members of the TRANS working group for reviewing it.
8.2. Informative References 9. References
[TRANS] Laurie, B., Langley, A., Kasper, E., Messeri, E., 9.1. Normative References
Stradling, R., "Certificate Transparency," draft-ietf-
trans-rfc6962-bis-16 (May 27, 2016), work in progress.
[DOMVAL] Kent, S., Andrews, R., "Syntactic and Semantic Checks [I-D.kent-trans-architecture]
for Domain Validation Certificates," draft-kent-trans- Kent, D., Mandelberg, D., and K. Seo, "Certificate
domain-validation-cert-checks-02, (December 2015), work Transparency (CT) System Architecture", draft-kent-trans-
in progress. architecture-04 (work in progress), August 2016.
[EXTVAL] Kent, S., Andrews, R., "Syntactic and Semantic Checks [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
for Extended Validation Certificates," draft-kent-trans- Requirement Levels", BCP 14, RFC 2119,
extended-validation-cert-checks-02 (December 2015), work DOI 10.17487/RFC2119, March 1997,
in progress. <http://www.rfc-editor.org/info/rfc2119>.
[gossip] Nordberg, L., Gillmore, D., Ritter, T., "Gossiping in 9.2. Informative References
CT," draft-ietf-trans-gossip-02, (March 21, 2016), work
in progress.
[RFC5280] Cooper, D., Santession, S., Farrell, S., Boeyen, S., [I-D.ietf-trans-gossip]
Housley, R., Polk, W., "Internet X.509 Public Key Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in
Infrastructure Certificate and Certificate Revocation CT", draft-ietf-trans-gossip-03 (work in progress), July
List (CRL) Profile," RFC 5280, May 2008. 2016.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [I-D.ietf-trans-rfc6962-bis]
Extensions: Extension Definitions", RFC 6066, DOI Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
10.17487/RFC6066, January 2011, <http://www.rfc- Stradling, "Certificate Transparency", draft-ietf-trans-
editor.org/info/rfc6066>. rfc6962-bis-18 (work in progress), July 2016.
[RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., [I-D.kent-trans-domain-validation-cert-checks]
Galperin, S., and C. Adams, "X.509 Internet Public Key Kent, S. and R. Andrews, "Syntactic and Semantic Checks
Infrastructure Online Certificate Status Protocol - for Domain Validation Certificates", draft-kent-trans-
OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013, domain-validation-cert-checks-02 (work in progress),
<http://www.rfc-editor.org/info/rfc6960>. December 2015.
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [I-D.kent-trans-extended-validation-cert-checks]
Multiple Certificate Status Request Extension", RFC Kent, S. and R. Andrews, "Syntactic and Semantic Checks
6961, DOI 10.17487/RFC6961, June 2013, <http://www.rfc- for Extended Validation Certificates", draft-kent-trans-
editor.org/info/rfc6961>. extended-validation-cert-checks-02 (work in progress),
December 2015.
[VASCO] VASCO, "DigiNotar reports security incident", [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
<https://www.vasco.com/about-vasco/press/2011/ Housley, R., and W. Polk, "Internet X.509 Public Key
news_diginotar_reports_security_incident.html> Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>.
Acknowledgments [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011,
<http://www.rfc-editor.org/info/rfc6066>.
The author would like to thank David Mandelberg and Karen Seo for [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
their assistance in reviewing and preparing this document, and other Galperin, S., and C. Adams, "X.509 Internet Public Key
members of the TRANS working group for reviewing it. Infrastructure Online Certificate Status Protocol - OCSP",
RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>.
Author's Addresses [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013,
<http://www.rfc-editor.org/info/rfc6961>.
Author's Address
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge MA 02138 Cambridge, MA 02138
USA USA
Phone: +1 (617) 873-3988 Phone: +1 (617) 873-3988
Email: skent@bbn.com Email: skent@bbn.com
 End of changes. 260 change blocks. 
890 lines changed or deleted 899 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/