idnits 2.17.1 draft-ietf-trans-rfc6962-bis-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: ---------------------------------------------------------------------------- == Mismatching filename: the document gives the document name as 'draft-ietf-trans-rfc6962-bis-03', but the file name used is 'draft-ietf-trans-rfc6962-bis-04' Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 10, 2014) is 3576 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 603 -- Looks like a reference, but probably isn't: '7' on line 608 -- Looks like a reference, but probably isn't: '0' on line 598 -- Looks like a reference, but probably isn't: '2' on line 600 -- Looks like a reference, but probably isn't: '32' on line 836 -- Obsolete informational reference (is this intentional?): RFC 2560 (Obsoleted by RFC 6960) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 3447 (Obsoleted by RFC 8017) -- Obsolete informational reference (is this intentional?): RFC 4627 (Obsoleted by RFC 7158, RFC 7159) -- Obsolete informational reference (is this intentional?): RFC 5246 (Obsoleted by RFC 8446) -- Obsolete informational reference (is this intentional?): RFC 6125 (Obsoleted by RFC 9525) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Public Notary Transparency Working Group B. Laurie 3 Internet-Draft A. Langley 4 Intended status: Standards Track E. Kasper 5 Expires: January 11, 2015 Google 6 R. Stradling 7 Comodo 8 July 10, 2014 10 Certificate Transparency 11 draft-ietf-trans-rfc6962-bis-03 13 Abstract 15 This document describes a protocol for publicly logging the existence 16 of Transport Layer Security (TLS) certificates as they are issued or 17 observed, in a manner that allows anyone to audit certificate 18 authority (CA) activity and notice the issuance of suspect 19 certificates as well as to audit the certificate logs themselves. 20 The intent is that eventually clients would refuse to honor 21 certificates that do not appear in a log, effectively forcing CAs to 22 add all issued certificates to the logs. 24 Logs are network services that implement the protocol operations for 25 submissions and queries that are defined in this document. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on January 11, 2015. 44 Copyright Notice 46 Copyright (c) 2014 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Informal Introduction . . . . . . . . . . . . . . . . . . . . 3 62 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 63 1.2. Data Structures . . . . . . . . . . . . . . . . . . . . . 4 64 2. Cryptographic Components . . . . . . . . . . . . . . . . . . 4 65 2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 4 66 2.1.1. Merkle Audit Paths . . . . . . . . . . . . . . . . . 5 67 2.1.2. Merkle Consistency Proofs . . . . . . . . . . . . . . 6 68 2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 7 69 2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . 8 70 3. Log Format and Operation . . . . . . . . . . . . . . . . . . 9 71 3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.2. Private Domain Name Labels . . . . . . . . . . . . . . . 12 73 3.2.1. Wildcard Certificates . . . . . . . . . . . . . . . . 12 74 3.2.2. Redacting Domain Name Labels in Precertificates . . . 12 75 3.2.3. Using a Name-Constrained Intermediate CA . . . . . . 13 76 3.3. Structure of the Signed Certificate Timestamp . . . . . . 14 77 3.4. Including the Signed Certificate Timestamp in the TLS 78 Handshake . . . . . . . . . . . . . . . . . . . . . . . . 15 79 3.4.1. TLS Extension . . . . . . . . . . . . . . . . . . . . 17 80 3.5. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 17 81 3.6. Signed Tree Head . . . . . . . . . . . . . . . . . . . . 18 82 4. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 19 83 4.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . 20 84 4.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 21 85 4.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . 21 86 4.4. Retrieve Merkle Consistency Proof between Two Signed Tree 87 Heads . . . . . . . . . . . . . . . . . . . . . . . . . . 21 88 4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash . . . . 22 89 4.6. Retrieve Entries from Log . . . . . . . . . . . . . . . . 22 90 4.7. Retrieve Accepted Root Certificates . . . . . . . . . . . 23 91 4.8. Retrieve Entry+Merkle Audit Proof from Log . . . . . . . 24 92 5. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 5.1. Submitters . . . . . . . . . . . . . . . . . . . . . . . 24 94 5.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . 25 95 5.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 25 96 5.4. Auditor . . . . . . . . . . . . . . . . . . . . . . . . . 26 98 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 99 6.1. TLS Extension Type . . . . . . . . . . . . . . . . . . . 26 100 6.2. Hash Algorithms . . . . . . . . . . . . . . . . . . . . . 26 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 102 7.1. Misissued Certificates . . . . . . . . . . . . . . . . . 27 103 7.2. Detection of Misissue . . . . . . . . . . . . . . . . . . 27 104 7.3. Redaction of Public Domain Name Labels . . . . . . . . . 27 105 7.4. Misbehaving Logs . . . . . . . . . . . . . . . . . . . . 28 106 8. Efficiency Considerations . . . . . . . . . . . . . . . . . . 28 107 9. Future Changes . . . . . . . . . . . . . . . . . . . . . . . 28 108 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 29 109 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 29 110 11.1. Normative Reference . . . . . . . . . . . . . . . . . . 29 111 11.2. Informative References . . . . . . . . . . . . . . . . . 29 113 1. Informal Introduction 115 Certificate transparency aims to mitigate the problem of misissued 116 certificates by providing publicly auditable, append-only, untrusted 117 logs of all issued certificates. The logs are publicly auditable so 118 that it is possible for anyone to verify the correctness of each log 119 and to monitor when new certificates are added to it. The logs do 120 not themselves prevent misissue, but they ensure that interested 121 parties (particularly those named in certificates) can detect such 122 misissuance. Note that this is a general mechanism, but in this 123 document, we only describe its use for public TLS server certificates 124 issued by public certificate authorities (CAs). 126 Each log consists of certificate chains, which can be submitted by 127 anyone. It is expected that public CAs will contribute all their 128 newly issued certificates to one or more logs, however certificate 129 holders can also contribute their own certificate chains, as can 130 third parties. In order to avoid logs being rendered useless by 131 submitting large numbers of spurious certificates, it is required 132 that each chain is rooted in a CA certificate accepted by the log. 133 When a chain is submitted to a log, a signed timestamp is returned, 134 which can later be used to provide evidence to TLS clients that the 135 chain has been submitted. TLS clients can thus require that all 136 certificates they accept as valid have been logged. 138 Those who are concerned about misissue can monitor the logs, asking 139 them regularly for all new entries, and can thus check whether 140 domains they are responsible for have had certificates issued that 141 they did not expect. What they do with this information, 142 particularly when they find that a misissuance has happened, is 143 beyond the scope of this document, but broadly speaking, they can 144 invoke existing business mechanisms for dealing with misissued 145 certificates, such as working with the CA to get the certificate 146 revoked, or with maintainers of trust anchor lists to get the CA 147 removed. Of course, anyone who wants can monitor the logs and, if 148 they believe a certificate is incorrectly issued, take action as they 149 see fit. 151 Similarly, those who have seen signed timestamps from a particular 152 log can later demand a proof of inclusion from that log. If the log 153 is unable to provide this (or, indeed, if the corresponding 154 certificate is absent from monitors' copies of that log), that is 155 evidence of the incorrect operation of the log. The checking 156 operation is asynchronous to allow TLS connections to proceed without 157 delay, despite network connectivity issues and the vagaries of 158 firewalls. 160 The append-only property of each log is technically achieved using 161 Merkle Trees, which can be used to show that any particular instance 162 of the log is a superset of any particular previous instance. 163 Likewise, Merkle Trees avoid the need to blindly trust logs: if a log 164 attempts to show different things to different people, this can be 165 efficiently detected by comparing tree roots and consistency proofs. 166 Similarly, other misbehaviors of any log (e.g., issuing signed 167 timestamps for certificates they then don't log) can be efficiently 168 detected and proved to the world at large. 170 1.1. Requirements Language 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 1.2. Data Structures 178 Data structures are defined according to the conventions laid out in 179 Section 4 of [RFC5246]. 181 2. Cryptographic Components 183 2.1. Merkle Hash Trees 185 Logs use a binary Merkle Hash Tree for efficient auditing. The 186 hashing algorithm used by each log is expected to be specified as 187 part of the metadata relating to that log. We have established a 188 registry of acceptable algorithms, see Section 6.2. The hashing 189 algorithm in use is referred to as HASH throughout this document. 190 The input to the Merkle Tree Hash is a list of data entries; these 191 entries will be hashed to form the leaves of the Merkle Hash Tree. 192 The output is a single 32-byte Merkle Tree Hash. Given an ordered 193 list of n inputs, D[n] = {d(0), d(1), ..., d(n-1)}, the Merkle Tree 194 Hash (MTH) is thus defined as follows: 196 The hash of an empty list is the hash of an empty string: 198 MTH({}) = HASH(). 200 The hash of a list with one entry (also known as a leaf hash) is: 202 MTH({d(0)}) = HASH(0x00 || d(0)). 204 For n > 1, let k be the largest power of two smaller than n (i.e., k 205 < n <= 2k). The Merkle Tree Hash of an n-element list D[n] is then 206 defined recursively as 208 MTH(D[n]) = HASH(0x01 || MTH(D[0:k]) || MTH(D[k:n])), 210 where || is concatenation and D[k1:k2] denotes the list {d(k1), 211 d(k1+1),..., d(k2-1)} of length (k2 - k1). (Note that the hash 212 calculations for leaves and nodes differ. This domain separation is 213 required to give second preimage resistance.) 215 Note that we do not require the length of the input list to be a 216 power of two. The resulting Merkle Tree may thus not be balanced; 217 however, its shape is uniquely determined by the number of leaves. 218 (Note: This Merkle Tree is essentially the same as the history tree 219 [CrosbyWallach] proposal, except our definition handles non-full 220 trees differently.) 222 2.1.1. Merkle Audit Paths 224 A Merkle audit path for a leaf in a Merkle Hash Tree is the shortest 225 list of additional nodes in the Merkle Tree required to compute the 226 Merkle Tree Hash for that tree. Each node in the tree is either a 227 leaf node or is computed from the two nodes immediately below it 228 (i.e., towards the leaves). At each step up the tree (towards the 229 root), a node from the audit path is combined with the node computed 230 so far. In other words, the audit path consists of the list of 231 missing nodes required to compute the nodes leading from a leaf to 232 the root of the tree. If the root computed from the audit path 233 matches the true root, then the audit path is proof that the leaf 234 exists in the tree. 236 Given an ordered list of n inputs to the tree, D[n] = {d(0), ..., 237 d(n-1)}, the Merkle audit path PATH(m, D[n]) for the (m+1)th input 238 d(m), 0 <= m < n, is defined as follows: 240 The path for the single leaf in a tree with a one-element input list 241 D[1] = {d(0)} is empty: 243 PATH(0, {d(0)}) = {} 245 For n > 1, let k be the largest power of two smaller than n. The path 246 for the (m+1)th element d(m) in a list of n > m elements is then 247 defined recursively as 249 PATH(m, D[n]) = PATH(m, D[0:k]) : MTH(D[k:n]) for m < k; and 251 PATH(m, D[n]) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m >= k, 253 where : is concatenation of lists and D[k1:k2] denotes the length (k2 254 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before. 256 2.1.2. Merkle Consistency Proofs 258 Merkle consistency proofs prove the append-only property of the tree. 259 A Merkle consistency proof for a Merkle Tree Hash MTH(D[n]) and a 260 previously advertised hash MTH(D[0:m]) of the first m leaves, m <= n, 261 is the list of nodes in the Merkle Tree required to verify that the 262 first m inputs D[0:m] are equal in both trees. Thus, a consistency 263 proof must contain a set of intermediate nodes (i.e., commitments to 264 inputs) sufficient to verify MTH(D[n]), such that (a subset of) the 265 same nodes can be used to verify MTH(D[0:m]). We define an algorithm 266 that outputs the (unique) minimal consistency proof. 268 Given an ordered list of n inputs to the tree, D[n] = {d(0), ..., 269 d(n-1)}, the Merkle consistency proof PROOF(m, D[n]) for a previous 270 Merkle Tree Hash MTH(D[0:m]), 0 < m < n, is defined as: 272 PROOF(m, D[n]) = SUBPROOF(m, D[n], true) 274 The subproof for m = n is empty if m is the value for which PROOF was 275 originally requested (meaning that the subtree Merkle Tree Hash 276 MTH(D[0:m]) is known): 278 SUBPROOF(m, D[m], true) = {} 280 The subproof for m = n is the Merkle Tree Hash committing inputs 281 D[0:m]; otherwise: 283 SUBPROOF(m, D[m], false) = {MTH(D[m])} 285 For m < n, let k be the largest power of two smaller than n. The 286 subproof is then defined recursively. 288 If m <= k, the right subtree entries D[k:n] only exist in the current 289 tree. We prove that the left subtree entries D[0:k] are consistent 290 and add a commitment to D[k:n]: 292 SUBPROOF(m, D[n], b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n]) 294 If m > k, the left subtree entries D[0:k] are identical in both 295 trees. We prove that the right subtree entries D[k:n] are consistent 296 and add a commitment to D[0:k]. 298 SUBPROOF(m, D[n], b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k]) 300 Here, : is a concatenation of lists, and D[k1:k2] denotes the length 301 (k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before. 303 The number of nodes in the resulting proof is bounded above by 304 ceil(log2(n)) + 1. 306 2.1.3. Example 308 The binary Merkle Tree with 7 leaves: 310 hash 311 / \ 312 / \ 313 / \ 314 / \ 315 / \ 316 k l 317 / \ / \ 318 / \ / \ 319 / \ / \ 320 g h i j 321 / \ / \ / \ | 322 a b c d e f d6 323 | | | | | | 324 d0 d1 d2 d3 d4 d5 326 The audit path for d0 is [b, h, l]. 328 The audit path for d3 is [c, g, l]. 330 The audit path for d4 is [f, j, k]. 332 The audit path for d6 is [i, k]. 334 The same tree, built incrementally in four steps: 336 hash0 hash1=k 337 / \ / \ 338 / \ / \ 339 / \ / \ 340 g c g h 341 / \ | / \ / \ 342 a b d2 a b c d 343 | | | | | | 344 d0 d1 d0 d1 d2 d3 346 hash2 hash 347 / \ / \ 348 / \ / \ 349 / \ / \ 350 / \ / \ 351 / \ / \ 352 k i k l 353 / \ / \ / \ / \ 354 / \ e f / \ / \ 355 / \ | | / \ / \ 356 g h d4 d5 g h i j 357 / \ / \ / \ / \ / \ | 358 a b c d a b c d e f d6 359 | | | | | | | | | | 360 d0 d1 d2 d3 d0 d1 d2 d3 d4 d5 362 The consistency proof between hash0 and hash is PROOF(3, D[7]) = [c, 363 d, g, l]. c, g are used to verify hash0, and d, l are additionally 364 used to show hash is consistent with hash0. 366 The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l]. 367 hash can be verified using hash1=k and l. 369 The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i, 370 j, k]. k, i are used to verify hash2, and j is additionally used to 371 show hash is consistent with hash2. 373 2.1.4. Signatures 375 Various data structures are signed. A log MUST use either elliptic 376 curve signatures using the NIST P-256 curve (Section D.1.2.3 of the 377 Digital Signature Standard [DSS]) or RSA signatures (RSASSA- 378 PKCS1-V1_5 with SHA-256, Section 8.2 of [RFC3447]) using a key of at 379 least 2048 bits. 381 3. Log Format and Operation 383 Anyone can submit certificates to certificate logs for public 384 auditing; however, since certificates will not be accepted by TLS 385 clients unless logged, it is expected that certificate owners or 386 their CAs will usually submit them. A log is a single, ever-growing, 387 append-only Merkle Tree of such certificates. 389 When a valid certificate is submitted to a log, the log MUST return a 390 Signed Certificate Timestamp (SCT). The SCT is the log's promise to 391 incorporate the certificate in the Merkle Tree within a fixed amount 392 of time known as the Maximum Merge Delay (MMD). If the log has 393 previously seen the certificate, it MAY return the same SCT as it 394 returned before. TLS servers MUST present an SCT from one or more 395 logs to the TLS client together with the certificate. TLS clients 396 MUST reject certificates that are not accompanied by an SCT for 397 either the end-entity certificate or for a name-constrained 398 intermediate the end-entity certificate chains to. 400 Periodically, each log appends all its new entries to the Merkle Tree 401 and signs the root of the tree. The log MUST incorporate a 402 certificate in its Merkle Tree within the Maximum Merge Delay period 403 after the issuance of the SCT. When encountering an SCT, an Auditor 404 can verify that the certificate was added to the Merkle Tree within 405 that timeframe. 407 Log operators MUST NOT impose any conditions on retrieving or sharing 408 data from the log. 410 3.1. Log Entries 412 In order to enable attribution of each logged certificate to its 413 issuer, each submitted certificate MUST be accompanied by all 414 additional certificates required to verify the certificate chain up 415 to an accepted root certificate. The root certificate itself MAY be 416 omitted from the chain submitted to the log server. The log SHALL 417 allow retrieval of a list of acceptable root certificates (this list 418 might usefully be the union of root certificates trusted by major 419 browser vendors). 421 Alternatively, (root as well as intermediate) certificate authorities 422 may submit a certificate to logs prior to issuance in order to 423 incorporate the SCT in the issued certificate. To do so, the CA 424 submits a Precertificate that the log can use to create an entry that 425 will be valid against the issued certificate. The Precertificate is 426 an X.509v3 certificate for simplicity, but, since it isn't used for 427 anything but logging, could equally be some other data structure. 428 The Precertificate is constructed from the certificate to be issued 429 by adding a special critical poison extension (OID 430 1.3.6.1.4.1.11129.2.4.3, whose extnValue OCTET STRING contains ASN.1 431 NULL data (0x05 0x00)) to the end-entity TBSCertificate, minus the 432 SCT extension, which is obviously unknown until after the 433 Precertificate has been submitted to the log. The poison extension 434 is to ensure that the Precertificate cannot be validated by a 435 standard X.509v3 client. The Precertificate MAY redact certain 436 domain name labels that will be present in the final certificate (see 437 Section 3.2.2). The resulting TBSCertificate [RFC5280] is then 438 signed with either 440 o a special-purpose (CA:true, Extended Key Usage: Certificate 441 Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing 442 Certificate. The Precertificate Signing Certificate MUST be 443 directly certified by the (root or intermediate) CA certificate 444 that will ultimately sign the end-entity TBSCertificate yielding 445 the end-entity certificate (note that the log may relax standard 446 validation rules to allow this, so long as the issued certificate 447 will be valid), 449 o or, the CA certificate that will sign the final certificate. 451 As above, the Precertificate submission MUST be accompanied by the 452 Precertificate Signing Certificate, if used, and all additional 453 certificates required to verify the chain up to an accepted root 454 certificate. The signature on the TBSCertificate indicates the 455 certificate authority's intent to issue a certificate. This intent 456 is considered binding (i.e., misissuance of the Precertificate is 457 considered equal to misissuance of the final certificate). Each log 458 verifies the Precertificate signature chain and issues a Signed 459 Certificate Timestamp on the corresponding TBSCertificate. 461 Logs MUST verify that the submitted end-entity certificate or 462 Precertificate has a valid signature chain leading back to a trusted 463 root CA certificate, using the chain of intermediate CA certificates 464 provided by the submitter. Logs MAY accept certificates that have 465 expired, are not yet valid, have been revoked, or are otherwise not 466 fully valid according to X.509 verification rules in order to 467 accommodate quirks of CA certificate-issuing software. However, logs 468 MUST refuse to publish certificates without a valid chain to a known 469 root CA. If a certificate is accepted and an SCT issued, the 470 accepting log MUST store the entire chain used for verification, 471 including the certificate or Precertificate itself and including the 472 root certificate used to verify the chain (even if it was omitted 473 from the submission), and MUST present this chain for auditing upon 474 request. This chain is required to prevent a CA from avoiding blame 475 by logging a partial or empty chain. (Note: This effectively 476 excludes self-signed and DANE-based certificates until some mechanism 477 to limit the submission of spurious certificates is found. The 478 authors welcome suggestions.) 480 Each certificate entry in a log MUST include the following 481 components: 483 enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType; 485 struct { 486 LogEntryType entry_type; 487 select (entry_type) { 488 case x509_entry: X509ChainEntry; 489 case precert_entry: PrecertChainEntry; 490 } entry; 491 } LogEntry; 493 opaque ASN.1Cert<1..2^24-1>; 495 struct { 496 ASN.1Cert leaf_certificate; 497 ASN.1Cert certificate_chain<0..2^24-1>; 498 } X509ChainEntry; 500 struct { 501 ASN.1Cert pre_certificate; 502 ASN.1Cert precertificate_chain<0..2^24-1>; 503 } PrecertChainEntry; 505 Logs SHOULD limit the length of chain they will accept. 507 "entry_type" is the type of this entry. Future revisions of this 508 protocol may add new LogEntryType values. Section 4 explains how 509 clients should handle unknown entry types. 511 "leaf_certificate" is the end-entity certificate submitted for 512 auditing. 514 "certificate_chain" is a chain of additional certificates required to 515 verify the end-entity certificate. The first certificate MUST 516 certify the end-entity certificate. Each following certificate MUST 517 directly certify the one preceding it. The final certificate MUST 518 either be, or be issued by, a root certificate accepted by the log. 520 "pre_certificate" is the Precertificate submitted for auditing. 522 "precertificate_chain" is a chain of additional certificates required 523 to verify the Precertificate submission. The first certificate MAY 524 be a valid Precertificate Signing Certificate and MUST certify the 525 first certificate. Each following certificate MUST directly certify 526 the one preceding it. The final certificate MUST be a root 527 certificate accepted by the log. 529 3.2. Private Domain Name Labels 531 Some regard some DNS domain name labels within their registered 532 domain space as private and security sensitive. Even though these 533 domains are often only accessible within the domain owner's private 534 network, it's common for them to be secured using publicly trusted 535 TLS server certificates. We define a mechanism to allow these 536 private labels to not appear in public logs. 538 3.2.1. Wildcard Certificates 540 A certificate containing a DNS-ID [RFC6125] of "*.example.com" could 541 be used to secure the domain "topsecret.example.com", without 542 revealing the string "topsecret" publicly. 544 Since TLS clients only match the wildcard character to the complete 545 leftmost label of the DNS domain name (see Section 6.4.3 of 546 [RFC6125]), this approach would not work for a DNS-ID such as 547 "top.secret.example.com". Also, wildcard certificates are prohibited 548 in some cases, such as Extended Validation Certificates 549 [EVSSLGuidelines]. 551 3.2.2. Redacting Domain Name Labels in Precertificates 553 When creating a Precertificate, the CA MAY substitute one or more of 554 the complete leftmost labels in each DNS-ID with the literal string 555 "(PRIVATE)". For example, if a certificate contains a DNS-ID of 556 "top.secret.example.com", then the corresponding Precertificate could 557 contain "(PRIVATE).example.com" instead. Labels in a CN-ID [RFC6125] 558 MUST remain unredacted. 560 When a Precertificate contains one or more redacted labels, a non- 561 critical extension (OID 1.3.6.1.4.1.11129.2.4.6, whose extnValue 562 OCTET STRING contains an ASN.1 SEQUENCE OF INTEGERs) MUST be added to 563 the corresponding certificate: the first INTEGER indicates the number 564 of labels redacted in the Precertificate's first DNS-ID; the second 565 INTEGER does the same for the Precertificate's second DNS-ID; etc. 566 There MUST NOT be more INTEGERs than there are DNS-IDs. If there are 567 fewer INTEGERs than there are DNS-IDs, the shortfall is made up by 568 implicitly repeating the last INTEGER. Each INTEGER MUST have a 569 value of zero or more. The purpose of this extension is to enable 570 TLS clients to accurately reconstruct the Precertificate from the 571 certificate without having to perform any guesswork. 573 3.2.3. Using a Name-Constrained Intermediate CA 575 An intermediate CA certificate or Precertificate that contains the 576 critical or non-critical Name Constraints [RFC5280] extension MAY be 577 logged in place of end-entity certificates issued by that 578 intermediate CA, as long as all of the following conditions are met: 580 o there MUST be a non-critical extension (OID 581 1.3.6.1.4.1.11129.2.4.7, whose extnValue OCTET STRING contains 582 ASN.1 NULL data (0x05 0x00)). This extension is an explicit 583 indication that it is acceptable to not log certificates issued by 584 this intermediate CA. 586 o permittedSubtrees MUST specify one or more dNSNames. 588 o excludedSubtrees MUST specify the entire IPv4 and IPv6 address 589 ranges. 591 Below is an example Name Constraints extension that meets these 592 conditions: 594 SEQUENCE { 595 OBJECT IDENTIFIER '2 5 29 30' 596 OCTET STRING, encapsulates { 597 SEQUENCE { 598 [0] { 599 SEQUENCE { 600 [2] 'example.com' 601 } 602 } 603 [1] { 604 SEQUENCE { 605 [7] 00 00 00 00 00 00 00 00 606 } 607 SEQUENCE { 608 [7] 609 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 610 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 611 } 612 } 613 } 614 } 615 } 617 3.3. Structure of the Signed Certificate Timestamp 619 enum { certificate_timestamp(0), tree_hash(1), (255) } 620 SignatureType; 622 enum { v1(0), (255) } 623 Version; 625 struct { 626 opaque key_id[32]; 627 } LogID; 629 opaque TBSCertificate<1..2^24-1>; 631 struct { 632 opaque issuer_key_hash[32]; 633 TBSCertificate tbs_certificate; 634 } PreCert; 636 opaque CtExtensions<0..2^16-1>; 638 "key_id" is the SHA-256 hash of the log's public key, calculated over 639 the DER encoding of the key represented as SubjectPublicKeyInfo. 641 "issuer_key_hash" is the SHA-256 hash of the certificate issuer's 642 public key, calculated over the DER encoding of the key represented 643 as SubjectPublicKeyInfo. This is needed to bind the issuer to the 644 final certificate. 646 "tbs_certificate" is the DER-encoded TBSCertificate (see [RFC5280]) 647 component of the Precertificate -- that is, without the signature and 648 the poison extension. If the Precertificate is not signed with the 649 CA certificate that will issue the final certificate, then the 650 TBSCertificate also has its issuer changed to that of the CA that 651 will issue the final certificate. Note that it is also possible to 652 reconstruct this TBSCertificate from the final certificate by 653 extracting the TBSCertificate from it and deleting the SCT extension. 654 Also note that since the TBSCertificate contains an 655 AlgorithmIdentifier that must match both the Precertificate signature 656 algorithm and final certificate signature algorithm, they must be 657 signed with the same algorithm and parameters. If the Precertificate 658 is issued using a Precertificate Signing Certificate and an Authority 659 Key Identifier extension is present in the TBSCertificate, the 660 corresponding extension must also be present in the Precertificate 661 Signing Certificate -- in this case, the TBSCertificate also has its 662 Authority Key Identifier changed to match the final issuer. 664 struct { 665 Version sct_version; 666 LogID id; 667 uint64 timestamp; 668 CtExtensions extensions; 669 digitally-signed struct { 670 Version sct_version; 671 SignatureType signature_type = certificate_timestamp; 672 uint64 timestamp; 673 LogEntryType entry_type; 674 select(entry_type) { 675 case x509_entry: ASN.1Cert; 676 case precert_entry: PreCert; 677 } signed_entry; 678 CtExtensions extensions; 679 }; 680 } SignedCertificateTimestamp; 682 The encoding of the digitally-signed element is defined in [RFC5246]. 684 "sct_version" is the version of the protocol to which the SCT 685 conforms. This version is v1. 687 "timestamp" is the current NTP Time [RFC5905], measured since the 688 epoch (January 1, 1970, 00:00), ignoring leap seconds, in 689 milliseconds. 691 "entry_type" may be implicit from the context in which the SCT is 692 presented. 694 "signed_entry" is the "leaf_certificate" (in the case of an 695 X509ChainEntry) or is the PreCert (in the case of a 696 PrecertChainEntry), as described above. 698 "extensions" are future extensions to this protocol version (v1). 699 Currently, no extensions are specified. 701 3.4. Including the Signed Certificate Timestamp in the TLS Handshake 703 The SCT data corresponding to at least one certificate in the chain 704 from at least one log must be included in the TLS handshake, either 705 by using an X509v3 certificate extension as described below, by using 706 a TLS extension (Section 7.4.1.4 of [RFC5246]) with type 707 "signed_certificate_timestamp", or by using Online Certificate Status 708 Protocol (OCSP) Stapling (also known as the "Certificate Status 709 Request" TLS extension; see [RFC6066]), where the OCSP response 710 includes a non-critical extension with OID 1.3.6.1.4.1.11129.2.4.5 711 (see [RFC2560]) and body: 713 SignedCertificateTimestampList ::= OCTET STRING 715 in the singleExtensions component of the SingleResponse pertaining to 716 the end-entity certificate. 718 At least one SCT MUST be included. Server operators MAY include more 719 than one SCT. 721 Similarly, a certificate authority MAY submit a Precertificate to 722 more than one log, and all obtained SCTs can be directly embedded in 723 the final certificate, by encoding the SignedCertificateTimestampList 724 structure as an ASN.1 OCTET STRING and inserting the resulting data 725 in the TBSCertificate as a non-critical X.509v3 certificate extension 726 (OID 1.3.6.1.4.1.11129.2.4.2). Upon receiving the certificate, 727 clients can reconstruct the original TBSCertificate to verify the SCT 728 signature. 730 The contents of the ASN.1 OCTET STRING embedded in an OCSP extension 731 or X509v3 certificate extension are as follows: 733 opaque SerializedSCT<1..2^16-1>; 735 struct { 736 SerializedSCT sct_list <1..2^16-1>; 737 } SignedCertificateTimestampList; 739 Here, "SerializedSCT" is an opaque byte string that contains the 740 serialized SCT structure. This encoding ensures that TLS clients can 741 decode each SCT individually (i.e., if there is a version upgrade, 742 out-of-date clients can still parse old SCTs while skipping over new 743 SCTs whose versions they don't understand). 745 Likewise, SCTs can be embedded in a TLS extension. See below for 746 details. 748 TLS clients MUST implement all three mechanisms. Servers MUST 749 implement at least one of the three mechanisms. Note that existing 750 TLS servers can generally use the certificate extension mechanism 751 without modification. 753 TLS servers SHOULD send SCTs from multiple logs in case one or more 754 logs are not acceptable to the client (for example, if a log has been 755 struck off for misbehavior, has had a key compromise or is not known 756 to the client). 758 3.4.1. TLS Extension 760 The SCT can be sent during the TLS handshake using a TLS extension 761 with type "signed_certificate_timestamp". 763 Clients that support the extension SHOULD send a ClientHello 764 extension with the appropriate type and empty "extension_data". 766 Servers MUST only send SCTs to clients who have indicated support for 767 the extension in the ClientHello, in which case the SCTs are sent by 768 setting the "extension_data" to a "SignedCertificateTimestampList". 770 Session resumption uses the original session information: clients 771 SHOULD include the extension type in the ClientHello, but if the 772 session is resumed, the server is not expected to process it or 773 include the extension in the ServerHello. 775 3.5. Merkle Tree 777 The hashing algorithm for the Merkle Tree Hash is specified in the 778 log's metadata. 780 Structure of the Merkle Tree input: 782 enum { v1(0), v2(1), (255) } 783 LeafVersion; 785 struct { 786 uint64 timestamp; 787 LogEntryType entry_type; 788 select(entry_type) { 789 case x509_entry: ASN.1Cert; 790 case precert_entry: PreCert; 791 } signed_entry; 792 CtExtensions extensions; 793 } TimestampedEntry; 795 struct { 796 LeafVersion version; 797 TimestampedEntry timestamped_entry; 798 } MerkleTreeLeaf; 800 Here, "version" is the version of the MerkleTreeLeaf structure. This 801 version is v2. Note that MerkleTreeLeaf v1 [RFC6962] had another 802 layer of indirection which is removed in v2. 804 "timestamp" is the timestamp of the corresponding SCT issued for this 805 certificate. 807 "entry_type" is the type of entry stored in "signed_entry". New 808 "LogEntryType" values may be added to "signed_entry" without 809 increasing the "MerkleTreeLeaf" version. Section 4 explains how 810 clients should handle unknown entry types. 812 "signed_entry" is the "signed_entry" of the corresponding SCT. 814 "extensions" are "extensions" of the corresponding SCT. 816 The leaves of the Merkle Tree are the leaf hashes of the 817 corresponding "MerkleTreeLeaf" structures. 819 3.6. Signed Tree Head 821 Every time a log appends new entries to the tree, the log SHOULD sign 822 the corresponding tree hash and tree information (see the 823 corresponding Signed Tree Head client message in Section 4.3). The 824 signature for that data is structured as follows: 826 opaque CtSthExtensions<0..2^16-1>; 828 enum { v1(0), v2(1), (255) } 829 TreeHeadVersion; 831 digitally-signed struct { 832 TreeHeadVersion version; 833 SignatureType signature_type = tree_hash; 834 uint64 timestamp; 835 uint64 tree_size; 836 opaque sha256_root_hash[32]; 837 CtSthExtensions extensions; 838 } TreeHeadSignature; 840 "version" is the version of the TreeHeadSignature structure. This 841 version is v2. 843 "timestamp" is the current time. The timestamp MUST be at least as 844 recent as the most recent SCT timestamp in the tree. Each subsequent 845 timestamp MUST be more recent than the timestamp of the previous 846 update. 848 "tree_size" equals the number of entries in the new tree. 850 "sha256_root_hash" is the root of the Merkle Hash Tree. 852 "extensions" are future extensions to TreeHeadSignature v2. 853 Currently, no extensions are specified. Note that TreeHeadSignature 854 v1 [RFC6962] does not include this field. The purpose of the 855 "extensions" field is to allow augmenting the TreeHeadSignature 856 without increasing its version. 858 Each log MUST produce on demand a Signed Tree Head that is no older 859 than the Maximum Merge Delay. In the unlikely event that it receives 860 no new submissions during an MMD period, the log SHALL sign the same 861 Merkle Tree Hash with a fresh timestamp. 863 4. Log Client Messages 865 Messages are sent as HTTPS GET or POST requests. Parameters for 866 POSTs and all responses are encoded as JavaScript Object Notation 867 (JSON) objects [RFC4627]. Parameters for GETs are encoded as order- 868 independent key/value URL parameters, using the "application/x-www- 869 form-urlencoded" format described in the "HTML 4.01 Specification" 870 [HTML401]. Binary data is base64 encoded [RFC4648] as specified in 871 the individual messages. 873 Note that JSON objects and URL parameters may contain fields not 874 specified here. These extra fields should be ignored. 876 The prefix MAY include a path as well as a server name 877 and a port. 879 In general, where needed, the "version" is v1 and the "id" is the log 880 id for the log server queried. 882 If the log is unable to process a client's request, it MUST return an 883 HTTP response code of 4xx/5xx (see [RFC2616]), and, in place of the 884 responses outlined in the subsections below, the body SHOULD be a 885 JSON structure containing at least the following field: 887 error_message: 889 A human-readable string describing the error which prevented 890 the log from processing the request. 892 In the case of a malformed request, the string SHOULD provide 893 sufficient detail for the error to be rectified. 895 e.g. In response to a request of "/ct/v1/get- 896 entries?start=100&end=99", the log would return a "400 Bad Request" 897 response code with a body similar to the following: 899 { 900 "error_message": "'start' cannot be greater than 'end'", 901 } 903 Clients SHOULD treat "500 Internal Server Error" and "503 Service 904 Unavailable" responses as transient failures and MAY retry the same 905 request without modification at a later date. Note that as per 906 [RFC2616], in the case of a 503 response the log MAY include a 907 "Retry-After:" header in order to request a minimum time for the 908 client to wait before retrying the request. 910 4.1. Add Chain to Log 912 POST https:///ct/v1/add-chain 914 Inputs: 916 chain: An array of base64-encoded certificates. The first 917 element is the end-entity certificate; the second chains to the 918 first and so on to the last, which is either the root 919 certificate or a certificate that chains to a known root 920 certificate. 922 Outputs: 924 sct_version: The version of the SignedCertificateTimestamp 925 structure, in decimal. A compliant v1 implementation MUST NOT 926 expect this to be 0 (i.e., v1). 928 id: The log ID, base64 encoded. 930 timestamp: The SCT timestamp, in decimal. 932 extensions: An opaque type for future expansion. It is likely 933 that not all participants will need to understand data in this 934 field. Logs should set this to the empty string. Clients 935 should decode the base64-encoded data and include it in the 936 SCT. 938 signature: The SCT signature, base64 encoded. 940 If the "sct_version" is not v1, then a v1 client may be unable to 941 verify the signature. It MUST NOT construe this as an error. This 942 is to avoid forcing an upgrade of compliant v1 clients that do not 943 use the returned SCTs. 945 4.2. Add PreCertChain to Log 947 POST https:///ct/v1/add-pre-chain 949 Inputs: 951 chain: An array of base64-encoded Precertificates. The first 952 element is the end-entity certificate; the second chains to the 953 first and so on to the last, which is either the root 954 certificate or a certificate that chains to a known root 955 certificate. 957 Outputs are the same as in Section 4.1. 959 4.3. Retrieve Latest Signed Tree Head 961 GET https:///ct/v1/get-sth 963 No inputs. 965 Outputs: 967 tree_size: The size of the tree, in entries, in decimal. 969 timestamp: The timestamp, in decimal. 971 sha256_root_hash: The Merkle Tree Hash of the tree, in base64. 973 tree_head_signature: A TreeHeadSignature for the above data. 975 4.4. Retrieve Merkle Consistency Proof between Two Signed Tree Heads 977 GET https:///ct/v1/get-sth-consistency 979 Inputs: 981 first: The tree_size of the older tree, in decimal. 983 second: The tree_size of the newer tree, in decimal. 985 Both tree sizes must be from existing v1 STHs (Signed Tree Heads). 987 Outputs: 989 consistency: An array of Merkle Tree nodes, base64 encoded. 991 Note that no signature is required on this data, as it is used to 992 verify an STH, which is signed. 994 4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash 996 GET https:///ct/v1/get-proof-by-hash 998 Inputs: 1000 hash: A base64-encoded v1 leaf hash. 1002 tree_size: The tree_size of the tree on which to base the proof, 1003 in decimal. 1005 The "hash" must be calculated as defined in Section 3.5. The 1006 "tree_size" must designate an existing v1 STH. 1008 Outputs: 1010 leaf_index: The 0-based index of the entry corresponding to the 1011 "hash" parameter. 1013 audit_path: An array of base64-encoded Merkle Tree nodes proving 1014 the inclusion of the chosen certificate. 1016 4.6. Retrieve Entries from Log 1018 GET https:///ct/v1/get-entries 1020 Inputs: 1022 start: 0-based index of first entry to retrieve, in decimal. 1024 end: 0-based index of last entry to retrieve, in decimal. 1026 Outputs: 1028 entries: An array of objects, each consisting of 1030 leaf_input: The base64-encoded MerkleTreeLeaf structure. 1032 extra_data: The base64-encoded unsigned data pertaining to the 1033 log entry. In the case of an X509ChainEntry, this is the 1034 "certificate_chain". In the case of a PrecertChainEntry, 1035 this is the whole "PrecertChainEntry". 1037 Note that this message is not signed -- the retrieved data can be 1038 verified by constructing the Merkle Tree Hash corresponding to a 1039 retrieved STH. All leaves MUST be v1 or v2. However, a compliant v1 1040 client MUST NOT construe an unrecognized LogEntryType value as an 1041 error. This means it may be unable to parse some entries, but note 1042 that each client can inspect the entries it does recognize as well as 1043 verify the integrity of the data by treating unrecognized leaves as 1044 opaque input to the tree. 1046 The "start" and "end" parameters SHOULD be within the range 0 <= x < 1047 "tree_size" as returned by "get-sth" in Section 4.3. 1049 Logs MAY honor requests where 0 <= "start" < "tree_size" and "end" >= 1050 "tree_size" by returning a partial response covering only the valid 1051 entries in the specified range. Note that the following restriction 1052 may also apply: 1054 Logs MAY restrict the number of entries that can be retrieved per 1055 "get-entries" request. If a client requests more than the permitted 1056 number of entries, the log SHALL return the maximum number of entries 1057 permissible. These entries SHALL be sequential beginning with the 1058 entry specified by "start". 1060 4.7. Retrieve Accepted Root Certificates 1062 GET https:///ct/v1/get-roots 1064 No inputs. 1066 Outputs: 1068 certificates: An array of base64-encoded root certificates that 1069 are acceptable to the log. 1071 4.8. Retrieve Entry+Merkle Audit Proof from Log 1073 GET https:///ct/v1/get-entry-and-proof 1075 Inputs: 1077 leaf_index: The index of the desired entry. 1079 tree_size: The tree_size of the tree for which the proof is 1080 desired. 1082 The tree size must designate an existing STH. 1084 Outputs: 1086 leaf_input: The base64-encoded MerkleTreeLeaf structure. 1088 extra_data: The base64-encoded unsigned data, same as in 1089 Section 4.6. 1091 audit_path: An array of base64-encoded Merkle Tree nodes proving 1092 the inclusion of the chosen certificate. 1094 This API is probably only useful for debugging. 1096 5. Clients 1098 There are various different functions clients of logs might perform. 1099 We describe here some typical clients and how they could function. 1100 Any inconsistency may be used as evidence that a log has not behaved 1101 correctly, and the signatures on the data structures prevent the log 1102 from denying that misbehavior. 1104 All clients should gossip with each other, exchanging STHs at least; 1105 this is all that is required to ensure that they all have a 1106 consistent view. The exact mechanism for gossip will be described in 1107 a separate document, but it is expected there will be a variety. 1109 5.1. Submitters 1111 Submitters submit certificates or Precertificates to the log as 1112 described above. When a Submitter intends to use the returned SCT 1113 directly in a TLS handshake or to construct a certificate, they 1114 SHOULD validate the SCT as described in Section 5.2 if they 1115 understand its format. 1117 5.2. TLS Client 1119 TLS clients receive SCTs alongside or in server certificates. In 1120 addition to normal validation of the certificate and its chain, TLS 1121 clients SHOULD validate the SCT by computing the signature input from 1122 the SCT data as well as the certificate and verifying the signature, 1123 using the corresponding log's public key. TLS clients MAY audit the 1124 corresponding log by requesting, and verifying, a Merkle audit proof 1125 for said certificate. Note that this document does not describe how 1126 clients obtain the logs' public keys or URLs. 1128 TLS clients MUST reject SCTs whose timestamp is in the future. 1130 5.3. Monitor 1132 Monitors watch logs and check that they behave correctly. They also 1133 watch for certificates of interest. 1135 A monitor needs to, at least, inspect every new entry in each log it 1136 watches. It may also want to keep copies of entire logs. In order 1137 to do this, it should follow these steps for each log: 1139 1. Fetch the current STH (Section 4.3). 1141 2. Verify the STH signature. 1143 3. Fetch all the entries in the tree corresponding to the STH 1144 (Section 4.6). 1146 4. Confirm that the tree made from the fetched entries produces the 1147 same hash as that in the STH. 1149 5. Fetch the current STH (Section 4.3). Repeat until the STH 1150 changes. 1152 6. Verify the STH signature. 1154 7. Fetch all the new entries in the tree corresponding to the STH 1155 (Section 4.6). If they remain unavailable for an extended 1156 period, then this should be viewed as misbehavior on the part of 1157 the log. 1159 8. Either: 1161 1. Verify that the updated list of all entries generates a tree 1162 with the same hash as the new STH. 1164 Or, if it is not keeping all log entries: 1166 1. Fetch a consistency proof for the new STH with the previous 1167 STH (Section 4.4). 1169 2. Verify the consistency proof. 1171 3. Verify that the new entries generate the corresponding 1172 elements in the consistency proof. 1174 9. Go to Step 5. 1176 5.4. Auditor 1178 Auditors take partial information about a log as input and verify 1179 that this information is consistent with other partial information 1180 they have. An auditor might be an integral component of a TLS 1181 client; it might be a standalone service; or it might be a secondary 1182 function of a monitor. 1184 Any pair of STHs from the same log can be verified by requesting a 1185 consistency proof (Section 4.4). 1187 A certificate accompanied by an SCT can be verified against any STH 1188 dated after the SCT timestamp + the Maximum Merge Delay by requesting 1189 a Merkle audit proof (Section 4.5). 1191 Auditors can fetch STHs from time to time of their own accord, of 1192 course (Section 4.3). 1194 6. IANA Considerations 1196 6.1. TLS Extension Type 1198 IANA has allocated an RFC 5246 ExtensionType value (18) for the SCT 1199 TLS extension. The extension name is "signed_certificate_timestamp". 1200 IANA should update this extension type to point at this document. 1202 6.2. Hash Algorithms 1204 IANA is asked to establish a registry of hash values, initially 1205 consisting of: 1207 +-------+----------------------+ 1208 | Index | Hash | 1209 +-------+----------------------+ 1210 | 0 | SHA-256 [FIPS.180-4] | 1211 +-------+----------------------+ 1213 7. Security Considerations 1215 With CAs, logs, and servers performing the actions described here, 1216 TLS clients can use logs and signed timestamps to reduce the 1217 likelihood that they will accept misissued certificates. If a server 1218 presents a valid signed timestamp for a certificate, then the client 1219 knows that a log has committed to publishing the certificate. From 1220 this, the client knows that the subject of the certificate has had 1221 some time to notice the misissue and take some action, such as asking 1222 a CA to revoke a misissued certificate, or that the log has 1223 misbehaved, which will be discovered when the SCT is audited. A 1224 signed timestamp is not a guarantee that the certificate is not 1225 misissued, since the subject of the certificate might not have 1226 checked the logs or the CA might have refused to revoke the 1227 certificate. 1229 In addition, if TLS clients will not accept unlogged certificates, 1230 then site owners will have a greater incentive to submit certificates 1231 to logs, possibly with the assistance of their CA, increasing the 1232 overall transparency of the system. 1234 7.1. Misissued Certificates 1236 Misissued certificates that have not been publicly logged, and thus 1237 do not have a valid SCT, will be rejected by TLS clients. Misissued 1238 certificates that do have an SCT from a log will appear in that 1239 public log within the Maximum Merge Delay, assuming the log is 1240 operating correctly. Thus, the maximum period of time during which a 1241 misissued certificate can be used without being available for audit 1242 is the MMD. 1244 7.2. Detection of Misissue 1246 The logs do not themselves detect misissued certificates; they rely 1247 instead on interested parties, such as domain owners, to monitor them 1248 and take corrective action when a misissue is detected. 1250 7.3. Redaction of Public Domain Name Labels 1252 CAs SHOULD NOT redact domain name labels in Precertificates to the 1253 extent that domain name ownership becomes unclear (e.g. 1254 "(PRIVATE).com" and "(PRIVATE).co.uk" would both be problematic). 1256 Logs MUST NOT reject any Precertificate that is overly redacted but 1257 which is otherwise considered compliant. It is expected that 1258 monitors will treat overly redacted Precertificates as potentially 1259 misissued. TLS clients MAY reject a certificate whose corresponding 1260 Precertificate would be overly redacted. 1262 7.4. Misbehaving Logs 1264 A log can misbehave in two ways: (1) by failing to incorporate a 1265 certificate with an SCT in the Merkle Tree within the MMD and (2) by 1266 violating its append-only property by presenting two different, 1267 conflicting views of the Merkle Tree at different times and/or to 1268 different parties. Both forms of violation will be promptly and 1269 publicly detectable. 1271 Violation of the MMD contract is detected by log clients requesting a 1272 Merkle audit proof for each observed SCT. These checks can be 1273 asynchronous and need only be done once per each certificate. In 1274 order to protect the clients' privacy, these checks need not reveal 1275 the exact certificate to the log. Clients can instead request the 1276 proof from a trusted auditor (since anyone can compute the audit 1277 proofs from the log) or request Merkle proofs for a batch of 1278 certificates around the SCT timestamp. 1280 Violation of the append-only property is detected by global 1281 gossiping, i.e., everyone auditing logs comparing their instances of 1282 the latest Signed Tree Heads. As soon as two conflicting Signed Tree 1283 Heads for the same log are detected, this is cryptographic proof of 1284 that log's misbehavior. 1286 8. Efficiency Considerations 1288 The Merkle Tree design serves the purpose of keeping communication 1289 overhead low. 1291 Auditing logs for integrity does not require third parties to 1292 maintain a copy of each entire log. The Signed Tree Heads can be 1293 updated as new entries become available, without recomputing entire 1294 trees. Third-party auditors need only fetch the Merkle consistency 1295 proofs against a log's existing STH to efficiently verify the append- 1296 only property of updates to their Merkle Trees, without auditing the 1297 entire tree. 1299 9. Future Changes 1301 This section lists things we might address in a Standards Track 1302 version of this document. 1304 o Rather than forcing a log operator to create a new log in order to 1305 change the log signing key, we may allow some key roll mechanism. 1307 o We may add hash and signing algorithm agility. 1309 o We may describe some gossip protocols. 1311 10. Acknowledgements 1313 The authors would like to thank Erwann Abelea, Robin Alden, Al 1314 Cutter, Francis Dupont, Stephen Farrell, Brad Hill, Jeff Hodges, Paul 1315 Hoffman, Jeffrey Hutzelman, SM, Alexey Melnikov, Chris Palmer, Trevor 1316 Perrin, Ryan Sleevi and Carl Wallace for their valuable 1317 contributions. 1319 11. References 1321 11.1. Normative Reference 1323 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1324 Requirement Levels", BCP 14, RFC 2119, March 1997. 1326 11.2. Informative References 1328 [CrosbyWallach] 1329 Crosby, S. and D. Wallach, "Efficient Data Structures for 1330 Tamper-Evident Logging", Proceedings of the 18th USENIX 1331 Security Symposium, Montreal, August 2009, 1332 . 1335 [DSS] National Institute of Standards and Technology, "Digital 1336 Signature Standard (DSS)", FIPS 186-3, June 2009, 1337 . 1340 [EVSSLGuidelines] 1341 CA/Browser Forum, "Guidelines For The Issuance And 1342 Management Of Extended Validation Certificates", 2007, 1343 . 1346 [FIPS.180-4] 1347 National Institute of Standards and Technology, "Secure 1348 Hash Standard", FIPS PUB 180-4, March 2012, 1349 . 1352 [HTML401] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 1353 Specification", World Wide Web Consortium Recommendation 1354 REC-html401-19991224, December 1999, 1355 . 1357 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1358 Adams, "X.509 Internet Public Key Infrastructure Online 1359 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1361 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1362 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1363 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1365 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1366 Standards (PKCS) #1: RSA Cryptography Specifications 1367 Version 2.1", RFC 3447, February 2003. 1369 [RFC4627] Crockford, D., "The application/json Media Type for 1370 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1372 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1373 Encodings", RFC 4648, October 2006. 1375 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1376 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1378 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1379 Housley, R., and W. Polk, "Internet X.509 Public Key 1380 Infrastructure Certificate and Certificate Revocation List 1381 (CRL) Profile", RFC 5280, May 2008. 1383 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1384 Time Protocol Version 4: Protocol and Algorithms 1385 Specification", RFC 5905, June 2010. 1387 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1388 Extension Definitions", RFC 6066, January 2011. 1390 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 1391 Verification of Domain-Based Application Service Identity 1392 within Internet Public Key Infrastructure Using X.509 1393 (PKIX) Certificates in the Context of Transport Layer 1394 Security (TLS)", RFC 6125, March 2011. 1396 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 1397 Transparency", RFC 6962, June 2013. 1399 Authors' Addresses 1401 Ben Laurie 1402 Google UK Ltd. 1404 EMail: benl@google.com 1406 Adam Langley 1407 Google Inc. 1409 EMail: agl@google.com 1411 Emilia Kasper 1412 Google Switzerland GmbH 1414 EMail: ekasper@google.com 1416 Rob Stradling 1417 Comodo CA, Ltd. 1419 EMail: rob.stradling@comodo.com