idnits 2.17.1 draft-laurie-pki-sunlight-02.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 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RFC5280], [RFC5878]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 281: '...e submission, the log MUST immediately...' RFC 2119 keyword, line 285: '... MUST present an SCT from one or mor...' RFC 2119 keyword, line 286: '...ficate. Clients MUST reject certifica...' RFC 2119 keyword, line 292: '...he log. The log MUST incorporate a ce...' RFC 2119 keyword, line 302: '... certificate MUST be accompanied by ...' (29 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 18, 2012) is 4205 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) -- Missing reference section? 'RFC5878' on line 632 looks like a reference -- Missing reference section? 'RFC5280' on line 635 looks like a reference -- Missing reference section? '1' on line 643 looks like a reference -- Missing reference section? '7' on line 269 looks like a reference -- Missing reference section? 'TBD' on line 308 looks like a reference -- Missing reference section? 'RFC6066' on line 640 looks like a reference -- Missing reference section? '32' on line 522 looks like a reference -- Missing reference section? 'RFC5246' on line 629 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group B. Laurie 3 Internet-Draft A. Langley 4 Expires: April 21, 2013 E. Kasper 5 October 18, 2012 7 Certificate Transparency 8 draft-laurie-pki-sunlight-02 10 Abstract 12 The aim of Certificate Transparency is to have every public end- 13 entity and intermediate TLS certificate issued by a known Certificate 14 Authority recorded in one or more certificate logs. In order to 15 detect mis-issuance of certificates, all logs are publicly auditable. 16 In particular, domain owners or their agents will be able to monitor 17 logs for certificates issued on their own domain. 19 To protect clients from unlogged mis-issued certificates, logs sign 20 all recorded certificates, and clients can choose not to trust 21 certificates that are not accompanied by an appropriate log 22 signature. For privacy and performance reasons log signatures are 23 embedded in the TLS handshake via the TLS authorization extension 24 [RFC5878], or in the certificate itself via an X.509v3 certificate 25 extension [RFC5280]. 27 To ensure a globally consistent view of the log, logs also provide a 28 global signature over the entire log. Any inconsistency of logs can 29 be detected through cross-checks on the global signature. 30 Consistency between any pair of global signatures, corresponding to 31 snapshots of the log at different times, can be efficiently shown. 33 Logs are only expected to certify that they have seen a certificate, 34 and thus we do not specify any revocation mechanism for log 35 signatures in this document. Logs are append-only, and log 36 signatures will be valid indefinitely. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF). Note that other groups may also distribute 45 working documents as Internet-Drafts. The list of current Internet- 46 Drafts is at http://datatracker.ietf.org/drafts/current/. 48 Internet-Drafts are draft documents valid for a maximum of six months 49 and may be updated, replaced, or obsoleted by other documents at any 50 time. It is inappropriate to use Internet-Drafts as reference 51 material or to cite them other than as "work in progress." 53 This Internet-Draft will expire on April 21, 2013. 55 Copyright Notice 57 Copyright (c) 2012 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Cryptographic components . . . . . . . . . . . . . . . . . . . 4 73 1.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 4 74 1.1.1. Merkle audit paths . . . . . . . . . . . . . . . . . . 4 75 1.1.2. Merkle consistency proofs . . . . . . . . . . . . . . 5 76 1.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 6 77 2. Log Format . . . . . . . . . . . . . . . . . . . . . . . . . . 8 78 2.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 8 79 2.2. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 11 80 2.3. Audit Proofs . . . . . . . . . . . . . . . . . . . . . . . 13 81 3. Client Messages . . . . . . . . . . . . . . . . . . . . . . . 15 82 4. Security and Privacy Considerations . . . . . . . . . . . . . 16 83 4.1. Misissued Certificates . . . . . . . . . . . . . . . . . . 16 84 4.2. Detection of Misissue . . . . . . . . . . . . . . . . . . 16 85 4.3. Misbehaving logs . . . . . . . . . . . . . . . . . . . . . 16 86 5. Efficiency Considerations . . . . . . . . . . . . . . . . . . 17 87 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 90 1. Cryptographic components 92 1.1. Merkle Hash Trees 94 Logs use a binary Merkle hash tree for efficient auditing. The 95 hashing algorithm is SHA-256. The input to the Merkle tree hash is a 96 list of data entries; these entries will be hashed to form the leaves 97 of the Merkle hash tree. The output is a single 32-byte root hash. 98 Given an ordered list of n inputs, D[n] = {d(0), d(1), ..., d(n-1)}, 99 the Merkle Tree Hash (MTH) is thus defined as follows: 101 The hash of an empty list is the hash of an empty string: 103 MTH({}) = SHA-256(). 105 The hash of a list with one entry is: 107 MTH({d(0)}) = SHA-256(0 || d(0)). 109 For n > 1, let k be the largest power of two smaller than n. The 110 Merkle Tree Hash of an n-element list D[n] is then defined 111 recursively as 113 MTH(D[n]) = SHA-256(1 || MTH(D[0:k]) || MTH(D[k:n])), 115 where || is concatenation and D[k1:k2] denotes the length (k2 - k1) 116 list {d(k1), d(k1+1),..., d(k2-1)}. 118 Note that we do not require the length of the input list to be a 119 power of two. The resulting Merkle tree may thus not be balanced, 120 however, its shape is uniquely determined by the number of leaves. 121 [This Merkle tree is essentially the same as the history tree [1] 122 proposal, except our definition omits dummy leaves.] 124 1.1.1. Merkle audit paths 126 A Merkle audit path for a leaf in a Merkle hash tree is the shortest 127 list of additional nodes in the Merkle tree required to compute the 128 Merkle Tree Hash for that tree. Each node in the tree is either a 129 leaf node, or is computed from the two nodes immediately below it 130 (i.e. towards the leaves). At each step up the tree (towards the 131 root), a node from the audit path is combined with the node computed 132 so far. In other words, the audit path consists of the list of 133 missing nodes required to compute the nodes leading from a leaf to 134 the root of the tree. If the root computed from the audit path 135 matches the true root, then the audit path is proof that the leaf 136 exists in the tree. 138 Given an ordered list of n inputs to the tree, D[n] = {d(0), ..., 139 d(n-1)}, the Merkle audit path PATH(m, D[n]) for the (m+1)th input 140 d(m), 0 <= m < n, is defined as follows: 142 The path for the single leaf in a tree with a one-element input list 143 D[1] = {d(0)} is empty: 145 PATH(0, {d(0)}) = {} 147 For n > 1, let k be the largest power of two smaller than n. The 148 path for the (m+1)th element d(m) in a list of n > m elements is then 149 defined recursively as 151 PATH(m, D[n]) = PATH(m, D[0:k]) : MTH(D[k:n]) for m < k; and 153 PATH(m, D[n]) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m >= k, 155 where : is concatenation of lists and D[k1:k2] denotes the length (k2 156 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before. 158 1.1.2. Merkle consistency proofs 160 Merkle consistency proofs prove the append-only property of the tree. 161 A Merkle consistency proof for a Merkle Tree Hash MTH(D[n]) and a 162 previously advertised hash MTH(D[0:m]) of the first m leaves, m <= n, 163 is the list of nodes in the Merkle tree required to verify that the 164 first m inputs D[0:m] are equal in both trees. Thus, a consistency 165 proof must contain a set of intermediate nodes (i.e., commitments to 166 inputs) sufficient to verify MTH(D[n]), such that (a subset of) the 167 same nodes can be used to verify MTH(D[0:m]). We define an algorithm 168 that outputs the (unique) minimal consistency proof. 170 Given an ordered list of n inputs to the tree, D[n] = {d(0), ..., 171 d(n-1)}, the Merkle consistency proof PROOF(m, D[n]) for a previous 172 root hash MTH(D[0:m]), 0 < m < n, is defined as PROOF(m, D[n]) = 173 SUBPROOF(m, D[n], true): 175 The subproof for m = n is empty if m is the value for which PROOF was 176 originally requested (meaning that the subtree root hash MTH(D[0:m]) 177 is known): 179 SUBPROOF(m, D[m], true) = {} 181 The subproof for m = n is the root hash committing inputs D[0:m] 182 otherwise: 184 SUBPROOF(m, D[m], false) = {MTH(D[m])} 185 For m < n, let k be the largest power of two smaller than n. The 186 subproof is then defined recursively. 188 If m <= k, the right subtree entries D[k:n] only exist in the current 189 tree. We prove that the left subtree entries D[0:k] are consistent 190 and add a commitment to D[k:n]: 192 SUBPROOF(m, D[n], b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n]). 194 If m > k, the left subtree entries D[0:k] are identical in both 195 trees. We prove that the right subtree entries D[k:n] are consistent 196 and add a commitment to D[0:k]. 198 SUBPROOF(m, D[n], b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k]). 200 Here : is concatenation of lists and D[k1:k2] denotes the length (k2 201 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before. 203 The number of nodes in the resulting proof is bounded above by 204 ceil(log2(n)) + 1. 206 1.1.3. Example 208 The binary Merkle tree with 7 leaves: 210 hash 211 / \ 212 / \ 213 / \ 214 / \ 215 / \ 216 k l 217 / \ / \ 218 / \ / \ 219 / \ / \ 220 g h i j 221 / \ / \ / \ | 222 a b c d e f d6 223 | | | | | | 224 d0 d1 d2 d3 d4 d5 226 The audit path for d0 is [b, h, l]. 228 The audit path for d3 is [c, g, l]. 230 The audit path for d4 is [f, j, k]. 232 The audit path for d6 is [i, k]. 234 The same tree, built incrementally in four steps: 236 hash0 hash1=k 237 / \ / \ 238 / \ / \ 239 / \ / \ 240 g c g h 241 / \ | / \ / \ 242 a b d2 a b c d 243 | | | | | | 244 d0 d1 d0 d1 d2 d3 246 hash2 hash 247 / \ / \ 248 / \ / \ 249 / \ / \ 250 / \ / \ 251 / \ / \ 252 k i k l 253 / \ / \ / \ / \ 254 / \ e f / \ / \ 255 / \ | | / \ / \ 256 g h d4 d5 g h i j 257 / \ / \ / \ / \ / \ | 258 a b c d a b c d e f d6 259 | | | | | | | | | | 260 d0 d1 d2 d3 d0 d1 d2 d3 d4 d5 262 The consistency proof between hash0 and hash is PROOF(3, D[7]) = [c, 263 d, g, l]. c, g are used to verify hash0, and d, l are additionally 264 used to show hash is consistent with hash0. 266 The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l]. 267 hash can be verified, using hash1=k and l. 269 The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i, 270 j, k]. k, i are used to verify hash1, and j is additionally used to 271 show hash is consistent with hash2. 273 2. Log Format 275 Anyone can submit certificates to certificate logs for public 276 auditing, however, since certificates will not be accepted by clients 277 unless logged, it is expected that certificate owners or their CAs 278 will usually submit them. A log is a single, ever-growing, append- 279 only Merkle Tree of such certificates. 281 After accepting a certificate submission, the log MUST immediately 282 return a Signed Certificate Timestamp (SCT). The SCT is the log's 283 promise to incorporate the certificate in the Merkle Tree within a 284 fixed amount of time known as the Maximum Merge Delay (MMD). Servers 285 MUST present an SCT from one or more logs to the client together with 286 the certificate. Clients MUST reject certificates that do not have a 287 valid Signed Certificate Timestamp. 289 Periodically, the log appends all new entries to the Merkle Tree, and 290 signs the root of the tree. Clients and auditors can thus verify 291 that each certificate for which an SCT has been issued indeed appears 292 in the log. The log MUST incorporate a certificate in its Merkle 293 Tree within the Maximum Merge Delay period after the issuance of the 294 SCT. 296 2.1. Log Entries 298 Anyone can submit a certificate to the log. In order to attribute 299 each logged certificate to its issuer, the log shall publish a list 300 of acceptable root certificates (this list should be the union of 301 root certificates trusted by major browser vendors). Each submitted 302 certificate MUST be accompanied by all additional certificates 303 required to verify the certificate chain up to an accepted root 304 certificate. The self-signed root certificate itself MAY be omitted 305 from this list. 307 In this case, the SCT must be included in the TLS handshake, either 308 by using an Authorization Extension [RFC5878] with type [TBD] 309 containing the SCT, or by using OCSP Stapling (section 8 of 310 [RFC6066]), where the response includes an OCSP extension [RFC5280] 311 with OID 1.3.6.1.4.1.11129.2.4.5 and body: 313 SignedCertificateTimestamp ::= OCTET STRING 315 Alternatively, (root as well as intermediate) Certificate Authorities 316 may submit a certificate to the log prior to issuance. To do so, a 317 Certificate Authority constructs a Precertificate by signing the leaf 318 TBSCertificate [RFC5280] with a special-purpose (Extended Key Usage: 319 Certificate Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate 320 Signing Certificate. The Precertificate Signing Certificate MUST be 321 certified by the CA certificate. As above, the Precertificate 322 submission MUST be accompanied by the Precertificate Signing 323 Certificate and all additional certificates required to verify the 324 chain up to an accepted root certificate. The signature on the 325 TBSCertificate indicates the Certificate Authority's intent to issue 326 a certificate. This intent is considered binding (i.e., misissuance 327 of the Precertificate is considered equal to misissuance of the final 328 certificate). The log verifies the Precertificate signature chain, 329 and issues a Signed Certificate Timestamp on the corresponding 330 TBSCertificate. The SCT can then be directly embedded in the final 331 certificate, by inserting it in the TBSCertificate as an X.509v3 332 certificate extension (OID 1.3.6.1.4.1.11129.2.4.2). Upon receiving 333 the certificate, clients can reconstruct the original TBSCertificate 334 to verify the SCT signature. 336 The log MUST verify that the submitted leaf certificate or 337 Precertificate has a valid signature chain leading back to a trusted 338 root CA certificate, using the chain of intermediate CA certificates 339 provided by the submitter. In case of Precertificates, the log MUST 340 also verify that the Precertificate Signing Certificate has the 341 correct Extended Key Usage extension. The log MAY accept 342 certificates that have expired, are not yet valid, have been revoked 343 or are otherwise not fully valid according to X.509 verification 344 rules. However, the log MUST refuse to publish certificates without 345 a valid chain to a known root CA. If a certificate is accepted and 346 an SCT issued, the log MUST store the chain used for verification 347 including the certificate or Precertificate itself, and MUST present 348 this chain for auditing upon request. 350 Each certificate entry in the log MUST include the following 351 components: 353 enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType; 355 struct { 356 LogEntryType entry_type; 357 select (entry_type) { 358 case x509_entry: X509ChainEntry; 359 case precert_entry: PrecertChainEntry; 360 } entry; 361 } LogEntry; 363 opaque ASN.1Cert<1..2^24-1>; 365 struct { 366 ASN.1Cert leaf_certificate; 367 ASN.1Cert certificate_chain<0..2^24-1>; 368 } X509ChainEntry; 370 struct { 371 ASN.1Cert tbs_certificate; 372 ASN.1Cert precertificate_chain<1..2^24-1>; 373 } PrecertChainEntry; 375 Logs MAY limit the length of chain they will accept. 377 "leaf_certificate" is the end-entity certificate submitted for 378 auditing. 380 "certificate_chain" is a chain of additional certificates required to 381 verify the leaf certificate. The first certificate MUST certify the 382 leaf certificate. Each following certificate MUST directly certify 383 the one preceding it. The self-signed root certificate MAY be 384 omitted from the chain. 386 "tbs_certificate" is the TBSCertificate component of the 387 Precertificate (i.e., the original TBSCertificate, without the 388 Precertificate signature and the SCT extension). 390 "precertificate_chain" is a chain of certificates required to verify 391 the Precertificate submission. The first certificate MUST be the 392 original Precertificate, with its unsigned part matching the 393 "tbs_certificate". The second certificate MUST be a valid 394 Precertificate Signing Certificate, and MUST certify the first 395 certificate. Each following certificate MUST directly certify the 396 one preceding it. The self-signed root certificate MAY be omitted 397 from the chain. 399 Structure of the Signed Certificate Timestamp: 401 enum { certificate_timestamp(0), tree_hash(1), 255 } 402 SignatureType; 404 enum { v1(0) } 405 Version; 407 struct { 408 opaque key_id[32]; 409 } LogID; 411 "key_id" is the SHA-256 hash of the log's public key [TODO: define 412 how to calculate this]. 414 struct { 415 Version version; 416 LogID id; 417 uint64 timestamp; 418 digitally-signed struct { 419 SignatureType signature_type = certificate_timestamp; 420 uint64 timestamp; 421 LogEntryType entry_type; 422 select(entry_type) { 423 case x509_entry: ASN.1Cert; 424 case precert_entry: ASN.1Cert; 425 } signed_entry; 426 }; 427 } SignedCertificateTimestamp; 429 The encoding of the digitally-signed element is defined in [RFC5246]. 431 "version" is the version of the protocol the SCT conforms to. This 432 version is v1. 434 "timestamp" is the current UTC time since epoch (January 1, 1970, 435 00:00), in milliseconds. 437 "signed_entry" is the "leaf_certificate" (in case of an 438 X509ChainEntry), or "tbs_certificate" (in case of a 439 PrecertChainEntry). 441 2.2. Merkle Tree 443 A certificate log MUST periodically append all new log entries to the 444 log Merkle Tree. The log MUST sign these entries by constructing a 445 binary Merkle Tree with log entries as consecutive inputs to the 446 tree, signing the corresponding Merkle Tree Hash, and publishing each 447 update to the tree in a Signed Merkle Tree Update. The hashing 448 algorithm for the Merkle Tree Hash is SHA-256. 450 Structure of the Merkle Tree input: 452 struct { 453 uint64 timestamp; 454 LogEntryType entry_type; 455 select(entry_type) { 456 case x509_entry: ASN.1Cert; 457 case precert_entry: ASN.1Cert; 458 } signed_entry; 459 } MerkleTreeLeaf; 461 Here "timestamp" is the timestamp of the corresponding SCT issued for 462 this certificate. 464 "signed_entry" is the "signed_entry" of the corresponding SCT. 466 Structure of the Signed Merkle Tree Update: 468 struct { 469 Version version; 470 LogID id; 471 uint64 old_tree_size; 472 uint64 timestamp; 473 MerkleTreeLeaf new_leaves<0..2^64-1>; 474 digitally-signed struct { 475 SignatureType signature_type = tree_hash; 476 uint64 timestamp; 477 uint64 tree_size; 478 opaque sha256_root_hash[32]; 479 } TreeHeadSignature; 480 } SignedMerkleTreeUpdate; 482 "version" is the version of the protocol the SignedMerkleTreeUpdate 483 conforms to. 485 "old_tree_size" is the size of the tree prior to this update. 487 "timestamp" is the current time. The timestamp MUST be at least as 488 recent as the most recent SCT timestamp in the tree. Each subsequent 489 timestamp MUST be more recent than the timestamp of the previous 490 update. 492 "tree_size" equals the number of entries in the new tree. 494 "new_leaves" is the list of leaves added to the tree in this update, 495 ordered by leaf index. This order can be fixed arbitrarily amongst 496 new entries. 498 "sha256_root_hash" is the root of the Merkle Hash Tree. 500 The log MUST produce a Signed Merkle Tree Update at least as often as 501 the Maximum Merge Delay. In the unlikely event that it receives no 502 new submissions during an MMD period, the log SHALL sign the same 503 Merkle Tree Hash with a fresh timestamp. 505 2.3. Audit Proofs 507 It is possible to audit the entire log by computing the current 508 "sha256_root_hash" value from consecutive Signed Merkle Tree Updates, 509 and verifying the Tree Head Signature. We rely on cross-checks of 510 the Signed Tree Head between auditors to verify that their views of 511 the log are consistent. 513 Additionally, logs provide Merkle audit proofs for efficient partial 514 checks. (In fact, anyone can compute audit proofs from the full 515 log.) Merkle audit proofs allow auditors to efficiently verify that 516 a certificate for which an SCT has been issued indeed appears in the 517 log, without inspecting the entire log. 519 Structure of the Merkle audit proof: 521 struct { 522 opaque sha256_hash[32]; 523 } MerkleNode; 525 struct { 526 Version version; 527 LogID id; 528 uint64 tree_size; 529 uint64 timestamp; 530 uint64 leaf_index; 531 MerkleNode audit_path<0..2^16-1>; 532 TreeHeadSignature tree_head_signature; 533 } MerkleAuditProof; 535 "tree_size" is the generation of the tree that this proof is for. 537 "timestamp" is the corresponding timestamp. 539 "leaf_index" is the index of the audited node in the Merkle tree, 540 from 0 to "tree_size - 1". 542 "audit_path" is a list of additional nodes in the Merkle tree 543 required for reconstructing the root hash corresponding to the 544 "tree_size". Nodes must be listed from leaf to root level, i.e., in 545 the order they are used in the Merkle Tree Hash computation, as 546 defined in Section 1.1.1. _Notice that the left-right ordering is 547 determined by the position of the leaf._ The leaf node under audit as 548 well as the root node shall be omitted from the path. 550 "tree_head_signature" is the TreeHeadSignature for generation 551 "tree_size". 553 A valid audit proof for a Merkle Tree Leaf MUST satisfy the 554 following: 556 o The "tree_size" MUST be at least 1; 558 o The "leaf_index" MUST NOT exceed "tree_size - 1"; 560 o The "tree_signature" MUST be a valid signature on the 561 corresponding "timestamp", "tree_size", and the root hash 562 reconstructed from the Merkle Tree Leaf, "leaf_index" and 563 "audit_path". 565 3. Client Messages 567 TBD. Messages that clients send to logs, e.g. to request an SCT or 568 retrieve entries in the log. 570 4. Security and Privacy Considerations 572 4.1. Misissued Certificates 574 Misissued certificates that have not been publicly logged, and thus 575 do not have a valid SCT, will be rejected by clients. Misissued 576 certificates that do have an SCT from a log will appear in the public 577 log within the Maximum Merge Delay, assuming the log is operating 578 correctly. Thus, the maximum period of time during which a misissued 579 certificate can be used without being available for audit is the MMD. 581 4.2. Detection of Misissue 583 The log does not itself detect misissued certificate, it relies 584 instead on interested parties, such as domain owners, to monitor it 585 and take corrective action when a misissue is detected. 587 4.3. Misbehaving logs 589 A log can misbehave in two ways: (1), by failing to incorporate a 590 certificate with an SCT in the Merkle Tree within the MMD; and (2), 591 by violating its append-only property by presenting two different, 592 conflicting views of the Merkle Tree at different times and/or to 593 different parties. Both forms of violation will be promptly and 594 publicly detectable. 596 Violation of the MMD contract is detected by clients requesting a 597 Merkle audit proof for each observed SCT. These checks can be 598 asynchronous, and need only be done once per each certificate. In 599 order to protect the clients' privacy, these checks need not reveal 600 the exact certificate to the log. Clients can instead request the 601 proof from a trusted auditor (since anyone can compute the audit 602 proofs from the log), or request Merkle proofs for a batch of 603 certificates around the SCT timestamp. 605 Violation of the append-only property is detected by global 606 gossiping, i.e., everyone auditing the log comparing their versions 607 of the latest signed tree head. As soon as two conflicting signed 608 tree heads are detected, this is cryptographic proof of the log's 609 misbehaviour. 611 5. Efficiency Considerations 613 The Merkle tree design serves the purpose of keeping communication 614 overhead low. 616 Auditing the log for integrity does not require third parties to 617 maintain a copy of the entire log. The Signed Tree Head root hash 618 can be updated incrementally as new entries become available, without 619 recomputing the entire tree. Third party auditors need only store a 620 logarithmic number of intermediate nodes in the Merkle Tree. 622 Additionally, the Merkle consistency proofs defined in Section 1.1.2 623 can be used to efficiently prove the append-only property of an 624 incremental update to the Merkle Tree, without auditing the entire 625 tree. 627 6. References 629 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 630 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 632 [RFC5878] Brown, M. and R. Housley, "The Transport Layer Security 633 (TLS) Authorization Extensions", RFC 5280, May 2010. 635 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 636 Housley, R., and W. Polk, "Internet X.509 Public Key 637 Infrastructure Certificate and Certificate Revocation List 638 (CRL) Profile", RFC 5280, May 2008. 640 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 641 Extension Definitions", RFC 6066, January 2011. 643 [1] 645 Authors' Addresses 647 Ben Laurie 649 Email: benl@google.com 651 Adam Langley 653 Email: agl@google.com 655 Emilia Kasper 657 Email: ekasper@google.com