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