idnits 2.17.1 draft-ietf-trans-threat-analysis-15.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 30, 2018) is 2063 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1419 -- Looks like a reference, but probably isn't: '10' on line 296 -- Looks like a reference, but probably isn't: '12' on line 298 -- Looks like a reference, but probably isn't: '11' on line 297 -- Looks like a reference, but probably isn't: '2' on line 1421 == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-28 -- Obsolete informational reference (is this intentional?): RFC 6961 (Obsoleted by RFC 8446) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Public Notary Transparency S. Kent 3 Internet-Draft Independent 4 Intended status: Informational August 30, 2018 5 Expires: March 3, 2019 7 Attack and Threat Model for Certificate Transparency 8 draft-ietf-trans-threat-analysis-15 10 Abstract 12 This document describes an attack model and discusses threats for the 13 Web PKI context for which security mechanisms to detect mis-issuance 14 of web site certificates are being developed. The model provides an 15 analysis of detection and remediation mechanisms for both syntactic 16 and semantic mis-issuance. The model introduces an outline of 17 attacks to organize the discussion. The model also describes the 18 roles played by the elements of the Certificate Transparency (CT) 19 system, to establish a context for the model. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on March 3, 2019. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions used in this document . . . . . . . . . . . . 8 57 2. Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 3. Semantic mis-issuance . . . . . . . . . . . . . . . . . . . . 10 59 3.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 10 60 3.1.1. Certificate logged . . . . . . . . . . . . . . . . . 10 61 3.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 10 62 3.1.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 11 63 3.1.1.3. Misbehaving third party Monitor . . . . . . . . . 12 64 3.1.2. Certificate not logged . . . . . . . . . . . . . . . 12 65 3.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 12 66 3.2.1. Certificate logged . . . . . . . . . . . . . . . . . 13 67 3.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 13 68 3.2.1.2. Misbehaving log . . . . . . . . . . . . . . . . . 13 69 3.2.1.3. Misbehaving third party Monitor . . . . . . . . . 14 70 3.2.2. Certificate not logged . . . . . . . . . . . . . . . 14 71 3.2.2.1. CT-aware browser . . . . . . . . . . . . . . . . 14 72 3.3. Undetected Compromise of CAs or Logs . . . . . . . . . . 15 73 3.3.1. Compromised CA, Benign Log . . . . . . . . . . . . . 15 74 3.3.2. Benign CA, Compromised Log . . . . . . . . . . . . . 17 75 3.3.3. Compromised CA, Compromised Log . . . . . . . . . . . 18 76 3.4. Attacks Based on Exploiting Multiple Certificate Chains . 19 77 3.5. Attacks Related to Distribution of Revocation Status . . 20 78 4. Syntactic mis-issuance . . . . . . . . . . . . . . . . . . . 21 79 4.1. Non-malicious Web PKI CA context . . . . . . . . . . . . 21 80 4.1.1. Certificate logged . . . . . . . . . . . . . . . . . 22 81 4.1.1.1. Benign log . . . . . . . . . . . . . . . . . . . 22 82 4.1.1.2. Misbehaving log or third party Monitor . . . . . 23 83 4.1.2. Certificate not logged . . . . . . . . . . . . . . . 23 84 4.1.2.1. Self-monitoring Subject . . . . . . . . . . . . . 24 85 4.1.3. Situations Independent of Certificate Logging . . . . 24 86 4.1.3.1. Self-monitoring Subject and Benign third party 87 Monitor . . . . . . . . . . . . . . . . . . . . . 24 88 4.1.3.2. CT-enabled browser . . . . . . . . . . . . . . . 24 89 4.2. Malicious Web PKI CA context . . . . . . . . . . . . . . 25 90 4.2.1. Certificate logged . . . . . . . . . . . . . . . . . 25 91 4.2.1.1. Benign log . . . . . . . . . . . . . . . . . . . 25 92 4.2.1.2. Misbehaving log or third party Monitor . . . . . 25 93 4.2.1.3. CT-enabled browser . . . . . . . . . . . . . . . 26 94 4.2.2. Certificate is not logged . . . . . . . . . . . . . . 26 95 5. Issues Applicable to Sections 3 and 4 . . . . . . . . . . . . 26 96 5.1. How does a Subject know which Monitor(s) to use? . . . . 26 97 5.2. How does a Monitor discover new logs? . . . . . . . . . . 27 98 5.3. CA response to report of a bogus or erroneous certificate 27 99 5.4. Browser behavior . . . . . . . . . . . . . . . . . . . . 27 100 5.5. Remediation for a malicious CA . . . . . . . . . . . . . 28 101 5.6. Auditing - detecting misbehaving logs . . . . . . . . . . 28 102 6. Security Considerations . . . . . . . . . . . . . . . . . . . 30 103 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 104 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 105 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 106 9.1. Normative References . . . . . . . . . . . . . . . . . . 30 107 9.2. Informative References . . . . . . . . . . . . . . . . . 30 108 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 31 109 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 111 1. Introduction 113 Certificate transparency (CT) is a set of mechanisms designed to 114 detect, deter, and facilitate remediation of certificate mis- 115 issuance. The term certificate mis-issuance is defined here to 116 encompass violations of either semantic or syntactic constraints. 117 The fundamental semantic constraint for a certificate is that it was 118 issued to an entity that is authorized to represent the Subject (or 119 Subject Alternative) named in the certificate. (It is also assumed 120 that the entity requested the certificate from the CA that issued 121 it.) Throughout the remainder of this document we refer to a 122 semantically mis-issued certificate as "bogus." 124 A certificate is characterized as syntactically mis-issued (aka 125 erroneous) if it violates syntax constraints associated with the 126 class of certificate that it purports to represent. Syntax 127 constraints for certificates are established by certificate profiles, 128 and typically are application-specific. For example, certificates 129 used in the Web PKI environment might be characterized as domain 130 validation (DV) or extended validation (EV) certificates. 131 Certificates used with applications such as IPsec or S/MIME have 132 different syntactic constraints from those in the Web PKI context. 134 There are three classes of beneficiaries of CT: certificate Subjects, 135 CAs, and relying parties (RPs). In the initial focus context of CT, 136 the Web PKI, Subjects are web sites and RPs are browsers employing 137 HTTPS to access these web sites. The CAs that benefit are issuers of 138 certificates used to authenticate web sites. 140 A certificate Subject benefits from CT because CT helps detect 141 certificates that have been mis-issued in the name of that Subject. 142 A Subject learns of a bogus certificate (issued in its name), via the 143 Monitor function of CT. The Monitor function may be provided by the 144 Subject itself, i.e., self-monitoring, or by a third party trusted by 145 the Subject. When a Subject is informed of certificate mis-issuance 146 by a Monitor, the Subject is expected to request/demand revocation of 147 the bogus certificate. Revocation of a bogus certificate is the 148 primary means of remedying mis-issuance. 150 Certificate Revocations Lists (CRLs) [RFC5280] are the primary means 151 of certificate revocation established by IETF standards. 152 Unfortunately, most browsers do not make use of CRLs to check the 153 revocation status of certificates presented by a TLS Server 154 (Subject). Some browsers make use of Online Certificate Status 155 Protocol (OCSP) data [RFC6960] as a standards-based alternative to 156 CRLs. If a certificate contains an Authority Information Access 157 (AIA) extension [RFC5280], it directs a relying party to an OCSP 158 server to which a request can be directed. A browser may also 159 request OCSP responses from a TLS server with which it is 160 communicating [RFC6066][RFC6961]. 162 RFC 5280 does not require inclusion of an AIA extension in 163 certificates, so a browser cannot assume that this extension will be 164 present. The Certification Authority and Browser Forum (CABF) 165 baseline requirements and extended validation guidelines do mandate 166 inclusion of this extension in EE certificates (in conjunction with 167 their certificate policies). (See cabforum.org [1] for the most 168 recent versions of these policies.) 170 In addition to the revocation status data dissemination mechanisms 171 specified by IETF standards, most browser vendors employ proprietary 172 means of conveying certificate revocation status information to their 173 products, e.g., via a blacklist that enumerates revoked certificates 174 (EE or CA). Such capabilities enable a browser vendor to cause 175 browsers to reject any certificates on the blacklist. This approach 176 also can be employed to remedy mis-issuance. Throughout the 177 remainder of this document references to certificate revocation as a 178 remedy encompass this and analogous forms of browser behavior, if 179 available. Note: there are no IETF standards defining a browser 180 blacklist capability. 182 Note that a Subject can benefit from the Monitor function of CT even 183 if the Subject's certificate has not been logged. Monitoring of logs 184 for certificates issued in the Subject's name suffices to detect mis- 185 issuance targeting the Subject, if the bogus/erroneous certificate is 186 logged. 188 A relying party (e.g., browser) benefits from CT if it rejects a 189 bogus certificate, i.e., treats it as invalid. An RP is protected 190 from accepting a bogus certificate if that certificate is revoked, 191 and if the RP checks the revocation status of the certificate. (An 192 RP also is protected if a browser vendor "blacklists" a certificate 193 or places a CA on a "bad-CA-list", causing all certs issued by the CA 194 to be treated as invalid.) An RP also may benefit from CT if the RP 195 validates an SCT associated with a certificate (see 8.1.3 in 196 [I-D.ietf-trans-rfc6962-bis]), and rejects the certificate if the 197 Signed certificate Timestamp (SCT) [I-D.ietf-trans-rfc6962-bis] is 198 invalid. If an RP verified that a certificate that claims to have 199 been logged has a valid log entry, the RP probably would have a 200 higher degree of confidence that the certificate is genuine. 201 However, checking logs in this fashion imposes a burden on RPs and on 202 logs. Moreover, the existence of a log entry does not ensure that 203 the certificate is not mis-issued. Unless the certificate Subject is 204 monitoring the log(s) in question, a bogus certificate will not be 205 detected by CT mechanisms. Finally, if an RP were to check logs for 206 individual certificates, that would disclose to logs the identity of 207 web sites being visited by the RP, a privacy violation. Thus this 208 attack model does not assume that all RPs will check log entries. 210 A CA benefits from CT when it (acting as a Monitor for its clients) 211 detects a (mis-issued) certificate that represents the same Subject 212 name as a legitimate certificate issued by the CA. 214 Note that all RPs may benefit from CT even if they do nothing with 215 SCTs. If Monitors inform Subjects of mis-issuance, and if a CA 216 revokes a certificate in response to a request from the certificate's 217 legitimate Subject, then an RP benefits without having to implement 218 any CT-specific mechanisms. 220 Also note that one proposal [I-D.ietf-trans-gossip] for distributing 221 Audit information (to detect misbehaving logs) calls for a browser to 222 send SCTs it receives to the corresponding website when visited by 223 the browser. If a website acquires an inclusion proof from a log for 224 each (unique) SCT it receives in this fashion, this would cause a 225 bogus SCT to be discovered, and, presumably, trigger a revocation 226 request. 228 Logging [I-D.ietf-trans-rfc6962-bis] is the central element of CT. 229 Logging enables a Monitor to detect a bogus certificate based on 230 reference information provided by the certificate Subject. Logging 231 of certificates is intended to deter mis-issuance, by creating a 232 publicly-accessible record that associates a CA with any certificates 233 that it mis-issues. Logging does not remedy mis-issuance; but it 234 does facilitate remediation by providing the information needed to 235 enable detection and subsequent revocation of bogus certificates in 236 some circumstances. 238 Auditing is a function employed by CT to detect misbehavior by logs 239 and to deter mis-issuance that is abetted by misbehaving logs. 240 Auditing detects several types of log misbehavior, including failures 241 to adhere to the advertised Maximum Merge Delay (MMD) and Signed Tree 242 Head (STH) frequency count [I-D.ietf-trans-rfc6962-bis] violating the 243 append-only property, and providing inconsistent views of the log to 244 different log clients. The first three of these are relatively easy 245 for an individual auditor to detect, but the last form of misbehavior 246 requires communication among multiple log clients. Monitors ought 247 not trust logs that are detected misbehaving. Thus the Audit 248 function does not detect mis-issuance per se. The CT design 249 identifies audit functions designed to detect several types of 250 misbehavior. However, mechanisms to detect some forms of log 251 misbehavior are not yet standardized. 253 Figure 1 (below) illustrates the data exchanges among the major 254 elements of the CT system, based on the log specification 255 [I-D.ietf-trans-rfc6962-bis] and on the assumed behavior of other CT 256 system elements as described above. This Figure does not include the 257 Audit function, because there is not yet agreement on how that 258 function will work in a distributed, privacy-preserving fashion. 260 +----+ +---------+ +---------+ 261 | CA |---[1]--->| Log |<---[8]---| Monitor | 262 | | | | | | 263 | |<--[2]----| |----[9]-->| | 264 | | | | | | 265 | |---[3]--->| |<--[10]---| | 266 | | | | | |--------+ 267 | |<--[4]----| |---[11]-->| | | 268 | | | | +---------+ | 269 | | | | | 270 | | | | +---------+ | 271 | | | |<--[8]----| Self- | | 272 | | | | | Monitor | | 273 | | | |---[9]--->|(Subject)| | 274 | | | | | | | 275 | | | |<--[10]---| | [12] 276 | | | | | | | 277 | | | |---[11]-->| | | 278 | | +---------+ +---------+ | 279 | | | 280 | | +---------+ +---------+ | 281 | |---[5]--->| Website |---[7]--->| Browser | | 282 | | |(Subject)| +---------+ | 283 | |<--[6]--->| |<----------------------------+ 284 +----+ +---------+ 286 [ 1] Retrieve accepted root certs 287 [ 2] accepted root certs 288 [ 3] Add chain to log/add PreCertChain to log 289 [ 4] SCT 290 [ 5] send cert + SCTs (or cert with embedded SCTs) 291 [ 6] Revocation request/response (in response to detected 292 mis-issuance) 293 [ 7] cert + SCTs (or cert with embedded SCTs) 294 [ 8] Retrieve entries from Log 295 [ 9] returned entries from log 296 [10] Retrieve latest STH 297 [11] returned STH 298 [12] bogus/erroneous cert notification 300 Figure 1: Data Exchanges Between Major Elements of the CT System 302 Certificate mis-issuance may arise in one of several ways. The ways 303 by which CT enables a Subject (or others) to detect and redress mis- 304 issuance depends on the context and the entities involved in the mis- 305 issuance. This attack model applies to use of CT in the Web PKI 306 context. If CT is extended to apply to other contexts, each context 307 will require its own attack model, although most elements of the 308 model described here are likely to be applicable. 310 Because certificates are issued by CAs, the top level differentiation 311 in this analysis is whether the CA that mis-issued a certificate did 312 so maliciously or not. Next, for each scenario, the model considers 313 whether or not the certificate was logged. Scenarios are further 314 differentiated based on whether the logs and monitors are benign or 315 malicious and whether a certificate's Subject is self-monitoring or 316 is using a third party Monitoring service. Finally, the analysis 317 considers whether a browser is performing checking relevant to CT. 318 The scenarios are organized as illustrated by the following outline: 320 Web PKI CA - malicious vs non-malicious 321 Certificate - logged vs not logged 322 Log - benign vs malicious 323 Third party Monitor - benign vs malicious 324 Certificate's Subject - self-monitoring (or not) 325 Browser - CT-supporting (or not) 327 The next section of the document briefly discusses threats. 328 Subsequent sections examine each of the cases described above. As 329 noted earlier, the focus here is on the Web PKI context, although 330 most of the analysis is applicable to other PKI contexts. 332 1.1. Conventions used in this document 334 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 335 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 336 document are to be interpreted as described in [RFC2119]. 338 2. Threats 340 In the context of this document, a threat is defined, traditionally, 341 as a motivated, capable adversary. An adversary who is not motivated 342 to attack a system is not a threat. An adversary who is motivated 343 but not "capable" also is not a threat. Threats change over time; 344 new classes of adversaries may arise, new motivations may come into 345 play, and the capabilities of adversaries may change. Nonetheless, 346 it is useful to document perceived threats against a system to 347 provide a context for understanding attacks (even though some attacks 348 may be the result of errors, not threats). Even if the assumptions 349 about adversaries prove to be incorrect, documenting the assumptions 350 is valuable. 352 As noted above, the goals of CT are to deter, detect, and facilitate 353 remediation of attacks that result in certificate mis-issuance in the 354 Web PKI. (Note that errors by a CA are viewed as attacks, in the 355 context of this document.) Such attacks can enable an attacker to 356 spoof the identity of TLS-enabled web sites. Spoofing enables an 357 adversary to perform many types of attacks, e.g., delivery of malware 358 to a client, reporting bogus information, or acquiring information 359 that a client would not communicate if the client were aware of the 360 spoofing. Such information may include personal identification and 361 authentication information and electronic payment authorization 362 information. Because of the nature of the information that may be 363 divulged (or misinformation or malware that may be delivered), the 364 principal adversaries in the CT context are perceived to be (cyber) 365 criminals and nation states. Both adversaries are motivated to 366 acquire personal identification and authentication information. 367 Criminals are also motivated to acquire electronic payment 368 authorization information. 370 To make use of bogus web site certificates, an adversary must be able 371 to direct a TLS client to a spoofed web site, so that it can present 372 the bogus certificate during a TLS handshake. An adversary may 373 achieve this in various ways, e.g., by manipulation of the DNS 374 response sent to a TLS client or via a man-in-the-middle attack. The 375 former type of attack is well within the perceived capabilities of 376 both classes of adversary. The latter attack may be possible for 377 criminals and is certainly a capability available to a nation state 378 within its borders. Nation states also may be able to compromise DNS 379 servers outside their own jurisdiction. 381 The elements of CT may themselves be targets of attacks, as described 382 below. A criminal organization might compromise a CA and cause it to 383 issue bogus certificates, or it may exert influence over a CA (or CA 384 staff) to do so, e.g., through extortion or physical threat. A CA 385 may be the victim of social engineering, causing it to issue a 386 certificate to an inappropriate Subject. (Even though the CA is not 387 intentionally malicious in this case, the action is equivalent to a 388 malicious CA, hence the use of the term "bogus" here.) A nation 389 state may operate or influence a CA that is part of the large set of 390 "root CAs" in browsers. A CA, acting in this fashion, is termed a 391 "malicious" CA. A nation state also might compromise a CA in another 392 country, to effect issuance of bogus certificates. In this case the 393 (non-malicious) CA, upon detecting the compromise (perhaps because of 394 CT) is expected to work with Subjects to remedy the mis-issuance. 396 A log also might be compromised by a suitably sophisticated criminal 397 organization or by a nation state. Compromising a log would enable a 398 compromised or rogue CA to acquire SCTs, but log entries would be 399 suppressed, either for all log clients or for targeted clients (e.g., 400 to selected Monitors or Auditors). It seems unlikely that a 401 compromised, non-malicious, log would persist in presenting multiple 402 views of its data, but a malicious log would. 404 Finally, note that a browser trust store may include a CA that is 405 intended to issue certificates to enable monitoring of encrypted 406 browser sessions. The inclusion of a trust anchor for such a CA is 407 intended to facilitate monitoring encrypted content, via an 408 authorized man-in-the-middle (MITM) attack. CT is not designed to 409 counter this type of locally-authorized interception. 411 3. Semantic mis-issuance 413 3.1. Non-malicious Web PKI CA context 415 In this section, we address the case where the CA has no intent to 416 issue a bogus certificate. 418 A CA may have mis-issued a certificate as a result of an error or, in 419 the case of a bogus certificate, because it was the victim of a 420 social engineering or a technical attack. In the case of an error, 421 the CA should have a record of the erroneous certificate and be 422 prepared to revoke this certificate once it has discovered and 423 confirmed the error. In the event of a technical attack, a CA may 424 have no record of a bogus certificate. 426 3.1.1. Certificate logged 428 3.1.1.1. Benign log 430 The log (or logs) is benign and thus is presumed to provide 431 consistent, accurate responses to requests from all clients. 433 If a bogus (pre-)certificate has been submitted to one or more logs 434 prior to issuance to acquire an embedded SCT, or post-issuance to 435 acquire a standalone SCT, detection of this mis-issuance is the 436 responsibility of a Monitor. 438 3.1.1.1.1. Self-monitoring Subject 440 If a Subject is tracking the log(s) to which a certificate was 441 submitted, and is performing self-monitoring, then it will be able to 442 detect a bogus (pre-)certificate and request revocation. In this 443 case, the CA will make use of the log entry (supplied by the Subject) 444 to determine the serial number of the bogus certificate, and 445 investigate/revoke it. (See Sections 5.1, 5.2 and 5.3.) 447 3.1.1.1.2. Benign third party Monitor 449 If a benign third party monitor is checking the logs to which a 450 certificate was submitted and is protecting the targeted Subject, it 451 will detect a bogus certificate and will alert the Subject. The 452 Subject, in turn, will ask the CA to revoke the bogus certificate. 453 In this case, the CA will make use of the log entry (supplied by the 454 Subject) to determine the serial number of the bogus certificate, and 455 revoke it (after investigation). (See Sections 5.1, 5.2 and 5.3.) 457 3.1.1.2. Misbehaving log 459 In this case, the bogus (pre-)certificate has been submitted to one 460 or more logs, each of which generate an SCT for the submission. A 461 misbehaving log probably will suppress a bogus certificate log entry, 462 or it may create an entry for the certificate but report it 463 selectively. (A misbehaving log also could create and report entries 464 for bogus certificates that have not been issued by the indicated CA 465 (hereafter called "fake"). Unless a Monitor validates the associated 466 certificate chains up to roots that it trusts, these fake bogus 467 certificates could cause the Monitors to report non-existent semantic 468 problems to the Subject who would in turn report them to the 469 purported issuing CA. This might cause the CA to do needless 470 investigative work or perhaps incorrectly revoke and re-issue the 471 Subject's real certificate. Note that for every certificate 472 submitted to a log, the log must verify a complete certificate chain 473 up to one of the roots it accepts. So creating a log entry for a 474 fake bogus certificate marks the log as misbehaving. 476 3.1.1.2.1. Self-monitoring Subject & Benign third party Monitor 478 If a misbehaving log suppresses a bogus certificate log entry, a 479 Subject performing self-monitoring will not detect the bogus 480 certificate. CT relies on an Audit mechanism to detect log 481 misbehavior, as a deterrent. It is anticipated that logs that are 482 identified as persistently misbehaving will cease to be trusted by 483 Monitors, non-malicious CAs, and by browser vendors. This assumption 484 forms the basis for the perceived deterrent. It is not clear if 485 mechanisms to detect this sort of log misbehavior will be viable. 487 Similarly, when a misbehaving log suppresses a bogus certificate log 488 entry (or report such entries inconsistently) a benign third party 489 Monitor that is protecting the targeted Subject also will not detect 490 a bogus certificate. In this scenario, CT relies on a distributed 491 Auditing mechanism [I-D.ietf-trans-gossip] to detect log misbehavior, 492 as a deterrent. (See Section 5.6 below.) However, a Monitor (third- 493 party or self) must participate in the Audit mechanism in order to 494 become aware of log misbehavior. 496 If the misbehaving log has logged the bogus certificate when issuing 497 the associated SCT, it will try to hide this from the Subject (if 498 self-monitoring) or from the Monitor protecting the Subject. It does 499 so by presenting them with a view of its log entries and STH that 500 does not contain the bogus certificate. To other entities, the log 501 presents log entries and an STH that include the bogus certificate. 502 This discrepancy can be detected if there is an exchange of 503 information about the log entries and STH between the entities 504 receiving the view that excludes the bogus certificate and entities 505 that receive a view that includes it, i.e., a distributed Audit 506 mechanism. 508 If a malicious log does not create an entry for a bogus certificate 509 (for which an SCT has been issued), then any Monitor/Auditor that 510 enrounters the bogus certificate (and SCT) will detect this when it 511 checks with the log for log entries and STH (see Section 3.1.2.) 513 3.1.1.3. Misbehaving third party Monitor 515 A third party Monitor that misbehaves will not notify the targeted 516 Subject of a bogus certificate. This is true irrespective of whether 517 the Monitor checks the logs or whether the logs are benign or 518 malicious/conspiring. 520 Note that independent of any mis-issuance on the part of the CA, a 521 misbehaving Monitor could issue false warnings to a Subject that it 522 protects. These could cause the Subject to report non-existent 523 semantic problems to the issuing CA and cause the CA to do needless 524 investigative work or perhaps incorrectly revoke and re-issue the 525 Subject's certificate. 527 3.1.2. Certificate not logged 529 If the CA does not submit a pre-certificate to a log, whether a log 530 is benign or misbehaving does not matter. The same is true if a 531 Subject is issued a certificate without an SCT and does not log the 532 certificate itself, to acquire an SCT. Also, since there is no log 533 entry in this scenario, there is no difference in outcome between a 534 benign and a misbehaving third party Monitor. In both cases, no 535 Monitor (self or third-party) will detect a bogus certificate based 536 on Monitor functions and there will be no consequent reporting of the 537 problem to the Subject or by the Subject to the CA based on 538 examination of log entries. 540 3.2. Malicious Web PKI CA context 542 In this section, we address the scenario in which the mis-issuance is 543 intentional, not due to error. The CA is not the victim but the 544 attacker. 546 3.2.1. Certificate logged 548 3.2.1.1. Benign log 550 A bogus (pre-)certificate may be submitted to one or more benign logs 551 prior to issuance, to acquire an embedded SCT, or post-issuance to 552 acquire a standalone SCT. The log (or logs) replies correctly to 553 requests from clients. 555 3.2.1.1.1. Self-monitoring Subject 557 If a Subject is checking the logs to which a certificate was 558 submitted and is performing self-monitoring, it will be able to 559 detect the bogus certificate and will request revocation. The CA may 560 refuse to revoke, or may substantially delay revoking, the bogus 561 certificate. For example, the CA could make excuses about inadequate 562 proof that the certificate is bogus, or argue that it cannot quickly 563 revoke the certificate because of legal concerns, etc. In this case, 564 the CT mechanisms will have detected mis-issuance, but the 565 information logged by CT may not suffice to remedy the problem. (See 566 Sections 4 and 6.) 568 A malicious CA might revoke a bogus certificate to avoid having 569 browser vendors take punitive action against the CA and/or to 570 persuade them to not enter the bogus certificate on a vendor- 571 maintained blacklist. However, the CA might provide a "good" OCSP 572 response (from a server it operates) to a targeted browser instance 573 as a way to circumvent the remediation nominally offered by 574 revocation. No component of CT is tasked with detecting this sort of 575 misbehavior by a CA. (The misbehavior is analogous to a log offering 576 split views to different clients, as discussed later. The Audit 577 element of CT is tasked with detecting this sort of attack.) 579 3.2.1.1.2. Benign third party Monitor 581 If a benign third party monitor is checking the logs to which a 582 certificate was submitted and is protecting the targeted Subject, it 583 will detect the bogus certificate and will alert the Subject. The 584 Subject will then ask the CA to revoke the bogus certificate. As in 585 3.2.1.1.1, the CA may or may not revoke the certificate and it might 586 revoke the certificate but provide "good" OCSP responses to a 587 targeted browser instance. 589 3.2.1.2. Misbehaving log 591 A bogus (pre-)certificate may have been submitted to one or more logs 592 that are misbehaving, e.g., conspiring with an attacker. These logs 593 presumably issue SCTs, but will hide the log entries from some or all 594 Monitors. 596 3.2.1.2.1. Monitors - third party and self 598 If log entries are hidden from a Monitor (third party or self), the 599 Monitor will not be able to detect issuance of a bogus certificate. 601 The Audit function of CT is intended to detect logs that conspire to 602 delay or suppress log entries (potentially selectively), based on 603 consistency checking of logs. (See 3.1.1.2.2.) If a Monitor learns 604 of misbehaving log operation, it alerts the Subjects that it is 605 protecting, so that they no longer acquire SCTs from that log. The 606 Monitor also avoids relying upon such a log in the future. However, 607 unless a distributed Audit mechanism proves effective in detecting 608 such misbehavior, CT cannot be relied upon to detect this form of 609 mis-issuance. (See Section 5.6 below.) 611 3.2.1.3. Misbehaving third party Monitor 613 If the third party Monitor that is "protecting" the targeted Subject 614 is misbehaving, then it will not notify the targeted Subject of any 615 mis-issuance or of any malfeasant log behavior that it detects 616 irrespective of whether the logs it checks are benign or malicious/ 617 conspiring. The CT architecture does not include any measures to 618 detect misbehavior by third-party monitors. 620 3.2.2. Certificate not logged 622 Because the CA is presumed malicious, it may choose to not submit a 623 (pre-)certificate to a log. This means there is no SCT for the 624 certificate. 626 When a CA does not submit a certificate to a log, whether a log is 627 benign or misbehaving does not matter. Also, since there is no log 628 entry, there is no difference in behavior between a benign and a 629 misbehaving third-party Monitor. Neither will report a problem to 630 the Subject. 632 A bogus certificate would not be delivered to the legitimate Subject. 633 So the Subject, acting as a self-Monitor, cannot detect the issuance 634 of a bogus certificate in this case. 636 3.2.2.1. CT-aware browser 638 If careful browsers reject certificates without SCTs, CAs may be 639 "encouraged" to log certificates (see section 5.4). However, the CT 640 architecture does not require a browser to reject a certificate 641 lacking a matching SCT (or equivalent evidence of logging) in all 642 cases. This is a matter of local policy. Section 8.1.6 of 643 [I-D.ietf-trans-rfc6962-bis] says: "It is up to a client's local 644 policy to specify the quantity and form of evidence (SCTs, inclusion 645 proofs or a combination) needed to achieve compliance and how to 646 handle non-compliance." As a result, this attack model does not 647 assume that browsers will reject a certificate that is not 648 accompanied by an SCT in all circumstances. Since certificates have 649 to be logged to enable detection of mis-issuance by Monitors, and to 650 trigger subsequent revocation, the effectiveness of CT is diminished 651 in circumstances where local policy does not mandate SCT or inclusion 652 proof checking. 654 3.3. Undetected Compromise of CAs or Logs 656 Sections 3.1 and 3.2 examined attacks in the context of non-malicious 657 and malicious CAs, and benign and misbehaving logs. Another class of 658 attacks might occur in the context of a non-malicious CA and/or a 659 benign log. Specifically these CT elements might be compromised and 660 the compromise might go undetected. Compromise of CAs and logs was 661 noted in Section 2, as was coercion of a CA. As noted there, a 662 compromised CA is almost equivalent to a malicious CA, and thus the 663 discussions in Section 3.2 are applicable. Section 3.4 explores the 664 undetected compromise of a CA in the context of attacks designed to 665 issue a bogus certificate that might avoid revocation (because the 666 certificate would appear on distinct certificate paths). 668 The section focuses on undetected compromise of CAs. Such 669 compromises warrant some additional discussion, since some relying 670 parties may see signed objects issued by the legitimate (non- 671 malicious) CA, others may see signed objects from its compromised 672 counterpart, and some may see objects from both. In the case of a 673 compromised CA or log the adversary may have access to the private 674 key used by a CA to sign certificates, or used by a log to sign SCTs 675 and STHs. (An attacker might not have access to a CA or log private 676 key per se. The attacker may be able to cause a CA to issue bogus 677 certificates, or a log to generate bogus objects, and not have a 678 record of them. The DigiNotar [2] case is an example of this sort of 679 attack on a CA.) Because the compromise is undetected, there will be 680 no effort by a CA to have its certificate revoked or by a log to shut 681 down the log. 683 3.3.1. Compromised CA, Benign Log 685 In the case of a compromised (non-malicious) CA, an attacker may have 686 acquired the CA's private key, or it may be able to cause the CA to 687 sign certificates using that key, even though the attacker does not 688 know the key per se. In other case the goal is to cause the CA to 689 issues a bogus certificate (that the CA would not knowingly issue). 690 If this certificate is submitted to a (benign) log, then it subject 691 to detection by a Monitor, as discussed in 3.1.1.1. If the bogus 692 certificate is submitted to a misbehaving log, then an SCT can be 693 generated, but there will be no entry for it, as discussed in 694 3.1.1.2. If the bogus certificate is not logged, then there will be 695 no SCT, and the implications are as described in 3.1.2. 697 This sort of attack may be most effective if the CA that is the 698 victim of the attack has issued a certificate for the targeted 699 Subject. In this case the bogus certificate will then have the same 700 certification path as the legitimate certificate, which may help hide 701 the bogus certificate. However, means of remedying the attack are 702 independent of this aspect, i.e., revocation can be effected 703 irrespective of whether the targeted Subject received its certificate 704 from the compromised CA. 706 A compromised (non-malicious) CA may be able to revoke the bogus 707 certificate if it is detected by a Monitor, and the targeted Subject 708 has been notified. It can do so only when the serial number of the 709 bogus certificate is made known to this CA and assuming that the 710 bogus certificate was not issued with an Authority Information Access 711 (AIA) or CRL Distribution Point (CRL DP) extension that enables only 712 the malicious twin to revoke the certificate. (The AIA extension in 713 the bogus certificate could be used to direct relying parties to an 714 OCSP server controlled by the malicious twin. The CRL DP extension 715 could be used to direct relying parties to a CRL controlled by the 716 malicious twin.) If the bogus certificate contains either extension, 717 the compromised CA cannot effectively revoke it. However, the 718 presence of either of these extensions provides some evidence that an 719 entity other than the compromised CA issued the certificate in 720 question. (If the extensions differ from those in other certificates 721 issued by the compromised CA, that is suspicious.) 723 If the serial number of the bogus certificate is the same as for a 724 valid, not-expired certificate issued by the CA (to the target or to 725 another Subject), then revocation poses a problem. This is because 726 revocation of the bogus certificate will also invalidate a legitimate 727 certificate. This problem may cause the compromised CA to delay 728 revocation, thus allowing the bogus certificate to remain a danger 729 for a longer time. 731 The compromised CA may not realize that the bogus certificate was 732 issued by a malicious twin; one occurrence of this sort might be 733 regarded as an error, and not cause the CA to transition to a new key 734 pair. (This assumes that the bogus certificate does not contain an 735 AIA or CRL DP extension that wrests control of revocation from the 736 compromised CA.) If the compromised CA does determine that its 737 private key has been stolen, it probably will take some time to 738 transition to a new key pair, and reissue certificates to all of its 739 legitimate Subjects. Thus an attack of this sort probably will take 740 a while to be remedied. 742 Also note that the malicious twin of the compromised CA may be 743 capable of issuing its own CRL or OCSP responses, without changing 744 any AIA/CRL DP data present in the targeted certificate. The 745 revocation status data from the evil twin will appear as valid as 746 those of the compromised CA. If the attacker has the ability to 747 control the sources of revocation status data available to a targeted 748 user (browser instance), then the user may not become aware of the 749 attack. 751 A bogus certificate issued by the malicious CA will not match the SCT 752 for the legitimate certificate, since they are not identical, e.g., 753 at a minimum the private keys do not match. Thus a CT-aware browser 754 that rejects certificates without SCTs (see 3.2.2.1) will reject a 755 bogus certificate created under these circumstances if it is not 756 logged. If the bogus certificate is logged it is subject to 757 detection by Monitors. Because the CA is presumed to be malicious 758 the CA may delay revocation or try to suppress revocation status (see 759 Section 3.5) even when confronted with evidence of issuance of the 760 bogus certificate. In this case, even browsers that require an SCT 761 will still accept the bogus certificate until they become aware of 762 its revocation status. 764 3.3.2. Benign CA, Compromised Log 766 A benign CA does not issue bogus certificates, except as a result of 767 an accident or attack. So, in normal operation, it is not clear what 768 behavior by a compromised log would yield an attack. If a bogus 769 certificate is issued by a benign CA (under these circumstances) is 770 submitted to a compromised (non-malicious) log, then both an SCT and 771 a log entry will be created. Again, it is not clear what additional 772 adverse actions the compromised log would perform to further an 773 attack on CT. 775 It is worth noting that if a benign CA was attacked and thus issued 776 one or more bogus certificates, then a malicious log might provide 777 split views of its log to help conceal the bogus certificate from 778 targeted users. Specifically, the log would show an accurate set of 779 log entries (and STHs) to most clients, but would maintain a separate 780 log view for targeted users. This sort of attack motivates the need 781 for Audit capabilities based on "gossiping" [I-D.ietf-trans-gossip]. 782 However, even if such mechanisms are employed, they might be thwarted 783 if a user is unable to exchange log information with trustworthy 784 partners. 786 3.3.3. Compromised CA, Compromised Log 788 As noted in 3.4, an evil twin CA may issue a bogus certificate that 789 contains the same Subject name as a legitimate certificate issued by 790 the compromised CA. Alternatively, the bogus certificate may contain 791 a different name but reuse a serial number from a valid, not revoked 792 certificate issued by that CA. 794 An attacker who compromises a log might act in one of two ways. It 795 might use the private key of the log only to generate SCTs for a 796 malicious CA or the evil twin of a compromised CA. If a browser 797 checks the signature on an SCT but does not contact a log to verify 798 that the certificate appears in the log, then this is an effective 799 attack strategy. Alternatively, the attacker might not only generate 800 SCTs, but also pose as the compromised log, at least with regard to 801 requests from targeted users. In the latter case, this "evil twin" 802 log could respond to STH requests from targeted users, making appear 803 that the compromised log was offering a split view (thus acting as a 804 malicious log). To detect this attack an Auditor needs to employ a 805 gossip mechanism that is able to acquire CT data from diverse 806 sources, a feature not yet part of the base CT system. 808 An evil twin CA might submit a bogus certificate to the evil twin of 809 a compromised log. (The same adversary may be controlling both.) 810 The operator of the evil twin log can use the purloined private key 811 to generate SCTs for certificates that have not been logged by its 812 legitimate counterpart. These SCTs will appear valid relative to the 813 public key associated with the legitimate log. However, an STH 814 issued by the legitimate log will not correspond to a tree 815 (maintained by the compromised log) containing these SCTs. Thus 816 checking the SCTs issued by the evil twin log against STHs from the 817 compromised log will identify this discrepancy. As noted above, if 818 an attacker uses the key to generate log entries and respond to log 819 queries, the effect is analogous to a malicious log.) 821 An Auditor checking for log consistency and with access to bogus 822 SCTs, might conclude that the compromised log is acting maliciously, 823 and is presenting a split view to its clients. In this fashion the 824 compromised log may be shunned and forced to shut down. However, if 825 an attacker targets a set of TLS clients that do not have access to 826 the legitimate log, they may not be able to detect this 827 inconsistency. In this case CT would need to rely on a distributed 828 gossiping audit mechanism to detect the compromise (see Section 5.6). 830 3.4. Attacks Based on Exploiting Multiple Certificate Chains 832 Section 3.2 examined attacks in which a malicious CA issued a bogus 833 certificate and either tried to prevent the Subject from detecting 834 the bogus certificate, or reported the bogus certificate as valid, to 835 at least some relying parties, even if the Subject requested 836 revocation. These attacks are limited in that if the bogus 837 certificate is not submitted to a log, then it may not be accepted by 838 CT-aware browsers, and submitting the bogus certificate to a log 839 increases the chances that the CA's malicious behavior will be 840 detected. 842 In general, if a CA is discovered to be acting maliciously, its 843 certificates will no longer be accepted, either because its parent 844 will revoke its CA certificate, its CA certificate will be added to 845 browsers' blacklists, or both. However, a malicious CA may be able 846 to obtain an SCT for each bogus certificate that it issues and 847 continue to have those certificates accepted by relying parties even 848 after its malicious behavior has been detected. It can do this by 849 creating more than one path validation chain for the certificates, as 850 shown in Figure 2. 852 +-----------------+ +-----------------+ 853 | CA A | | CA B | 854 +-----------------+ +-----------------+ 855 \ / 856 \ / 857 CA certificate 1 \ / CA certificate 2 858 \ / 859 +----------------+ 860 | malicious CA | 861 +----------------+ 862 | 863 | bogus EE certificate 864 | 865 +------------------+ 866 | targeted Subject | 867 +------------------+ 869 Figure 2: Multiple Certificate Chains for a Bogus Certificate 871 In Figure 2, the malicious CA has been issued CA certificates by two 872 different parent CAs. The parent CAs may be two different trust 873 anchors, or one or both of them may be an intermediate CA (i.e., it 874 is subordinate to some trust anchor). If both parent CAs are 875 intermediate CAs, they may be subordinate to the same trust anchor or 876 to different trust anchors. The malicious CA may have obtained 877 certificates from the two parents by applying to them for the 878 certificates, or by compromising the parent CAs and creating the 879 certificates without the knowledge of the CAs. If the malicious CA 880 applied for its certificates from these CAs, it may have presented 881 false information as input to the CA's normal issuance procedures, 882 with the result that the CAs do not realize that a certificate with 883 the same subject name and public key has been issued by another CA. 885 Because there are two certificate path validation chains, the 886 malicious CA could provide the chain that includes CA A when 887 submitting a bogus certificate to one or more logs, but an attacker 888 (colluding with the malicious CA) could provide the chain that 889 includes CA B to targeted browsers. If the CA's malicious behavior 890 is detected, then CA A and browser vendors may be alerted (e.g., via 891 the CT Monitor function) and revoke/blacklist CA certificate 1. 892 However, CA certificate 2 does not appear in any logs, and CA A is 893 unaware that CA B has issued a certificate to the malicious CA. Thus 894 those who detected the malicious behavior may not discover the second 895 chain and so may not alert CA B or browser vendors of the need to 896 revoke/blacklist CA certificate 2. In this case, targeted browsers 897 would continue to accept the bogus certificates issued by the 898 malicious CA, since the certificate chain they are provided is valid 899 and because the SCT issued for the bogus certificate it the same 900 irrespective of which certificate chain is presented. 902 This sort of attack might be thwarted if all intermediate (i.e., CA) 903 certificates had to be logged. In that case CA certificate 2 might 904 be rejected by CT-aware browsers. 906 This type of attack also might be thwarted if a browser vendor 907 blacklists a malicious CA using the CA's public key (not by its 908 serial number and the name of the parent CA or by a hash of the 909 certificate). This approach to revocation would cause CA certificate 910 2 to be rejected as well as CA certificate 1. However none of these 911 mechanisms are part of the CT specification 912 [I-D.ietf-trans-rfc6962-bis] nor general IETF PKI standards (e.g., 913 [RFC5280]). 915 3.5. Attacks Related to Distribution of Revocation Status 917 A bogus certificate that has been revoked may still appear valid to a 918 browser under certain circumstances. In part this is because the 919 revocation information seen by a relying party is partly under the 920 control of the CA and/or the certificate subject. As a result, 921 different relying parties may be presented with different revocation 922 information. This is true irrespective of whether revocation is 923 effected via use of a CRL or OCSP. Additionally, an attacker can 924 steer a browser to specific revocation status data via various means, 925 preventing a targeted browser from acquiring accurate revocation 926 status information for a bogus certificate. 928 The bogus certificate might contain an AIA extension pointing to an 929 OCSP server controlled by the malicious CA (or the attacker). As 930 noted in Section 3.2.1.1.1, the malicious CA could send a "good" OCSP 931 response to a targeted browser instance, even if other parties are 932 provided with a "revoked" response. A TLS server can supply an OCSP 933 response to a browser as part of the TLS handshake [RFC6961], if 934 requested by the browser. A TLS server posing as the entity named in 935 the bogus certificate also could acquire a "good" OCSP response from 936 the malicious CA to effect the attack. Only if the browser relies 937 upon a trusted, third-party OCSP responder, one not part of the 938 collusion, would these OCSP-based attacks fail. 940 The bogus certificate could contain a CRL distribution point 941 extension instead of an AIA extension. In that case a site supplying 942 CRLs for the malicious CA could supply different CRLs to different 943 requestors, in an attempt to hide the revocation status of the bogus 944 certificate from targeted browser instances. This is analogous to a 945 split-view attack effected by a CT log. However, as noted in 946 Section 3.2.1.1 and 3.2.1.1.1, no element of CT is responsible for 947 detecting inconsistent reporting of certificate revocation status 948 data. (Monitoring in the CT context tracks log entries made by CAs 949 or Subjects. Auditing is designed to detect misbehavior by logs, not 950 by CAs per se.) 952 The failure of a bogus certificate to be detected as revoked (by a 953 browser) is not the fault of CT. In the class of attacks described 954 above, CT achieves its goal of detecting the bogus certificate when 955 that certificate is logged and a Monitor observes the log entry. 956 Detection is intended to trigger revocation, to effect remediation, 957 the details of which are outside the scope of CT. However the SCT 958 mechanism is intended to assure a relying party that certificate has 959 been logged, is susceptible to being detected as bogus by a Monitor, 960 and presumably will be revoked if detected as such. In the context 961 of these attacks, because of the way revocation may be implemented, 962 the assurance provided by the SCT may not have the anticipated 963 effect. 965 4. Syntactic mis-issuance 967 4.1. Non-malicious Web PKI CA context 969 This section analyzes the scenario in which the CA has no intent to 970 issue a syntactically incorrect certificate, but it may do so in 971 error. (Remember that errors are considered form of attack in this 972 document, see Section 2). As noted in Section 1, we refer to a 973 syntactically incorrect certificate as erroneous. A certificate is 974 erroneous if it violates a criteria to which the issuing CA claims to 975 adhere. This might be a general profile such as [RFC5280], or a 976 narrower profile such as those established by the CABF [1] for domain 977 validated (DV) or extended validation (EV) certificates. If the 978 Subject is a web site that expected to receive an EV certificate, but 979 the certificate issued to it carries the DV policy OID, or no policy 980 OID, relying parties may reject the certificate, causing harm to the 981 business of the Subject. Conversely, if a CA issues a certificate to 982 a web site and erroneously includes the EV policy OID, relying 983 parties may place more trust in the certificate than is warranted. 985 4.1.1. Certificate logged 987 4.1.1.1. Benign log 989 If a (pre )certificate is submitted to a benign log, syntactic mis- 990 issuance can (optionally) be detected, and noted. This will happen 991 only if the log performs syntactic checks in general, and if the log 992 is capable of performing the checks applicable to the submitted (pre 993 )certificate. (A (pre )certificate should be logged even if it fails 994 syntactic validation; logging takes precedence over detection of 995 syntactic mis-issuance.) If syntactic validation fails, this can be 996 noted in an SCT extension returned to the submitter. 998 If the (pre )certificate is submitted by the non-malicious issuing 999 CA, then the CA should remedy the syntactic problem and re-submit the 1000 (pre )certificate to a log or logs. If this is a pre-certificate 1001 submitted prior to issuance, syntactic checking by a log could help a 1002 CA detect and avoid issuance of an erroneous certificate. If the CA 1003 does not have a record of the certificate contents, then presumably 1004 it was a bogus certificate and the CA should revoke it. 1006 If a certificate is submitted by its Subject, and is deemed 1007 erroneous, then the Subject should contact the issuing CA and request 1008 a new certificate. If the Subject is a legitimate subscriber of the 1009 CA, then the CA will either have a record of the certificate content 1010 or can obtain a copy of the certificate from the Subject. The CA 1011 will remedy the syntactic problem and either re-submit a corrected 1012 (pre-)certificate to a log and send it to the Subject or the Subject 1013 will re-submit it to a log. Here too syntactic checking by a log 1014 enables a Subject to be informed that its certificate is erroneous 1015 and thus may hasten issuance of a replacement certificate. 1017 If a certificate is submitted by a third party, that party might 1018 contact the Subject or the issuing CA, but because the party is not 1019 the Subject of the certificate it is not clear how the CA will 1020 respond. 1022 This analysis suggests that syntactic mis-issuance of a certificate 1023 can be avoided by a CA if it makes use of logs that are capable of 1024 performing these checks for the types of certificates that are 1025 submitted, and if the CA acts on the feedback it receives. If a CA 1026 uses a log that does not perform such checks, or if the CA requests 1027 checking relative to criteria not supported by the log, then 1028 syntactic mis-issuance will not be detected or avoided by this 1029 mechanism. Similarly, syntactic mis-issuance can be remedied if a 1030 Subject submits a certificate to a log that performs syntactic 1031 checks, and if the Subject asks the issuing CA to fix problems 1032 detected by the log. (The issuer is presumed to be willing to re- 1033 issue the certificate, correcting any problems, because the issuing 1034 CA is not malicious.) 1036 4.1.1.2. Misbehaving log or third party Monitor 1038 A log or Monitor that is conspiring with the attacker or is 1039 independently malicious, will either not perform syntactic checks, 1040 even though it claims to do so, or simply not report errors. The log 1041 entry and the SCT for an erroneous certificate will assert that the 1042 certificate syntax was verified. 1044 As with detection of semantic mis-issuance, a distributed Audit 1045 mechanism could, in principle, detect misbehavior by logs or Monitors 1046 with respect to syntactic checking. For example, if for a given 1047 certificate, some logs (or Monitors) are reporting syntactic errors 1048 and some that claim to do syntactic checking, are not reporting these 1049 errors, this is indicative of misbehavior by these logs and/or 1050 Monitors. 1052 Note that a malicious log (or Monitor) could report syntactic errors 1053 for a syntactically valid certificate. This could result in 1054 reporting of non-existent syntactic problems to the issuing CA, which 1055 might cause the CA to do needless investigative work or perhaps 1056 incorrectly revoke and re-issue the Subject's certificate. 1058 4.1.2. Certificate not logged 1060 If a CA does not submit a certificate to a log, there can be no 1061 syntactic checking by the log. Detection of syntactic errors will 1062 depend on a Subject performing the requisite checks when it receives 1063 its certificate from a CA. A Monitor that performs syntactic checks 1064 on behalf of a Subject also could detect such problems, but the CT 1065 architecture does not require Monitors to perform such checks. 1067 4.1.2.1. Self-monitoring Subject 1069 A Subject performing self-monitoring will be able to detect the lack 1070 of an embedded SCT in the certificate it received from the CA, or the 1071 lack of an SCT supplied to the Subject via an out-of-band channel. A 1072 Subject ought to notify the CA if the Subject expected that its 1073 certificate was to be logged. (A Subject would expect its 1074 certificate to be logged if there is an agreement between the Subject 1075 and the CA to do so, or because the CA advertises that it logs all of 1076 the certificates that it issues.) If the certificate was supposed to 1077 be logged, but was not, the CA can use the certificate supplied by 1078 the Subject to investigate and remedy the problem. In the context of 1079 a benign CA, a failure to log the certificate might be the result of 1080 an operations error, or evidence of an attack on the CA. 1082 4.1.3. Situations Independent of Certificate Logging 1084 4.1.3.1. Self-monitoring Subject and Benign third party Monitor 1086 If a Subject or benign third party Monitor performs syntactic checks, 1087 it will detect the erroneous certificate and the issuing CA will be 1088 notified (by the Subject). If the Subject is a legitimate subscriber 1089 of the CA, then the CA will either have a record of the certificate 1090 content or can obtain a copy of the certificate from the Subject. 1091 The CA SHOULD revoke the erroneous certificate (after investigation) 1092 and remedy the syntactic problem. The CA SHOULD either re-submit the 1093 corrected (pre )certificate to one or more logs and then send the 1094 result to the Subject, or send the corrected certificate to the 1095 Subject, who will re-submit it to one or more logs. 1097 4.1.3.2. CT-enabled browser 1099 If a browser rejects an erroneous certificate and notifies the 1100 Subject and/or the issuing CA, then syntactic mis-issuance will be 1101 detected (see Section 5.) Unfortunately, experience suggests that 1102 many browsers do not always perform very good syntactic checks on 1103 certificates. For example, a browser may fail to verify that a 1104 certificate used in a certificate path is properly marked as a CA 1105 certificate. Also, it would be problematic for a browser to check a 1106 certificate against a specific version of a profile if the profile 1107 changes and the policy OID remains constant. Thus it seems unlikely 1108 that browsers will be a reliable way to detect erroneous certificates 1109 in all circumstances. Moreover, a protocol used by a browser to 1110 notify a Subject and/or CA of an erroneous certificate represents a 1111 DoS potential, and thus may not be appropriate. Additionally, if a 1112 browser directly contacts a CA when an erroneous certificate is 1113 detected, this is a potential privacy violation, i.e., the CA learns 1114 that the browser user is visiting the web site in question. These 1115 observations argue for syntactic checking to be performed by other 1116 elements of the CT system, e.g., logs and/or Monitors. 1118 4.2. Malicious Web PKI CA context 1120 This section analyzes the scenario in which the CA's issuance of a 1121 syntactically incorrect certificate is intentional, not due to error. 1122 The CA is not the victim but the attacker. 1124 Note that irrespective of whether syntactic checks are performed by a 1125 log, a malicious CA can acquire an embedded SCT, or post-issuance 1126 will acquire a standalone SCT for an erroneous certificate. If 1127 Subjects or Monitors perform syntactic checks that detect the 1128 syntactic mis-issuance and report the problem to the CA, a malicious 1129 CA may do nothing or may delay the action(s) needed to remedy the 1130 problem. 1132 4.2.1. Certificate logged 1134 4.2.1.1. Benign log 1136 Because the CA is presumed to be malicious, the CA might cause the 1137 log to not perform checks (if it had chosen to do so), in one of 1138 several ways. 1140 1. The CA may assert that the certificate is being issued w/o regard 1141 to any guidelines (the "no guidelines" reserved CCID). 1143 2. The CA may assert a CCID that has not been registered, and thus 1144 no log will be able to perform a check. 1146 3. The CA may check to see which CCIDs a log declares it can check, 1147 and chose a registered CCID that is not checked by the log in 1148 question. 1150 4. The CA may submit a (pre-) certificate to a log that is known to 1151 not perform any syntactic checks, and thus avoid syntactic 1152 checking. 1154 4.2.1.2. Misbehaving log or third party Monitor 1156 A misbehaving log or third party Monitor will either not perform 1157 syntactic checks or not report any problems that it discovers. (See 1158 4.1.1.2 for further problems). Also, as noted above, the CT 1159 architecture includes no explicit provisions for detecting a 1160 misbehaving third-party Monitor. 1162 4.2.1.3. CT-enabled browser 1164 As noted above (4.1.3.2), most browsers fail to perform thorough 1165 syntax checks on certificates. Such browsers might benefit from 1166 having syntax checks performed by a log and reported in the SCT, 1167 although the pervasive nature of syntactically-defective certificates 1168 may limit the utility of such checks. (Remember, in this scenario, 1169 the log is benign.) However, if a browser does not discriminate 1170 against certificates that do not contain SCTs (or that are not 1171 accompanied by an SCT in the TLS handshake), only minimal benefits 1172 might accrue to the browser from syntax checks perform by logs or 1173 Monitors. 1175 If a browser accepts certificates that do not appear to have been 1176 syntactically checked by a log (as indicated by the SCT), a malicious 1177 CA need not worry about failing a log-based check. Similarly, if 1178 there is no requirement for a browser to reject a certificate that 1179 was logged by an operator that does not perform syntactic checks, the 1180 fourth attack noted in 4.2.1.1 will succeed as well. If a browser 1181 were configured to know which versions of certificate types are 1182 applicable to its use of a certificate, the second and third attack 1183 strategies noted above could be thwarted. 1185 4.2.2. Certificate is not logged 1187 Since certificates are not logged in this scenario, a third-party 1188 Monitor cannot detect the issuance of an erroneous certificate based 1189 on examination of log entries. However, if a Subject informs a 1190 Monitor of the syntactic criteria applicable to the certificate it is 1191 supplying, the Monitor can perform syntactic checks on behalf of the 1192 Subject. Thus there is no difference between a benign or a 1193 malicious/conspiring log or a benign or conspiring/malicious Monitor. 1194 (Also note that a Subject MAY detect a syntax error by examining the 1195 certificate returned to it by the Issuer.) However, even if errors 1196 are detected and reported to the CA, a malicious/conspiring CA may do 1197 nothing to fix the problem or may delay action. 1199 5. Issues Applicable to Sections 3 and 4 1201 5.1. How does a Subject know which Monitor(s) to use? 1203 If a CA submits a bogus certificate to one or more logs, but these 1204 logs are not tracked by a Monitor that is protecting the targeted 1205 Subject, CT will not remedy this type of mis-issuance attack. If 1206 third-party Monitors advertise which logs they track, Subjects may be 1207 able to use this information to select an appropriate Monitor (or set 1208 thereof). Also, it is not clear whether every third-party Monitor 1209 must offer to track every Subject that requests protection. If a 1210 Subject acts as its own Monitor, this problem is solved for that 1211 Subject. 1213 5.2. How does a Monitor discover new logs? 1215 It is not clear how a (self-)Monitor becomes aware of all (relevant) 1216 logs, including newly created logs. The means by which Monitors 1217 become aware of new logs must accommodate self-monitoring by a 1218 potentially very large number of web site operators. If there are 1219 many logs, it may not be feasible for a (self-) Monitor to track all 1220 of them, or to determine what set of logs suffice to ensure an 1221 adequate level of coverage. 1223 5.3. CA response to report of a bogus or erroneous certificate 1225 A CA being presented with evidence of a bogus or erroneous 1226 certificate, supported by a log entry and/or SCT, will need to 1227 examine its records to determine if it has knowledge of the 1228 certificate in question. It also will likely require the targeted 1229 Subject to provide assurances that it is the authorized entity 1230 representing the Subject name (subjectAltname) in question. Thus a 1231 Subject should not expect immediate revocation of a contested 1232 certificate. The time frame in which a CA will respond to a 1233 revocation request usually is described in the CPS for the CA. Other 1234 certificate fields and extensions may be of interest for forensic 1235 purposes, but are not required to effect. The SCT and log entry, 1236 because each contains a timestamp from a third party, is probably 1237 valuable for forensic purposes (assuming a non-conspiring log 1238 operator). 1240 5.4. Browser behavior 1242 If a browser is to reject a certificate that lacks an embedded SCT, 1243 or is not accompanied by an SCT transported via the TLS handshake, 1244 this behavior needs to be defined in a way that is compatible with 1245 incremental deployment. [I-D.ietf-trans-rfc6962-bis] does not 1246 describe a strategy for incremental deployment, however it calls for 1247 local policy controls that might be used to facilitate incremental 1248 deployment (see 3.2.2.1 earlier). For example a browser might 1249 establish a date after which all certificates issued MUST contain an 1250 SCT or be accompanied by an SCT during TLS session establishment. A 1251 strategy like this would allow certificates issued before that date 1252 to be "grandfathered". This approach would allow a malicious CA to 1253 backdate a certificate to avoid logging it, exploiting a window of 1254 vulnerability. Note that issuing a warning to a (human) user is 1255 probably insufficient, based on experience with warnings displayed 1256 for expired certificates, lack of certificate revocation status 1257 information, and similar errors that violate RFC 5280 path validation 1258 rules [RFC5280]. 1260 5.5. Remediation for a malicious CA 1262 A targeted Subject might ask the parent of a malicious CA to revoke 1263 the certificate of the non-cooperative CA. However, a request of 1264 this sort may be rejected, e.g., because of the potential for 1265 significant collateral damage. A browser might be configured to 1266 reject all certificates issued by the malicious CA, e.g., using a 1267 bad-CA-list distributed by a browser vendor. However, if the 1268 malicious CA has a sufficient number of legitimate clients, treating 1269 all of their certificates as bogus or erroneous still represents 1270 serious collateral damage. If this specification were to require 1271 that a browser can be configured to reject a specific, bogus or 1272 erroneous certificate identified by a Monitor, then the bogus or 1273 erroneous certificate could be rejected in that fashion. This 1274 remediation strategy calls for communication between Monitors and 1275 browsers, or between Monitors and browser vendors. Such 1276 communication has not been specified, i.e., there are no standard 1277 ways to configure a browser to reject individual bogus or erroneous 1278 certificates based on information provided by an external entity such 1279 as a Monitor. Moreover, the same or another malicious CA could issue 1280 new bogus or erroneous certificates for the targeted Subject, which 1281 would have to be detected and rejected in this (as yet unspecified) 1282 fashion. Thus, for now, CT does not seem to provide a way to 1283 facilitate remediation of this form of attack, even though it 1284 provides a basis for detecting such attacks. 1286 5.6. Auditing - detecting misbehaving logs 1288 The combination of a malicious CA and one or more conspiring logs 1289 motivates the definition of an audit function, to detect conspiring 1290 logs. If a Monitor protecting a Subject does not see bogus 1291 certificates, it cannot alert the Subject. If one or more SCTs are 1292 present in a certificate, or passed via the TLS handshake, a browser 1293 has no way to know that the logged certificate is not visible to 1294 Monitors. Only if Monitors and browsers reject certificates that 1295 contain SCTs from conspiring logs (based on information from an 1296 auditor) will CT be able to detect and deter use of such logs. Thus 1297 the means by which a Monitor performing an audit function detects 1298 such logs, and informs browsers must be specified for CT to be 1299 effective in the context of misbehaving logs. 1301 Absent a well-defined mechanism that enables Monitors to verify that 1302 data from logs are reported in a consistent fashion, CT cannot claim 1303 to provide protection against logs that are malicious or may conspire 1304 with, or are victims of, attackers effecting certificate mis- 1305 issuance. The mechanism needs to protect the privacy of users with 1306 respect to which web sites they visit. It needs to scale to 1307 accommodate a potentially large number of self-monitoring Subjects 1308 and a vast number of browsers, if browsers are part of the mechanism. 1309 Even when an Audit mechanism is defined, it will be necessary to 1310 describe how the CT system will deal with a misbehaving or 1311 compromised log. For example, will there be a mechanism to alert all 1312 browsers to reject SCTs issued by such a log? Absent a description 1313 of a remediation strategy to deal with misbehaving or compromised 1314 logs, CT cannot ensure detection of mis-issuance in a wide range of 1315 scenarios. 1317 Monitors play a critical role in detecting semantic certificate mis- 1318 issuance, for Subjects that have requested monitoring of their 1319 certificates. A monitor (including a Subject performing self- 1320 monitoring) examines logs for certificates associated with one or 1321 more Subjects that are being "protected". A third-party Monitor must 1322 obtain a list of valid certificates for the Subject being monitored, 1323 in a secure manner, to use as a reference. It also must be able to 1324 identify and track a potentially large number of logs on behalf of 1325 its Subjects. This may be a daunting task for Subjects that elect to 1326 perform self-monitoring. 1328 Note: A Monitor should not rely on a CA or RA database for its 1329 reference information or use certificate discovery protocols; this 1330 information should be acquired by the Monitor based on reference 1331 certificates provided by a Subject. If a Monitor were to rely on a 1332 CA or RA database (for the CA that issued a targeted certificate), 1333 the Monitor would not detect mis-issuance due to malfeasance on the 1334 part of that CA or the RA, or due to compromise of the CA or the RA. 1335 If a CA or RA database is used, it would support detection of mis- 1336 issuance by an unauthorized CA. 1338 As noted above, Monitors represent another target for adversaries who 1339 wish to effect certificate mis-issuance. If a Monitor is compromised 1340 by, or conspires with, an attacker, it will fail to alert a Subject 1341 to a bogus or erroneous certificate targeting that Subject, as noted 1342 above. It is suggested that a Subject request certificate monitoring 1343 from multiple sources to guard against such failures. Operation of a 1344 Monitor by a Subject, on its own behalf, avoids dependence on third 1345 party Monitors. However, the burden of Monitor operation may be 1346 viewed as too great for many web sites, and thus this mode of 1347 operation ought not be assumed to be universal when evaluating 1348 protection against Monitor compromise. 1350 6. Security Considerations 1352 An attack and threat model is, by definition, a security-centric 1353 document. Unlike a protocol description, a threat model does not 1354 create security problems nor does it purport to address security 1355 problems. This model postulates a set of threats (i.e., motivated, 1356 capable adversaries) and examines classes of attacks that these 1357 threats are capable of effecting, based on the motivations ascribed 1358 to the threats. It then analyses the ways in which the CT 1359 architecture addresses these attacks. 1361 7. IANA Considerations 1363 None. 1365 8. Acknowledgments 1367 The author would like to thank David Mandelberg and Karen Seo for 1368 their assistance in reviewing and preparing this document, and other 1369 members of the TRANS working group for reviewing it. Most of the 1370 text of Section 3.4 was provided by David Cooper, motivated by 1371 observations from Daniel Kahn Gilmor. Thanks also go to Daiming Li 1372 for her editorial assistance. 1374 9. References 1376 9.1. Normative References 1378 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1379 Requirement Levels", BCP 14, RFC 2119, 1380 DOI 10.17487/RFC2119, March 1997, 1381 . 1383 9.2. Informative References 1385 [I-D.ietf-trans-gossip] 1386 Nordberg, L., Gillmor, D., and T. Ritter, "Gossiping in 1387 CT", draft-ietf-trans-gossip-05 (work in progress), 1388 January 2018. 1390 [I-D.ietf-trans-rfc6962-bis] 1391 Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 1392 Stradling, "Certificate Transparency Version 2.0", draft- 1393 ietf-trans-rfc6962-bis-28 (work in progress), March 2018. 1395 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1396 Housley, R., and W. Polk, "Internet X.509 Public Key 1397 Infrastructure Certificate and Certificate Revocation List 1398 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 1399 . 1401 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 1402 Extensions: Extension Definitions", RFC 6066, 1403 DOI 10.17487/RFC6066, January 2011, 1404 . 1406 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 1407 Galperin, S., and C. Adams, "X.509 Internet Public Key 1408 Infrastructure Online Certificate Status Protocol - OCSP", 1409 RFC 6960, DOI 10.17487/RFC6960, June 2013, 1410 . 1412 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) 1413 Multiple Certificate Status Request Extension", RFC 6961, 1414 DOI 10.17487/RFC6961, June 2013, 1415 . 1417 9.3. URIs 1419 [1] https://cabforum.org 1421 [2] https://en.wikipedia.org/wiki/DigiNotar 1423 Author's Address 1425 Stephen Kent 1426 Independent 1428 Email: kent@alum.mit.edu