draft-ietf-trans-threat-analysis-03.txt   draft-ietf-trans-threat-analysis-04.txt 
Public Notary Transparency S. Kent Public Notary Transparency S. Kent
Internet Draft BBN Technologies Internet Draft BBN Technologies
Expires: April 2016 October 6, 2015 Expires: July 2016 January 30, 2016
Intended Status: Informational Intended Status: Informational
Attack Model and Threat for Certificate Transparency Attack Model and Threat for Certificate Transparency
draft-ietf-trans-threat-analysis-03 draft-ietf-trans-threat-analysis-04
Abstract Abstract
This document describes an attack model and discusses threats for the This document describes an attack model and discusses threats for
Web PKI context in which security mechanisms to detect mis-issuance the Web PKI context in which security mechanisms to detect mis-
of web site certificates are being developed. The model provides an issuance of web site certificates are being developed. The model
analysis of detection and remediation mechanisms for both syntactic provides an analysis of detection and remediation mechanisms for
and semantic mis-issuance. The model introduces an outline of attacks both syntactic and semantic mis-issuance. The model introduces an
to organize the discussion. The model also describes the roles played outline of attacks to organize the discussion. The model also
by the elements of the Certificate Transparency (CT) system, to describes the roles played by the elements of the Certificate
establish a context for the model. Transparency (CT) system, to establish a context for the model.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with This Internet-Draft is submitted to IETF in full conformance with
the provisions of BCP 78 and BCP 79. the provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other documents
time. It is inappropriate to use Internet-Drafts as reference at any time. It is inappropriate to use Internet-Drafts as
material or to cite them other than as "work in progress." reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on April 6, 2016. This Internet-Draft will expire on July 30, 2016.
Table of Contents Table of Contents
1. Introduction....................................................... 3 1. Introduction....................................................... 3
2. Threats............................................................ 7 2. Threats............................................................ 8
3. Semantic mis-issuance.............................................. 9 3. Semantic mis-issuance.............................................. 9
3.1. Non-malicious Web PKI CA context ............................... 9 3.1. Non-malicious Web PKI CA context ............................... 9
3.1.1. Certificate logged ......................................... 9 3.1.1. Certificate logged ........................................ 10
3.1.1.1. Benign log.............................................. 9 3.1.1.1. Benign log............................................. 10
3.1.1.1.1. Self-monitoring Subject ............................. 9 3.1.1.1.1. Self-monitoring Subject ............................ 10
3.1.1.1.2. Benign third party Monitor .......................... 9 3.1.1.1.2. Benign third party Monitor ......................... 10
3.1.1.2. Misbehaving log........................................ 10 3.1.1.2. Misbehaving log........................................ 10
3.1.1.2.1. Self-monitoring Subject ............................ 10 3.1.1.2.1. Self-monitoring Subject ............................ 11
3.1.1.2.2. Benign third party Monitor ......................... 10 3.1.1.2.2. Benign third party Monitor ......................... 11
3.1.1.3. Misbehaving third party Monitor........................ 11 3.1.1.3. Misbehaving third party Monitor........................ 12
3.1.2. Certificate not logged .................................... 11 3.1.2. Certificate not logged .................................... 12
3.1.2.1. Self-monitoring Subject................................ 12 3.1.2.1. Self-monitoring Subject................................ 12
3.1.2.2. CT-enabled browser..................................... 12 3.1.2.2. CT-enabled browser..................................... 12
3.2. Malicious Web PKI CA context .................................. 12 3.2. Malicious Web PKI CA context .................................. 13
3.2.1. Certificate logged ........................................ 12 3.2.1. Certificate logged ........................................ 13
3.2.1.1. Benign log............................................. 12 3.2.1.1. Benign log............................................. 13
3.2.1.1.1. Self-monitoring Subject ............................ 13 3.2.1.1.1. Self-monitoring Subject ............................ 13
3.2.1.1.2. Benign third party Monitor ......................... 13 3.2.1.1.2. Benign third party Monitor ......................... 13
3.2.1.2. Misbehaving log........................................ 13 3.2.1.2. Misbehaving log........................................ 14
3.2.1.2.1. Monitors - third party and self .................... 13 3.2.1.2.1. Monitors - third party and self .................... 14
3.2.1.3. Misbehaving third party Monitor........................ 13 3.2.1.3. Misbehaving third party Monitor........................ 14
3.2.2. Certificate not logged .................................... 14 3.2.2. Certificate not logged .................................... 14
3.2.2.1. CT-aware browser....................................... 14 3.2.2.1. CT-aware browser....................................... 15
4. Syntactic mis-issuance............................................ 14 4. Syntactic mis-issuance............................................ 15
4.1. Non-malicious Web PKI CA context .............................. 14 4.1. Non-malicious Web PKI CA context .............................. 15
4.1.1. Certificate logged ........................................ 15 4.1.1. Certificate logged ........................................ 15
4.1.1.1. Benign log............................................. 15 4.1.1.1. Benign log............................................. 15
4.1.1.2. Misbehaving log or third party Monitor................. 16 4.1.1.2. Misbehaving log or third party Monitor................. 16
4.1.1.3. Self-monitoring Subject and Benign third party Monitor. 16 4.1.1.3. Self-monitoring Subject and Benign third party Monitor. 17
4.1.1.4. CT-enabled browser..................................... 16 4.1.1.4. CT-enabled browser..................................... 17
4.1.2. Certificate not logged .................................... 17 4.1.2. Certificate not logged .................................... 17
4.2. Malicious Web PKI CA context .................................. 17 4.2. Malicious Web PKI CA context .................................. 17
4.2.1. Certificate logged ........................................ 17 4.2.1. Certificate logged ........................................ 18
4.2.1.1. Benign log............................................. 17 4.2.1.1. Benign log............................................. 18
4.2.1.2. Misbehaving log or third party Monitor................. 18 4.2.1.2. Misbehaving log or third party Monitor................. 18
4.2.1.3. Self-monitoring Subject and Benign third party Monitor. 18 4.2.1.3. Self-monitoring Subject and Benign third party Monitor. 18
4.2.1.4. CT-enabled browser..................................... 18 4.2.1.4. CT-enabled browser..................................... 18
4.2.2. Certificate is not logged ................................. 18 4.2.2. Certificate is not logged ................................. 19
5. Issues Applicable to Sections 3 and 4............................. 19 5. Issues Applicable to Sections 3 and 4............................. 19
5.1. How does a Subject know which Monitor(s) to use? .............. 19 5.1. How does a Subject know which Monitor(s) to use? .............. 19
5.2. How does a Monitor discover new logs? ......................... 19 5.2. How does a Monitor discover new logs? ......................... 19
5.3. CA response to report of a bogus or erroneous certificate ..... 19 5.3. CA response to report of a bogus or erroneous certificate ..... 20
5.4. Browser behavior .............................................. 20 5.4. Browser behavior .............................................. 20
5.5. Remediation for a malicious CA ................................ 20 5.5. Remediation for a malicious CA ................................ 20
5.6. Auditing - detecting misbehaving logs ......................... 20 5.6. Auditing - detecting misbehaving logs ......................... 21
6. Security Considerations........................................... 22 6. Security Considerations........................................... 22
7. IANA Considerations............................................... 22 7. IANA Considerations............................................... 22
8. Acknowledgments................................................... 22 8. Acknowledgments................................................... 23
9. References........................................................ 23 9. References........................................................ 24
9.1. Normative References .......................................... 23 9.1. Normative References .......................................... 24
9.2. Informative References ........................................ 23 9.2. Informative References ........................................ 24
Author's Addresses................................................... 23 Author's Addresses................................................... 24
Copyright Statement.................................................. 24 Copyright Statement.................................................. 25
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 if it A certificate is characterized as syntactically mis-issued (aka
violates syntax constraints associated with the class of certificate erroneous) if it violates syntax constraints associated with the
that it purports to represent. Syntax constraints for certificates class of certificate that it purports to represent. Syntax
are established by certificate profiles, and typically are constraints for certificates are established by certificate
application-specific. For example, certificates used in the Web PKI profiles, and typically are application-specific. For example,
environment might be characterized as domain validation (DV) or certificates used in the Web PKI environment might be characterized
extended validation (EV) certificates. Certificates used with as domain validation (DV) or extended validation (EV) certificates.
applications such as IPsec or S/MIME have different syntactic Certificates used with applications such as IPsec or S/MIME have
constraints from those in the Web PKI context. different syntactic constraints from those in the Web PKI context.
There are two classes of beneficiaries of CT: certificate Subjects There are two classes of beneficiaries of CT: certificate Subjects
and relying parties (RPs). In the initial focus context of CT, the and relying parties (RPs). In the initial focus context of CT, the
Web PKI, Subjects are web sites and RPs are browsers employing HTTPS Web PKI, Subjects are web sites and RPs are browsers employing HTTPS
to access these web sites. to access these web sites.
A certificate Subject benefits from CT because CT helps detect A certificate Subject benefits from CT because CT helps detect
certificates that have been mis-issued in the name of that Subject. certificates that have been mis-issued in the name of that Subject.
A Subject learns of a bogus certificate (issued in its name), via A Subject learns of a bogus certificate (issued in its name), via
the Monitor function of CT. The Monitor function may be provided by the Monitor function of CT. The Monitor function may be provided by
the Subject itself, i.e., self-monitoring, or by a third party the Subject itself, i.e., self-monitoring, or by a third party
trusted by the Subject. When a Subject is informed of certificate trusted by the Subject. When a Subject is informed of certificate
mis-issuance by a Monitor, the Subject is expected to request/demand mis-issuance by a Monitor, the Subject is expected to request/demand
revocation of the bogus certificate. Revocation of a bogus revocation of the bogus certificate. Revocation of a bogus
certificate is the primary means of remedying mis-issuance. (If a certificate is the primary means of remedying mis-issuance.
browser vendor distributes a ''blacklist'' of bogus certificates or a
bad-CA-list of certificates of CAs that have mis-issued certificates Certificate Revocations Lists (CRLs) [RFC5280] are the primary means
and modifies the browser to reject any certificates on the blacklist of certificate revocation established by IETF (and ISO) standards.
or for which the issuing CA is on the bad-CA-list, this too remedies Unfortunately, most browsers do not make use of CRLs to check the
mis-issuance. Throughout the remainder of this document references revocation status of certificates presented by a TLS Server
to certificate revocation as a remedy encompass this and analogous (Subject). Some browsers make use of Online Certificate Status
forms of browser behavior, if available. Note: there are no IETF Protocol(OCSP) data [RFC4366] as a standards-based alternative to
standards defining a browser blacklist capability.) CRLs. Also, most browser vendors employ proprietary means of
revoking certificates, e.g., via a "blacklist" or a bad-CA-list.
Such capabilities enable a browser vendor to cause browsers to
reject any certificates on the blacklist or for which the issuing CA
is on the bad-CA-list. This approach also remedies mis-issuance.
Throughout the remainder of this document references to certificate
revocation as a remedy encompass this and analogous forms of browser
behavior, if available. Note: there are no IETF standards defining a
browser blacklist capability.)
Note that a Subject can benefit from the Monitor function of CT even Note that a Subject can benefit from the Monitor function of CT even
if the Subject's certificate has not been logged. Monitoring of logs if the Subject's certificate has not been logged. Monitoring of logs
for certificates issued in the Subject's name suffices to detect for certificates issued in the Subject's name suffices to detect
mis-issuance targeting the Subject, if the bogus/erroneous mis-issuance targeting the Subject, if the bogus/erroneous
certificate is logged. certificate is logged.
A relying party (e.g., browser) benefits from CT if it rejects a A relying party (e.g., browser) benefits from CT if it rejects a
bogus certificate, i.e., treats it as invalid. An RP is protected bogus certificate, i.e., treats it as invalid. An RP is protected
from accepting a bogus certificate if that certificate is revoked, from accepting a bogus certificate if that certificate is revoked,
and if the RP checks the revocation status of the certificate. (An and if the RP checks the revocation status of the certificate. (An
RP is also protected if a browser vendor ''blacklists'' a certificate RP is also protected if a browser vendor "blacklists" a certificate
or ''bad-CA-lists'' a CA as noted above.) An RP also may benefit from or "bad-CA-lists" a CA as noted above.) An RP also may benefit from
CT if the RP validates an SCT associated with a certificate, and CT if the RP validates an SCT associated with a certificate, and
rejects the certificate if the SCT is invalid. If an RP verified rejects the certificate if the Signed certificate Timestamp (SCT)
that a certificate that claims to have been logged has a valid log [TRANS] is invalid. If an RP verified that a certificate that claims
entry, the RP would have a higher degree of confidence that the to have been logged has a valid log entry, the RP would have a
certificate is genuine. However, checking logs in this fashion higher degree of confidence that the certificate is genuine.
imposes a burden on RPs and on logs. Moreover, the existence of a However, checking logs in this fashion imposes a burden on RPs and
log entry does not ensure that the certificate is not mis-issued. on logs. Moreover, the existence of a log entry does not ensure that
Unless the certificate Subject is monitoring the log(s) in question, the certificate is not mis-issued. Unless the certificate Subject is
a bogus certificate will not be detected by CT mechanisms. Finally, monitoring the log(s) in question, a bogus certificate will not be
if an RP were to check logs for individual certificates, that would detected by CT mechanisms. Finally, if an RP were to check logs for
disclose to logs the identity of web sites being visited by the RP, individual certificates, that would disclose to logs the identity of
a privacy violation. Thus this attack model assumes that RPs will web sites being visited by the RP, a privacy violation. Thus this
not check log entries. attack model assumes that RPs will not check log entries.
Note that all RPs may benefit from CT even if they do nothing with Note that all RPs may benefit from CT even if they do nothing with
SCTs. If Monitors inform Subjects of mis-issuance, and if a CA SCTs. If Monitors inform Subjects of mis-issuance, and if a CA
revokes a certificate in response to a request from the revokes a certificate in response to a request from the
certificate's legitimate Subject, then an RP benefits without having certificate's legitimate Subject, then an RP benefits without having
to implement any CT-specific mechanisms. to implement any CT-specific mechanisms.
Also note that one proposal for distributing Audit information (to
detect misbehaving logs) calls for a browser to send SCTs it
receives to the corresponding website when visited by 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 bogus
SCT to be discovered, and, presumably, trigger a revocation request.
Logging [TRANS] is the central element of CT. Logging enables a Logging [TRANS] is the central element of CT. Logging enables a
Monitor to detect a bogus certificate based on reference information Monitor to detect a bogus certificate based on reference information
provided by the certificate Subject. Logging of certificates is provided by the certificate Subject. Logging of certificates is
intended to deter mis-issuance, by creating a publicly-accessible intended to deter mis-issuance, by creating a publicly-accessible
record that associates a CA with any certificates that it mis- record that associates a CA with any certificates that it mis-
issues. Logging does not remedy mis-issuance; but it does facilitate issues. Logging does not remedy mis-issuance; but it does facilitate
remediation by providing the information needed to enable detection remediation by providing the information needed to enable detection
and consequently revocation of bogus certificates in some and consequently revocation of bogus certificates in some
circumstances. circumstances.
Auditing is a function employed by CT to detect misbehavior by logs Auditing is a function employed by CT to detect misbehavior by logs
and to deter mis-issuance that is abetted by misbehaving logs. and to deter mis-issuance that is abetted by misbehaving logs.
Auditing detects several types of log misbehavior, including Auditing detects several types of log misbehavior, including
failures to adhere to the advertised MMD and STH frequency count, failures to adhere to the advertised Maximum Merge Delay (MMD) and
violating the append-only property, and providing inconsistent views Signed Tree Head (STH) frequency count [TRANS] violating the append-
of the log to different log clients. The first three of these are only property, and providing inconsistent views of the log to
relatively easy for an individual auditor to detect, but the last different log clients. The first three of these are relatively easy
form of misbehavior requires communication among multiple log for an individual auditor to detect, but the last form of
clients. Monitors ought not trust logs that are detected misbehavior requires communication among multiple log clients.
misbehaving. Thus the Audit function does not detect mis-issuance Monitors ought not trust logs that are detected misbehaving. Thus
per se. There is no agreed-upon Audit function design for CT at the the Audit function does not detect mis-issuance per se. There is no
time of this writing. As a result, the model merely notes where agreed-upon Audit function design for CT at the time of this
Auditing is needed to detect certain classes of attacks. writing. As a result, the model merely notes where Auditing is
needed to detect certain classes of attacks.
Figure 1 (below) illustrates the data exchanges among the major Figure 1 (below) illustrates the data exchanges among the major
elements of the CT system, based on the log specification [TRANS] elements of the CT system, based on the log specification [TRANS]
and on the assumed behavior of other CT system elements as described and on the assumed behavior of other CT system elements as described
above. This Figure does not include the Audit function, because above. This Figure does not include the Audit function, because
there is not yet agreement on how that function will work in a there is not yet agreement on how that function will work in a
distributed, privacy-preserving fashion. distributed, privacy-preserving fashion.
+----+ +---------+ +---------+ +----+ +---------+ +---------+
| CA |---[ 1]-->| Log |<---[8]---| Monitor | | CA |---[ 1]-->| Log |<---[8]---| Monitor |
skipping to change at page 7, line 50 skipping to change at page 8, line 20
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
2. Threats 2. Threats
A threat is defined, traditionally, as a motivated, capable A threat is defined, traditionally, as a motivated, capable
adversary. An adversary who is not motivated to attack a system is adversary. An adversary who is not motivated to attack a system is
not a threat. An adversary who is motivated but not ''capable'' also is not a threat. An adversary who is motivated but not "capable" also
not a threat. Threats change over time; new classes of adversaries is not a threat. Threats change over time; new classes of
may arise, new motivations may come into play, and the capabilities adversaries may arise, new motivations may come into play, and the
of adversaries may change. Nonetheless, it is useful to document capabilities of adversaries may change. Nonetheless, it is useful to
perceived threats against a system to provide a context for document perceived threats against a system to provide a context for
understanding attacks. Even if the assumptions about adversaries understanding attacks. Even if the assumptions about adversaries
prove to be incorrect, documenting the assumptions is valuable. prove to be incorrect, documenting the assumptions is valuable.
As noted above, the goals of CT are to deter, detect, and facilitate As noted above, the goals of CT are to deter, detect, and facilitate
remediation of attacks on the web PKI. Such attacks can enable an remediation of attacks on the web PKI. Such attacks can enable an
attacker to spoof the identity of TLS-enabled web sites. Spoofing attacker to spoof the identity of TLS-enabled web sites. Spoofing
enables an adversary to acquire information that a TLS-enabled client enables an adversary to acquire information that a TLS-enabled
would not communicate if the client were aware of the spoofing. Such client would not communicate if the client were aware of the
information may include personal identification and authentication spoofing. Such information may include personal identification and
information and electronic payment authorization information. authentication information and electronic payment authorization
Because of the nature of the information that may be divulged, the information. Because of the nature of the information that may be
principal adversaries in the CT context are perceived to be (cyber) divulged, the principal adversaries in the CT context are perceived
criminals and nation states. Both adversaries are motivated to to be (cyber) criminals and nation states. Both adversaries are
acquire personal identification and authentication information. motivated to acquire personal identification and authentication
Criminals are also motivated to acquire electronic payment information. Criminals are also motivated to acquire electronic
authorization information. <want to list other ino targets here?> payment authorization information.
To make use of forged web site certificates, an adversary must be To make use of forged web site certificates, an adversary must be
able to direct a TLS client to a spoofed web site, to present the able to direct a TLS client to a spoofed web site, so that it can
forged certificate during a TLS handshake. An adversary may achieve present the forged certificate during a TLS handshake. An adversary
this in various ways, e.g., by causing a user to click on a link to may achieve this in various ways, e.g., by causing a user to click
the website, or by manipulation of the DNS response sent to a TLS on a link to the website, or by manipulation of the DNS response
client. The former type of attack is well within the perceived sent to a TLS client. The former type of attack is well within the
capabilities of both classes of adversary. The latter attack may be perceived capabilities of both classes of adversary. The latter
possible for criminals and is certainly a capability available to a attack may be possible for criminals and is certainly a capability
nation state within its borders. Nation states also may be able to available to a nation state within its borders. Nation states also
compromise DNS servers outside their own jurisdiction. 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
below. A criminal organization might compromise a CA and cause it to described below. A criminal organization might compromise a CA and
issue bogus certificates, or it may exert influence over a CA (or CA cause it to issue bogus certificates, or it may exert influence over
staff) to do so, e.g., through extortion or physical threat. A nation a CA (or CA staff) to do so, e.g., through extortion or physical
state may operate or influence a CA that is part of the large set of threat. (Even though the CA is not intentionally malicious in this
''root CAs'' in browsers. A CA, acting in this fashion, is termed a case, the action is equivalent to a malicious CA, hence the use of
''malicious'' CA. A nation state also might compromise a CA in another the term "bogus" here.) A nation state may operate or influence a CA
country, to effect issuance of bogus certificates. In this case the that is part of the large set of "root CAs" in browsers. A CA,
(non-malicious) CA, upon detecting the compromise (perhaps because of acting in this fashion, is termed a "malicious" CA. A nation state
CT) is expected to work with Subjects to remedy the mis-issuance. also might compromise a CA in another country, to effect issuance of
bogus certificates. In this case the (non-malicious) CA, upon
detecting the compromise (perhaps because of CT) is expected to work
with Subjects to remedy the mis-issuance.
A log also might be compromised by a suitably sophisticated criminal A log also might be compromised by a suitably sophisticated criminal
organization or by a nation state. Compromising a log would enable a organization or by a nation state. Compromising a log would enable a
compromised or rogue CA to acquire SCTs, but log entries would be compromised or rogue CA to acquire SCTs, but log entries would be
suppressed, either for all log clients or for targeted clients (e.g., suppressed, either for all log clients or for targeted clients
to selected Monitors or Auditors). It seems unlikely that a (e.g., to selected Monitors or Auditors). It seems unlikely that a
compromised, non-malicious, log would persist in presenting multiple compromised, non-malicious, log would persist in presenting multiple
views of its data, but a malicious log would. views of its data, but a malicious log would.
Finally, note that a browser trust store may include a CA that is
intended to issue certificates to enable monitoring of encrypted
browser sessions. The inclusion of a trust anchor for such a CA is
intended to facilitate monitoring encrypted content, via an
authorized man-in-the-middle (MITM) attack. CT is not designed to
detect and counter this type of locally-authorized interception.
3. Semantic mis-issuance 3. Semantic mis-issuance
3.1. Non-malicious Web PKI CA context 3.1. Non-malicious Web PKI CA context
In this section, we address the case where the CA has no intent to In this section, we address the case where the CA has no intent to
issue a bogus certificate. issue a bogus certificate.
A CA may have mis-issued a certificate as a result of an error or, in A CA may have mis-issued a certificate as a result of an error or,
the case of a bogus certificate, because it was the victim of a in the case of a bogus certificate, because it was the victim of a
social engineering attack or an attack such as the one that affected social engineering attack or an attack such as the one that affected
DigiNotar DigiNotar
[https://www.vasco.com/company/about_vasco/press_room/news_archive/20 [https://www.vasco.com/company/about_vasco/press_room/news_archive/2
11/news_diginotar_reports_any security_incident.aspx]. In the case of 011/news_diginotar_reports_any security_incident.aspx]. In the case
an error, the CA should have a record of the erroneous certificate of an error, the CA should have a record of the erroneous
and be prepared to revoke this certificate once it has discovered and certificate and be prepared to revoke this certificate once it has
confirmed the error. In the event of an attack, a CA may have no discovered and confirmed the error. In the event of an attack, a CA
record of a bogus certificate. may have no record of a bogus certificate.
3.1.1. Certificate logged 3.1.1. Certificate logged
3.1.1.1. Benign log 3.1.1.1. Benign log
The log (or logs) is benign and thus is presumed to provide The log (or logs) is benign and thus is presumed to provide
consistent, accurate responses to requests from all clients. consistent, accurate responses to requests from all clients.
If a bogus (pre-)certificate has been submitted to one or more logs If a bogus (pre-)certificate has been submitted to one or more logs
prior to issuance to acquire an embedded SCT, or post-issuance to prior to issuance to acquire an embedded SCT, or post-issuance to
acquire a standalone SCT, detection of this mis-issuance is the acquire a standalone SCT, detection of this mis-issuance is the
responsibility of a Monitor. responsibility of a Monitor.
3.1.1.1.1. Self-monitoring Subject 3.1.1.1.1. Self-monitoring Subject
If a Subject is tracking the log(s) to which a certificate was If a Subject is tracking the log(s) to which a certificate was
submitted, and is performing self-monitoring, then it will be able to submitted, and is performing self-monitoring, then it will be able
detect a bogus (pre-)certificate and request revocation. In this to detect a bogus (pre-)certificate and request revocation. In this
case, the CA will make use of the log entry (supplied by the Subject) case, the CA will make use of the log entry (supplied by the
to determine the serial number of the bogus certificate, and Subject) to determine the serial number of the bogus certificate,
investigate/revoke it. (See Sections 5.1, 5.2 and 5.3.) and investigate/revoke it. (See Sections 5.1, 5.2 and 5.3.)
3.1.1.1.2. Benign third party Monitor 3.1.1.1.2. Benign third party Monitor
If a benign third party monitor is checking the logs to which a If a benign third party monitor is checking the logs to which a
certificate was submitted and is protecting the targeted Subject, it certificate was submitted and is protecting the targeted Subject, it
will detect a bogus certificate and will alert the Subject. The will detect a bogus certificate and will alert the Subject. The
Subject, in turn, will ask the CA to revoke the bogus certificate. In Subject, in turn, will ask the CA to revoke the bogus certificate.
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,
revoke it (after investigation). (See Sections 5.1, 5.2 and 5.3.) and 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 misbehaving log probably will suppress a bogus certificate log
entry, or it may create an entry for the certificate but report it entry, or it may create an entry for the certificate but report it
selectively. (A misbehaving log also could create and report entries selectively. (A misbehaving log also could create and report entries
for bogus certificates that have not been issued by the indicated CA for bogus certificates that have not been issued by the indicated CA
(hereafter called ''fake''). Unless a Monitor validates the associated (hereafter called "fake"). Unless a Monitor validates the associated
certificate chains up to roots that it trusts, these fake bogus certificate chains up to roots that it trusts, these fake bogus
certificates could cause the Monitors to report non-existent semantic certificates could cause the Monitors to report non-existent
problems to the Subject who would in turn report them to the semantic problems to the Subject who would in turn report them to
purported issuing CA. This might cause the CA to do needless the purported issuing CA. This might cause the CA to do needless
investigative work or perhaps incorrectly revoke and re-issue the investigative work or perhaps incorrectly revoke and re-issue the
Subject's real certificate. Note that for every certificate submitted Subject's real certificate. Note that for every certificate
to a log, the log MUST verify a complete certificate chain up to one submitted to a log, the log MUST verify a complete certificate chain
of the roots it accepts. So creating a log entry for a fake bogus up to one of the roots it accepts. So creating a log entry for a
certificate marks the log as misbehaving.) fake bogus certificate marks the log as misbehaving.
3.1.1.2.1. Self-monitoring Subject 3.1.1.2.1. Self-monitoring Subject
If a misbehaving log suppresses a bogus certificate log entry, a If a misbehaving log suppresses a bogus certificate log entry, a
Subject performing self-monitoring will not detect the bogus Subject performing self-monitoring will not detect the bogus
certificate. CT relies on an Audit mechanism to detect log certificate. CT relies on an Audit mechanism to detect log
misbehavior, as a deterrent. (It is anticipated that logs that are misbehavior, as a deterrent. It is anticipated that logs that are
identified as persistently misbehaving will cease to be trusted by identified as persistently misbehaving will cease to be trusted by
Monitors, non-malicious CAs, and by browser vendors. This assumption Monitors, non-malicious CAs, and by browser vendors. This assumption
forms the basis for the perceived deterrent.) It is not clear if forms the basis for the perceived deterrent. It is not clear if
mechanisms to detect this sort of log misbehavior will be viable. mechanisms to detect this sort of log misbehavior will be viable.
3.1.1.2.2. Benign third party Monitor 3.1.1.2.2. Benign third party Monitor
Because a misbehaving log will suppress a bogus certificate log Because a misbehaving log will suppress a bogus certificate log
entry (or report such entries inconsistently) a benign third party entry (or report such entries inconsistently) a benign third party
Monitor that is protecting the targeted Subject also will not detect Monitor that is protecting the targeted Subject also will not detect
a bogus certificate. In this scenario, CT relies on a distributed a bogus certificate. In this scenario, CT relies on a distributed
Auditing mechanism [gossip] to detect log misbehavior, as a Auditing mechanism [gossip] to detect log misbehavior, as a
deterrent. (See Section 5.6 below.) However, a Monitor (third-party deterrent. (See Section 5.6 below.) However, a Monitor (third-party
skipping to change at page 11, line 45 skipping to change at page 12, line 28
3.1.2. Certificate not logged 3.1.2. Certificate not logged
If the CA does not submit a pre-certificate to a log, whether a log If the CA does not submit a pre-certificate to a log, whether a log
is benign or misbehaving does not matter. The same is true if a is benign or misbehaving does not matter. The same is true if a
Subject is issued a certificate without an SCT and does not log the Subject is issued a certificate without an SCT and does not log the
certificate itself, to acquire an SCT. Also, since there is no log certificate itself, to acquire an SCT. Also, since there is no log
entry in this scenario, there is no difference in outcome between a entry in this scenario, there is no difference in outcome between a
benign and a misbehaving third party Monitor. In both cases, no benign and a misbehaving third party Monitor. In both cases, no
Monitor (self or third-party) will detect a bogus certificate based Monitor (self or third-party) will detect a bogus certificate based
on Monitor functions and there will be no consequent reporting of the on Monitor functions and there will be no consequent reporting of
problem to the Subject or by the Subject to the CA based on the problem to the Subject or by the Subject to the CA based on
examination of log entries. examination of log entries.
3.1.2.1. Self-monitoring Subject 3.1.2.1. Self-monitoring Subject
A Subject performing self-monitoring will be able to detect the lack A Subject performing self-monitoring will be able to detect the lack
of an embedded SCT in the certificate it received from the CA, or the of an embedded SCT in the certificate it received from the CA, or
lack of an SCT supplied to the Subject via an out-of-band channel. A the lack of an SCT supplied to the Subject via an out-of-band
Subject ought to notify the CA if the Subject expected that its channel. A Subject ought to notify the CA if the Subject expected
certificate was to be logged. (A Subject would expect its certificate that its certificate was to be logged. (A Subject would expect its
to be logged if there is an agreement between the Subject and the CA certificate to be logged if there is an agreement between the
to do so, or because the CA advertises that it logs all of the Subject and the CA to do so, or because the CA advertises that it
certificates that it issues.) If the certificate was supposed to be logs all of the certificates that it issues.) If the certificate was
logged, but was not, the CA can use the certificate supplied by the supposed to be logged, but was not, the CA can use the certificate
Subject to investigate and remedy the problem. In the context of a supplied by the Subject to investigate and remedy the problem. In
benign CA, a failure to log the certificate might be the result of an the context of a benign CA, a failure to log the certificate might
operations error, or evidence of an attack on the CA. be the result of an operations error, or evidence of an attack on
the CA.
3.1.2.2. CT-enabled browser 3.1.2.2. CT-enabled browser
If a browser rejects certificates without SCTs (see Section 5.4), If a browser rejects certificates without SCTs (see Section 5.4),
CAs may be ''encouraged'' to log the certificates they issue. This, in CAs may be "encouraged" to log the certificates they issue. This, in
turn, would make it easier for Monitors to detect bogus turn, would make it easier for Monitors to detect bogus
certificates. However, the CT architecture does not describe how certificates. However, the CT architecture does not describe how
such behavior by browsers can be deployed incrementally throughout such behavior by browsers can be deployed incrementally throughout
the Internet. As a result, this attack model does not assume that the Internet. As a result, this attack model does not assume that
browsers will reject a certificate that is not accompanied by an browsers will reject a certificate that is not accompanied by an
SCT. In the CT architecture certificates have to be logged to enable SCT. In the CT architecture certificates have to be logged to enable
Monitors to detect mis-issuance, and to trigger subsequent Monitors to detect mis-issuance, and to trigger subsequent
revocation [CTarch]. Thus the effectiveness of CT is diminished in revocation [CTarch]. Thus the effectiveness of CT is diminished in
this context. this context.
3.2. Malicious Web PKI CA context 3.2. Malicious Web PKI CA context
In this section, we address the scenario in which the mis-issuance In this section, we address the scenario in which the mis-issuance
is intentional, not due to error. The CA is not the victim but the is 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
prior to issuance, to acquire an embedded SCT, or post-issuance to logs prior to issuance, to acquire an embedded SCT, or post-issuance
acquire a standalone SCT. The log (or logs) replies correctly to to acquire a standalone SCT. The log (or logs) replies correctly to
requests from clients. requests from clients.
3.2.1.1.1. Self-monitoring Subject 3.2.1.1.1. Self-monitoring Subject
If a Subject is checking the logs to which a certificate was If a Subject is checking the logs to which a certificate was
submitted and is performing self-monitoring, it will be able to submitted and is performing self-monitoring, it will be able to
detect the bogus certificate and will request revocation. The CA may detect the bogus certificate and will request revocation. The CA may
refuse to revoke, or may substantially delay revoking, the bogus refuse to revoke, or may substantially delay revoking, the bogus
certificate. The CA could make excuses about inadequate proof that certificate. For example, the CA could make excuses about inadequate
the certificate is bogus, or argue that it cannot quickly revoke the proof that the certificate is bogus, or argue that it cannot quickly
certificate because of legal concerns, etc. In this case, the CT revoke the certificate because of legal concerns, etc. In this case,
mechanisms will have detected mis-issuance, but the information the CT mechanisms will have detected mis-issuance, but the
logged by CT does not help remedy the problem. (See Sections 4 and information logged by CT does not help remedy the problem. (See
6.) Sections 4 and 6.)
3.2.1.1.2. Benign third party Monitor 3.2.1.1.2. Benign third party Monitor
If a benign third party monitor is checking the logs to which a If a benign third party monitor is checking the logs to which a
certificate was submitted and is protecting the targeted Subject, it certificate was submitted and is protecting the targeted Subject, it
will detect the bogus certificate and will alert the Subject. The will detect the bogus certificate and will alert the Subject. The
Subject will then ask the CA to revoke the bogus certificate. As in Subject will then ask the CA to revoke the bogus certificate. As in
3.2.1.1.1, the CA may or may not revoke the certificate. 3.2.1.1.1, the CA may or may not revoke the certificate.
3.2.1.2. Misbehaving log 3.2.1.2. Misbehaving log
skipping to change at page 14, line 18 skipping to change at page 14, line 45
3.2.2. Certificate not logged 3.2.2. Certificate not logged
Because the CA is presumed malicious, it may choose to not submit a Because the CA is presumed malicious, it may choose to not submit a
(pre-)certificate to a log. This means there is no SCT for the (pre-)certificate to a log. This means there is no SCT for the
certificate. certificate.
When a CA does not submit a certificate to a log, whether a log is When a CA does not submit a certificate to a log, whether a log is
benign or misbehaving does not matter. Also, since there is no log benign or misbehaving does not matter. Also, since there is no log
entry, there is no difference in behavior between a benign and a entry, there is no difference in behavior between a benign and a
misbehaving third-party Monitor. Neither will report a problem to the misbehaving third-party Monitor. Neither will report a problem to
Subject. the Subject.
A bogus certificate would not be delivered to the (legitimate) A bogus certificate would not be delivered to the legitimate
Subject. So the Subject, acting as a self-Monitor, cannot detect the Subject. So the Subject, acting as a self-Monitor, cannot detect the
issuance of a bogus certificate in this case. issuance of a bogus certificate in this case.
3.2.2.1. CT-aware browser 3.2.2.1. CT-aware browser
If careful browsers reject certificates without SCTs, CAs may be If careful browsers reject certificates without SCTs, CAs may be
''encouraged'' to log certificates (see section 5.4.) However, the CT "encouraged" to log certificates (see section 5.4.) However, the CT
architecture does not describe how such behavior by browsers can be architecture does not describe how such behavior by browsers can be
deployed incrementally throughout the Internet. As a result, this deployed incrementally throughout the Internet. As a result, this
attack model does not assume that browsers will reject a certificate attack model does not assume that browsers will reject a certificate
that is not accompanied by an SCT. Since certificates have to be that is not accompanied by an SCT. Since certificates have to be
logged to enable detection of mis-issuance by Monitors, and to logged to enable detection of mis-issuance by Monitors, and to
trigger subsequent revocation, the effectiveness of CT is diminished trigger subsequent revocation, the effectiveness of CT is diminished
in this context. in this context.
4. Syntactic mis-issuance 4. Syntactic mis-issuance
4.1. Non-malicious Web PKI CA context 4.1. Non-malicious Web PKI CA context
This section analyzes the scenario in which the CA has no intent to This section analyzes the scenario in which the CA has no intent to
issue a syntactically incorrect certificate. Throughout the issue a syntactically incorrect certificate. As noted in Section 1,
remainder of this document we refer to a syntactically incorrect we refer to a syntactically incorrect certificate as erroneous.
certificate as ''erroneous''.
4.1.1. Certificate logged 4.1.1. Certificate logged
4.1.1.1. Benign log 4.1.1.1. Benign log
If a (pre-)certificate is submitted to a benign log, syntactic mis- If a (pre-)certificate is submitted to a benign log, syntactic mis-
issuance can (optionally) be detected, and noted. This will happen issuance can (optionally) be detected, and noted. This will happen
only if the log performs syntactic checks in general, and if the log only if the log performs syntactic checks in general, and if the log
is capable of performing the checks applicable to the submitted is capable of performing the checks applicable to the submitted
(pre-)certificate. (A (pre-)certificate SHOULD be logged even if it (pre-)certificate. (A (pre-)certificate SHOULD be logged even if it
fails syntactic validation; logging takes precedence over detection fails syntactic validation; logging takes precedence over detection
of syntactic mis-issuance.) If syntactic validation fails, this can of syntactic mis-issuance.) If syntactic validation fails, this can
be noted in an SCT extension returned to the submitter. be noted in an SCT extension returned to the submitter.
. If the (pre-)certificate is submitted by the non-malicious issuing If the (pre-)certificate is submitted by the non-malicious issuing
CA, and if the CA has a record of the certificate content, then CA, and if the CA has a record of the certificate content, then the
the CA SHOULD remedy the syntactic problem and re-submit 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 helps submitted prior to issuance, syntactic checking by a log helps avoid
avoid issuance of an erroneous certificate. If the CA does not issuance of an erroneous certificate. If the CA does not have a
have a record of the certificate contents, then presumably it record of the certificate contents, then presumably it was a bogus
was a bogus certificate and the CA SHOULD revoke it. certificate and the CA SHOULD revoke it.
. If a certificate is submitted by its Subject, and is deemed If a certificate is submitted by its Subject, and is deemed
erroneous, then the Subject SHOULD contact the issuing CA and erroneous, then the Subject SHOULD contact the issuing CA and
request a new certificate. If the Subject is a legitimate request a new certificate. If the Subject is a legitimate subscriber
subscriber of the CA, then the CA will either have a record of of the CA, then the CA will either have a record of the certificate
the certificate content or can obtain a copy of the certificate content or can obtain a copy of the certificate from the Subject.
from the Subject. The CA will remedy the syntactic problem and
either re-submit a corrected (pre-)certificate to a log and send
it to the Subject or the Subject will re-submit it to a log.
Here too syntactic checking by a log enables a Subject to be
informed that its certificate is erroneous and thus may hasten
issuance of a replacement certificate.
. If a certificate is submitted by a third party, that party might The CA will remedy the syntactic problem and either re-submit a
contact the Subject or the issuing CA, but because the party is corrected (pre-)certificate to a log and send it to the Subject or
not the Subject of the certificate it is not clear how the CA the Subject will re-submit it to a log. Here too syntactic checking
will respond. by a log enables a Subject to be informed that its certificate is
erroneous and thus may hasten issuance of a replacement certificate.
Bottom line: Syntactic mis-issuance of a certificate can be avoided If a certificate is submitted by a third party, that party might
by a CA if it makes use of logs that are capable of performing these contact the Subject or the issuing CA, but because the party is not
checks for the types of certificates that are submitted, and if the the Subject of the certificate it is not clear how the CA will
CA acts on the feedback it receives. If a CA uses a log that does not respond.
perform such checks, or if the CA requests checking relative to
criteria not supported by the log, then syntactic mis-issuance will This analysis suggests that syntactic mis-issuance of a certificate
not be detected or avoided by this mechanism. Similarly, syntactic can be avoided by a CA if it makes use of logs that are capable of
mis-issuance can be remedied if a Subject submits a certificate to a performing these checks for the types of certificates that are
log that performs syntactic checks, and if the Subject asks the submitted, and if the CA acts on the feedback it receives. If a CA
issuing CA to fix problems detected by the log. (The issuer is uses a log that does not perform such checks, or if the CA requests
presumed to be willing to re-issue the certificate, correcting any checking relative to criteria not supported by the log, then
problems, because the issuing CA is not malicious.) syntactic mis-issuance will not be detected or avoided by this
mechanism. Similarly, syntactic mis-issuance can be remedied if a
Subject submits a certificate to a log that performs syntactic
checks, and if the Subject asks the issuing CA to fix problems
detected by the log. (The issuer is presumed to be willing to re-
issue the certificate, correcting any problems, because the issuing
CA is not malicious.)
4.1.1.2. Misbehaving log or third party Monitor 4.1.1.2. Misbehaving log or third party Monitor
A log or Monitor that is conspiring with the attacker or is A log or Monitor that is conspiring with the attacker or is
independently malicious, will either not perform syntactic checks, independently malicious, will either not perform syntactic checks,
even though it claims to do so, or simply not report errors. The log even though it claims to do so, or simply not report errors. The log
entry and the SCT for an erroneous certificate will assert that the entry and the SCT for an erroneous certificate will assert that the
certificate syntax was verified. certificate syntax was verified.
As with detection of semantic mis-issuance, a distributed Audit As with detection of semantic mis-issuance, a distributed Audit
mechanism could, in principle, detect misbehavior by logs or mechanism could, in principle, detect misbehavior by logs or
Monitors with respect to syntactic checking. For example, if for a Monitors with respect to syntactic checking. For example, if for a
given certificate, some logs (or Monitors) are reporting syntactic given certificate, some logs (or Monitors) are reporting syntactic
errors and some that claim to do syntactic checking, are not errors and some that claim to do syntactic checking, are not
reporting these errors, this is indicative of misbehavior by these reporting these errors, this is indicative of misbehavior by these
logs and/or Monitors. logs and/or Monitors.
Note that a malicious log (or Monitor) could report syntactic errors Note that a malicious log (or Monitor) could report syntactic errors
for a syntactically valid certificate. This could result in for a syntactically valid certificate. This could result in
reporting of non-existent syntactic problems to the issuing CA, which reporting of non-existent syntactic problems to the issuing CA,
might cause the CA to do needless investigative work or perhaps which might cause the CA to do needless investigative work or
incorrectly revoke and re-issue the Subject's certificate. perhaps incorrectly revoke and re-issue the Subject's certificate.
4.1.1.3. Self-monitoring Subject and Benign third party Monitor 4.1.1.3. Self-monitoring Subject and Benign third party Monitor
If a Subject or benign third party Monitor performs syntactic checks, If a Subject or benign third party Monitor performs syntactic
it will detect the erroneous certificate and the issuing CA will be checks, it will detect the erroneous certificate and the issuing CA
notified (by the Subject). If the Subject is a legitimate subscriber will be notified (by the Subject). If the Subject is a legitimate
of the CA, then the CA will either have a record of the certificate subscriber of the CA, then the CA will either have a record of the
content or can obtain a copy of the certificate from the Subject. The certificate content or can obtain a copy of the certificate from the
CA SHOULD revoke the erroneous certificate (after investigation) and Subject. The CA SHOULD revoke the erroneous certificate (after
remedy the syntactic problem. The CA SHOULD either re-submit the investigation) and remedy the syntactic problem. The CA SHOULD
corrected (pre-)certificate to one or more logs and then send the either re-submit the corrected (pre-)certificate to one or more logs
result to the Subject, or send the corrected certificate to the and then send the result to the Subject, or send the corrected
Subject, who will re-submit it to one or more logs. certificate to the Subject, who will re-submit it to one or more
logs.
4.1.1.4. CT-enabled browser 4.1.1.4. CT-enabled browser
If a browser rejects an erroneous certificate and notifies the If a browser rejects an erroneous certificate and notifies the
Subject and/or the issuing CA, then syntactic mis-issuance will be Subject and/or the issuing CA, then syntactic mis-issuance will be
detected (see Section 5.) Unfortunately, experience suggests that detected (see Section 5.) Unfortunately, experience suggests that
many browsers do not perform thorough syntactic checks on many browsers do not perform thorough syntactic checks on
certificates, and so it seems unlikely that browsers will be a certificates, and so it seems unlikely that browsers will be a
reliable way to detect erroneous certificates. Moreover, a protocol reliable way to detect erroneous certificates. Moreover, a protocol
used by a browser to notify a Subject and/or CA of an erroneous used by a browser to notify a Subject and/or CA of an erroneous
skipping to change at page 17, line 26 skipping to change at page 17, line 48
If a CA does not submit a certificate to a log, there can be no If a CA does not submit a certificate to a log, there can be no
syntactic checking by the log. Detection of syntactic errors will syntactic checking by the log. Detection of syntactic errors will
depend on a Subject performing the requisite checks when it receives depend on a Subject performing the requisite checks when it receives
its certificate from a CA. A Monitor that performs syntactic checks its certificate from a CA. A Monitor that performs syntactic checks
on behalf of a Subject also could detect such problems, but the CT on behalf of a Subject also could detect such problems, but the CT
architecture does not require Monitors to perform such checks. architecture does not require Monitors to perform such checks.
4.2. Malicious Web PKI CA context 4.2. Malicious Web PKI CA context
This section analyzes the scenario in which the CA's issuance of a This section analyzes the scenario in which the CA's issuance of a
syntactically incorrect certificate is intentional, not due to error. syntactically incorrect certificate is intentional, not due to
The CA is not the victim but the attacker. error. The CA is not the victim but the attacker.
4.2.1. Certificate logged 4.2.1. Certificate logged
4.2.1.1. Benign log 4.2.1.1. Benign log
Because the CA is presumed to be malicious, the CA may cause the log Because the CA is presumed to be malicious, the CA may cause the log
to not perform checks, in one of several ways. (See [DOMVAL] and to not perform checks, in one of several ways. (See [DOMVAL] and
[EXTVAL] for more details on validation checks and CCIDs). [EXTVAL] for more details on validation checks and CCIDs).
1. The CA may assert that the certificate is being issued w/o 1. The CA may assert that the certificate is being issued w/o
regard to any guidelines (the ''no guidelines'' reserved CCID). regard to any guidelines (the "no guidelines" reserved CCID).
2. The CA may assert a CCID that has not been registered, and thus 2. The CA may assert a CCID that has not been registered, and
no log will be able to perform a check. thus no log will be able to perform a check.
3. The CA may check to see which CCIDs a log declares it can 3. The CA may check to see which CCIDs a log declares it can
check, and chose a registered CCID that is not checked by the log check, and chose a registered CCID that is not checked by the log
in question. in question.
4. The CA may submit a (pre-) certificate to a log that is known 4. The CA may submit a (pre-) certificate to a log that is known
to not perform any syntactic checks, and thus avoid syntactic to not perform any syntactic checks, and thus avoid syntactic
checking. checking.
4.2.1.2. Misbehaving log or third party Monitor 4.2.1.2. Misbehaving log or third party Monitor
skipping to change at page 18, line 45 skipping to change at page 19, line 19
malicious CA need not worry about failing a log-based check. malicious CA need not worry about failing a log-based check.
Similarly, if there is no requirement for a browser to reject a Similarly, if there is no requirement for a browser to reject a
certificate that was logged by an operator that does not perform certificate that was logged by an operator that does not perform
syntactic checks, the fourth attack noted in 4.2.1.1 will succeed as syntactic checks, the fourth attack noted in 4.2.1.1 will succeed as
well. If a browser were configured to know which versions of well. If a browser were configured to know which versions of
certificate types are applicable to its use of a certificate, the certificate types are applicable to its use of a certificate, the
second and third attack strategies noted above could be thwarted. second and third attack strategies noted above could be thwarted.
4.2.2. Certificate is not logged 4.2.2. Certificate is not logged
Since certificates are not logged in this scenario, a Monitor (third- Since certificates are not logged in this scenario, a Monitor
party or self) cannot detect the issuance of an erroneous (third-party or self) cannot detect the issuance of an erroneous
certificate. Thus there is no difference between a benign or a certificate. Thus there is no difference between a benign or a
malicious/conspiring log or a benign or conspiring/malicious Monitor. malicious/conspiring log or a benign or conspiring/malicious
(A Subject MAY detect a syntax error by examining the certificate Monitor. (A Subject MAY detect a syntax error by examining the
returned to it by the Issuer.) However, even if errors are detected certificate returned to it by the Issuer.) However, even if errors
and reported to the CA, a malicious/conspiring CA may do nothing to are detected and reported to the CA, a malicious/conspiring CA may
fix the problem or may delay action. do nothing to fix the problem or may delay action.
5. Issues Applicable to Sections 3 and 4 5. Issues Applicable to Sections 3 and 4
5.1. How does a Subject know which Monitor(s) to use? 5.1. How does a Subject know which Monitor(s) to use?
If a CA submits a bogus certificate to one or more logs, but these If a CA submits a bogus certificate to one or more logs, but these
logs are not tracked by a Monitor that is protecting the targeted logs are not tracked by a Monitor that is protecting the targeted
Subject, CT will not remedy this type of mis-issuance attack. If Subject, CT will not remedy this type of mis-issuance attack. If
third-party Monitors advertise which logs they track, Subjects may be third-party Monitors advertise which logs they track, Subjects may
able to use this information to select an appropriate Monitor (or set be able to use this information to select an appropriate Monitor (or
thereof). Also, it is not clear whether every third-party Monitor set thereof). Also, it is not clear whether every third-party
MUST offer to track every Subject that requests protection. If a Monitor MUST offer to track every Subject that requests protection.
Subject acts as its own Monitor, this problem is solved for that If a Subject acts as its own Monitor, this problem is solved for
Subject. that Subject.
5.2. How does a Monitor discover new logs? 5.2. How does a Monitor discover new logs?
It is not clear how a (self-)Monitor becomes aware of all (relevant) It is not clear how a (self-)Monitor becomes aware of all (relevant)
logs, including newly created logs. The means by which Monitors logs, including newly created logs. The means by which Monitors
become aware of new logs MUST accommodate self-monitoring by a become aware of new logs MUST accommodate self-monitoring by a
potentially very large number of web site operators. If there are potentially very large number of web site operators. If there are
many logs, it may not be feasible for a (self-) Monitor to track all many logs, it may not be feasible for a (self-) Monitor to track all
of them, or to determine what set of logs suffice to ensure an of them, or to determine what set of logs suffice to ensure an
adequate level of coverage. adequate level of coverage.
skipping to change at page 20, line 13 skipping to change at page 20, line 31
purposes (assuming a non-conspiring log operator). purposes (assuming a non-conspiring log operator).
5.4. Browser behavior 5.4. Browser behavior
If a browser is to reject a certificate that lacks an embedded SCT, If a browser is to reject a certificate that lacks an embedded SCT,
or is not accompanied by an SCT transported via the TLS handshake, or is not accompanied by an SCT transported via the TLS handshake,
this behavior needs to be defined in a way that is compatible with this behavior needs to be defined in a way that is compatible with
incremental deployment. Issuing a warning to a (human) user is incremental deployment. Issuing a warning to a (human) user is
probably insufficient, based on experience with warnings displayed probably insufficient, based on experience with warnings displayed
for expired certificates, lack of certificate revocation status for expired certificates, lack of certificate revocation status
information, and similar errors that violate RFC 5280 path validation information, and similar errors that violate RFC 5280 path
rules [RFC5280]. Unless a mechanism is defined that accommodates validation rules [RFC5280]. Unless a mechanism is defined that
incremental deployment of this capability, attackers probably will accommodates incremental deployment of this capability, attackers
avoid submitting bogus certificates to (benign) logs as a means of probably will avoid submitting bogus certificates to (benign) logs
evading detection. as a means of evading detection.
5.5. Remediation for a malicious CA 5.5. Remediation for a malicious CA
A targeted Subject might ask the parent of a malicious CA to revoke A targeted Subject might ask the parent of a malicious CA to revoke
the certificate of the non-cooperative CA. However, a request of this the certificate of the non-cooperative CA. However, a request of
sort may be rejected, e.g., because of the potential for significant this sort may be rejected, e.g., because of the potential for
collateral damage. A browser might be configured to reject all significant collateral damage. A browser might be configured to
certificates issued by the malicious CA, e.g., using a bad-CA-list reject all certificates issued by the malicious CA, e.g., using a
distributed by a browser vendor. However, if the malicious CA has a bad-CA-list distributed by a browser vendor. However, if the
sufficient number of legitimate clients, treating all of their malicious CA has a sufficient number of legitimate clients, treating
certificates as bogus or erroneous still represents serious all of their certificates as bogus or erroneous still represents
collateral damage. If this specification were to require that a serious collateral damage. If this specification were to require
browser can be configured to reject a specific, bogus or erroneous that a browser can be configured to reject a specific, bogus or
certificate identified by a Monitor, then the bogus or erroneous erroneous certificate identified by a Monitor, then the bogus or
certificate could be rejected in that fashion. This remediation erroneous certificate could be rejected in that fashion. This
strategy calls for communication between Monitors and browsers, or remediation strategy calls for communication between Monitors and
between Monitors and browser vendors. Such communication has not been browsers, or between Monitors and browser vendors. Such
specified, i.e., there are no standard ways to configure a browser to communication has not been specified, i.e., there are no standard
reject individual bogus or erroneous certificates based on ways to configure a browser to reject individual bogus or erroneous
information provided by an external entity such as a Monitor. certificates based on information provided by an external entity
Moreover, the same or another malicious CA could issue new bogus or such as a Monitor. Moreover, the same or another malicious CA could
erroneous certificates for the targeted Subject, which would have to issue new bogus or erroneous certificates for the targeted Subject,
be detected and rejected in this (as yet unspecified) fashion. Thus, which would have to be detected and rejected in this (as yet
for now, CT does not seem to provide a way to remedy this form of unspecified) fashion. Thus, for now, CT does not seem to provide a
attack, even though it provides a basis for detecting such attacks. way to remedy this form of attack, even though it provides a basis
for detecting such attacks.
5.6. Auditing - detecting misbehaving logs 5.6. Auditing - detecting misbehaving logs
The combination of a malicious CA and one or more conspiring logs The combination of a malicious CA and one or more conspiring logs
motivates the definition of an audit function, to detect conspiring motivates the definition of an audit function, to detect conspiring
logs. If a Monitor protecting a Subject does not see bogus logs. If a Monitor protecting a Subject does not see bogus
certificates, it cannot alert the Subject. If one or more SCTs are certificates, it cannot alert the Subject. If one or more SCTs are
present in a certificate, or passed via the TLS handshake, a browser present in a certificate, or passed via the TLS handshake, a browser
has no way to know that the logged certificate is not visible to has no way to know that the logged certificate is not visible to
Monitors. Only if Monitors and browsers reject certificates that Monitors. Only if Monitors and browsers reject certificates that
skipping to change at page 21, line 31 skipping to change at page 21, line 50
or compromised log. For example, will there be a mechanism to alert or compromised log. For example, will there be a mechanism to alert
all browsers to reject SCTs issued by such a log? Absent a all browsers to reject SCTs issued by such a log? Absent a
description of a remediation strategy to deal with misbehaving or description of a remediation strategy to deal with misbehaving or
compromised logs, CT cannot ensure detection of mis-issuance in a compromised logs, CT cannot ensure detection of mis-issuance in a
wide range of scenarios. wide range of scenarios.
Monitors play a critical role in detecting semantic certificate mis- Monitors play a critical role in detecting semantic certificate mis-
issuance, for Subjects that have requested monitoring of their issuance, for Subjects that have requested monitoring of their
certificates. A monitor (including a Subject performing self- certificates. A monitor (including a Subject performing self-
monitoring) examines logs for certificates associated with one or monitoring) examines logs for certificates associated with one or
more Subjects that are being ''protected''. A third-party Monitor must more Subjects that are being "protected". A third-party Monitor must
obtain a list of valid certificates for the Subject being monitored, obtain a list of valid certificates for the Subject being monitored,
in a secure manner, to use as a reference. It also must be able to in a secure manner, to use as a reference. It also must be able to
identify and track a potentially large number of logs on behalf of identify and track a potentially large number of logs on behalf of
its Subjects. This may be a daunting task for Subjects that elect to its Subjects. This may be a daunting task for Subjects that elect to
perform self-monitoring. perform self-monitoring.
Note: A Monitor must not rely on a CA or RA database for its Note: A Monitor must not rely on a CA or RA database for its
reference information or use certificate discovery protocols; this reference information or use certificate discovery protocols; this
information must be acquired by the Monitor based on reference information must be acquired by the Monitor based on reference
certificates provided by a Subject. If a Monitor were to rely on a certificates provided by a Subject. If a Monitor were to rely on a
skipping to change at page 23, line 12 skipping to change at page 24, line 12
their assistance in reviewing and preparing this document, and other their assistance in reviewing and preparing this document, and other
members of the TRANS working group for reviewing it. members of the TRANS working group for reviewing it.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 14, RFC 2119, March 1997. Requirement Levels," BCP 14, RFC 2119, March 1997.
[CTarch] Kent, S., Mandelberg, D., Seo, K., ''Certificate Transparency [CTarch] Kent, S., Mandelberg, D., Seo, K., "Certificate
(CT) System Architecture'', draft-kent-trans-architecture- Transparency (CT) System Architecture", draft-kent-trans-
00, (October 2015), work in progress. architecture-00, (October 2015), work in progress.
9.2. Informative References 9.2. Informative References
[TRANS] Laurie, B., Langley, A., Kasper, E., Messeri, E., [TRANS] Laurie, B., Langley, A., Kasper, E., Messeri, E.,
Stradling, R., "Certificate Transparency," draft-ietf- Stradling, R., "Certificate Transparency," draft-ietf-
trans-rfc6962-bis-07 (March 9, 2015), work in progress. trans-rfc6962-bis-07 (March 9, 2015), work in progress.
[DOMVAL] Kent, S., ''Syntactic and Semantic Checks for Domain [DOMVAL] Kent, S., "Syntactic and Semantic Checks for Domain
Validation Certificates,'' draft-kent-trans-domain- Validation Certificates," draft-kent-trans-domain-
validation-cert-checks-01, (December 2014), work in validation-cert-checks-01, (December 2014), work in
progress. progress.
[EXTVAL] Kent, S., ''Syntactic and Semantic Checks for Extended [EXTVAL] Kent, S., "Syntactic and Semantic Checks for Extended
Validation Certificates,'' draft-kent-trans-extended- Validation Certificates," draft-kent-trans-extended-
validation-cert-checks-01 (December 2014), work in validation-cert-checks-01 (December 2014), work in
progress. progress.
[gossip] Nordberg, L, Gillmore, D, ''Gossiping in CT,'' draft-linus- [gossip] Nordberg, L, Gillmore, D, "Gossiping in CT," draft-linus-
trans-gossip-ct-01, (March 9, 2015), work in progress trans-gossip-ct-01, (March 9, 2015), work in progress
[RFC5280] Cooper, D., Santession, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santession, S., Farrell, S., Boeyen, S.,
Housley, R., Polk, W., ''Internet X.509 Public Key Housley, R., Polk, W., "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile,'' RFC 5280, May 2008. (CRL) Profile," RFC 5280, May 2008.
Author's Addresses Author's Addresses
Stephen Kent Stephen Kent
BBN Technologies BBN Technologies
10 Moulton Street 10 Moulton Street
Cambridge MA 02138 Cambridge MA 02138
USA USA
Phone: +1 (617) 873-3988 Phone: +1 (617) 873-3988
Email: skent@bbn.com Email: skent@bbn.com
Copyright Statement Copyright Statement
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with
to this document. Code Components extracted from this document must respect to this document. Code Components extracted from this
include Simplified BSD License text as described in Section 4.e of document must include Simplified BSD License text as described in
the Trust Legal Provisions and are provided without warranty as Section 4.e of the Trust Legal Provisions and are provided without
described in the Simplified BSD License. warranty as described in the Simplified BSD License.
 End of changes. 70 change blocks. 
286 lines changed or deleted 317 lines changed or added

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