idnits 2.17.1 draft-kent-trans-architecture-04.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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 18 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 5, 2016) is 2818 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 366 -- Looks like a reference, but probably isn't: '2' on line 368 -- Looks like a reference, but probably isn't: '3' on line 343 == Missing Reference: 'RFC5280' is mentioned on line 418, but not defined == Missing Reference: 'TLS-Server' is mentioned on line 442, but not defined == Unused Reference: 'RFC5246' is defined on line 659, but no explicit reference was found in the text == Unused Reference: 'RFC6066' is defined on line 662, but no explicit reference was found in the text == Unused Reference: 'RFC6960' is defined on line 665, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'Merkle' == Outdated reference: A later version (-42) exists of draft-ietf-trans-rfc6962-bis-10 ** Downref: Normative reference to an Experimental draft: draft-ietf-trans-rfc6962-bis (ref. '6962-bis') ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6961 (Obsoleted by RFC 8446) == Outdated reference: A later version (-05) exists of draft-ietf-trans-gossip-01 Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Public Notary Transparency S. Kent 2 Internet Draft D. Mandelberg 3 Intended status: Standards Track K. Seo 4 Expires: July 2016 BBN Technologies 5 August 5, 2016 7 Certificate Transparency (CT) System Architecture 8 draft-kent-trans-architecture-04.txt 10 Abstract 12 This document describes the architecture for Certificate Transparency 13 (CT) focusing on the Web PKI context. It defines the goals of CT and 14 the elements that comprise the CT system. It also describes the major 15 features of these elements. Other documents, cited in the References, 16 establish requirements for these CT system elements and describe 17 their operation in greater detail. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html 40 This Internet-Draft will expire on July 30, 2016. 42 Copyright Notice 44 Copyright (c) 2016 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. 54 Table of Contents 56 1. Introduction...................................................2 57 1.1. Requirements Language.....................................5 58 2. Beneficiaries of CT............................................6 59 3. The Elements of the CT Architecture............................7 60 3.1. Logs.....................................................10 61 3.2. CT-aware Certification Authorities (CAs).................11 62 3.3. Monitors.................................................12 63 3.4. CT-aware Subjects (TLS web servers)......................13 64 3.5. CT-aware TLS clients (web browsers)......................14 65 3.6. Auditors.................................................15 66 4. Security Considerations.......................................15 67 5. IANA Considerations...........................................16 68 6. References....................................................16 69 6.1. Normative References.....................................16 70 6.2. Informative References...................................17 71 7. Acknowledgments...............................................17 73 1. Introduction 75 Certificate transparency (CT) is a set of mechanisms designed to 76 deter, detect, and facilitate remediation of certificate mis-issuance 77 (as defined below). CT deters mis-issuance by encouraging CAs to 78 publish the certificates that they issue in a set of publically- 79 accessible logs. Each log uses a Merkle tree design to ensure that it 80 is an append-only database, and the log entries are digitally signed 81 by the log operator. Monitoring of logs detects mis-issuance. 82 Remediation of mis-issuance is effected via certificate revocation. 84 In the context of CT, the term mis-issuance refers to violations of 85 either semantic or syntactic constraints associated with certificates 86 [draft-trans-threat-analysis]. The fundamental semantic constraint 87 for a (Web PKI) certificate is that it was issued to an entity that 88 is authorized to represent the Subject name in the certificate. If 89 any Subject Alternative Names (SANs) are present in the certificate, 90 the entity also must be authorized to represent them. (It is also 91 assumed that the entity requested the certificate from the CA that 92 issued it.) Throughout the remainder of this document we refer to a 93 semantically mis-issued certificate as "bogus." 95 A certificate is characterized as syntactically mis-issued if it 96 violates syntax constraints associated with the class of certificates 97 that it purports to represent. Syntax constraints for certificates 98 are established by certificate profiles, and typically are 99 application-specific. For example, certificates used in the Web PKI 100 environment might be characterized as domain validation (DV) or 101 extended validation (EV) certificates. Certificates issued for use 102 by applications such as IPsec or S/MIME have different syntactic 103 constraints from those issued in the Web PKI context. Throughout the 104 remainder of this document we refer to a syntactically mis-issued 105 certificate as "erroneous." From a security perspective, erroneous 106 certificates are not perceived as being as significant a concern as 107 bogus certificates. 109 As noted above, CT deters mis-issuance by encouraging CAs to log the 110 certificates that they issue. A CT log is a publicly auditable, 111 append-only, database of issued certificates [6962-bis] based on a 112 binary Merkle hash tree [Merkle]. Each CT log operates in a fashion 113 that enables external entities (Auditors) to detect inconsistent 114 behavior. As a result, logs need not be operated by trusted (third) 115 parties. Some forms of log misbehavior require comparing information 116 gleaned from multiple sources, e.g., using mechanisms such as the 117 ones described in [Gossip]. If an Auditor detects misbehavior by the 118 log, it will notify Monitors (described below) and Browser Vendors 119 that it serves. In turn, the Monitors and Browser Vendors are 120 expected to cease relying onlogs that repeatedlymisbehave in a 121 fashion indicative of malice. (Ultimately, what constitutes malicious 122 misbehavior will be determined by Monitors and Browser Vendors, and 123 thus is outside the scope of this document.) 125 A bogus certificate that has been logged will be detected by an 126 entity (a Monitor) that observes the log and that has knowledge of 127 all legitimate certificates issued to the set of certificate Subjects 128 that it serves. If a Monitor detects a log entry for a certificate 129 that is inconsistent with the reference data for a Subject, the 130 Monitor notifies the Subject. (A Subject may perform self- 131 monitoring.) Thus Monitors implement the mis-issuance detection 132 aspect of CT. 134 CAs are presumed to be deterred from logging mis-issued certificates, 135 because of the implied reputational consequences. (The assumption is 136 that a CA that is detected repeatedly mis-issuing certificates will, 137 in time, be blacklisted by the Browser Vendors (who control the set 138 of CAs that are accepted by Browsers). 140 Revocation of a bogus/erroneous certificate is the primary means of 141 remedying mis-issuance. A browser vendor may distribute a "blacklist" 142 of mis-issued certificates or a bad-CA-list of certificates of CAs 143 that have mis-issued certificates. Browsers may then use such lists 144 to reject certificates on the blacklist, or certificates issued by 145 CAs whose certificates are on the bad-CA-list. This form of 146 revocation, although not codified in IETF standards, is also a means 147 of remediation for mis-issuance. Throughout the remainder of this 148 document, references to certificate revocation as a remedy encompass 149 these and analogous forms of revocation. 151 Figure 1 provides a top-level view of these elements of CT and their 152 interactions. 154 +-----+ +----+ 155 | Log |<--->| CA |<********************** 156 | | +----+ * 157 | | ^ * 158 | | * +++++++++++++++++++ * ++++++ 159 | | v v * + 160 | | +---------+ * + 161 | |<--->| Subject |<************* * + 162 | | +---------+ * * + 163 | | ^ ^ ^ * * + 164 | | * + ****** * * + 165 | | v v * * * + 166 | | +---------+ * * * + 167 | |<--->| Browser | * * * + 168 | | +---------+ * * * + 169 | | ^ ^ * * * + 170 | | * ++++ * ++++++++ * + * +++ + 171 | | v v * * + + 172 | | +----------------+ * * + + 173 | |<***>| Browser Vendor |<*** * * + + 174 | | +----------------+ * * * + + 175 | | v v v + + 176 | | +---------+ + + 177 | |<---------------------->| Monitor | + + 178 | | +---------+ + + 179 | | ^ ^ + + 180 | | + * +++++ + 181 | | v v v + 182 | | +---------+ + 183 | |<---------------------->| Auditor |<+++++ 184 +-----+ +---------+ 186 Legend: 187 <---> Interface defined by CT 188 <***> Interface out of scope for CT 189 <+++> Proposed in Experimental Gossip Design 191 Figure 1 Elements of the CT Architecture 193 1.1. Requirements Language 195 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 196 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 197 document are to be interpreted as described in RFC 2119 [RFC2119]. 199 2. Beneficiaries of CT 201 There are three classes of beneficiaries of CT: certificate Subjects, 202 TLS Clients, and Certification Authorities (CAs). In the initial 203 context of CT, the Web PKI, Subjects are web sites and TLS Clients 204 are Browsers employing HTTPS to access these web sites. CAs are the 205 issuers of certificates used in the Web PKI context. 207 A certificate Subject benefits from CT because CT enables Monitors to 208 detect certificates that have been mis-issued in the name of that 209 Subject. A Subject learns of a bogus/erroneous certificate (issued in 210 its name), via a Monitor, as noted above. (The Monitor function may 211 be provided by the Subject itself, i.e., self-monitoring, or by a 212 third party trusted by the Subject.) When a Subject is informed of 213 certificate mis-issuance by a Monitor, the Subject is expected to 214 request/demand revocation of the bogus/erroneous certificate by the 215 issuing CA and/or by the browser vendors (if the CA refuses to revoke 216 the certificate). 218 A Subject also may benefit from the Monitor element of CT even if the 219 Subject's legitimate certificate(s) has(have) not been logged. If the 220 bogus/erroneous certificate is logged and if a Monitor has been 221 provided with reference data from the Subject, then monitoring of 222 logs for certificates issued in the Subject's name suffices to detect 223 an instance of mis-issuance targeting the Subject. (If a CA operates 224 a Monitor on behalf of its Subjects, then the CA has the requisite 225 information to detect bogus/erroneous certificates in logs that it 226 observes.) 228 A TLS client (Browser) benefits from CT if the TLS client rejects a 229 mis-issued certificate, i.e., treats the certificate as invalid. A 230 TLS client is protected from accepting a mis-issued certificate if 231 that certificate is revoked, and if the TLS client checks the 232 revocation status of the certificate. (A TLS client also is protected 233 if a browser vendor "blacklists" a certificate or a CA as noted 234 above.) A TLS client also may benefit from CT if the client validates 235 a Signed Certificate Timestamp (SCT) [6962-bis] associated with a 236 certificate, and rejects the certificate if the SCT is invalid. 238 CAs are also CT beneficiaries. If one CA issues a legitimate 239 certificate to a Subject, and another CA issues a bogus certificate, 240 the second certificate can be detected by a Monitor (if the bogus 241 certificate has been logged). In this fashion the CA that issued the 242 legitimate certificate benefits, since the bogus certificate is 243 detected and, presumably revoked. Even the CA that issued the bogus 244 certificate is a potential beneficiary. If the bogus certificate was 245 issued as a result of an error or an (undetected) attack, CT can help 246 the CA become aware of the error or attack and act accordingly. This 247 is presumed to be beneficial to the reputation of this CA. 249 3. The Elements of the CT Architecture 251 There are six elements of the CT architecture: logs, CAs, Monitors, 252 Subjects, TLS clients (especially browsers and browser vendors), and 253 Auditors. CAs, Subjects, and TLS clients are pre-existing elements 254 affected by CT if they choose to participate. Because not all CAs, 255 Subjects, and TLS clients may choose to participate in CT, these 256 elements are qualified as "CT-aware" to distinguish them from 257 existing instances of these types of Web PKI elements. Logs, 258 Monitors, and Auditors are new elements introduced by CT and thus 259 they are intrinsically CT "aware". Figure 2 shows how all of these 260 elements interact with the central CT element, the log. Figure 3 261 shows how the pre-existing elements interact with one another under 262 CT. Figure 4 shows the interactions of monitors and auditors that are 263 not covered by Figure 2. 265 +-----+ +---------------+ 266 | Log |<- add-chain or add-pre-chain -----| CA or Subject | 267 | |-- SCT for the new entry --------->| | 268 | |<- get-proof-by-hash --------------| | 269 | |-- inclusion proof for the entry ->| | 270 | | +---------------+ 271 | | +---------+ 272 | |<- get-sth [1] ------| Monitor | 273 | |-- current STH ----->| | 274 | |<- get-entries [1] --| | 275 | |-- log entries ----->| | 276 | | +---------+ 277 | | +---------+ 278 | |<- get-proof-by-hash [2] --| Browser | 279 | |-- inclusion proof [2] --->| | 280 | | +---------+ 281 | | +----------------+ 282 | |<- get log metadata --| Browser Vendor | 283 | |-- log metadata ----->| | 284 | | +----------------+ 285 | | +-----------------+ 286 | | | Auditor | 287 | | |+---------------+| 288 | |<- get-sth [1] --------------|| MMD checking || 289 | |-- current STH ------------->|| || 290 | |<- get-entries [1] ----------|| || 291 | |-- log entries ------------->|| || 292 | | |+---------------+| 293 | |<- get-sth ------------------|| STH frequency || 294 | |-- current STH ------------->|| checking || 295 | | |+---------------+| 296 | |<- get-sth [1] --------------|| Append-only || 297 | |-- current STH ------------->|| checking || 298 | |<- get-entries [1] ----------|| || 299 | |-- log entries ------------->|| || 300 | |<- get-sth-consistency [3] --|| || 301 | |-- consistency proof ------->|| || 302 +-----+ |+---------------+| 303 +-----------------+ 305 [1] The get-sth operation is performed periodically, and get-entries 306 is performed each time a new STH is available. 307 [2] See Section 3.5 for privacy and performance caveats. 308 [3] If the Auditor stores copies of all Log entries, then this 309 operation is not needed. 311 Figure 2 Interactions with a Log 313 +---------+ +---------+ 314 | Browser |-- log metadata[1] ------------------------->| Browser | 315 | Vendor |-- revocation information[1] --------------->| | 316 | | | | 317 | | +---------+ | | 318 | | / request \--| Subject | | | 319 | | | to | | | | | 320 | | | blacklist | | | | | 321 | | | a CA or | | | | | 322 | |<-\ EE cert / | | | | 323 +---------+ | | | | 324 | | | | 325 +----+ | | | | 326 | CA | / certificate \-----| | | | 327 | |<-\ request / | | | | 328 | |-- certificate[2] ->| | | | 329 | | | | | | 330 | | / request \---| | | | 331 | | | revocation of | | | | | 332 | |<-\ a certificate / | | | | 333 +----+ | | | | 334 | | / TLS \---| | 335 | |<-\ connection / | | 336 | |-- certificate ->| | 337 | |-- SCT[3] ------>| | 338 | |<- HTTPS ------->| | 339 +---------+ +---------+ 341 [1] Not subject to standardization. 342 [2] Optionally including SCTs in an extension. 343 [3] Optional, via an OCSP response or in a TLS extension. 345 Figure 3 Interfaces of Pre-existing Elements 347 +---------+ +---------+ 348 | Monitor |<- establish a business relationship [1] ->| Subject | 349 | |<- list of protected subject names --------| | 350 | | / per protected subject name, a \---------| | 351 | |<-\ list of acceptable public keys / | | 352 | | +---------+ 353 | | 354 | | +----+ 355 | |-- notification of mis-issuance --+-->| CA | 356 | | | +----+ 357 | | | 358 | | | +----------------+ 359 | | +-->| Browser Vendor | 360 | | +----------------+ 361 | | 362 | | +---------+ 363 | |<- notification of log mis-behavior [2] --| Auditor | 364 +---------+ +---------+ 366 [1] In the case of a self-monitor, the business relationship is 367 trivial - the Subject and Monitor are the same organization. 368 [2] An entity performing the Monitor function MAY also choose to 369 implement some of the Auditor functions. In that case the 370 Monitor/Auditor interface is trivial. If the Auditor is separate, we 371 note that there is no interface defined at the time of this writing. 373 Figure 4 Monitor and Auditor Interfaces 375 3.1. Logs 377 Logs are the central elements of the CT architecture. Logging of 378 certificates enables Monitors to detect mis-issuance and, 379 subsequently, to trigger Subjects to issue revocation requests to CAs 380 and/or browser vendors and to notify CAs and browser vendors 381 directly. Logging also deters mis-issuance, as noted above. The 382 interfaces to a log are defined in [6962-bis], as are the details of 383 how a log operates. 385 Briefly, a certificate chain (that must be verifiable under a trust 386 anchor acceptable to the log) is submitted to a log by a CA, Subject 387 or other party. The log creates an entry for the terminal certificate 388 in the chain, and returns this Signed Certificate Timestamp (SCT) to 389 the submitter. The SCT can be conveyed to a browser in one of three 390 ways: it can be incorporated into a certificate by the CA that issues 391 it, as described later. (A CA also may submit a so-called "pre- 392 certificate" to a log, to acquire an SCT for inclusion in the 393 certificate, prior to signing the certificate.) It also can be 394 conveyed explicitly in the TLS handshake or in OSCP data generated by 395 a CA. The SCT is a token that can be verified by browsers to 396 establish, to first order, that a certificate has been logged. See 397 [6962-bis] for additional details of SCTs. 399 All clients that interact with a log require access to metadata 400 associated with each log upon which they rely. This metadata includes 401 the URL and public key for the log, the list of trust anchors 402 accepted by the log, the hash and signature algorithms employed, etc. 403 Log metadata is made available to log clients via out of band means 404 that are generally outside the scope of the CT specifications. In the 405 Web PKI context, CT assumes that browser vendors will make the 406 necessary log metadata available to browsers via the same mechanisms 407 used to convey trust anchor (and vendor-managed revocation data). Log 408 metadata provided via this channel is not mutable by log operators 409 (since it is part of browser configuration data), with one exception. 410 When a log ceases operation, it publishes its final STH, enabling 411 clients to verify previous log entries and to detect any 412 (unauthorized) additions to the log. See [6962-bis] for additional 413 details. 415 An open question is how other log clients receive the metadata they 416 require to interact with the log in a predictable fashion. For 417 example, a log may elect to check the syntax of certificates relative 418 to [RFC5280], or it may skip some of all of the checks specified 419 there. Absent a way to determine what checks a log will perform on 420 submitted certificates, a CA (or other submitter) has no way to know 421 whether a submitted certificate will be accepted by a given log. 422 Similarly, a Monitor needs to acquire log metadata so that the 423 Monitor can locate the log and verify the signatures on log entries. 425 3.2. CT-aware Certification Authorities (CAs) 427 A (CT-aware) CA interacts with a log to submit a certificate (or a 428 pre-certificate) to create a log entry. (Most logged certificates are 429 expected to be end-entity certificates, each associated with the web 430 site that it represents. However, it also is possible to log a CA 431 certificate under certain circumstances. See Section 3.2.3 of [6962- 432 bis].) The pre-certificate capability is offered to facilitate rapid 433 deployment of CT. It has the advantage that web sites need not make 434 any software changes to acquire one or more SCTs, because the SCTs 435 are embedded in the certificate itself. There is, however, a downside 436 of embedding SCTs in certificates. If a log that provided an SCT is 437 compromised or otherwise becomes unacceptable to browsers and 438 Monitors, the certificate associated with that SCT will have to be 439 re-issued with a replacement SCT. Thus, in the long term, other 440 options for conveying an SCT, i.e., via the TLS handshake or in an 441 OCSP response (perhaps "stapled" into the handshake [RFC6961]), are 442 preferred [TLS-Server]. 444 A CA also may submit a "name-redacted" pre-certificate to a log. A 445 name-redacted pre-certificate includes one or more "?" labels in lieu 446 of DNS name components. See Section 4.2 of [6962-bis] for more 447 details. Name-redaction is a feature of CT designed to enable an 448 organization to request a CA to log its certificates without 449 revealing all of the DNS name components in the certificate that will 450 be matched to the log entry. This is an attractive feature for 451 organizations that want to benefit from CT without revealing internal 452 server names as a side effect of logging. An end-entity certificate 453 that is to be treated as logged via this mechanism contains a 454 critical (X.509v3) extension that indicates which labels have been 455 redacted in the log entry. This extension is needed to enable TLS 456 clients and Monitors to match a received certificate against the 457 corresponding log entry in an unambiguous fashion. See Section 458 of [CA-Subject] for more details. 460 The CT architecture does not mandate a specific number of SCTs that 461 should be associated with a certificate. Browser vendors might 462 establish requirements for the minimum number of associated SCTs in 463 different contexts, but such requirements are outside the scope of 464 the CT architecture. 466 [CA-Subject] describes the requirements imposed on CT-enabled CAs. 468 3.3. Monitors 470 The primary role of a Monitor is to observe a set of logs, looking 471 for log entries of interest. A Subject may act as a self-monitor, or 472 may make use of the services of a third-party Monitor, as noted 473 earlier. 475 In the self-monitoring context, log entries of interest are ones that 476 contain a Subject or Subject Alternative Name (SAN) associated with 477 the Subject's web site(s). (Name-constrained CA certificates and 478 wildcard certificates also have to be examined to detect certificates 479 that would match the end-entity certificates associated with a 480 Subject's web sites.) Whenever a certificate of interest is detected, 481 the Subject compares it with the public key information associated 482 with its certificate(s). If there is a mismatch, this indicates that 483 this logged certificate was mis-issued. The Subject contacts the CA 484 that issued the certificate (using the Issuer name in the 485 certificate) and requests revocation of the mis-issued certificate, 486 to resolve the problem. (The means by which a Subject determines how 487 to contact a CA based on the issuer name is outside the scope of the 488 CT architecture.) The means by which a Subject determines which set 489 of logs to watch also is outside the scope of the CT architecture. It 490 is anticipated that there will be a small number of logs that are 491 widely used, and that the metadata for these logs will be available 492 from browser vendors. 494 A third-party Monitor watches for certificates of interest to its 495 clients. Each client of a third party Monitor supplies the Monitor 496 with a list of Subject names and SANs associated with the client's 497 web site(s), and public key information associated with each name. 498 (As a special case, if a CA offers a Monitor service to its clients, 499 then the CA/Monitor already has this information.) The Monitor 500 watches a set of logs looking for entries that match the client 501 certificates of interest. If it detects an apparent mis-issued 502 certificate, the Monitor contacts the client and forwards the log 503 entry, along with log metadata. The client (Subject) then follows the 504 procedure noted above to request revocation of the mis-issued 505 certificate. 507 Note that a Monitor does not try to detect mis-behavior by a log. 508 That is the responsibility of an Auditor. [Monitor-Auditor] defines 509 the requirements for a Monitor (self of third-party) and discusses 510 additional operational details. 512 Note also that CT does not include any mechanisms designed to detect 513 misbehavior by a Monitor. A self-Monitor does not require such 514 mechanisms; Subjects who elect to rely upon third-party Monitors 515 would benefit from such mechanisms. See [Monitor-Auditor] for the 516 requirements imposed on Monitors by CT and for a more detailed 517 description of how a Monitor operates. 519 3.4. CT-aware Subjects (TLS web servers) 521 A (CT-aware) Subject (e.g., a web site operator) can submit its 522 certificate(s) to a log, and acquire an SCT for each certificate it 523 submits (see Section 4.1 of [6962-bis]). There are three reasons why 524 a Subject may choose to log its own certificate(s): (1) its CA did 525 not embed an SCT in the certificate(s) it issued to the Subject, (2) 526 the Subject wants to acquire SCTs from additional logs, or (3) the 527 Subject wants the flexibility offered by conveying SCTs (from logs of 528 its choosing) in the TLS handshake. [CA-Subject] describes the 529 requirements imposed on Subjects for delivery of SCTs to CT-aware TLS 530 clients. 532 Every Subject should either perform self-monitoring, or become a 533 client of a third-party Monitor so that bogus certificates issued in 534 the name of the Subject will be detected. When a Subject is notified 535 of a bogus certificate issued in its name, the Subject contacts the 536 CA that issued the certificate and requests that it be revoked, using 537 whatever mechanisms the CA provides for such requests. The Subject 538 may also contact browser vendors and ask that they put the 539 certificate on a blacklist of mis-issued certificates or put the CA's 540 certificate on a bad-CA-list, if the CA refuses to revoke the bogus 541 certificate. [CA-Subject] describe the requirements established for 542 for CT-aware Subjects. 544 3.5. CT-aware TLS clients (web browsers) 546 As noted in Section 2, a TLS client can benefit from CT even without 547 actively participating. A Monitor will detect a mis-issued, logged 548 certificate and notify the affected Subject. The Subject will, in 549 turn attempt to trigger revocation by the CA that mis-issued the 550 certificate in question, ultimately asking browser vendors to 551 blacklist the certificate (or the CA) if revocation is not effected. 552 Thus a TLS client that processes certificate revocation status data, 553 e.g., CRLs, OCSP responses, will be protected from bogus certificates 554 that have been logged, detected, and revoked. 556 If a TLS client required that every certificate it accepted was 557 accompanied by an SCT, the client could have some confidence that the 558 certificate had been logged. This would increase confidence that the 559 certificate, if it were mis-issued, would have been revoked. However, 560 there are two problems with mandating that every TLS client reject 561 (treat as invalid) any certificate that is not accompanied by an SCT. 562 First, such behavior does not accommodate incremental deployment of 563 CT. Second, the mere presence of an SCT is not a guarantee that the 564 certificate has been logged. 566 To have high confidence that a certificate has been logged, a TLS 567 client would have to verify that a log entry exists for the 568 certificate. This requires acquisition of an inclusion proof from the 569 log (see Section 4.5 of [6962-bis]). Requesting an inclusion proof 570 directly from a log for a certificate discloses to a log that the TLS 571 client is interested in the certificate in question. For a browser, 572 this would disclose which web sites a user was visiting, a potential 573 privacy concern for many users. Also, the data acquisition and 574 processing might pose an unacceptable burden for some TLS clients, 575 (e.g., browsers), and might not be performed in realtime anyway. Thus 576 CT-aware TLS clients are not expected to fetch an inclusion proof in 577 realtime, e.g., during TLS connection establishment. Such clients 578 also are not expected to reject a certificate that has no associated 579 SCT, because there is no plan for incremental deployment of CT that 580 accommodates such rejection in a backwards compatible fashion. 581 Nonetheless, if an SCT is provided with a certificate, a CT-aware TLS 582 client could verify the signature and the SCT data for the 583 certificate in question. If performing these checks would not impose 584 an undue burden on the TLS client, the checks would help detect 585 errors in SCTs and provided feedback to log operators (via Subjects). 587 A TLS client that is a browser might discriminate against a 588 certificate presented for a web site if the certificate is not 589 accompanied by an SCT, e.g., providing an indication of this via the 590 user interface. See [browser-vendor] for the requirements established 591 for CT-aware browsers and browser vendors. 593 3.6. Auditors 595 Auditors perform checks intended to detect mis-behavior by logs. 596 There are four log behavior properties that Auditors check: 598 1. The Maximum Merge Delay (MMD) 600 2. The STH Frequency Count 602 3. The append-only property 604 4. The consistency of the log view presented to all query sources 606 The first three of these checks are easily performed using existing 607 log interfaces and log metadata (see [6962-bis]). For example, an 608 Auditor could submit a certificate to a log and request an STH after 609 the indicated MMD, to verify that the log is achieving its advertised 610 MMD. The last check is more difficult to perform because it requires 611 a way to share log responses among a set of CT elements, perhaps 612 including browsers, web sites, Monitors, and Auditors, e.g., using 613 so-called gossiping [Gossip]. There is as yet no standard for 614 gossiping and thus the last check is NOT part of Auditor requirements 615 at this time. See [Monitor-Auditor] for additional details of Auditor 616 operation. 618 4. Security Considerations 620 CT is a system created to improve security for X.509 public key 621 certificates, especially in the Web PKI context. An attack analysis 622 [draft-trans-threat-analysis] examines the types of attacks that can 623 be mounted against CT, to effect mis-issuance, and how CT addresses 624 (or fails to address) each type of attack. That analysis is based on 625 the architecture described in this document, and thus readers of this 626 document are referred to that one for a thorough discussion of the 627 security aspects of CT. Briefly, CT logs represent a viable means of 628 deterring semantic mis-issuance of certificates. Monitors are an 629 effective way to detect semantic mis-issuance of logged certificates. 630 The CT architecture enables certificate Subjects to request 631 revocation of mis-issued certificates, thus remedying such mis- 632 issuance. Residual vulnerabilities exist with regard to some forms of 633 log and Monitor misbehavior, because the architecture does not 634 include normative means of detecting such behavior. The current 635 design also does not ensure the ability of Monitors to detect 636 syntactic mis-issuance of certificates. This is because provisions 637 for asserting the type of certificate being issued, for inclusion in 638 an SCT, have not been standardized. 640 5. IANA Considerations 642 644 6. References 646 6.1. Normative References 648 [Merkle] Merkle, R. C. (1988). "A Digital Signature Based on a 649 Conventional Encryption Function." Advances in Cryptology - 650 CRYPTO '87. Lecture Notes in Computer Science 293. p. 369 652 [6962-bis] Laurie, B., Langley, A., Kasper, E., Messeri, E., and R. 653 Stradling, "Certificate Transparency," draft-ietf-trans- 654 rfc6962-bis-10 (work in progress), October 2015. 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, March 1997. 659 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 660 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 662 [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) 663 Extensions: Extension Definitions", RFC 6066, January 2011. 665 [RFC6960] Santesson, S., Myers, M., Ankney, R., Malpani, A., 666 Galperin, S., and C. Adams, "X.509 Internet Public Key 667 Infrastructure Online Certificate Status Protocol - OCSP", 668 RFC 6960, June 2013. 670 [RFC6961] Pettersen, Y., "The Transport Layer Security (TLS) Multiple 671 Certificate Status Request Extension," RFC 6961, June 2013. 673 6.2. Informative References 675 [draft-trans-threat-analysis] Kent, S., "Attack Model and Threat for 676 Certificate Transparency," draft-ietf-trans-threat- 677 analysis-03 (work in progress), October 2015. 679 [Gossip] Nordberg, L., Gillmor, D., and Ritter, T., "Gossiping in 680 CT," draft-ietf-trans-gossip-01 (work in progress), October 681 2015. 683 [Monitor-Auditor] 685 [CA-Subject] 687 [browser-vendor] 689 7. Acknowledgments 691 692 Authors' Addresses 694 Stephen Kent 695 BBN Technologies 696 10 Moulton St. 697 Cambridge, MA 02138 698 US 700 Email: kent@bbn.com 702 David Mandelberg 703 unaffiliated 705 Email: david@mandelberg.org 707 Karen Seo 708 BBN Technologies 709 10 Moulton St. 710 Cambridge, MA 02138 711 US 713 Email: kseo@bbn.com