draft-ietf-trans-threat-analysis-15.txt   draft-ietf-trans-threat-analysis-16.txt 
Public Notary Transparency S. Kent Public Notary Transparency S. Kent
Internet-Draft Independent Internet-Draft Independent
Intended status: Informational August 30, 2018 Intended status: Informational October 4, 2018
Expires: March 3, 2019 Expires: April 7, 2019
Attack and Threat Model for Certificate Transparency Attack and Threat Model for Certificate Transparency
draft-ietf-trans-threat-analysis-15 draft-ietf-trans-threat-analysis-16
Abstract Abstract
This document describes an attack model and discusses threats for the This document defines an attack model and discusses threats based on
Web PKI context for which security mechanisms to detect mis-issuance the system design presented in [I-D.ietf-trans-rfc6962-bis]. It
of web site certificates are being developed. The model provides an analyzes potential vulnerabilities associated with that design, and
analysis of detection and remediation mechanisms for both syntactic considers compromises of system elements and malicious behavior by
and semantic mis-issuance. The model introduces an outline of such elements. It does not consider implementation vulnerabilities,
attacks to organize the discussion. The model also describes the including ones that might enable denial of service attacks against
roles played by the elements of the Certificate Transparency (CT) these elements.
system, to establish a context for the model.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 3, 2019. This Internet-Draft will expire on April 7, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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 respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions used in this document . . . . . . . . . . . . 8 1.1. Conventions used in this document . . . . . . . . . . . . 9
2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 10 3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 10
3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 10 3.1. Non-malicious CA context . . . . . . . . . . . . . . . . 10
3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 10 3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 11
3.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 10 3.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 11
3.1.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 11 3.1.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 11
3.1.1.3. Misbehaving third party Monitor . . . . . . . . . 12 3.1.1.3. Misbehaving third party Monitor . . . . . . . . . 13
3.1.2. Certificate not logged . . . . . . . . . . . . . . . 12 3.1.2. Certificate not logged . . . . . . . . . . . . . . . 13
3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12 3.2. Malicious CA context . . . . . . . . . . . . . . . . . . 13
3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 13 3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 13
3.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 13 3.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 13
3.2.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 13 3.2.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 14
3.2.1.3. Misbehaving third party Monitor . . . . . . . . . 14 3.2.1.3. Misbehaving third party Monitor . . . . . . . . . 15
3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14 3.2.2. Certificate not logged . . . . . . . . . . . . . . . 15
3.2.2.1. CT-aware browser . . . . . . . . . . . . . . . . 14 3.2.2.1. CT-aware browser . . . . . . . . . . . . . . . . 15
3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15 3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 16
3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 15 3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 16
3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 17 3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 18
3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 18 3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 18
3.4. Attacks Based on Exploiting Multiple Certificate Chains . 19 3.4. Attacks Based on Exploiting Multiple Certificate Chains . 19
3.5. Attacks Related to Distribution of Revocation Status . . 20 3.5. Attacks Related to Distribution of Revocation Status . . 21
4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 21 4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 22
4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 21 4.1. Non-malicious CA context . . . . . . . . . . . . . . . . 22
4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 22 4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 22
4.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 22 4.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 23
4.1.1.2. Misbehaving log or third party Monitor . . . . . 23 4.1.1.2. Misbehaving log or third party Monitor . . . . . 24
4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23 4.1.2. Certificate not logged . . . . . . . . . . . . . . . 24
4.1.2.1. Self-monitoring Subject . . . . . . . . . . . . . 24 4.1.2.1. Self-monitoring Subject . . . . . . . . . . . . . 24
4.1.3. Situations Independent of Certificate Logging . . . . 24 4.1.3. Situations Independent of Certificate Logging . . . . 25
4.1.3.1. Self-monitoring Subject and Benign third party 4.1.3.1. Self-monitoring Subject and Benign third party
Monitor . . . . . . . . . . . . . . . . . . . . . 24 Monitor . . . . . . . . . . . . . . . . . . . . . 25
4.1.3.2. CT-enabled browser . . . . . . . . . . . . . . . 24 4.1.3.2. CT-enabled browser . . . . . . . . . . . . . . . 25
4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 25 4.2. Malicious CA context . . . . . . . . . . . . . . . . . . 25
4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 25 4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 26
4.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 25 4.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 26
4.2.1.2. Misbehaving log or third party Monitor . . . . . 25 4.2.1.2. Misbehaving log or third party Monitor . . . . . 26
4.2.1.3. CT-enabled browser . . . . . . . . . . . . . . . 26 4.2.1.3. CT-enabled browser . . . . . . . . . . . . . . . 26
4.2.2. Certificate is not logged . . . . . . . . . . . . . . 26 4.2.2. Certificate is not logged . . . . . . . . . . . . . . 27
5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 26 5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 27
5.1. How does a Subject know which Monitor(s) to use? . . . . 26 5.1. How does a Subject know which Monitor(s) to use? . . . . 27
5.2. How does a Monitor discover new logs? . . . . . . . . . . 27 5.2. How does a Monitor discover new logs? . . . . . . . . . . 27
5.3. CA response to report of a bogus or erroneous certificate 27 5.3. CA response to report of a bogus or erroneous certificate 27
5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 27 5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 28
5.5. Remediation for a malicious CA . . . . . . . . . . . . . 28 5.5. Remediation for a malicious CA . . . . . . . . . . . . . 28
5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 28 5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 29
6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.1. Normative References . . . . . . . . . . . . . . . . . . 30 9.1. Normative References . . . . . . . . . . . . . . . . . . 31
9.2. Informative References . . . . . . . . . . . . . . . . . 30 9.2. Informative References . . . . . . . . . . . . . . . . . 31
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 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 profiles, constraints for certificates are established by certificate profiles,
and typically are application-specific. For example, certificates and often are application-specific. For example, certificates used
used in the Web PKI environment might be characterized as domain in the environment might be characterized as domain validation (DV)
validation (DV) or extended validation (EV) certificates. or extended validation (EV) certificates. Certificates used with
Certificates used with applications such as IPsec or S/MIME have applications such as IPsec or S/MIME have different syntactic
different syntactic constraints from those in the Web PKI context. constraints from those in the context.
There are three classes of beneficiaries of CT: certificate Subjects, There are three classes of beneficiaries of CT: certificate Subjects,
CAs, and relying parties (RPs). In the initial focus context of CT, CAs, and relying parties (RPs). In the initial focus context of CT,
the Web PKI, Subjects are web sites and RPs are browsers employing Subjects are web sites and RPs are users of browsers employing HTTPS
HTTPS to access these web sites. The CAs that benefit are issuers of to access these web sites. (In some contexts human users may not be
certificates used to authenticate web sites. the final arbiters of what certificates are accepted, e.g., an
organization may 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 the 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 trusted by Subject itself, i.e., self-monitoring, or by a third party trusted by
the Subject. When a Subject is informed of certificate mis-issuance the Subject. When a Subject is informed of certificate mis-issuance
by a Monitor, the Subject is expected to request/demand revocation of by a Monitor, the Subject is expected to request/demand revocation of
the bogus certificate. Revocation of a bogus certificate is the the bogus certificate. Revocation of a bogus 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] and the Online
of certificate revocation established by IETF standards. Certificate Status Protocol (OCSP) data [RFC6960] are the primary
Unfortunately, most browsers do not make use of CRLs to check the certificate revocation mechanisms established by IETF standards.
revocation status of certificates presented by a TLS Server Browsers may make use of proprietary mechanisms to effect revocation
(Subject). Some browsers make use of Online Certificate Status status checking, in lieu or in addition to the mechanisms noted
Protocol (OCSP) data [RFC6960] as a standards-based alternative to above. 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. A browser may also server to which a request can be directed. A browser may also
request OCSP responses from a TLS server with which it is request OCSP responses from a TLS server with which it is
communicating [RFC6066][RFC6961]. 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 browser Forum (CABF) Baseline
baseline requirements and extended validation guidelines do mandate Requirements and Extended Validation Guidelines do mandate inclusion
inclusion of this extension in EE certificates (in conjunction with of this extension in EE certificates (in conjunction with their
their certificate policies). (See cabforum.org [1] for the most certificate policies). (See cabforum.org [1] for the most recent
recent versions of these policies.) versions of these policies.)
In addition to the revocation status data dissemination mechanisms As noted above, browser vendors may employ proprietary means of
specified by IETF standards, most browser vendors employ proprietary conveying certificate revocation status information to their
means of conveying certificate revocation status information to their
products, e.g., via a blacklist that enumerates revoked certificates products, e.g., via a blacklist that enumerates revoked certificates
(EE or CA). Such capabilities enable a browser vendor to cause (EE or CA). Such capabilities enable a browser vendor to cause
browsers to reject any certificates on the blacklist. This approach browsers to reject any certificates on the blacklist. This 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 mis- for certificates issued in the Subject's name suffices to detect mis-
issuance targeting the Subject, if the bogus/erroneous certificate is issuance targeting the Subject, if the bogus/erroneous certificate is
logged. logged.
A relying party (e.g., browser) benefits from CT if it rejects a A relying party (e.g., browser user) 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. (Note that
from accepting a bogus certificate if that certificate is revoked, [I-D.ietf-trans-rfc6962-bis] notes that anyone can elect to monitor
and if the RP checks the revocation status of the certificate. (An logs for mis-issuance, indicating that there is a potentially larger,
RP also is protected if a browser vendor "blacklists" a certificate unspecified set of potential beneficiaries.) An RP is protected from
or places a CA on a "bad-CA-list", causing all certs issued by the CA accepting a bogus certificate if that certificate is revoked, and if
to be treated as invalid.) An RP also may benefit from CT if the RP the RP checks the revocation status of the certificate, even in the
validates an SCT associated with a certificate (see 8.1.3 in absence of an SCT. (An RP also is protected if a browser vendor
[I-D.ietf-trans-rfc6962-bis]), and rejects the certificate if the "blacklists" a certificate or places a CA on a "bad-CA-list", causing
Signed certificate Timestamp (SCT) [I-D.ietf-trans-rfc6962-bis] is all certs issued by the CA to be treated as invalid.) An RP also may
invalid. If an RP verified that a certificate that claims to have benefit from CT if the RP validates an SCT associated with a
been logged has a valid log entry, the RP probably would have a certificate (see 8.1.3 in [I-D.ietf-trans-rfc6962-bis]), and rejects
higher degree of confidence that the certificate is genuine. the certificate if the Signed certificate Timestamp (SCT)
However, checking logs in this fashion imposes a burden on RPs and on [I-D.ietf-trans-rfc6962-bis] is invalid. If an RP acquires and
logs. Moreover, the existence of a log entry does not ensure that verifies an inclusion proof for a certificate that claims to have
the certificate is not mis-issued. Unless the certificate Subject is been logged has a valid log entry (8.1.4 in
[I-D.ietf-trans-rfc6962-bis]), the RP probably would have a higher
degree of confidence that the certificate is not bogus. 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 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 potential privacy violation.
attack model does not assume that all RPs will check log entries. Thus this attack model does not assume that all RPs will check log
entries.
A CA benefits from CT when it (acting as a Monitor for its clients) A CA benefits from CT when it (acting as a Monitor for its clients)
detects a (mis-issued) certificate that represents the same Subject detects a (mis-issued) certificate that represents the same Subject
name as a legitimate certificate issued by the CA. 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 potential mis-issuance, and if
revokes a certificate in response to a request from the certificate's a CA revokes a certificate in response to a request from the
legitimate Subject, then an RP benefits without having to implement certificate's legitimate Subject, then an RP benefits without having
any CT-specific mechanisms. to implement any CT-specific mechanisms.
Also note that one proposal [I-D.ietf-trans-gossip] for distributing Also note that one proposal [I-D.ietf-trans-gossip] for distributing
Audit information (to detect misbehaving logs) calls for a browser to Audit information (to detect misbehaving logs) calls for a browser to
send SCTs it receives to the corresponding website when visited by send SCTs it receives to the corresponding website when visited by
the browser. If a website acquires an inclusion proof from a log for the browser. If a website acquires an inclusion proof from a log for
each (unique) SCT it receives in this fashion, this would cause a each (unique) SCT it receives in this fashion, this would cause a
bogus SCT to be discovered, and, presumably, trigger a revocation bogus SCT to be discovered, and, presumably, trigger a revocation
request. request.
Logging [I-D.ietf-trans-rfc6962-bis] is the central element of CT. Logging [I-D.ietf-trans-rfc6962-bis] is the central element of CT.
Logging enables a Monitor to detect a bogus certificate based on Logging enables a Monitor to detect a bogus certificate based on
reference information provided by the certificate Subject. Logging reference information provided by the certificate Subject. (Monitors
of certificates is intended to deter mis-issuance, by creating a also perform an Audit function.) Logging of certificates thus helps
publicly-accessible record that associates a CA with any certificates to deter mis-issuance, by creating a publicly-accessible record that
that it mis-issues. Logging does not remedy mis-issuance; but it associates a CA with any certificates that it mis-issues. Logging
does facilitate remediation by providing the information needed to does not remedy mis-issuance; but it does facilitate remediation by
enable detection and subsequent revocation of bogus certificates in providing the information needed to enable detection and subsequent
some circumstances. revocation of bogus certificates in 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 failures Auditing detects several types of log misbehavior, including failures
to adhere to the advertised Maximum Merge Delay (MMD) and Signed Tree to adhere to the advertised Maximum Merge Delay (MMD) and Signed Tree
Head (STH) frequency count [I-D.ietf-trans-rfc6962-bis] violating the Head (STH) frequency count [I-D.ietf-trans-rfc6962-bis] violating the
append-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 misbehavior for an individual auditor to detect, but the last form of misbehavior
requires communication among multiple log clients. Monitors ought requires communication among multiple log clients. Monitors ought
not trust logs that are detected misbehaving. Thus the Audit not trust logs that are detected misbehaving. Thus the Audit
function does not detect mis-issuance per se. The CT design function does not detect mis-issuance per se. The CT design
identifies audit functions designed to detect several types of identifies audit functions designed to detect several types 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 1a (below) illustrates the data exchanges among the major
elements of the CT system, based on the log specification elements of the CT system, in the contest of CA submission of
[I-D.ietf-trans-rfc6962-bis] and on the assumed behavior of other CT certificate (or pre-certificates) to Logs. It is based on the log
system elements as described above. This Figure does not include the specification [I-D.ietf-trans-rfc6962-bis] and on the assumed
Audit function, because there is not yet agreement on how that behavior of other CT system elements as described above. This
function will work in a distributed, privacy-preserving fashion. 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.
Figure 1b (later) illustrates data exchanges in the context where a
Subject submist a certificate to a Log.
+----+ +---------+ +---------+ +----+ +---------+ +---------+
| CA |---[1]--->| Log |<---[8]---| Monitor | | CA |---[1]--->| Log |<---[8]---| Monitor |
| | | | | | | | | | | |
| |<--[2]----| |----[9]-->| | | |<--[2]----| |----[9]-->| |
| | | | | | | | | | | |
| |---[3]--->| |<--[10]---| | | |---[3]--->| |<--[10]---| |
| | | | | |--------+ | | | | | |--------+
| |<--[4]----| |---[11]-->| | | | |<--[4]----| |---[11]-->| | |
| | | | +---------+ | | | | | +---------+ |
skipping to change at page 7, line 33 skipping to change at page 7, line 33
| | +---------+ +---------+ | | | +---------+ +---------+ |
| | | | | |
| | +---------+ +---------+ | | | +---------+ +---------+ |
| |---[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 [ 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 1a: Data Exchanges Among CT System Element (CA submission)
+----+ +---------+ +---------+
| W |---[1]--->| Log |<---[8]---| Monitor |
| e | | | | (3rd |
| b |<--[2]----| |----[9]-->| party) |
| s | | | | |
| i |---[3]--->| |<--[10]---| |
| t | | | | |--------+
| e |<--[4]----| |---[11]-->| | |
| | +---------+ +---------+ |
| S | |
| u | [12]
| b | |
| j | +---------+ |
| e | | | |
| c |--------------[7]------------->| Browser |<-------+
| t | | |
+----+ +---------+
[ 1] Retrieve accepted root certs
[ 2] accepted root certs
[ 3] Add chain to Log
[ 4] SCT + STH
[ 7] cert + SCTs
[ 8] Retrieve entries from Log
[ 9] returned entries from Log
[10] Retrieve latest STH
[11] returned STH
[12] bogus/erroneous cert notification
Figure 1b: Data Exchanges Among CT System Elements (Subject
submission)
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 mis- 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 issuance. This attack model applies to use of CT in the context of
context. If CT is extended to apply to other contexts, each context browsers and TLS-enabled web servers. If CT is extended to apply to
will require its own attack model, although most elements of the other contexts, each context will require its own attack model,
model described here are likely to be applicable. although most elements of the model described here are likely to be
applicable.
Because certificates are issued by CAs, the top level differentiation Because certificates are issued by CAs, the top level differentiation
in this analysis is whether the CA that mis-issued a certificate did in this analysis is whether the CA that mis-issued a certificate did
so maliciously or not. Next, for each scenario, the model considers so maliciously or not. Next, for each scenario, the model considers
whether or not the certificate was logged. Scenarios are further whether or not the certificate was logged. Scenarios are further
differentiated based on whether the logs and monitors are benign or differentiated based on whether the logs and monitors are benign or
malicious and whether a certificate's Subject is self-monitoring or malicious and whether a certificate's Subject is self-monitoring or
is using a third party Monitoring service. Finally, the analysis is using a third party Monitoring service. Finally, the analysis
considers whether a browser is performing checking relevant to CT. considers whether a browser is performing checking relevant to CT.
The scenarios are organized as illustrated by the following outline: The scenarios are organized as illustrated by the following outline:
Web PKI CA - malicious vs non-malicious 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 context, although most of the
most of the analysis is applicable to other PKI contexts. 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
In the context of this document, a threat is defined, traditionally, In the context of this document, a threat is defined, traditionally,
skipping to change at page 8, line 49 skipping to change at page 9, line 39
to attack a system is not a threat. An adversary who is motivated to attack a system is not a threat. An adversary who is motivated
but not "capable" also is not a threat. Threats change over time; but not "capable" also is not a threat. Threats change over time;
new classes of adversaries may arise, new motivations may come into new classes of adversaries may arise, new motivations may come into
play, and the capabilities of adversaries may change. Nonetheless, play, and the capabilities of adversaries may change. Nonetheless,
it is useful to document perceived threats against a system to it is useful to document perceived threats against a system to
provide a context for understanding attacks (even though some attacks provide a context for understanding attacks (even though some attacks
may be the result of errors, not threats). Even if the assumptions may be the result of errors, not threats). Even if the assumptions
about adversaries prove to be incorrect, documenting the assumptions about adversaries prove to be incorrect, documenting the assumptions
is valuable. is valuable.
As noted above, the goals of CT are to deter, detect, and facilitate As noted above, the goals of CT appear to be to deter, detect, and
remediation of attacks that result in certificate mis-issuance in the facilitate remediation of attacks that result in certificate mis-
Web PKI. (Note that errors by a CA are viewed as attacks, in the issuance in the context of browsers and TLS-enabled web servers.
context of this document.) Such attacks can enable an attacker to (Note that errors by a CA are viewed as attacks, in the context of
spoof the identity of TLS-enabled web sites. Spoofing enables an this document.) Such attacks can enable an attacker to spoof the
adversary to perform many types of attacks, e.g., delivery of malware identity of TLS-enabled web sites. Spoofing enables an adversary to
to a client, reporting bogus information, or acquiring information perform many types of attacks, e.g., delivery of malware to a client,
that a client would not communicate if the client were aware of the reporting bogus information, or acquiring information that a client
spoofing. Such information may include personal identification and would not communicate if the client were aware of the spoofing. Such
authentication information and electronic payment authorization information may include personal identification and authentication
information. Because of the nature of the information that may be information and electronic payment authorization information.
divulged (or misinformation or malware that may be delivered), the Because of the nature of the information that may be divulged (or
principal adversaries in the CT context are perceived to be (cyber) misinformation or malware that may be delivered), the principal
criminals and nation states. Both adversaries are motivated to adversaries in the CT context are perceived to be (cyber) criminals
acquire personal identification and authentication information. and nation states. Both adversaries are motivated to acquire
Criminals are also motivated to acquire electronic payment personal identification and authentication information. Criminals
authorization information. are also motivated to acquire electronic payment authorization
information.
To make use of bogus web site certificates, an adversary must be able To make use of bogus web site certificates, an adversary must be able
to direct a TLS client to a spoofed web site, so that it can present to direct a TLS client to a spoofed web site, so that it can present
the bogus certificate during a TLS handshake. An adversary may the bogus certificate during a TLS handshake. An adversary may
achieve this in various ways, e.g., by manipulation of the DNS 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.
former type of attack is well within the perceived capabilities of
both classes of adversary. The latter attack may be possible for
criminals and is certainly a capability available to a nation state
within its borders. Nation states also may be able to compromise DNS
servers outside their own jurisdiction.
The elements of CT may themselves be targets of attacks, as described The elements of CT may themselves be targets of attacks, as described
below. A criminal organization might compromise a CA and cause it to below. A criminal organization might compromise a CA and cause it to
issue bogus certificates, or it may exert influence over a CA (or CA issue bogus certificates, or it may exert influence over a CA (or CA
staff) to do so, e.g., through extortion or physical threat. A CA staff) to do so, e.g., through extortion or physical threat. A CA
may be the victim of social engineering, causing it to issue a may be the victim of social engineering, causing it to issue a
certificate to an inappropriate Subject. (Even though the CA is not certificate to an inappropriate Subject. (Even though the CA is not
intentionally malicious in this case, the action is equivalent to a intentionally malicious in this case, the action is equivalent to a
malicious CA, hence the use of the term "bogus" here.) A nation malicious CA, hence the use of the term "bogus" here.) A nation
state may operate or influence a CA that is part of the large set of state may operate or influence a CA that is part of the large set of
"root CAs" in browsers. A CA, acting in this fashion, is termed a "root CAs" in browsers. A CA, acting in this fashion, is termed a
"malicious" CA. A nation state also might compromise a CA in another "malicious" CA. A nation state also might compromise a CA in another
country, to effect issuance of bogus certificates. In this case the country, to effect issuance of bogus certificates. In this case the
(non-malicious) CA, upon detecting the compromise (perhaps because of (non-malicious) CA, upon detecting the compromise (perhaps because of
CT) is expected to work with Subjects to remedy the mis-issuance. 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 (e.g., suppressed, either for all log clients or for targeted clients (e.g.,
to selected Monitors or Auditors). It seems unlikely that a to selected Monitors or Auditors).
compromised, non-malicious, log would persist in presenting multiple
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 use
intended to issue certificates to enable monitoring of encrypted to issue certificates to enable monitoring of encrypted browser
browser sessions. The inclusion of a trust anchor for such a CA is sessions, for example. Additional certificates may be locally
intended to facilitate monitoring encrypted content, via an installed to enable an organization to acts as its own trust anchor.
authorized man-in-the-middle (MITM) attack. CT is not designed to CT mechanisms may or may not be applied address locally-managed
counter this type of locally-authorized interception. certificates of this sort.
3. Semantic mis-issuance 3. Semantic mis-issuance
3.1. Non-malicious Web PKI CA context 3.1. Non-malicious 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, in 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 the case of a bogus certificate, because it was the victim of a
social engineering or a technical attack. In the case of an error, social engineering or a technical attack. In the case of an error,
the CA should have a record of the erroneous certificate and be the CA should have a record of the erroneous certificate and be
prepared to revoke this certificate once it has discovered and prepared to revoke this certificate once it has discovered and
confirmed the error. In the event of a technical attack, a CA may confirmed the error. In the event of a technical attack, a CA may
skipping to change at page 11, line 13 skipping to change at page 11, line 48
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, and Subject) to determine the serial number of the bogus certificate, and
revoke it (after investigation). (See Sections 5.1, 5.2 and 5.3.) revoke it (after investigation). (See Sections 5.1, 5.2 and 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 entry, misbehaving log may will suppress a bogus certificate log entry, or
or it may create an entry for the certificate but report it it may create an entry for the certificate but report it selectively.
selectively. (A misbehaving log also could create and report entries (A misbehaving log also could create and report entries for bogus
for bogus certificates that have not been issued by the indicated CA certificates that have not been issued by the indicated CA (hereafter
(hereafter called "fake"). Unless a Monitor validates the associated called "fake"). Fake bogus certificates could cause the Monitors to
certificate chains up to roots that it trusts, these fake bogus report non-existent semantic problems to a Subject who would, in
certificates could cause the Monitors to report non-existent semantic turn, report them to the indicated issuing CA. This might cause the
problems to the Subject who would in turn report them to the CA to incorrectly revoke and re-issue the Subject's real certificate.
purported issuing CA. This might cause the CA to do needless Note that for every certificate submitted to a log, the log must
investigative work or perhaps incorrectly revoke and re-issue the verify a complete certificate chain up to one of the roots it
Subject's real certificate. Note that for every certificate accepts. So creating a log entry for a fake bogus certificate
submitted to a log, the log must verify a complete certificate chain suggests that the log may be misbehaving.
up to one of the roots it accepts. So creating a log entry for a
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 relied upon
Monitors, non-malicious CAs, and by browser vendors. This assumption by Monitors, non-malicious CAs, and by browser vendors. This
forms the basis for the perceived deterrent. It is not clear if assumption forms the basis for the perceived deterrent. It is not
mechanisms to detect this sort of log misbehavior will be viable. clear if 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 may rely upon a
Auditing mechanism [I-D.ietf-trans-gossip] to detect log misbehavior, distributed Auditing mechanism, e.g., [I-D.ietf-trans-gossip], to
as a deterrent. (See Section 5.6 below.) However, a Monitor (third- detect log misbehavior, as a deterrent. (See Section 5.6 below.)
party or self) must participate in the Audit mechanism in order to However, a Monitor (third-party or self) must participate in the
become aware of log misbehavior. Audit mechanism in order to 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 relevant
information about the log entries and STH between the entities STHs between the entities receiving the view that excludes the bogus
receiving the view that excludes the bogus certificate and entities certificate and entities that receive a view that includes it, i.e.,
that receive a view that includes it, i.e., a distributed Audit 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
enrounters the bogus certificate (and SCT) will detect this when it encounters the bogus certificate (and SCT) will detect this when it
checks with the log for log entries and STH (see Section 3.1.2.) checks with the log for inclusion proofs 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 (or Subject) does not submit a pre-certificate to a log,
is benign or misbehaving does not matter. The same is true if a whether a log is benign or misbehaving does not matter. The same is
Subject is issued a certificate without an SCT and does not log the true if a Subject is issued a certificate without an SCT and does not
certificate itself, to acquire an SCT. Also, since there is no log log the certificate itself, to acquire an SCT. Also, since there is
entry in this scenario, there is no difference in outcome between a no log entry in this scenario, there is no difference in outcome
benign and a misbehaving third party Monitor. In both cases, no between a benign and a misbehaving third party Monitor. In both
Monitor (self or third-party) will detect a bogus certificate based cases, no Monitor (self or third-party) will detect a bogus
on Monitor functions and there will be no consequent reporting of the certificate based on Monitor functions and there will be no
problem to the Subject or by the Subject to the CA based on consequent reporting of the problem to the Subject or by the Subject
examination of log entries. to the CA based on examination of log entries.
3.2. Malicious Web PKI CA context 3.2. Malicious CA context
In this section, we address the scenario in which the mis-issuance is In this section, we address the scenario in which the mis-issuance 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 logs A bogus (pre-)certificate may be submitted to one or more benign 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. 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 may 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
skipping to change at page 14, line 16 skipping to change at page 14, line 48
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.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. The Monitor also may avoid relying upon such a for
Monitor also avoids relying upon such a log in the future. However, future entries. However, unless a distributed Audit mechanism, or
unless a distributed Audit mechanism proves effective in detecting equivalent, proves effective in detecting such misbehavior, CT cannot
such misbehavior, CT cannot be relied upon to detect this form of be relied upon to detect this form of mis-issuance. (See Section 5.6
mis-issuance. (See Section 5.6 below.) 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 malicious/ irrespective of whether the logs it checks are benign or malicious/
conspiring. The CT architecture does not include any measures to conspiring. The CT architecture does not include any 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. (Note that an entity other than the issuing CA might
submit a certificate issued by this CA to a log, if it encountered
the certificate. In a narrowly-focused attack, such logging would
not occur, i.e., only the target of the attack would see the
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 Subject. A bogus certificate would not be delivered to the legitimate Subject.
So the Subject, acting as a self-Monitor, cannot detect the issuance So the Subject, acting as a self-Monitor, cannot detect the issuance
of a bogus certificate in this case. of a bogus certificate in this case.
skipping to change at page 15, line 11 skipping to change at page 15, line 48
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 require a browser to reject a certificate architecture does not require a browser to reject a certificate
lacking a matching SCT (or equivalent evidence of logging) in all lacking a matching SCT (or equivalent evidence of logging) in all
cases. This is a matter of local policy. Section 8.1.6 of cases. This is a matter of local policy. Section 8.1.6 of
[I-D.ietf-trans-rfc6962-bis] says: "It is up to a client's local [I-D.ietf-trans-rfc6962-bis] says: "It is up to a client's local
policy to specify the quantity and form of evidence (SCTs, inclusion policy to specify the quantity and form of evidence (SCTs, inclusion
proofs or a combination) needed to achieve compliance and how to proofs or a combination) needed to achieve compliance and how to
handle non-compliance." As a result, this attack model does not handle non-compliance." As a result, this attack model does not
assume that browsers will reject a certificate that is not assume that browsers will reject a certificate that is not
accompanied by an SCT in all circumstances. Since certificates have accompanied by an SCT in all circumstances. Certificates have to be
to be logged to enable detection of mis-issuance by Monitors, and to logged to enable detection of possible mis-issuance by Monitors, and
trigger subsequent revocation, the effectiveness of CT is diminished to trigger possible subsequent revocation. The effectiveness of CT
in circumstances where local policy does not mandate SCT or inclusion in protecting an RP is diminished in circumstances where local policy
proof checking. does not mandate SCT or inclusion proof checking by the RP's
software.
3.3. Undetected Compromise of CAs or Logs 3.3. Undetected Compromise of CAs or Logs
Sections 3.1 and 3.2 examined attacks in the context of non-malicious Sections 3.1 and 3.2 examined attacks in the context of non-malicious
and malicious CAs, and benign and misbehaving logs. Another class of and malicious CAs, and benign and misbehaving logs. Another class of
attacks might occur in the context of a non-malicious CA and/or a attacks might occur in the context of a non-malicious CA and/or a
benign log. Specifically these CT elements might be compromised and benign log. Specifically these CT elements might be compromised and
the compromise might go undetected. Compromise of CAs and logs was 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 noted in Section 2, as was coercion of a CA. As noted there, a
compromised CA is almost equivalent to a malicious CA, and thus the compromised CA is almost equivalent to a malicious CA, and thus the
skipping to change at page 15, line 42 skipping to change at page 16, line 32
compromises warrant some additional discussion, since some relying compromises warrant some additional discussion, since some relying
parties may see signed objects issued by the legitimate (non- parties may see signed objects issued by the legitimate (non-
malicious) CA, others may see signed objects from its compromised malicious) CA, others may see signed objects from its compromised
counterpart, and some may see objects from both. In the case of a counterpart, and some may see objects from both. In the case of a
compromised CA or log the adversary may have access to the private compromised CA or log the adversary may have access to the private
key used by a CA to sign certificates, or used by a log to sign SCTs key used by a CA to sign certificates, or used by a log to sign SCTs
and STHs. (An attacker might not have access to a CA or log private and STHs. (An attacker might not have access to a CA or log private
key per se. The attacker may be able to cause a CA to issue bogus key per se. The attacker may be able to cause a CA to issue bogus
certificates, or a log to generate bogus objects, and not have a certificates, or a log to generate bogus objects, and not have a
record of them. The DigiNotar [2] case is an example of this sort of record of them. The DigiNotar [2] case is an example of this sort of
attack on a CA.) Because the compromise is undetected, there will be attack on a CA.) Until such time that the compromise is detected,
no effort by a CA to have its certificate revoked or by a log to shut there will be no effort by a CA to have its certificate revoked or by
down the log. a log to shut down the log.
3.3.1. Compromised CA, Benign Log 3.3.1. Compromised CA, Benign Log
In the case of a compromised (non-malicious) CA, an attacker may have In the case of a compromised (non-malicious) CA, an attacker may have
acquired the CA's private key, or it may be able to cause the CA to acquired the CA's private key, or it may be able to cause the CA to
sign certificates using that key, even though the attacker does not sign certificates using that key, even though the attacker does not
know the key per se. In other case the goal is to cause the CA to know the key per se. In other cases the goal is to cause the CA to
issues a bogus certificate (that the CA would not knowingly issue). issues a bogus certificate (that the CA would not knowingly issue).
If this certificate is submitted to a (benign) log, then it subject If this certificate is submitted to a (benign) log, then it is
to detection by a Monitor, as discussed in 3.1.1.1. If the bogus subject to detection by a Monitor, as discussed in 3.1.1.1. If the
certificate is submitted to a misbehaving log, then an SCT can be bogus certificate is submitted to a misbehaving log, then an SCT can
generated, but there will be no entry for it, as discussed in be generated, but there will be no entry for it, as discussed in
3.1.1.2. If the bogus certificate is not logged, then there will be 3.1.1.2. If the bogus certificate is not logged, then there will be
no SCT, and the implications are as described in 3.1.2. no SCT, and the implications are as described in 3.1.2.
This sort of attack may be most effective if the CA that is the 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 hide certification path as the legitimate certificate, which may help hide
the bogus certificate. However, means of remedying the attack are the bogus certificate (depending on details of Monitor behavior).
independent of this aspect, i.e., revocation can be effected However, means of remedying the attack are independent of this
irrespective of whether the targeted Subject received its certificate aspect, i.e., revocation can be effected irrespective of whether the
from the compromised CA. targeted Subject received its 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 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 Access bogus certificate was not issued with an Authority Information Access
(AIA) or CRL Distribution Point (CRL DP) extension that enables only (AIA) or CRL Distribution Point (CRL DP) extension that enables only
the malicious twin to revoke the certificate. (The AIA extension in the malicious twin to revoke the certificate. (The AIA extension in
the bogus certificate could be used to direct relying parties to an the bogus certificate could be used to direct relying parties to an
OCSP server controlled by the malicious twin. The CRL DP extension OCSP server controlled by the malicious twin. The CRL DP extension
skipping to change at page 16, line 51 skipping to change at page 17, line 41
revocation of the bogus certificate will also invalidate a legitimate revocation of the bogus certificate will also invalidate a legitimate
certificate. This problem may cause the compromised CA to delay certificate. This problem may cause the compromised CA to delay
revocation, thus allowing the bogus certificate to remain a danger revocation, thus allowing the bogus certificate to remain a 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 key regarded as an error, and not cause the CA to transition to a new key
pair. (This assumes that the bogus certificate does not contain an pair. (This assumes that the bogus certificate does not contain an
AIA or CRL DP extension that wrests control of revocation from the AIA or CRL DP extension that wrests control of revocation from the
compromised CA.) If the compromised CA does determine that its compromised CA.)
private key has been stolen, it probably will take some time to
transition to a new key pair, and reissue certificates to all of its
legitimate Subjects. Thus an attack of this sort probably will take
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 targeted control the sources of revocation status data available to a targeted
user (browser instance), then the user may not become aware of the user (browser instance), then the user may not become aware of the
attack. attack.
skipping to change at page 18, line 16 skipping to change at page 18, line 51
As noted in 3.4, an evil twin CA may issue a bogus certificate that As noted in 3.4, an evil twin CA may issue a bogus certificate that
contains the same Subject name as a legitimate certificate issued by contains the same Subject name as a legitimate certificate issued by
the compromised CA. Alternatively, the bogus certificate may contain the compromised CA. Alternatively, the bogus certificate may contain
a different name but reuse a serial number from a valid, not revoked a different name but reuse a serial number from a valid, 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 acquire an inclusion
that the certificate appears in the log, then this is an effective proof, then this could be an effective attack strategy.
attack strategy. Alternatively, the attacker might not only generate
SCTs, but also pose as the compromised log, at least with regard to Alternatively, the attacker might not only generate SCTs, but also
requests from targeted users. In the latter case, this "evil twin" pose as the compromised log, at least with regard to requests from
log could respond to STH requests from targeted users, making appear targeted users. In the latter case, this "evil twin" log could
that the compromised log was offering a split view (thus acting as a respond to STH requests from targeted users, making it appear that
malicious log). To detect this attack an Auditor needs to employ a the compromised log was offering a split view (thus acting as a
gossip mechanism that is able to acquire CT data from diverse malicious log). To detect this attack an Auditor may need to employ
sources, a feature not yet part of the base CT system. a mechanism that is able to acquire CT data from diverse sources,
e.g., [I-D.ietf-trans-gossip].
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.) a compromised log. (The same adversary may be controlling both.)
The operator of the evil twin log can use the purloined private key The operator of the evil twin log can use the purloined private key
to generate SCTs for certificates that have not been logged by its 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 might need to rely on a distributed
gossiping audit mechanism to detect the compromise (see Section 5.6). gossiping audit mechanism to detect the compromise (see Section 5.6).
3.4. Attacks Based on Exploiting Multiple Certificate Chains 3.4. Attacks Based on Exploiting Multiple Certificate Chains
Section 3.2 examined attacks in which a malicious CA issued a bogus Section 3.2 examined attacks in which a malicious CA issued a bogus
certificate and either tried to prevent the Subject from detecting certificate and either tried to prevent the Subject from detecting
the bogus certificate, or reported the bogus certificate as valid, to the bogus certificate, or reported the bogus certificate as valid, to
at least some relying parties, even if the Subject requested at least some relying parties, even if the Subject requested
revocation. These attacks are limited in that if the bogus revocation. These attacks are limited in that if the bogus
certificate is not submitted to a log, then it may not be accepted by certificate is not submitted to a log, then it may not be accepted by
skipping to change at page 20, line 49 skipping to change at page 21, line 32
[RFC5280]). [RFC5280]).
3.5. Attacks Related to Distribution of Revocation Status 3.5. Attacks Related to Distribution of Revocation Status
A bogus certificate that has been revoked may still appear valid to a A bogus certificate that has been revoked may still appear valid to a
browser under certain circumstances. In part this is because the browser under certain circumstances. In part this is because the
revocation information seen by a relying party is partly under the revocation information seen by a relying party is partly under the
control of the CA and/or the certificate subject. As a result, control of the CA and/or the certificate subject. As a result,
different relying parties may be presented with different revocation different relying parties may be presented with different revocation
information. This is true irrespective of whether revocation is information. This is true irrespective of whether revocation is
effected via use of a CRL or OCSP. Additionally, an attacker can effected via use of a CRL or OCSP. (This analysis does not consider
steer a browser to specific revocation status data via various means, proprietary browser revocation status mechanisms.) Additionally, an
preventing a targeted browser from acquiring accurate revocation attacker can steer a browser to specific revocation status data via
status information for a bogus certificate. various means, preventing a targeted browser from acquiring accurate
revocation status information for a bogus certificate.
The bogus certificate might contain an AIA extension pointing to an The bogus certificate might contain an AIA extension pointing to an
OCSP server controlled by the malicious CA (or the attacker). As OCSP server controlled by the malicious CA (or the attacker). As
noted in Section 3.2.1.1.1, the malicious CA could send a "good" OCSP noted in Section 3.2.1.1.1, the malicious CA could send a "good" OCSP
response to a targeted browser instance, even if other parties are response to a targeted browser instance, even if other parties are
provided with a "revoked" response. A TLS server can supply an OCSP provided with a "revoked" response. A TLS server can supply an OCSP
response to a browser as part of the TLS handshake [RFC6961], if 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 requested by the browser. A TLS server posing as the entity named in
the bogus certificate also could acquire a "good" OCSP response from the bogus certificate also could acquire a "good" OCSP response from
the malicious CA to effect the attack. Only if the browser relies the malicious CA to effect the attack. If the browser relies upon a
upon a trusted, third-party OCSP responder, one not part of the trusted, third-party OCSP responder, one not part of the collusion,
collusion, would these OCSP-based attacks fail. would these OCSP-based attacks fail.
The bogus certificate could contain a CRL distribution point The bogus certificate could contain a CRL distribution point
extension instead of an AIA extension. In that case a site supplying extension instead of an AIA extension. In that case a site supplying
CRLs for the malicious CA could supply different CRLs to different CRLs for the malicious CA could supply different CRLs to different
requestors, in an attempt to hide the revocation status of the bogus requestors, in an attempt to hide the revocation status of the bogus
certificate from targeted browser instances. This is analogous to a certificate from targeted browser instances. This is analogous to a
split-view attack effected by a CT log. However, as noted in 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 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 detecting inconsistent reporting of certificate revocation status
data. (Monitoring in the CT context tracks log entries made by CAs data. (Monitoring in the CT context tracks log entries made by CAs
skipping to change at page 21, line 46 skipping to change at page 22, line 29
the details of which are outside the scope of CT. However the SCT the details of which are outside the scope of CT. However the SCT
mechanism is intended to assure a relying party that certificate has mechanism is intended to assure a relying party that certificate has
been logged, is susceptible to being detected as bogus by a Monitor, been logged, is susceptible to being detected as bogus by a Monitor,
and presumably will be revoked if detected as such. In the context and presumably will be revoked if detected as such. In the context
of these attacks, because of the way revocation may be implemented, of these attacks, because of the way revocation may be implemented,
the assurance provided by the SCT may not have the anticipated the assurance provided by the SCT may not have the anticipated
effect. effect.
4. Syntactic mis-issuance 4. Syntactic mis-issuance
4.1. Non-malicious Web PKI CA context 4.1. Non-malicious 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, but it may do so in issue a syntactically incorrect certificate, but it may do so in
error. (Remember that errors are considered form of attack in this error. (Remember that errors are considered form of attack in this
document, see Section 2). As noted in Section 1, we refer to a document, see Section 2). As noted in Section 1, we refer to a
syntactically incorrect certificate as erroneous. A certificate is syntactically incorrect certificate as erroneous. A certificate is
erroneous if it violates a criteria to which the issuing CA claims to erroneous if it violates a criteria to which the issuing CA claims to
adhere. This might be a general profile such as [RFC5280], or a adhere. This might be a general profile such as [RFC5280], or a
narrower profile such as those established by the CABF [1] for domain narrower profile such as those established by the CABF [1] for domain
validated (DV) or extended validation (EV) certificates. If the validated (DV) or extended validation (EV) certificates. If the
skipping to change at page 22, line 17 skipping to change at page 23, line 4
narrower profile such as those established by the CABF [1] for domain narrower profile such as those established by the CABF [1] for domain
validated (DV) or extended validation (EV) certificates. If the validated (DV) or extended validation (EV) certificates. If the
Subject is a web site that expected to receive an EV certificate, but Subject is a web site that expected to receive an EV certificate, but
the certificate issued to it carries the DV policy OID, or no policy the certificate issued to it carries the DV policy OID, or no policy
OID, relying parties may reject the certificate, causing harm to the OID, relying parties may reject the certificate, causing harm to the
business of the Subject. Conversely, if a CA issues a certificate to business of the Subject. Conversely, if a CA issues a certificate to
a web site and erroneously includes the EV policy OID, relying a web site and erroneously includes the EV policy OID, relying
parties may place more trust in the certificate than is warranted. parties may place more trust in the certificate than is warranted.
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 (pre is capable of performing the checks applicable to the submitted (pre
)certificate. (A (pre )certificate should be logged even if it fails )certificate. (A (pre-)certificate should be logged even if it fails
syntactic validation; logging takes precedence over detection of syntactic validation; logging takes precedence over detection of
syntactic mis-issuance.) If syntactic validation fails, this can be syntactic mis-issuance.) If syntactic validation fails, this could
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, then the CA should remedy the syntactic problem and re-submit the CA, then the CA should remedy the syntactic problem and re-submit 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 could help a submitted prior to issuance, syntactic checking by a log could help a
CA detect and avoid issuance of an erroneous certificate. If the CA CA detect and avoid issuance of an erroneous certificate. If the CA
does not have a record of the certificate contents, then presumably does not have a record of the certificate contents, then presumably
it was a bogus certificate and the CA should revoke it. it was a bogus 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 request erroneous, then the Subject should contact the issuing CA and request
a new certificate. If the Subject is a legitimate subscriber of the a new certificate. If the Subject is a legitimate subscriber of the
CA, then the CA will either have a record of the certificate content CA, then the CA will either have a record of the certificate content
or can obtain a copy of the certificate from the Subject. The CA or can obtain a copy of the certificate from the Subject. The CA
skipping to change at page 23, line 44 skipping to change at page 24, line 30
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, which reporting of non-existent syntactic problems to the issuing CA, which
might cause the CA to do needless investigative work or perhaps might cause the CA to do needless investigative work or perhaps
incorrectly revoke and re-issue the Subject's certificate. incorrectly revoke and re-issue the Subject's certificate.
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. (Note that a Monitor might choose to
depend on a Subject performing the requisite checks when it receives perform such checks, instead of a log, although this capability is
its certificate from a CA. A Monitor that performs syntactic checks not addressed in [I-D.ietf-trans-rfc6962-bis].) Detection of
on behalf of a Subject also could detect such problems, but the CT syntactic errors will depend on a Subject performing the requisite
architecture does not require Monitors to perform such checks. checks when it receives its certificate from a CA. A Monitor that
performs syntactic checks on behalf of a Subject also could detect
such problems, but the CT architecture does not require Monitors to
perform such checks.
4.1.2.1. Self-monitoring Subject 4.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 the of an embedded SCT in the certificate it received from the CA, or the
lack of an SCT supplied to the Subject via an out-of-band channel. A lack of an SCT supplied to the Subject via an out-of-band channel. A
Subject ought to notify the CA if the Subject expected that its Subject ought to notify the CA if the Subject expected 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 Subject certificate to be logged if there is an agreement between the Subject
and the CA to do so, or because the CA advertises that it logs all of and the CA to do so, or because the CA advertises that it logs all of
skipping to change at page 24, line 31 skipping to change at page 25, line 16
4.1.3.1. Self-monitoring Subject and Benign third party Monitor 4.1.3.1. Self-monitoring Subject and Benign third party Monitor
If a Subject or benign third party Monitor performs syntactic checks, If a Subject or benign third party Monitor performs syntactic checks,
it will detect the erroneous certificate and the issuing CA will be it will detect the erroneous certificate and the issuing CA will be
notified (by the Subject). If the Subject is a legitimate subscriber notified (by the Subject). 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.
The CA SHOULD revoke the erroneous certificate (after investigation) The CA SHOULD revoke the erroneous certificate (after investigation)
and remedy the syntactic problem. The CA SHOULD either re-submit the and remedy the syntactic problem. The CA SHOULD either re-submit the
corrected (pre )certificate to one or more logs and then send the corrected (pre-)certificate to one or more logs and then send the
result to the Subject, or send the corrected certificate to the result to the Subject, or send the corrected certificate to the
Subject, who will re-submit it to one or more logs. Subject, who will re-submit it to one or more logs.
4.1.3.2. CT-enabled browser 4.1.3.2. 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 always perform very good syntactic checks on many browsers do not always perform very good syntactic checks on
certificates. For example, a browser may fail to verify that a certificates. For example, a browser may fail to verify that a
skipping to change at page 25, line 7 skipping to change at page 25, line 41
that browsers will be a reliable way to detect erroneous certificates that browsers will be a reliable way to detect erroneous certificates
in all circumstances. Moreover, a protocol used by a browser to in all circumstances. Moreover, a protocol used by a browser to
notify a Subject and/or CA of an erroneous certificate represents a notify a Subject and/or CA of an erroneous certificate represents a
DoS potential, and thus may not be appropriate. Additionally, if a DoS potential, and thus may not be appropriate. Additionally, if a
browser directly contacts a CA when an erroneous certificate is browser directly contacts a CA when an erroneous certificate is
detected, this is a potential privacy violation, i.e., the CA learns detected, this is a potential privacy violation, i.e., the CA learns
that the browser user is visiting the web site in question. These that the browser user is visiting the web site in question. These
observations argue for syntactic checking to be performed by other observations argue for syntactic checking to be performed by other
elements of the CT system, e.g., logs and/or Monitors. elements of the CT system, e.g., logs and/or Monitors.
4.2. Malicious Web PKI CA context 4.2. Malicious 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 error. syntactically incorrect certificate is intentional, not due to error.
The CA is not the victim but the attacker. The CA is not the victim but the attacker.
Note that irrespective of whether syntactic checks are performed by a Note that irrespective of whether syntactic checks are performed by a
log, a malicious CA can acquire an embedded SCT, or post-issuance log, a malicious CA can acquire an embedded SCT, or post-issuance
will acquire a standalone SCT for an erroneous certificate. If will acquire a standalone SCT for an erroneous certificate. If
Subjects or Monitors perform syntactic checks that detect the Subjects or Monitors perform syntactic checks that detect the
syntactic mis-issuance and report the problem to the CA, a malicious syntactic mis-issuance and report the problem to the CA, a malicious
CA may do nothing or may delay the action(s) needed to remedy the CA may do nothing or may delay the action(s) needed to remedy the
problem. problem.
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 might cause the Because the CA is presumed to be malicious, the CA might cause the
log to not perform checks (if it had chosen to do so), in one of log to not perform checks (if the log offered this option). Because
several ways. logs are not required to perform syntax checks, there probably would
have to be a way for a CA to request checking, the CA might indicate
1. The CA may assert that the certificate is being issued w/o regard that it did not desire such checks to be performed. Or the CA might
to any guidelines (the "no guidelines" reserved CCID). submit a (pre-)certificate to a log that is known to not perform any
syntactic checks, and thus avoid syntactic checking.
2. The CA may assert a CCID that has not been registered, and thus
no log will be able to perform a check.
3. The CA may check to see which CCIDs a log declares it can check,
and chose a registered CCID that is not checked by the log in
question.
4. The CA may submit a (pre-) certificate to a log that is known to
not perform any syntactic checks, and thus avoid syntactic
checking.
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. CT-enabled browser 4.2.1.3. CT-enabled browser
As noted above (4.1.3.2), most browsers fail to perform thorough As noted above (4.1.3.2), most browsers do not 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 certificates although the pervasive nature of syntactically-defective certificates
may limit the utility of such checks. (Remember, in this scenario, may limit the utility of such checks. (Remember, in this scenario,
the log is benign.) However, if a browser does not discriminate the log is benign.) However, if a browser does not discriminate
against certificates that do not contain SCTs (or that are not against certificates that do not contain SCTs (or that are not
accompanied by an SCT in the TLS handshake), only minimal benefits accompanied by an SCT in the TLS handshake), only minimal benefits
might accrue to the browser from syntax checks perform by logs or might accrue to the browser from syntax checks perform by logs or
Monitors. Monitors.
skipping to change at page 28, line 22 skipping to change at page 28, line 46
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. If a browser
communication has not been specified, i.e., there are no standard vendor operates it's own Monitor, there is no need for a standard way
ways to configure a browser to reject individual bogus or erroneous to convey this information. However, there are no standard ways to
certificates based on information provided by an external entity such convey Monitor information to a browser, e.g., to reject individual
as a Monitor. Moreover, the same or another malicious CA could issue bogus or erroneous certificates based on information provided by a
new bogus or erroneous certificates for the targeted Subject, which Monitor. Moreover, the same or another malicious CA could issue new
would have to be detected and rejected in this (as yet unspecified) bogus or erroneous certificates for the targeted Subject, which would
have to be detected and rejected in this (as yet unspecified)
fashion. Thus, for now, CT does not seem to provide a way to fashion. Thus, for now, CT does not seem to provide a 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 may not be visible to
Monitors. Only if Monitors and browsers reject certificates that Monitors. If browsers reject certificates that contain SCTs from
contain SCTs from conspiring logs (based on information from an conspiring logs (e.g., based on information from an auditor) CT
auditor) will CT be able to detect and deter use of such logs. Thus should be able to detect and deter use of such logs by (benign) CAs.
the means by which a Monitor performing an audit function detects
such logs, and informs browsers must be specified for CT to be
effective in the context of misbehaving logs.
Absent a well-defined mechanism that enables Monitors to verify that Section 8.3 of [I-D.ietf-trans-rfc6962-bis] specifies that auditing
data from logs are reported in a consistent fashion, CT cannot claim is performed by Monitors and/or browsers. If a Monitor performs the
to provide protection against logs that are malicious or may conspire function, then it needs a way to communicate the results of audit
with, or are victims of, attackers effecting certificate mis- infractions to CAs and browsers. If a browser vendor operates a
issuance. The mechanism needs to protect the privacy of users with Monitor it could use its audit information to cause browsers to
respect to which web sites they visit. It needs to scale to reject certificates with SCTs from suspect logs. However, there is
accommodate a potentially large number of self-monitoring Subjects no standard mechanism defined to allow a self-monitoring Subject to
and a vast number of browsers, if browsers are part of the mechanism. convey this information to browsers directly.
Even when an Audit mechanism is defined, it will be necessary to
describe how the CT system will deal with a misbehaving or If auditing is performed by browsers directly there may be user
compromised log. For example, will there be a mechanism to alert all privacy concerns due to direct interaction with logs, as noted in
browsers to reject SCTs issued by such a log? Absent a description Section 8.1.4 of [I-D.ietf-trans-rfc6962-bis]. Also, unless browsers
of a remediation strategy to deal with misbehaving or compromised have ways to share audit information with other browsers, local
logs, CT cannot ensure detection of mis-issuance in a wide range of detection of a misbehaving log does not necessarily benefit a larger
scenarios. community. At the time of this writing, one mechanism has been
defined (via an RFC) for use with CT to achieve the necessary
communication: [I-D.ietf-trans-gossip].
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
 End of changes. 73 change blocks. 
300 lines changed or deleted 330 lines changed or added

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