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