draft-ietf-trans-threat-analysis-05.txt   draft-ietf-trans-threat-analysis-06.txt 
Public Notary Transparency S. Kent Public Notary Transparency S. Kent
Internet Draft BBN Technologies Internet Draft BBN Technologies
Expires: October 2016 April 7, 2016 Expires: November 2016 May 31, 2016
Intended Status: Informational Intended Status: Informational
Attack Model and Threat for Certificate Transparency Attack Model and Threat for Certificate Transparency
draft-ietf-trans-threat-analysis-05 draft-ietf-trans-threat-analysis-06
Abstract Abstract
This document describes an attack model and discusses threats for This document describes an attack model and discusses threats for
the Web PKI context in which security mechanisms to detect mis- the Web PKI context in which security mechanisms to detect mis-
issuance of web site certificates are being developed. The model issuance of web site certificates are being developed. The model
provides an analysis of detection and remediation mechanisms for provides an analysis of detection and remediation mechanisms for
both syntactic and semantic mis-issuance. The model introduces an both syntactic and semantic mis-issuance. The model introduces an
outline of attacks to organize the discussion. The model also outline of attacks to organize the discussion. The model also
describes the roles played by the elements of the Certificate describes the roles played by the elements of the Certificate
skipping to change at page 1, line 42 skipping to change at page 2, line 26
months and may be updated, replaced, or obsoleted by other documents months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on October 7, 2016. This Internet-Draft will expire on November 31, 2016.
Copyright Statement
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction....................................................... 3 1. Introduction.................................................... 5
2. Threats............................................................ 8 1.1. Conventions used in this document........................... 9
3. Semantic mis-issuance............................................. 10 2. Threats......................................................... 9
3.1. Non-malicious Web PKI CA context .............................. 10 3. Semantic mis-issuance.......................................... 11
3.1.1. Certificate logged ........................................ 10 3.1. Non-malicious Web PKI CA context........................... 11
3.1.1.1. Benign log............................................. 10 3.1.1. Certificate logged..................................... 11
3.1.1.1.1. Self-monitoring Subject ............................ 10 3.1.1.1. Benign log......................................... 11
3.1.1.1.2. Benign third party Monitor ......................... 11 3.1.1.1.1. Self-monitoring Subject........................ 11
3.1.1.2. Misbehaving log........................................ 11 3.1.1.1.2. Benign third party Monitor..................... 12
3.1.1.2.1. Self-monitoring Subject ............................ 11 3.1.1.2. Misbehaving log.................................... 12
3.1.1.2.2. Benign third party Monitor ......................... 11 3.1.1.2.1. Self-monitoring Subject & Benign third party
3.1.1.3. Misbehaving third party Monitor........................ 12 Monitor............................................. 12
3.1.2. Certificate not logged .................................... 12 3.1.1.3. Misbehaving third party Monitor.................... 13
3.1.2.1. Self-monitoring Subject................................ 13 3.1.2. Certificate not logged................................. 13
3.1.2.2. CT-enabled browser..................................... 13 3.1.2.1. Self-monitoring Subject............................ 14
3.2. Malicious Web PKI CA context .................................. 13 3.1.2.2. CT-enabled browser................................. 14
3.2.1. Certificate logged ........................................ 13 3.2. Malicious Web PKI CA context............................... 14
3.2.1.1. Benign log............................................. 13 3.2.1. Certificate logged..................................... 14
3.2.1.1.1. Self-monitoring Subject ............................ 14 3.2.1.1. Benign log......................................... 14
3.2.1.1.2. Benign third party Monitor ......................... 14 3.2.1.1.1. Self-monitoring Subject........................ 15
3.2.1.2. Misbehaving log........................................ 14 3.2.1.1.2. Benign third party Monitor..................... 15
3.2.1.2.1. Monitors - third party and self .................... 14 3.2.1.2. Misbehaving log.................................... 15
3.2.1.3. Misbehaving third party Monitor........................ 15 3.2.1.2.1. Monitors - third party and self................ 16
3.2.2. Certificate not logged .................................... 15 3.2.1.3. Misbehaving third party Monitor.................... 16
3.2.2.1. CT-aware browser....................................... 15 3.2.2. Certificate not logged................................. 16
3.3. Malicious, Colluding CAs ...................................... 16 3.2.2.1. CT-aware browser................................... 16
3.3.1. Revocation of the Bogus Certificate ....................... 17 3.3. Malicious, Colluding CAs................................... 17
3.3.2. Revocation of the Colluding CA Certificate ................ 18 3.3.1. Revocation of the Bogus Certificate.................... 18
3.4. Undetected Compromise of CAs or Logs .......................... 18 3.3.2. Revocation of the Colluding CA Certificate............. 19
3.4.1. Compromised CA, Benign Log ................................ 19 3.4. Undetected Compromise of CAs or Logs....................... 19
3.4.2. Benign CA, Compromised Log ................................ 20 3.4.1. Compromised CA, Benign Log............................. 20
3.4.3. Compromised CA, Compromised Log ........................... 20 3.4.2. Benign CA, Compromised Log............................. 21
4. Syntactic mis-issuance............................................ 21 3.4.3. Compromised CA, Compromised Log........................ 22
4.1. Non-malicious Web PKI CA context .............................. 21 4. Syntactic mis-issuance......................................... 23
4.1.1. Certificate logged ........................................ 21 4.1. Non-malicious Web PKI CA context........................... 23
4.1.1.1. Benign log............................................. 21 4.1.1. Certificate logged..................................... 23
4.1.1.2. Misbehaving log or third party Monitor................. 22 4.1.1.1. Benign log......................................... 23
4.1.1.3. Self-monitoring Subject and Benign third party Monitor. 23 4.1.1.2. Misbehaving log or third party Monitor............. 24
4.1.1.4. CT-enabled browser..................................... 23 4.1.1.3. Self-monitoring Subject and Benign third party
4.1.2. Certificate not logged .................................... 24 Monitor............................................... 25
4.2. Malicious Web PKI CA context .................................. 24 4.1.1.4. CT-enabled browser................................. 25
4.2.1. Certificate logged ........................................ 24 4.1.2. Certificate not logged................................. 25
4.2.1.1. Benign log............................................. 24 4.2. Malicious Web PKI CA context............................... 26
4.2.1.2. Misbehaving log or third party Monitor................. 24 4.2.1. Certificate logged..................................... 26
4.2.1.3. Self-monitoring Subject and Benign third party Monitor. 25 4.2.1.1. Benign log......................................... 26
4.2.1.4. CT-enabled browser..................................... 25 4.2.1.2. Misbehaving log or third party Monitor............. 26
4.2.2. Certificate is not logged ................................. 25 4.2.1.3. Self-monitoring Subject and Benign third party
5. Issues Applicable to Sections 3 and 4............................. 25 Monitor............................................... 26
5.1. How does a Subject know which Monitor(s) to use? .............. 25 4.2.1.4. CT-enabled browser................................. 27
5.2. How does a Monitor discover new logs? ......................... 26 4.2.2. Certificate is not logged.............................. 27
5.3. CA response to report of a bogus or erroneous certificate ..... 26 5. Issues Applicable to Sections 3 and 4.......................... 27
5.4. Browser behavior .............................................. 26 5.1. How does a Subject know which Monitor(s) to use?........... 27
5.5. Remediation for a malicious CA ................................ 27 5.2. How does a Monitor discover new logs?...................... 28
5.6. Auditing - detecting misbehaving logs ......................... 27 5.3. CA response to report of a bogus or erroneous certificate.. 28
6. Security Considerations........................................... 29 5.4. Browser behavior........................................... 28
7. IANA Considerations............................................... 29 5.5. Remediation for a malicious CA............................. 28
8. Acknowledgments................................................... 29 5.6. Auditing - detecting misbehaving logs...................... 29
9. References........................................................ 30 6. IANA Considerations............................................ 30
9.1. Normative References .......................................... 30 7. Security Considerations........................................ 31
9.2. Informative References ........................................ 30 8. References..................................................... 31
Author's Addresses................................................... 30 8.1. Normative References....................................... 31
Copyright Statement.................................................. 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, and typically are application-specific. For example, profiles, and typically are application-specific. For example,
certificates used in the Web PKI environment might be characterized certificates used in the Web PKI environment might be characterized
as domain validation (DV) or extended validation (EV) certificates. as domain 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 two classes of beneficiaries of CT: certificate Subjects There are three classes of beneficiaries of CT: certificate
and relying parties (RPs). In the initial focus context of CT, the Subjects, CAs, and relying parties (RPs). In the initial focus
Web PKI, Subjects are web sites and RPs are browsers employing HTTPS context of CT, the Web PKI, Subjects are web sites and RPs are
to access these web sites. browsers employing HTTPS to access these web sites. The CAs that
benefit are issuers 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 Monitor function of CT. The Monitor function may be provided by the Monitor function of CT. The Monitor function may be provided by
the Subject itself, i.e., self-monitoring, or by a third party the Subject itself, i.e., self-monitoring, or by a third party
trusted by the Subject. When a Subject is informed of certificate trusted by the Subject. When a Subject is informed of certificate
mis-issuance by a Monitor, the Subject is expected to request/demand mis-issuance by a Monitor, the Subject is expected to request/demand
revocation of the bogus certificate. Revocation of a bogus revocation of the bogus certificate. Revocation of a bogus
certificate is the primary means of remedying mis-issuance. certificate is the primary means of remedying mis-issuance.
Certificate Revocations Lists (CRLs) [RFC5280] are the primary means Certificate Revocations Lists (CRLs) [RFC5280] are the primary means
of certificate revocation established by IETF 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 replying 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 which it is communicating [RFC6066, RFC6961]. with 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
skipping to change at page 5, line 46 skipping to change at page 7, line 5
[TRANS] is invalid. If an RP verified that a certificate that claims [TRANS] is invalid. If an RP verified that a certificate that claims
to have been logged has a valid log entry, the RP would have a to have been logged has a valid log entry, the RP would have a
higher degree of confidence that the certificate is genuine. higher degree of confidence that the certificate is genuine.
However, checking logs in this fashion imposes a burden on RPs and However, checking logs in this fashion imposes a burden on RPs and
on logs. Moreover, the existence of a log entry does not ensure that on logs. Moreover, the existence of a log entry does not ensure that
the certificate is not mis-issued. Unless the certificate Subject is the certificate is not mis-issued. Unless the certificate Subject is
monitoring the log(s) in question, a bogus certificate will not be monitoring the log(s) in question, a bogus certificate will not be
detected by CT mechanisms. Finally, if an RP were to check logs for detected by CT mechanisms. Finally, if an RP were to check logs for
individual certificates, that would disclose to logs the identity of individual certificates, that would disclose to logs the identity of
web sites being visited by the RP, a privacy violation. Thus this web sites being visited by the RP, a privacy violation. Thus this
attack model assumes that RPs will not check log entries. attack model does not assume that all RPs will check log entries.
A CA benefits from CT when it detects a (mis-issued) certificate
that represents the same Subject name as a legitimate certificate
issued 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 legitimate Subject, then an RP benefits without having certificate's legitimate Subject, then an RP benefits without having
to implement any CT-specific mechanisms. to implement any CT-specific mechanisms.
Also note that one proposal for distributing Audit information (to Also note that one proposal for distributing Audit information (to
detect misbehaving logs) calls for a browser to send SCTs it detect misbehaving logs) calls for a browser to send SCTs it
receives to the corresponding website when visited by the browser. receives to the corresponding website when visited by the browser.
skipping to change at page 6, line 34 skipping to change at page 7, line 44
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 to adhere to the advertised Maximum Merge Delay (MMD) and failures to adhere to the advertised Maximum Merge Delay (MMD) and
Signed Tree Head (STH) frequency count [TRANS] violating the append- Signed Tree Head (STH) frequency count [TRANS] violating the append-
only property, and providing inconsistent views of the log to 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 requires communication among multiple log clients. misbehavior requires communication among multiple log clients.
Monitors ought not trust logs that are detected misbehaving. Thus Monitors ought not trust logs that are detected misbehaving. Thus
the Audit function does not detect mis-issuance per se. There is no the Audit function does not detect mis-issuance per se. The CT
agreed-upon Audit function design for CT at the time of this design identifies audit functions designed to detect several types
writing. As a result, the model merely notes where Auditing is of misbehavior. However, mechanisms to detect some forms of log
needed to detect certain classes of attacks. 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 [TRANS]
and on the assumed behavior of other CT system elements as described and on the assumed behavior of other CT system elements as described
above. This Figure does not include the Audit function, because above. This Figure does not include the Audit function, because
there is not yet agreement on how that function will work in a there is not yet agreement on how that function will work in a
distributed, privacy-preserving fashion. distributed, privacy-preserving fashion.
+----+ +---------+ +---------+ +----+ +---------+ +---------+
| CA |---[ 1]-->| Log |<---[8]---| Monitor | | CA |---[ 1]-->| Log |<---[8]---| Monitor |
| | | | | | | | | | | |
| |<--[ 2]---| |----[9]-->| | | |<--[ 2]---| |----[9]-->| |
| | | | | | | | | | | |
| |---[ 3]-->| |<--[10]---| | | |---[ 3]-->| |<--[10]---| |
| | | | | |--------+ | | | | | |--------+
| |<--[ 4]---| |---[11]-->| | | | |<--[ 4]---| |---[11]-->| | |
| | | | +---------+ | | | | | +---------+ |
| | | | | | | | | |
| | | | +---------+ | | | | | +---------+ |
| | | |<--[8]----| Self- | | | | | |<--[8]----| Self- | |
| | | | | Monitor | | | | | | | Monitor | |
| | | |---[9]--->|(Subject)| | | | | |---[9]--->|(Subject)| |
| | | | | | | | | | | | | |
| | | |<--[10]---| | [12] | | | |<--[10]---| | [12]
| | | | | | | | | | | | | |
| | | |---[11]-->| | | | | | |---[11]-->| | |
| | +---------+ +---------+ | | | +---------+ +---------+ |
| | | | | |
| | +---------+ +---------+ | | | +---------+ +---------+ |
| |---[ 5]-->| Website |---[7]--->| Browser | | | |---[ 5]-->| Website |---[7]--->| Browser | |
| | |(Subject)| +---------+ | | | |(Subject)| +---------+ |
| |<--[ 6]-->| |<----------------------------+ | |<--[ 6]-->| |<----------------------------+
+----+ +---------+ +----+ +---------+
[ 1] Retrieve accepted root certs [ 1] Retrieve accepted root certs
[ 2] accepted root certs [ 2] accepted root certs
[ 3] Add chain to log/add PreCertChain to log [ 3] Add chain to log/add PreCertChain to log
[ 4] SCT (embedded in pre-cert, if applicable) [ 4] SCT
[ 5] send cert + SCTs (or cert with embedded SCTs) [ 5] send cert + SCTs (or cert with embedded SCTs)
[ 6] Revocation request/response (in response to detected [ 6] Revocation request/response (in response to detected
mis-issuance) mis-issuance)
[ 7] cert + SCTs (or cert with embedded SCTs) [ 7] cert + SCTs (or cert with embedded SCTs)
[ 8] Retrieve entries from Log [ 8] Retrieve entries from Log
[ 9] returned entries from log [ 9] returned entries from log
[10] Retrieve latest STH [10] Retrieve latest STH
[11] returned STH [11] returned STH
[12] bogus/erroneous cert notification [12] bogus/erroneous cert notification
Figure 1. Data Exchanges Between Major Elements of the CT System Figure 1: Data Exchanges Between Major Elements of the CT System
Certificate mis-issuance may arise in one of several ways. The ways 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-issuance. This attack model applies to use of CT in the Web PKI mis-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
skipping to change at page 8, line 32 skipping to change at page 9, line 36
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.
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 acquire information that a TLS-enabled enables an adversary to perform many types of attacks, e.g.,
client would not communicate if the client were aware of the delivery of malware to a client, reporting bogus information, or
spoofing. Such information may include personal identification and acquiring information that a client would not communicate if the
authentication information and electronic payment authorization client were aware of the spoofing. Such information may include
information. Because of the nature of the information that may be personal identification and authentication information and
divulged, the principal adversaries in the CT context are perceived electronic payment authorization information. Because of the nature
to be (cyber) criminals and nation states. Both adversaries are of the information that may be divulged (or misinformation or
motivated to acquire personal identification and authentication malware that may be delivered), the principal adversaries in the CT
information. Criminals are also motivated to acquire electronic context are perceived to be (cyber) criminals and nation states.
payment authorization information. Both adversaries are motivated to acquire personal identification
and authentication information. Criminals are also motivated to
acquire electronic 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 causing a user to click may achieve this in various ways, e.g., by manipulation of the DNS
on a link to the website, or by manipulation of the DNS response response sent to a TLS client or via a man-in-the-middle attack. The
sent to a TLS client. The former type of attack is well within the former type of attack is well within the perceived capabilities of
perceived capabilities of both classes of adversary. The latter both classes of adversary. The latter attack may be possible for
attack may be possible for criminals and is certainly a capability criminals and is certainly a capability available to a nation state
available to a nation state within its borders. Nation states also within its borders. Nation states also may be able to compromise DNS
may be able to compromise DNS servers outside their own servers outside their own jurisdiction.
jurisdiction.
The elements of CT may themselves be targets of attacks, as The elements of CT may themselves be targets of attacks, as
described below. A criminal organization might compromise a CA and described below. A criminal organization might compromise a CA and
cause it to issue bogus certificates, or it may exert influence over cause it to issue bogus certificates, or it may exert influence over
a CA (or CA staff) to do so, e.g., through extortion or physical a CA (or CA staff) to do so, e.g., through extortion or physical
threat. (Even though the CA is not intentionally malicious in this threat. A CA may be the victim of social engineering, causing it to
case, the action is equivalent to a malicious CA, hence the use of issue a certificate to an inappropriate Subject. (Even though the CA
the term "bogus" here.) A nation state may operate or influence a CA is not intentionally malicious in this case, the action is
that is part of the large set of "root CAs" in browsers. A CA, equivalent to a malicious CA, hence the use of the term "bogus"
acting in this fashion, is termed a "malicious" CA. A nation state here.) A nation state may operate or influence a CA that is part of
also might compromise a CA in another country, to effect issuance of the large set of "root CAs" in browsers. A CA, acting in this
bogus certificates. In this case the (non-malicious) CA, upon fashion, is termed a "malicious" CA. A nation state also might
detecting the compromise (perhaps because of CT) is expected to work compromise a CA in another country, to effect issuance of bogus
with Subjects to remedy the mis-issuance. certificates. In this case the (non-malicious) CA, upon detecting
the compromise (perhaps because of CT) is expected to work with
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., to selected Monitors or Auditors). It seems unlikely that a (e.g., 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
detect and 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 the case of a bogus certificate, because it was the victim of a in 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 DigiNotar [VASCO]. In the case of an error, the CA should have a
[https://www.vasco.com/company/about_vasco/press_room/news_archive/2 record of the erroneous certificate and be prepared to revoke this
011/news_diginotar_reports_any security_incident.aspx]. In the case certificate once it has discovered and confirmed the error. In the
of an error, the CA should have a record of the erroneous event of an attack, a CA may have no record of a bogus certificate.
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
skipping to change at page 11, line 35 skipping to change at page 12, line 38
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 problems to the Subject who would in turn report them to semantic problems to the Subject who would in turn report them to
the purported issuing CA. This might cause the CA to do needless the 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 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.
3.1.1.2.2. Benign third party Monitor Similarly, when a misbehaving log suppresses a bogus certificate log
Because a misbehaving log will suppress 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 [gossip] to detect log misbehavior, as a
deterrent. (See Section 5.6 below.) However, a Monitor (third-party deterrent. (See Section 5.6 below.) However, a Monitor (third-party
or self) must participate in the Audit mechanism in order to become or self) must participate in the Audit mechanism in order to become
aware of log misbehavior. 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
skipping to change at page 14, line 15 skipping to change at page 15, line 17
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 does not help 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. The Audit element of CT is tasked split views to different clients, as discussed later. The Audit
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.
skipping to change at page 15, line 7 skipping to change at page 16, line 12
logs may or may not issue SCTs, but will hide the log entries from logs may or may not issue SCTs, but will hide the log entries from
some or all Monitors. some or all Monitors.
3.2.1.2.1. Monitors - third party and self 3.2.1.2.1. Monitors - third party and self
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.2.) If a Monitor learns consistency checking of logs. (See 3.1.1.2.1.) 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
skipping to change at page 16, line 20 skipping to change at page 17, line 24
foil the remediation (but not detection) safeguards envisioned by foil the remediation (but not detection) safeguards envisioned by
CT. Their goal would be trick a CT-aware browser into accepting a CT. Their goal would be trick a CT-aware browser into accepting a
bogus certificate because it was accompanied by a valid SCT, while bogus certificate because it was accompanied by a valid SCT, while
evading certificate revocation status indications. This section evading certificate revocation status indications. This section
explores such scenarios. explores such scenarios.
In this attack two CAs that do not share a common path to a trust In this attack two CAs that do not share a common path to a trust
anchor, collude to create a "doppelganger" (bogus) EE certificate. anchor, collude to create a "doppelganger" (bogus) EE certificate.
The attack need not be initiated by trust anchors; any subordinate The attack need not be initiated by trust anchors; any subordinate
pair of (not name-constrained) CAs can effect this attack without pair of (not name-constrained) CAs can effect this attack without
the knowledge of superiors CAs (which are presumed to be benign). the knowledge of superior CAs (which are presumed to be benign).
The two CAs must have the same Subject name and the same public key (The following text refers to these as two CAs, because they might
for the attack. (RFC 5280 doe not explicitly preclude the creation be represented by entities that are organizationally distinct,
of two CAs with the same name, so long as the parent CAs are perhaps realized by different physical presences. However, because
distinct. Requirements for Subject name uniqueness apply 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 individually to each CA but not across CA boundaries, as per Section
4.2.1.6. However, the Security Considerations section of RFC 5280 4.2.1.6. However, the Security Considerations section of RFC 5280
warns that name collisions could cause security problems.) warns that name collisions could cause security problems.)
Because the two CAs have the same name and make use of the same key, 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 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 log the certificate and acquire an SCT for it, while the other
would not. would not.
Because the bogus certificate is logged, it is subject to detection Because the bogus certificate is logged, it is subject to detection
skipping to change at page 19, line 32 skipping to change at page 20, line 42
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 the bogus certificate. However, means of remedying the attack hide the bogus certificate. However, means of remedying the attack
are independent of this aspect, i.e., revocation can be effected are 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 from the compromised CA. certificate 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. Also, the bogus bogus certificate is made known to this CA and assuming that the
certificate cannot have been issued with an Authority Information bogus certificate was not issued with an Authority Information
Access (AIA) or CRL Distribution Point (CRL DP) extension that Access (AIA) or CRL Distribution Point (CRL DP) extension that
enables only the malicious twin to revoke the certificate. (The AIA enables only the malicious twin to revoke the certificate. (The AIA
extension in the bogus certificate could be used to direct relying extension in the bogus certificate could be used to direct relying
parties to an OCSP server controlled by the malicious twin. The CRL parties to an OCSP server controlled by the malicious twin. The CRL
DP extension could be used to direct relying parties to a CRL DP extension could be used to direct relying parties to a CRL
controlled by the malicious twin.) If the bogus certificate controlled by the malicious twin.) If the bogus certificate
contains either extension, the compromised CA cannot effectively contains either extension, the compromised CA cannot effectively
revoke it, but it will also be apparent that the bogus certificate revoke it. However, the presence of either of these extensions
was issued by the malicious twin. (The AIA or CRL DP extension would provides some evidence that an entity other than the compromised CA
provide a strong indication that the bogus certificate was not issued the certificate in question. (If the extensions differ from
generated by the compromised CA itself.) those in other certificates issued by the compromised CA, that is
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 certificate. This problem may cause the compromised CA to legitimate certificate. This problem may cause the compromised CA to
delay revocation, thus allowing the bogus certificate to remain a delay revocation, thus allowing the bogus certificate to remain a
danger for a longer time. danger 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 pair. (This assumes that the bogus certificate does not contain key pair. (This assumes that the bogus certificate does not contain
an AIA or CRL DP extension that wrests control of revocation from an AIA or CRL DP extension that wrests control of revocation from
skipping to change at page 20, line 46 skipping to change at page 22, line 9
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
one or more bogus certificates, then a malicious log might provide
split views of its log to help conceal the bogus certificate from
targeted users. Specifically, the log would show an accurate set of
log entries (and STHs) to most clients, but would maintain a
separate log view for targeted users. This sort of attack motivates
the need for Audit capabilities based on "gossiping" [gossip].
However, even if such mechanisms are employed, they might be
thwarted if a user is unable to exchange log information with
trustworthy partners.
3.4.3. Compromised CA, Compromised Log 3.4.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 contains the same Subject name as a legitimate certificate that contains the same Subject name as a legitimate certificate
issued by the compromised CA. Alternatively, the bogus certificate issued by the compromised CA. Alternatively, the bogus certificate
may contain a different name but reuse a serial number from a valid, may contain a different name but reuse a serial number from a valid,
not revoked certificate issued by that CA. not revoked certificate issued by that CA.
The evil twin CA might submit a bogus certificate to the evil twin An attacker who compromises a log might act in one of two ways. It
of a compromised log. The operator of the evil twin log can use the might use the private key of the log only to generate SCTs for a
purloined private key to generate SCTs for certificates that have malicious CA or the evil twin of a compromised CA. If a browser
not been logged by its legitimate counterpart. These SCTs will checks the signature on an SCT but does not contact a log to verify
appear valid relative to the public key associated with the that the certificate appears in the log, then this is an effective
legitimate log. However, an STH issued by the legitimate log will attack strategy. Alternatively, the attacker might not only generate
not correspond to a tree containing these SCTs. Thus thorough SCTs, but also pose as the compromised log, at least with regard to
checking of the SCTs issued by the evil twin log will identify this requests from targeted users. In the latter case, this "evil twin"
discrepancy. log could respond to STH requests from targeted users, making appear
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
gossip mechanism that is able to acquire CT data from diverse
sources, a feature not yet part of the base CT system.
An Auditor checking for log consistency might conclude that the An evil twin CA might submit a bogus certificate to the evil twin of
compromised log is acting maliciously, and is presenting a split a compromised log. (The same adversary may be controlling both.) The
view to its clients. In this fashion the compromised log may be operator of the evil twin log can use the purloined private key to
shunned and forced to shut down. However, if an attacker targets a generate SCTs for certificates that have not been logged by its
set of TLS clients that do not have access to the legitimate log, legitimate counterpart. These SCTs will appear valid relative to the
they may not be able to detect this inconsistency. In this case CT public key associated with the legitimate log. However, an STH
would need to rely on a distributed gossiping audit mechanism to issued by the legitimate log will not correspond to a tree
detect the compromise (see Section 5.6). (maintained by the compromised log) containing these SCTs. Thus
checking the SCTs issued by the evil twin log against STHs from the
compromised log will identify this discrepancy. As noted above, if
an attacker uses the key to generate log entries and respond to log
queries, the effect is analogous to a malicious log.)
An Auditor checking for log consistency and with access to bogus
SCTs, might conclude that the compromised log is acting maliciously,
and is presenting a split view to its clients. In this fashion the
compromised log may be shunned and forced to shut down. However, if
an attacker targets a set of TLS clients that do not have access to
the legitimate log, they may not be able to detect this
inconsistency. In this case CT would need to rely on a distributed
gossiping audit mechanism to detect the compromise (see Section
5.6).
In general, this sort of attack is analogous to a malicious CA In general, this sort of attack is analogous to a malicious CA
creating a bogus certificate and receiving an SCT (with no log 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) from a misbehaving log (Section 4.2.1.2). The lack of a log
entry prevents detection of the bogus certificate by Monitors, and entry prevents detection of the bogus certificate by Monitors, and
the presence of the SCT prevents rejection by a CT-aware browser the presence of the SCT prevents rejection by a CT-aware browser
that accepts SCTs from the compromised log. that accepts SCTs from the compromised log.
4. Syntactic mis-issuance 4. Syntactic mis-issuance
skipping to change at page 22, line 8 skipping to change at page 23, line 47
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-)certificate. (A (pre-)certificate SHOULD be logged even if it (pre-)certificate. (A (pre-)certificate SHOULD be logged even if it
fails syntactic validation; logging takes precedence over detection fails syntactic validation; logging takes precedence over detection
of syntactic mis-issuance.) If syntactic validation fails, this can of syntactic mis-issuance.) If syntactic validation fails, this can
be noted in an SCT extension returned to the submitter. be 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, and if the CA has a record of the certificate content, then the CA, then the CA SHOULD remedy the syntactic problem and re-submit
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 a new certificate. If the Subject is a legitimate subscriber request a new certificate. If the Subject is a legitimate subscriber
of the CA, then the CA will either have a record of the certificate of the CA, then the CA will either have a record of the certificate
content or can obtain a copy of the certificate from the Subject. content or can obtain a copy of the certificate from the Subject.
skipping to change at page 23, line 39 skipping to change at page 25, line 31
investigation) and remedy the syntactic problem. The CA SHOULD investigation) and remedy the syntactic problem. The CA SHOULD
either re-submit the corrected (pre-)certificate to one or more logs either re-submit the corrected (pre-)certificate to one or more logs
and then send the result to the Subject, or send the corrected and then send the result to the Subject, or send the corrected
certificate to the Subject, who will re-submit it to one or more certificate to the 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.,
skipping to change at page 24, line 28 skipping to change at page 26, line 21
error. The CA is not the victim but the attacker. error. 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 [DOMVAL] and
[EXTVAL] for more details on validation checks and CCIDs). [EXTVAL] for more details on validation checks and CCIDs).
1. The CA may assert that the certificate is being issued w/o 1. The CA may assert that the certificate is being issued w/o regard
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 2. The CA may assert a CCID that has not been registered, and thus
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 3. The CA may check to see which CCIDs a log declares it can check,
check, and chose a registered CCID that is not checked by the log and chose a registered CCID that is not checked by the log in
in question. question.
4. The CA may submit a (pre-) certificate to a log that is known 4. The CA may submit a (pre-) certificate to a log that is known to
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.
skipping to change at page 25, line 16 skipping to change at page 27, line 7
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), many browsers fail to perform thorough As noted above (4.1.1.4), most browsers fail to perform thorough
syntax checks on certificates. Such browsers would benefit from syntax checks on certificates. Such browsers might benefit from
having such checks performed by a log and reported in the SCT. having syntax checks performed by a log and reported in the SCT,
(Remember, in this scenario, the log is benign.) However, if a although the pervasive nature of syntactically-defective
browser does not discriminate against certificates that do not certificates may limit the utility of such checks. (Remember, in
contain SCTs (or that are not accompanied by an SCT in the TLS this scenario, the log is benign.) However, if a browser does not
handshake), only minimal benefits might accrue to the browser from discriminate against certificates that do not contain SCTs (or that
syntax checks perform by logs or Monitors. are not accompanied by an SCT in the TLS handshake), only minimal
benefits might accrue to the browser from syntax checks perform by
logs or 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 CA need not worry about failing a log-based check. malicious CA need not worry about failing a log-based check.
Similarly, if there is no requirement for a browser to reject a Similarly, if there is no requirement for a browser to reject a
certificate that was logged by an operator that does not perform certificate that was logged by an operator that does not perform
syntactic checks, the fourth attack noted in 4.2.1.1 will succeed as syntactic checks, the fourth attack noted in 4.2.1.1 will succeed as
well. If a browser were configured to know which versions of well. If a browser were configured to know which versions of
certificate types are applicable to its use of a certificate, the certificate types are applicable to its use of a certificate, the
second and third attack strategies noted above could be thwarted. second and third attack strategies noted above could be thwarted.
skipping to change at page 27, line 30 skipping to change at page 29, line 22
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 as a Monitor. Moreover, the same or another malicious CA could such as a Monitor. Moreover, the same or another malicious CA could
issue new bogus or erroneous certificates for the targeted Subject, issue new bogus or erroneous certificates for the targeted Subject,
which would have to be detected and rejected in this (as yet which would have to be detected and rejected in this (as yet
unspecified) fashion. Thus, for now, CT does not seem to provide a unspecified) fashion. Thus, for now, CT does not seem to provide a
way to remedy this form of attack, even though it provides a basis way to facilitate remediation of this form of attack, even though it
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
skipping to change at page 29, line 7 skipping to change at page 30, line 45
compromised by, or conspires with, an attacker, it will fail to compromised by, or conspires with, an attacker, it will fail to
alert a Subject to a bogus or erroneous certificate targeting that alert a Subject to a bogus or erroneous certificate targeting that
Subject, as noted above. It is suggested that a Subject request Subject, as noted above. It is suggested that a Subject request
certificate monitoring from multiple sources to guard against such certificate monitoring from multiple sources to guard against such
failures. Operation of a Monitor by a Subject, on its own behalf, failures. Operation of a Monitor by a Subject, on its own behalf,
avoids dependence on third party Monitors. However, the burden of avoids dependence on third party Monitors. However, the burden of
Monitor operation may be viewed as too great for many web sites, and 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 thus this mode of operation ought not be assumed to be universal
when evaluating protection against Monitor compromise. when evaluating protection against Monitor compromise.
6. Security Considerations 6. IANA Considerations
None.
7. 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.
7. IANA Considerations 8. References
None. 8.1. Normative References
8. Acknowledgments [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997.
The author would like to thank David Mandelberg and Karen Seo for [CTarch] Kent, S., Mandelberg, D., Seo, K., "Certificate
their assistance in reviewing and preparing this document, and other Transparency (CT) System Architecture", draft-kent-
members of the TRANS working group for reviewing it. trans-architecture-02, (January 2016), work in progress.
9. References 8.2. Informative References
9.1. Normative References [TRANS] Laurie, B., Langley, A., Kasper, E., Messeri, E.,
Stradling, R., "Certificate Transparency," draft-ietf-
trans-rfc6962-bis-16 (May 27, 2016), work in progress.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [DOMVAL] Kent, S., Andrews, R., "Syntactic and Semantic Checks
Requirement Levels," BCP 14, RFC 2119, March 1997. for Domain Validation Certificates," draft-kent-trans-
domain-validation-cert-checks-02, (December 2015), work
in progress.
[CTarch] Kent, S., Mandelberg, D., Seo, K., "Certificate [EXTVAL] Kent, S., Andrews, R., "Syntactic and Semantic Checks
Transparency (CT) System Architecture", draft-kent-trans- for Extended Validation Certificates," draft-kent-trans-
architecture-02, (January 2016), work in progress. extended-validation-cert-checks-02 (December 2015), work
in progress.
9.2. Informative References [gossip] Nordberg, L., Gillmore, D., Ritter, T., "Gossiping in
CT," draft-ietf-trans-gossip-02, (March 21, 2016), work
in progress.
[TRANS] Laurie, B., Langley, A., Kasper, E., Messeri, E., [RFC5280] Cooper, D., Santession, S., Farrell, S., Boeyen, S.,
Stradling, R., "Certificate Transparency," draft-ietf- Housley, R., Polk, W., "Internet X.509 Public Key
trans-rfc6962-bis-13 (March 21, 2016), work in progress. Infrastructure Certificate and Certificate Revocation
List (CRL) Profile," RFC 5280, May 2008.
[DOMVAL] Kent, S., Andrews, R., "Syntactic and Semantic Checks for [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Domain Validation Certificates," draft-kent-trans-domain- Extensions: Extension Definitions", RFC 6066, DOI
validation-cert-checks-02, (December 2015), work in 10.17487/RFC6066, January 2011, <http://www.rfc-
progress. editor.org/info/rfc6066>.
[EXTVAL] Kent, S., Andrews, R., "Syntactic and Semantic Checks for [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A.,
Extended Validation Certificates," draft-kent-trans- Galperin, S., and C. Adams, "X.509 Internet Public Key
extended-validation-cert-checks-02 (December 2015), work Infrastructure Online Certificate Status Protocol -
in progress. OCSP", RFC 6960, DOI 10.17487/RFC6960, June 2013,
<http://www.rfc-editor.org/info/rfc6960>.
[gossip] Nordberg, L., Gillmore, D., Ritter, T., "Gossiping in CT," [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
draft-ietf-trans-gossip-02, (March 21, 2016), work in Multiple Certificate Status Request Extension", RFC
progress 6961, DOI 10.17487/RFC6961, June 2013, <http://www.rfc-
editor.org/info/rfc6961>.
[RFC5280] Cooper, D., Santession, S., Farrell, S., Boeyen, S., [VASCO] VASCO, "DigiNotar reports security incident",
Housley, R., Polk, W., "Internet X.509 Public Key <https://www.vasco.com/about-vasco/press/2011/
Infrastructure Certificate and Certificate Revocation List news_diginotar_reports_security_incident.html>
(CRL) Profile," RFC 5280, May 2008.
Acknowledgments
The author would like to thank David Mandelberg and Karen Seo for
their assistance in reviewing and preparing this document, and other
members of the TRANS working group for reviewing it.
Author's Addresses Author's Addresses
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
Copyright Statement
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
 End of changes. 55 change blocks. 
245 lines changed or deleted 321 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/