draft-ietf-trans-threat-analysis-13.txt   draft-ietf-trans-threat-analysis-14.txt 
Public Notary Transparency S. Kent Public Notary Transparency S. Kent
Internet-Draft Independent Internet-Draft Independent
Intended status: Informational April 12, 2018 Intended status: Informational May 29, 2018
Expires: October 14, 2018 Expires: November 30, 2018
Attack and Threat Model for Certificate Transparency Attack and Threat Model for Certificate Transparency
draft-ietf-trans-threat-analysis-13 draft-ietf-trans-threat-analysis-14
Abstract Abstract
This document describes an attack model and discusses threats for the This document describes an attack model and discusses threats for the
Web PKI context in which security mechanisms to detect mis-issuance Web PKI context for which security mechanisms to detect mis-issuance
of web site certificates are being developed. The model provides an of web site certificates are being developed. The model provides an
analysis of detection and remediation mechanisms for both syntactic analysis of detection and remediation mechanisms for both syntactic
and semantic mis-issuance. The model introduces an outline of and semantic mis-issuance. The model introduces an outline of
attacks to organize the discussion. The model also describes the attacks to organize the discussion. The model also describes the
roles played by the elements of the Certificate Transparency (CT) roles played by the elements of the Certificate Transparency (CT)
system, to establish a context for the model. system, to establish a context for the model.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 37 skipping to change at page 1, line 37
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 October 14, 2018. This Internet-Draft will expire on November 30, 2018.
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 . . . . . . . . . . . . 7 1.1. Conventions used in this document . . . . . . . . . . . . 8
2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 9 3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 10
3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 9 3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 10
3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 9 3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 10
3.1.2. Certificate not logged . . . . . . . . . . . . . . . 11 3.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 10
3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12 3.1.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 11
3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 12 3.1.1.3. Misbehaving third party Monitor . . . . . . . . . 12
3.1.2. Certificate not logged . . . . . . . . . . . . . . . 12
3.1.2.1. CT-enabled browser . . . . . . . . . . . . . . . 12
3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 13
3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 13
3.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 13
3.2.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 14
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 . . . . . . . . . . . . . . . . 15
3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15 3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15
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 . . . . . . . . . . . . . 17
3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 17 3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 18
3.4. Attacks Based on Exploiting Multiple Certificate Chains . 18 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 . . 20
4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 21 4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 21
4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 21 4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 22
4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 21 4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 22
4.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 22
4.1.1.2. Misbehaving log or third party Monitor . . . . . 23
4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23 4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23
4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 23 4.1.2.1. Self-monitoring Subject . . . . . . . . . . . . . 23
4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 24 4.1.3. Situations Independent of Certificate Logging . . . . 24
4.2.2. Certificate is not logged . . . . . . . . . . . . . . 25 4.1.3.1. Self-monitoring Subject and Benign third party
5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 25 Monitor . . . . . . . . . . . . . . . . . . . . . 24
5.1. How does a Subject know which Monitor(s) to use? . . . . 25 4.1.3.2. CT-enabled browser . . . . . . . . . . . . . . . 24
5.2. How does a Monitor discover new logs? . . . . . . . . . . 25 4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 24
5.3. CA response to report of a bogus or erroneous certificate 26 4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 25
5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 26 4.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 25
5.5. Remediation for a malicious CA . . . . . . . . . . . . . 26 4.2.1.2. Misbehaving log or third party Monitor . . . . . 25
5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 27 4.2.1.3. CT-enabled browser . . . . . . . . . . . . . . . 25
6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 4.2.2. Certificate is not logged . . . . . . . . . . . . . . 26
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 26
5.1. How does a Subject know which Monitor(s) to use? . . . . 26
5.2. How does a Monitor discover new logs? . . . . . . . . . . 26
5.3. CA response to report of a bogus or erroneous certificate 27
5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 27
5.5. Remediation for a malicious CA . . . . . . . . . . . . . 27
5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 28
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.1. Normative References . . . . . . . . . . . . . . . . . . 29 9.1. Normative References . . . . . . . . . . . . . . . . . . 30
9.2. Informative References . . . . . . . . . . . . . . . . . 29 9.2. Informative References . . . . . . . . . . . . . . . . . 30
9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 30 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction 1. Introduction
Certificate transparency (CT) is a set of mechanisms designed to Certificate transparency (CT) is a set of mechanisms designed to
detect, deter, and facilitate remediation of certificate mis- detect, deter, and facilitate remediation of certificate mis-
issuance. The term certificate mis-issuance is defined here to issuance. The term certificate mis-issuance is defined here to
encompass violations of either semantic or syntactic constraints. encompass violations of either semantic or syntactic constraints.
The fundamental semantic constraint for a certificate is that it was The fundamental semantic constraint for a certificate is that it was
issued to an entity that is authorized to represent the Subject (or issued to an entity that is authorized to represent the Subject (or
Subject Alternative) named in the certificate. (It is also assumed Subject Alternative) named in the certificate. (It is also assumed
skipping to change at page 3, line 31 skipping to change at page 3, line 45
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 typically are application-specific. For example, certificates
used in the Web PKI environment might be characterized as domain used in the Web PKI environment might be characterized as domain
validation (DV) or extended validation (EV) certificates. validation (DV) or extended validation (EV) certificates.
Certificates used with applications such as IPsec or S/MIME have Certificates used with applications such as IPsec or S/MIME have
different syntactic constraints from those in the Web PKI context. different syntactic constraints from those in the Web PKI context.
There are three classes of beneficiaries of CT: certificate 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 the Web PKI, Subjects are web sites and RPs are browsers employing
HTTPS to access these web sites. Thee CAs that benefit are issuers HTTPS to access these web sites. The CAs that benefit are issuers of
of certificates used to authenticate web sites. 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] are the primary means
of certificate revocation established by IETF standards. of certificate revocation established by IETF standards.
Unfortunately, most browsers do not make use of CRLs to check the Unfortunately, most browsers do not make use of CRLs to check the
revocation status of certificates presented by a TLS Server revocation status of certificates presented by a TLS Server
(Subject). Some browsers make use of Online Certificate Status (Subject). Some browsers make use of Online Certificate Status
Protocol (OCSP) data [RFC6960] as a standards-based alternative to Protocol (OCSP) data [RFC6960] as a standards-based alternative to
CRLs. If a certificate contains an Authority Information Access CRLs. If a certificate contains an Authority Information Access
(AIA) extension [RFC5280], it directs a relying party to an OCSP (AIA) extension [RFC5280], it directs a relying party to an OCSP
server to which a request can be directed. This extension also may server to which a request can be directed. The data from this
be used by a browser to request OCSP responses from a TLS server with extension also may be used by a browser to request OCSP responses
which it is communicating [RFC6066][RFC6961]. from a TLS server with which it is communicating [RFC6066][RFC6961].
RFC 5280 does not require inclusion of an AIA extension in RFC 5280 does not require inclusion of an AIA extension in
certificates, so a browser cannot assume that this extension will be certificates, so a browser cannot assume that this extension will be
present. The Certification Authority and Browser Forum (CABF) present. The Certification Authority and Browser Forum (CABF)
baseline requirements and extended validation guidelines do mandate baseline requirements and extended validation guidelines do mandate
inclusion of this extension in EE certificates (in conjunction with inclusion of this extension in EE certificates (in conjunction with
their certificate policies). (See https://cabforum.org [1] for the their certificate policies). (See cabforum.org [1] for the most
most recent versions of these policies.) recent versions of these policies.)
In addition to the revocation status data dissemination mechanisms In addition to the revocation status data dissemination mechanisms
specified by IETF standards, most browser vendors employ proprietary specified by IETF standards, most browser vendors employ proprietary
means of conveying certificate revocation status information to 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
skipping to change at page 4, line 37 skipping to change at page 5, line 4
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) 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 also is protected if a browser vendor "blacklists" a certificate
or "bad-CA-lists" a CA as noted above.) An RP also may benefit from or places a CA on a "bad-CA-list", causing all certs issued by the CA
CT if the RP validates an SCT associated with a certificate, and to be treated as invalid.) An RP also may benefit from CT if the RP
rejects the certificate if the Signed certificate Timestamp (SCT) validates an SCT associated with a certificate (see 8.1.3 in
[I-D.ietf-trans-rfc6962-bis] is invalid. If an RP verified that a [I-D.ietf-trans-rfc6962-bis]), and rejects the certificate if the
certificate that claims to have been logged has a valid log entry, Signed certificate Timestamp (SCT) [I-D.ietf-trans-rfc6962-bis] is
the RP would have a higher degree of confidence that the certificate invalid. If an RP verified that a certificate that claims to have
is genuine. However, checking logs in this fashion imposes a burden been logged has a valid log entry, the RP probably would have a
on RPs and on logs. Moreover, the existence of a log entry does not higher degree of confidence that the certificate is genuine.
ensure that the certificate is not mis-issued. Unless the However, checking logs in this fashion imposes a burden on RPs and on
certificate Subject is monitoring the log(s) in question, a bogus logs. Moreover, the existence of a log entry does not ensure that
certificate will not be detected by CT mechanisms. Finally, if an RP the certificate is not mis-issued. Unless the certificate Subject is
were to check logs for individual certificates, that would disclose monitoring the log(s) in question, a bogus certificate will not be
to logs the identity of web sites being visited by the RP, a privacy detected by CT mechanisms. Finally, if an RP were to check logs for
violation. Thus this attack model does not assume that all RPs will individual certificates, that would disclose to logs the identity of
check log entries. web sites being visited by the RP, a privacy violation. Thus this
attack model does not assume that all RPs will check log entries.
A CA benefits from CT when it detects a (mis-issued) certificate that A CA benefits from CT when it (acting as a Monitor for its clients)
represents the same Subject name as a legitimate certificate issued detects a (mis-issued) certificate that represents the same Subject
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 mis-issuance, and if a CA
revokes a certificate in response to a request from the certificate's revokes a certificate in response to a request from the certificate's
legitimate Subject, then an RP benefits without having to implement legitimate Subject, then an RP benefits without having to implement
any CT-specific mechanisms. 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
skipping to change at page 5, line 32 skipping to change at page 5, line 47
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. Logging
of certificates is intended to deter mis-issuance, by creating a of certificates is intended to deter mis-issuance, by creating a
publicly-accessible record that associates a CA with any certificates publicly-accessible record that associates a CA with any certificates
that it mis-issues. Logging does not remedy mis-issuance; but it that it mis-issues. Logging does not remedy mis-issuance; but it
does facilitate remediation by providing the information needed to does facilitate remediation by providing the information needed to
enable detection and consequently revocation of bogus certificates in enable detection and subsequent revocation of bogus certificates in
some circumstances. some circumstances.
Auditing is a function employed by CT to detect misbehavior by logs Auditing is a function employed by CT to detect misbehavior by logs
and to deter mis-issuance that is abetted by misbehaving logs. and to deter mis-issuance that is abetted by misbehaving logs.
Auditing detects several types of log misbehavior, including 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
skipping to change at page 6, line 4 skipping to change at page 6, line 20
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 1 (below) illustrates the data exchanges among the major
elements of the CT system, based on the log specification elements of the CT system, based on the log specification
[I-D.ietf-trans-rfc6962-bis] and on the assumed behavior of other CT [I-D.ietf-trans-rfc6962-bis] and on the assumed behavior of other CT
system elements as described above. This Figure does not include the system elements as described above. This Figure does not include the
Audit function, because there is not yet agreement on how that Audit function, because there is not yet agreement on how that
function will work in a distributed, privacy-preserving fashion. function will work in a distributed, privacy-preserving fashion.
+----+ +---------+ +---------+ +----+ +---------+ +---------+
| CA |---[ 1]-->| Log | ---[8]---| Monitor | | CA |---[1-]-->| Log |<---[8]---| Monitor |
| | | | | | | | | | | |
| | --[ 2]---| |----[9]-->| | | |<--[2]----| |----[9]-->| |
| | | | | | | | | | | |
| |---[ 3]-->| | --[10]---| | | |---[3]--->| |<--[10]---| |
| | | | | |--------+ | | | | | |--------+
| | --[ 4]---| |---[11]-->| | | | |<--[4]----| |---[11]-->| | |
| | | | +---------+ | | | | | +---------+ |
| | | | | | | | | |
| | | | +---------+ | | | | | +---------+ |
| | | | --[8]----| Self- | | | | | |<--[8]----| Self- | |
| | | | | Monitor | | | | | | | Monitor | |
| | | |---[9]--->|(Subject)| | | | | |---[9]--->|(Subject)| |
| | | | | | | | | | | | | |
| | | | --[10]---| | [12] | | | |<--[10]---| | [12]
| | | | | | | | | | | | | |
| | | |---[11]-->| | | | | | |---[11]-->| | |
| | +---------+ +---------+ | | | +---------+ +---------+ |
| | | | | |
| | +---------+ +---------+ | | | +---------+ +---------+ |
| |---[ 5]-->| Website |---[7]--->| Browser | | | |----[5]-->| Website |---[7]--->| Browser | |
| | |(Subject)| +---------+ | | | |(Subject)| +---------+ |
| | --[ 6]-->| | ----------------------------+ | |<---[6]-->| |<----------------------------+
+----+ +---------+ +----+ +---------+
[ 1] Retrieve accepted root certs [ 1] Retrieve accepted root certs
[ 2] accepted root certs [ 2] accepted root certs
[ 3] Add chain to log/add PreCertChain to log [ 3] Add chain to log/add PreCertChain to log
[ 4] SCT [ 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)
skipping to change at page 7, line 50 skipping to change at page 8, line 44
2. Threats 2. Threats
A threat is defined, traditionally, as a motivated, capable A threat is defined, traditionally, as a motivated, capable
adversary. An adversary who is not motivated to attack a system is adversary. An adversary who is not motivated to attack a system is
not a threat. An adversary who is motivated but not "capable" also not a threat. An adversary who is motivated but not "capable" also
is not a threat. Threats change over time; new classes of is not a threat. Threats change over time; new classes of
adversaries may arise, new motivations may come into play, and the adversaries may arise, new motivations may come into play, and the
capabilities of adversaries may change. Nonetheless, it is useful to capabilities of adversaries may change. Nonetheless, it is useful to
document perceived threats against a system to provide a context for document perceived threats against a system to provide a context for
understanding attacks. Even if the assumptions about adversaries understanding attacks (even though some attacks may be the result of
errors, not threats). 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 that result in certificate mis-issuance in the
Web PKI. (CT also may facilitate detection and remediation of errors
that result in certificate mis-issuance.) Such attacks can enable an
attacker to spoof the identity of TLS-enabled web sites. Spoofing attacker to spoof the identity of TLS-enabled web sites. Spoofing
enables an adversary to perform many types of attacks, e.g., delivery enables an adversary to perform many types of attacks, e.g., delivery
of malware to a client, reporting bogus information, or acquiring of malware to a client, reporting bogus information, or acquiring
information that a client would not communicate if the client were information that a client would not communicate if the client were
aware of the spoofing. Such information may include personal aware of the spoofing. Such information may include personal
identification and authentication information and electronic payment identification and authentication information and electronic payment
authorization information. Because of the nature of the information authorization information. Because of the nature of the information
that may be divulged (or misinformation or malware that may be that may be divulged (or misinformation or malware that may be
delivered), the principal adversaries in the CT context are perceived delivered), the principal adversaries in the CT context are perceived
to be (cyber) criminals and nation states. Both adversaries are to be (cyber) criminals and nation states. Both adversaries are
motivated to acquire personal identification and authentication motivated to acquire personal identification and authentication
information. Criminals are also motivated to acquire electronic information. Criminals are also motivated to acquire electronic
payment authorization information. payment authorization information.
To make use of forged web site certificates, an adversary must be To make use of bogus web site certificates, an adversary must be able
able to direct a TLS client to a spoofed web site, so that it can to direct a TLS client to a spoofed web site, so that it can present
present the forged certificate during a TLS handshake. An adversary the bogus certificate during a TLS handshake. An adversary may
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. The
former type of attack is well within the perceived capabilities of former type of attack is well within the perceived capabilities of
both classes of adversary. The latter attack may be possible for both classes of adversary. The latter attack may be possible for
criminals and is certainly a capability available to a nation state criminals and is certainly a capability available to a nation state
within its borders. Nation states also may be able to compromise DNS within its borders. Nation states also may be able to compromise DNS
servers outside their own jurisdiction. servers outside their own jurisdiction.
The elements of CT may themselves be targets of attacks, as 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
skipping to change at page 9, line 23 skipping to change at page 10, line 21
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, in
the case of a bogus certificate, because it was the victim of a the case of a bogus certificate, because it was the victim of a
social engineering attack or an attack such as the one that affected social engineering or a technical attack. In the case of an error,
DigiNotar [https://www.vasco.com/company/about_vasco/press_room/ the CA should have a record of the erroneous certificate and be
news_archive/2011/news_diginotar_reports_any security_incident.aspx prepared to revoke this certificate once it has discovered and
[2]]. In the case of an error, the CA should have a record of the confirmed the error. In the event of a technical attack, a CA may
erroneous certificate and be prepared to revoke this certificate once have no record of a bogus certificate.
it has discovered and confirmed the error. In the event of an
attack, a CA may have no record of a bogus certificate.
3.1.1. Certificate logged 3.1.1. Certificate logged
3.1.1.1. Benign log 3.1.1.1. Benign log
The log (or logs) is benign and thus is presumed to provide The log (or logs) is benign and thus is presumed to provide
consistent, accurate responses to requests from all clients. consistent, accurate responses to requests from all clients.
If a bogus (pre-)certificate has been submitted to one or more logs If a bogus (pre-)certificate has been submitted to one or more logs
prior to issuance to acquire an embedded SCT, or post-issuance to prior to issuance to acquire an embedded SCT, or post-issuance to
skipping to change at page 10, line 30 skipping to change at page 11, line 24
or it may create an entry for the certificate but report it or it may create an entry for the certificate but report it
selectively. (A misbehaving log also could create and report entries selectively. (A misbehaving log also could create and report entries
for bogus certificates that have not been issued by the indicated CA for bogus certificates that have not been issued by the indicated CA
(hereafter called "fake"). Unless a Monitor validates the associated (hereafter called "fake"). Unless a Monitor validates the associated
certificate chains up to roots that it trusts, these fake bogus certificate chains up to roots that it trusts, these fake bogus
certificates could cause the Monitors to report non-existent semantic certificates could cause the Monitors to report non-existent semantic
problems to the Subject who would in turn report them to the problems to the Subject who would in turn report them to the
purported issuing CA. This might cause the CA to do needless purported issuing CA. This might cause the CA to do needless
investigative work or perhaps incorrectly revoke and re-issue the investigative work or perhaps incorrectly revoke and re-issue the
Subject's real certificate. Note that for every certificate Subject's real certificate. Note that for every certificate
submitted to a log, the log MUST verify a complete certificate chain submitted to a log, the log must verify a complete certificate chain
up to one of the roots it accepts. So creating a log entry for a up to one of the roots it accepts. So creating a log entry for a
fake bogus certificate marks the log as misbehaving. fake bogus certificate marks the log as misbehaving.
3.1.1.2.1. Self-monitoring Subject & Benign third party Monitor 3.1.1.2.1. Self-monitoring Subject & Benign third party Monitor
If a misbehaving log suppresses a bogus certificate log entry, a If a misbehaving log suppresses a bogus certificate log entry, a
Subject performing self-monitoring will not detect the bogus Subject performing self-monitoring will not detect the bogus
certificate. CT relies on an Audit mechanism to detect log certificate. CT relies on an Audit mechanism to detect log
misbehavior, as a deterrent. It is anticipated that logs that are misbehavior, as a deterrent. It is anticipated that logs that are
identified as persistently misbehaving will cease to be trusted by identified as persistently misbehaving will cease to be trusted by
skipping to change at page 11, line 19 skipping to change at page 12, line 14
does not contain the bogus certificate. To other entities, the log does not contain the bogus certificate. To other entities, the log
presents log entries and an STH that include the bogus certificate. presents log entries and an STH that include the bogus certificate.
This discrepancy can be detected if there is an exchange of This discrepancy can be detected if there is an exchange of
information about the log entries and STH between the entities information about the log entries and STH between the entities
receiving the view that excludes the bogus certificate and entities receiving the view that excludes the bogus certificate and entities
that receive a view that includes it, i.e., a distributed Audit that receive a view that includes it, i.e., a distributed Audit
mechanism. mechanism.
If a malicious log does not create an entry for a bogus certificate If a malicious log does not create an entry for a bogus certificate
(for which an SCT has been issued), then any Monitor/Auditor that (for which an SCT has been issued), then any Monitor/Auditor that
sees the bogus certificate will detect this when it checks with the enrounters the bogus certificate (and SCT) will detect this when it
log for log entries and STH (see Section 3.1.2.) checks with the log for log entries and STH (see Section 3.1.2.)
3.1.1.3. Misbehaving third party Monitor 3.1.1.3. Misbehaving third party Monitor
A third party Monitor that misbehaves will not notify the targeted A third party Monitor that misbehaves will not notify the targeted
Subject of a bogus certificate. This is true irrespective of whether Subject of a bogus certificate. This is true irrespective of whether
the Monitor checks the logs or whether the logs are benign or the Monitor checks the logs or whether the logs are benign or
malicious/conspiring. malicious/conspiring.
Note that independent of any mis-issuance on the part of the CA, a Note that independent of any mis-issuance on the part of the CA, a
misbehaving Monitor could issue false warnings to a Subject that it misbehaving Monitor could issue false warnings to a Subject that it
skipping to change at page 12, line 5 skipping to change at page 12, line 44
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 the
problem to the Subject or by the Subject to the CA based on problem to the Subject or by the Subject to the CA based on
examination of log entries. examination of log entries.
3.1.2.1. Self-monitoring Subject 3.1.2.1. CT-enabled browser
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
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
certificate was to be logged. (A Subject would expect its
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
the certificates that it issues.) If the certificate was supposed to
be logged, but was not, the CA can use the certificate supplied by
the Subject to investigate and remedy the problem. In the context of
a benign CA, a failure to log the certificate might be the result of
an operations error, or evidence of an attack on the CA.
3.1.2.2. CT-enabled browser
If a browser rejects certificates without SCTs (see Section 5.4), CAs If a browser rejects certificates without SCTs (see Section 5.4), CAs
may be "encouraged" to log the certificates they issue. This, in may be "encouraged" to log the certificates they issue. This, in
turn, would make it easier for Monitors to detect bogus certificates. turn, would make it easier for Monitors to detect bogus certificates.
However, the CT architecture does not describe how such behavior by However, the CT architecture does not describe how such behavior by
browsers can be deployed incrementally throughout the Internet. As a browsers can be deployed incrementally throughout the Internet. As a
result, this attack model does not assume that browsers will reject a result, this attack model does not assume that browsers will reject a
certificate that is not accompanied by an SCT. In the CT certificate that is not accompanied by an SCT. In the CT
architecture certificates have to be logged to enable Monitors to architecture certificates have to be logged to enable Monitors to
detect mis-issuance, and to trigger subsequent revocation detect mis-issuance, and to trigger subsequent revocation. Thus the
[I-D.kent-trans-architecture]. Thus the effectiveness of CT is effectiveness of CT is diminished in this context.
diminished in this context.
3.2. Malicious Web PKI CA context 3.2. Malicious Web PKI CA context
In this section, we address the scenario in which the mis-issuance 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
skipping to change at page 13, line 43 skipping to change at page 14, line 19
will detect the bogus certificate and will alert the Subject. The will detect the bogus certificate and will alert the Subject. The
Subject will then ask the CA to revoke the bogus certificate. As in Subject will then ask the CA to revoke the bogus certificate. As in
3.2.1.1.1, the CA may or may not revoke the certificate and it might 3.2.1.1.1, the CA may or may not revoke the certificate and it might
revoke the certificate but provide "good" OCSP responses to a revoke the certificate but provide "good" OCSP responses to a
targeted browser instance. targeted browser instance.
3.2.1.2. Misbehaving log 3.2.1.2. Misbehaving log
A bogus (pre-)certificate may have been submitted to one or more logs A bogus (pre-)certificate may have been submitted to one or more logs
that are misbehaving, e.g., conspiring with an attacker. These logs that are misbehaving, e.g., conspiring with an attacker. These logs
may or may not issue SCTs, but will hide the log entries from some or presumably issue SCTs, but will hide the log entries from some or all
all Monitors. Monitors.
3.2.1.2.1. Monitors - third party and self 3.2.1.2.1. Monitors - third party and self
If log entries are hidden from a Monitor (third party or self), the If log entries are hidden from a Monitor (third party or self), the
Monitor will not be able to detect issuance of a bogus certificate. Monitor will not be able to detect issuance of a bogus certificate.
The Audit function of CT is intended to detect logs that conspire to The Audit function of CT is intended to detect logs that conspire to
delay or suppress log entries (potentially selectively), based on delay or suppress log entries (potentially selectively), based on
consistency checking of logs. (See 3.1.1.2.2.) If a Monitor learns consistency checking of logs. (See 3.1.1.2.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
skipping to change at page 15, line 13 skipping to change at page 15, line 35
in this context. in this context.
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 essentially a malicious CA, and thus the compromised CA is almost equivalent to a malicious CA, and thus the
discussions in Section 3.2 are applicable. Section 3.3 explored the discussions in Section 3.2 are applicable. Section 3.4 explores the
undetected compromise of a CA in the context of attacks designed to undetected compromise of a CA in the context of attacks designed to
issue a bogus certificate that might avoid revocation (because the issue a bogus certificate that might avoid revocation (because the
certificate would appear on distinct certificate paths). certificate would appear on distinct certificate paths).
The section focuses on undetected compromise of CAs. Such The section focuses on undetected compromise of CAs. Such
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 is presumed to have access to the compromised CA or log the adversary may have access to the private
private key used by a CA to sign certificates, or used by a log to key used by a CA to sign certificates, or used by a log to sign SCTs
sign SCTs and STHs. Because the compromise is undetected, there will and STHs. (An attacker might not have access to a CA or log private
be no effort by a CA to have its certificate revoked or by a log to key per se. The attacker may be able to cause a CA to issue bogus
shut down the log. 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
attack on a CA.) Because the compromise is undetected, there will be
no effort by a CA to have its certificate revoked or by a log to shut
down the log.
3.3.1. Compromised CA, Benign Log 3.3.1. Compromised CA, Benign Log
In the case of a compromised (non-malicious) CA, an attacker uses the In the case of a compromised (non-malicious) CA, an attacker uses the
purloined private key to generate a bogus certificate (that the purloined private key to generate a bogus certificate (that the CA
compromised CA would not issue). If this certificate is submitted to would not knowingly issue). If this certificate is submitted to a
a (benign) log, then it subject to detection by a Monitor, as (benign) log, then it subject to detection by a Monitor, as discussed
discussed in 3.1.1.1. If the bogus certificate is submitted to a in 3.1.1.1. If the bogus certificate is submitted to a misbehaving
misbehaving log, then an SCT can be generated, but there will be no log, then an SCT can be generated, but there will be no entry for it,
entry for it, as discussed in 3.1.1.2. If the bogus certificate is as discussed in 3.1.1.2. If the bogus certificate is not logged,
not logged, then there will be no SCT, and the implications are as then there will be no SCT, and the implications are as described in
described in 3.1.2. 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. However, means of remedying the attack are
independent of this aspect, i.e., revocation can be effected independent of this aspect, i.e., revocation can be effected
irrespective of whether the targeted Subject received its certificate irrespective of whether the targeted Subject received its certificate
from the compromised CA. from the compromised CA.
skipping to change at page 17, line 4 skipping to change at page 17, line 30
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.
A bogus certificate issued by the malicious CA will not match the SCT A bogus certificate issued by the malicious CA will not match the SCT
for the legitimate certificate, since they are not identical, e.g., for the legitimate certificate, since they are not identical, e.g.,
at a minimum the private keys do not match. Thus a CT-aware browser at a minimum the private keys do not match. Thus a CT-aware browser
that rejects certificates without SCTs (see 3.1.2.2) will reject a that rejects certificates without SCTs (see 3.1.2.2) will reject a
bogus certificate created under these circumstances if it is not bogus certificate created under these circumstances if it is not
logged. If the bogus certificate is detected and logged, browsers logged. If the bogus certificate is logged it is subject to
that require an SCT will reject the bogus certificate. detection by Monitors. Because the CA is presumed to be malicious
the CA may delay revocation or try to suppress revocation status (see
Section 3.5) even when confronted with evidence of issuance of the
bogus certificate. In this case, even browsers that require an SCT
will still accept the bogus certificate until they become aware of
its revocation status.
3.3.2. Benign CA, Compromised Log 3.3.2. Benign CA, Compromised Log
A benign CA does not issue bogus certificates, except as a result of A benign CA does not issue bogus certificates, except as a result of
an accident or attack. So, in normal operation, it is not clear what an accident or attack. So, in normal operation, it is not clear what
behavior by a compromised log would yield an attack. If a bogus behavior by a compromised log would yield an attack. If a bogus
certificate is issued by a benign CA (under these circumstances) is certificate is issued by a benign CA (under these circumstances) is
submitted to a compromised (non-malicious) log, then both an SCT and submitted to a compromised (non-malicious) log, then both an SCT and
a log entry will be created. Again, it is not clear what additional a log entry will be created. Again, it is not clear what additional
adverse actions the compromised log would perform to further an adverse actions the compromised log would perform to further an
skipping to change at page 17, line 31 skipping to change at page 18, line 13
targeted users. Specifically, the log would show an accurate set of targeted users. Specifically, the log would show an accurate set of
log entries (and STHs) to most clients, but would maintain a separate log entries (and STHs) to most clients, but would maintain a separate
log view for targeted users. This sort of attack motivates the need log view for targeted users. This sort of attack motivates the need
for Audit capabilities based on "gossiping" [I-D.ietf-trans-gossip]. for Audit capabilities based on "gossiping" [I-D.ietf-trans-gossip].
However, even if such mechanisms are employed, they might be thwarted However, even if such mechanisms are employed, they might be thwarted
if a user is unable to exchange log information with trustworthy if a user is unable to exchange log information with trustworthy
partners. partners.
3.3.3. Compromised CA, Compromised Log 3.3.3. Compromised CA, Compromised Log
As noted in 3.4.1, an evil twin CA may issue a bogus certificate 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 contact a log to verify
that the certificate appears in the log, then this is an effective that the certificate appears in the log, then this is an effective
skipping to change at page 20, line 7 skipping to change at page 20, line 31
However, CA certificate 2 does not appear in any logs, and CA A is However, CA certificate 2 does not appear in any logs, and CA A is
unaware that CA B has issued a certificate to the malicious CA. Thus unaware that CA B has issued a certificate to the malicious CA. Thus
those who detected the malicious behavior may not discover the second those who detected the malicious behavior may not discover the second
chain and so may not alert CA B or browser vendors of the need to chain and so may not alert CA B or browser vendors of the need to
revoke/blacklist CA certificate 2. In this case, targeted browsers revoke/blacklist CA certificate 2. In this case, targeted browsers
would continue to accept the bogus certificates issued by the would continue to accept the bogus certificates issued by the
malicious CA, since the certificate chain they are provided is valid malicious CA, since the certificate chain they are provided is valid
and because the SCT issued for the bogus certificate it the same and because the SCT issued for the bogus certificate it the same
irrespective of which certificate chain is presented. irrespective of which certificate chain is presented.
This sort of attack might be thwarted if all intermediate (i.e., CA)
certificates had to be logged. In that case CA certificate 2 might
be rejected by CT-aware browsers.
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. Additionally, an attacker can
steer a browser to specific revocation status data via various means, steer a browser to specific revocation status data via various means,
skipping to change at page 21, line 9 skipping to change at page 21, line 37
that certificate is logged and a Monitor observes the log entry. that certificate is logged and a Monitor observes the log entry.
Detection is intended to trigger revocation, to effect remediation, Detection is intended to trigger revocation, to effect remediation,
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.
This type of attack might be thwarted in several ways. For example, This type of attack might be thwarted in several ways. If a
if all intermediate (i.e., CA) certificates had to be logged, then CA malicious CA is discovered, a browser vendor might blacklist it by
certificate 2 might be rejected by CT-aware browsers. If a malicious public key (not by its serial number and the name of the parent CA or
CA is discovered, a browser vendor might blacklist it by public key by a hash of the certificate). This approach to revocation would
(not by its serial number and the name of the parent CA or by a hash cause CA certificate 2 to be rejected as well as CA certificate 1.
of the certificate). This approach to revocation would cause CA However none of these mechanisms are part of the CT specification
certificate 2 to be rejected as well as CA certificate 1. However
none of these mechanisms are part of the CT specification
[I-D.ietf-trans-rfc6962-bis] nor general IETF PKI standards (e.g., [I-D.ietf-trans-rfc6962-bis] nor general IETF PKI standards (e.g.,
[RFC5280]). [RFC5280]).
4. Syntactic mis-issuance 4. Syntactic mis-issuance
4.1. Non-malicious Web PKI CA context 4.1. Non-malicious Web PKI CA context
This section analyzes the scenario in which the CA has no intent to This section analyzes the scenario in which the CA has no intent to
issue a syntactically incorrect certificate. As noted in Section 1, issue a syntactically incorrect certificate. As noted in Section 1,
we refer to a syntactically incorrect certificate as erroneous. we refer to a syntactically incorrect certificate as erroneous.
4.1.1. Certificate logged 4.1.1. Certificate logged
4.1.1.1. Benign log 4.1.1.1. Benign log
skipping to change at page 21, line 36 skipping to change at page 22, line 18
we refer to a syntactically incorrect certificate as erroneous. we refer to a syntactically incorrect certificate as erroneous.
4.1.1. Certificate logged 4.1.1. Certificate logged
4.1.1.1. Benign log 4.1.1.1. Benign log
If a (pre )certificate is submitted to a benign log, syntactic mis- If a (pre )certificate is submitted to a benign log, syntactic mis-
issuance can (optionally) be detected, and noted. This will happen issuance can (optionally) be detected, and noted. This will happen
only if the log performs syntactic checks in general, and if the log only if the log performs syntactic checks in general, and if the log
is capable of performing the checks applicable to the submitted (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 can be
noted in an SCT extension returned to the submitter. noted in an SCT extension returned to the submitter.
If the (pre )certificate is submitted by the non-malicious issuing If the (pre )certificate is submitted by the non-malicious issuing
CA, then the CA SHOULD remedy the syntactic problem and re-submit 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 helps avoid submitted prior to issuance, syntactic checking by a log could help a
issuance of an erroneous certificate. If the CA does not have a CA detect and avoid issuance of an erroneous certificate. If the CA
record of the certificate contents, then presumably it was a bogus does not have a record of the certificate contents, then presumably
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
will remedy the syntactic problem and either re-submit a corrected 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 (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 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 enables a Subject to be informed that its certificate is erroneous
and thus may hasten issuance of a replacement certificate. and thus may hasten issuance of a replacement certificate.
If a certificate is submitted by a third party, that party might If a certificate is submitted by a third party, that party might
skipping to change at page 23, line 5 skipping to change at page 23, line 35
and some that claim to do syntactic checking, are not reporting these and some that claim to do syntactic checking, are not reporting these
errors, this is indicative of misbehavior by these logs and/or errors, this is indicative of misbehavior by these logs and/or
Monitors. Monitors.
Note that a malicious log (or Monitor) could report syntactic errors Note that a malicious log (or Monitor) could report syntactic errors
for a syntactically valid certificate. This could result in for a syntactically valid certificate. This could result in
reporting of non-existent syntactic problems to the issuing CA, 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.1.3. Self-monitoring Subject and Benign third party Monitor 4.1.2. Certificate not logged
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
depend on a Subject performing the requisite 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
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
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
certificate was to be logged. (A Subject would expect its
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
the certificates that it issues.) If the certificate was supposed to
be logged, but was not, the CA can use the certificate supplied by
the Subject to investigate and remedy the problem. In the context of
a benign CA, a failure to log the certificate might be the result of
an operations error, or evidence of an attack on the CA.
4.1.3. Situations Independent of Certificate Logging
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.1.4. 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 perform thorough syntactic checks on many browsers do not perform thorough syntactic checks on
certificates, and so it seems unlikely that browsers will be a certificates, and so it seems unlikely that browsers will be a
reliable way to detect erroneous certificates. Moreover, a protocol reliable way to detect erroneous certificates. Moreover, a protocol
used by a browser to notify a Subject and/or CA of an erroneous used by a browser to notify a Subject and/or CA of an erroneous
certificate represents a DoS potential, and thus may not be certificate represents a DoS potential, and thus may not be
appropriate. Additionally, if a browser directly contacts a CA when appropriate. Additionally, if a browser directly contacts a CA when
an erroneous certificate is detected, this is a potential privacy an erroneous certificate is detected, this is a potential privacy
violation, i.e., the CA learns that the browser user is visiting the violation, i.e., the CA learns that the browser user is visiting the
web site in question. These observations argue for syntactic web site in question. These observations argue for syntactic
checking to be performed by other elements of the CT system, e.g., checking to be performed by other elements of the CT system, e.g.,
logs and/or Monitors. logs and/or Monitors.
4.1.2. Certificate not logged
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
depend on a Subject performing the requisite 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.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 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
log, a malicious CA can acquire an embedded SCT, or post-issuance
will acquire a standalone SCT for an erroneous certificate. If
Subjects or Monitors perform syntactic checks that detect the
syntactic mis-issuance and report the problem to the CA, a malicious
CA may do nothing or may delay the action(s) needed to remedy the
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 may cause the log Because the CA is presumed to be malicious, the CA might cause the
to not perform checks, in one of several ways. (See log to not perform checks (if it had chosen to do so), in one of
[I-D.kent-trans-domain-validation-cert-checks] and several ways.
[I-D.kent-trans-extended-validation-cert-checks] for more details on
validation checks and CCIDs).
1. The CA may assert that the certificate is being issued w/o regard 1. The CA may assert that the certificate is being issued w/o regard
to any guidelines (the "no guidelines" reserved CCID). to any guidelines (the "no guidelines" reserved CCID).
2. The CA may assert a CCID that has not been registered, and thus 2. The CA may assert a CCID that has not been registered, and thus
no log will be able to perform a check. no log will be able to perform a check.
3. The CA may check to see which CCIDs a log declares it can check, 3. The CA may check to see which CCIDs a log declares it can check,
and chose a registered CCID that is not checked by the log in and chose a registered CCID that is not checked by the log in
question. question.
skipping to change at page 24, line 37 skipping to change at page 25, line 39
checking. checking.
4.2.1.2. Misbehaving log or third party Monitor 4.2.1.2. Misbehaving log or third party Monitor
A misbehaving log or third party Monitor will either not perform A misbehaving log or third party Monitor will either not perform
syntactic checks or not report any problems that it discovers. (See syntactic checks or not report any problems that it discovers. (See
4.1.1.2 for further problems). Also, as noted above, the CT 4.1.1.2 for further problems). Also, as noted above, the CT
architecture includes no explicit provisions for detecting a architecture includes no explicit provisions for detecting a
misbehaving third-party Monitor. misbehaving third-party Monitor.
4.2.1.3. Self-monitoring Subject and Benign third party Monitor 4.2.1.3. CT-enabled browser
Irrespective of whether syntactic checks are performed by a log, a
malicious CA will acquire an embedded SCT, or post-issuance will
acquire a standalone SCT. If Subjects or Monitors perform syntactic
checks that detect the syntactic mis-issuance and report the problem
to the CA, a malicious CA may do nothing or may delay the action(s)
needed to remedy the problem.
4.2.1.4. CT-enabled browser
As noted above (4.1.1.4), most browsers fail to perform thorough As noted above (4.1.1.4), most browsers fail to perform thorough
syntax checks on certificates. Such browsers might benefit from syntax checks on certificates. Such browsers might benefit from
having syntax checks performed by a log and reported in the SCT, having syntax checks performed by a log and reported in the SCT,
although the pervasive nature of syntactically-defective 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
skipping to change at page 25, line 22 skipping to change at page 26, line 17
CA need not worry about failing a log-based check. Similarly, if CA need not worry about failing a log-based check. Similarly, if
there is no requirement for a browser to reject a certificate that there is no requirement for a browser to reject a certificate that
was logged by an operator that does not perform syntactic checks, the was logged by an operator that does not perform syntactic checks, the
fourth attack noted in 4.2.1.1 will succeed as well. If a browser fourth attack noted in 4.2.1.1 will succeed as well. If a browser
were configured to know which versions of certificate types are were configured to know which versions of certificate types are
applicable to its use of a certificate, the second and third attack applicable to its use of a certificate, the second and third attack
strategies noted above could be thwarted. strategies noted above could be thwarted.
4.2.2. Certificate is not logged 4.2.2. Certificate is not logged
Since certificates are not logged in this scenario, a Monitor (third- Since certificates are not logged in this scenario, a third-party
party or self) cannot detect the issuance of an erroneous Monitor cannot detect the issuance of an erroneous certificate based
certificate. Thus there is no difference between a benign or a on examination of log entries. However, if a Subject informs a
Monitor of the syntactic criteria applicable to the certificate it is
supplying, the Monitor can perform syntactic checks on behalf of the
Subject. 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 Monitor.
(A Subject MAY detect a syntax error by examining the certificate (Also note that 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 do
fix the problem or may delay action. 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 be
able to use this information to select an appropriate Monitor (or set able to use this information to select an appropriate Monitor (or set
thereof). Also, it is not clear whether every third-party Monitor thereof). Also, it is not clear whether every third-party Monitor
MUST offer to track every Subject that requests protection. If a must offer to track every Subject that requests protection. If a
Subject acts as its own Monitor, this problem is solved for that Subject acts as its own Monitor, this problem is solved for that
Subject. Subject.
5.2. How does a Monitor discover new logs? 5.2. How does a Monitor discover new logs?
It is not clear how a (self-)Monitor becomes aware of all (relevant) It is not clear how a (self-)Monitor becomes aware of all (relevant)
logs, including newly created logs. The means by which Monitors logs, including newly created logs. The means by which Monitors
become aware of new logs MUST accommodate self-monitoring by a become aware of new logs must accommodate self-monitoring by a
potentially very large number of web site operators. If there are potentially very large number of web site operators. If there are
many logs, it may not be feasible for a (self-) Monitor to track all many logs, it may not be feasible for a (self-) Monitor to track all
of them, or to determine what set of logs suffice to ensure an of them, or to determine what set of logs suffice to ensure an
adequate level of coverage. adequate level of coverage.
5.3. CA response to report of a bogus or erroneous certificate 5.3. CA response to report of a bogus or erroneous certificate
A CA being presented with evidence of a bogus or erroneous A CA being presented with evidence of a bogus or erroneous
certificate, in the form of a log entry and/or SCT, will need to certificate, supported by a log entry and/or SCT, will need to
examine its records to determine if it has knowledge of the examine its records to determine if it has knowledge of the
certificate in question. It also will likely require the targeted certificate in question. It also will likely require the targeted
Subject to provide assurances that it is the authorized entity Subject to provide assurances that it is the authorized entity
representing the Subject name (subjectAltname) in question. Thus a representing the Subject name (subjectAltname) in question. Thus a
Subject should not expect immediate revocation of a contested Subject should not expect immediate revocation of a contested
certificate. The time frame in which a CA will respond to a certificate. The time frame in which a CA will respond to a
revocation request usually is described in the CPS for the CA. Other revocation request usually is described in the CPS for the CA. Other
certificate fields and extensions may be of interest for forensic certificate fields and extensions may be of interest for forensic
purposes, but are not required to effect revocation nor to verify purposes, but are not required to effect. The SCT and log entry,
that the certificate to be revoked is bogus or erroneous, based on because each contains a timestamp from a third party, is probably
applicable criteria. The SCT and log entry, because each contains a valuable for forensic purposes (assuming a non-conspiring log
timestamp from a third party, is probably valuable for forensic 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 validation
skipping to change at page 28, line 11 skipping to change at page 29, line 7
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 should 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 should be acquired by the Monitor based on reference
certificates provided by a Subject. If a Monitor were to rely on a certificates provided by a Subject. If a Monitor were to rely on a
CA or RA database (for the CA that issued a targeted certificate), CA or RA database (for the CA that issued a targeted certificate),
the Monitor would not detect mis-issuance due to malfeasance on the the Monitor would not detect mis-issuance due to malfeasance on the
part of that CA or the RA, or due to compromise of the CA or the RA. part of that CA or the RA, or due to compromise of the CA or the RA.
If a CA or RA database is used, it would support detection of mis- If a CA or RA database is used, it would support detection of mis-
issuance by an unauthorized CA. A Monitor must not rely on issuance by an unauthorized CA.
certificate discovery mechanisms to build the list of valid
certificates since such mechanisms might result in bogus or erroneous
certificates being added to the list.
As noted above, Monitors represent another target for adversaries who As noted above, Monitors represent another target for adversaries who
wish to effect certificate mis-issuance. If a Monitor is compromised wish to effect certificate mis-issuance. If a Monitor is compromised
by, or conspires with, an attacker, it will fail to alert a Subject by, or conspires with, an attacker, it will fail to alert a Subject
to a bogus or erroneous certificate targeting that Subject, as noted to a bogus or erroneous certificate targeting that Subject, as noted
above. It is suggested that a Subject request certificate monitoring above. It is suggested that a Subject request certificate monitoring
from multiple sources to guard against such failures. Operation of a from multiple sources to guard against such failures. Operation of a
Monitor by a Subject, on its own behalf, avoids dependence on third Monitor by a Subject, on its own behalf, avoids dependence on third
party Monitors. However, the burden of Monitor operation may be party Monitors. However, the burden of Monitor operation may be
viewed as too great for many web sites, and thus this mode of viewed as too great for many web sites, and thus this mode of
skipping to change at page 29, line 18 skipping to change at page 30, line 9
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. Most of the members of the TRANS working group for reviewing it. Most of the
text of Section 3.4 was provided by David Cooper, motivated by text of Section 3.4 was provided by David Cooper, motivated by
observations from Daniel Kahn Gilmor. Thanks also go to Daiming Li observations from Daniel Kahn Gilmor. Thanks also go to Daiming Li
for her editorial assistance. for her editorial assistance.
9. References 9. References
9.1. Normative References 9.1. Normative References
[I-D.kent-trans-architecture]
Kent, S., Mandelberg, D., and K. Seo, "Certificate
Transparency (CT) System Architecture", draft-kent-trans-
architecture-07 (work in progress), December 2017.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
9.2. Informative References 9.2. Informative References
[I-D.ietf-trans-gossip] [I-D.ietf-trans-gossip]
Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in
CT", draft-ietf-trans-gossip-05 (work in progress), CT", draft-ietf-trans-gossip-05 (work in progress),
January 2018. January 2018.
[I-D.ietf-trans-rfc6962-bis]
Laurie, B., Langley, A., Kasper, E., Messeri, E., and R.
Stradling, "Certificate Transparency Version 2.0", draft-
ietf-trans-rfc6962-bis-28 (work in progress), March 2018.
[I-D.kent-trans-domain-validation-cert-checks]
Kent, S. and R. Andrews, "Syntactic and Semantic Checks
for Domain Validation Certificates", draft-kent-trans-
domain-validation-cert-checks-02 (work in progress),
December 2015.
[I-D.kent-trans-extended-validation-cert-checks] [I-D.kent-trans-extended-validation-cert-checks]
Kent, S. and R. Andrews, "Syntactic and Semantic Checks Kent, S. and R. Andrews, "Syntactic and Semantic Checks
for Extended Validation Certificates", draft-kent-trans- for Extended Validation Certificates", draft-kent-trans-
extended-validation-cert-checks-02 (work in progress), extended-validation-cert-checks-02 (work in progress),
December 2015. December 2015.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
skipping to change at page 30, line 31 skipping to change at page 31, line 9
[RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS)
Multiple Certificate Status Request Extension", RFC 6961, Multiple Certificate Status Request Extension", RFC 6961,
DOI 10.17487/RFC6961, June 2013, DOI 10.17487/RFC6961, June 2013,
<https://www.rfc-editor.org/info/rfc6961>. <https://www.rfc-editor.org/info/rfc6961>.
9.3. URIs 9.3. URIs
[1] https://cabforum.org [1] https://cabforum.org
[2] https://www.vasco.com/company/about_vasco/press_room/ [2] https://en.wikipedia.org/wiki/DigiNotar
news_archive/2011/news_diginotar_reports_any
security_incident.aspx
Author's Address Author's Address
Stephen Kent Stephen Kent
Independent Independent
Email: kent@alum.mit.edu Email: kent@alum.mit.edu
 End of changes. 66 change blocks. 
208 lines changed or deleted 217 lines changed or added

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