idnits 2.17.1 draft-laurie-pki-sunlight-12.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 18, 2013) is 4019 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 226 -- Looks like a reference, but probably isn't: '7' on line 353 -- Looks like a reference, but probably isn't: '32' on line 711 == Missing Reference: 'TBD' is mentioned on line 640, but not defined ** Obsolete normative reference: RFC 2560 (Obsoleted by RFC 6960) ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 4627 (Obsoleted by RFC 7158, RFC 7159) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) Summary: 6 errors (**), 0 flaws (~~), 2 warnings (==), 4 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 Intended status: Experimental E. Kasper 5 Expires: October 20, 2013 Google 6 April 18, 2013 8 Certificate Transparency 9 draft-laurie-pki-sunlight-12 11 Abstract 13 This document describes an experimental protocol for publicly logging 14 the existence of TLS certificates as they are issued or observed, in 15 a manner that allows anyone to audit certificate authority activity 16 and notice the issuance of suspect certificates, as well as to audit 17 the certificate logs themselves. The intent is that eventually 18 clients would refuse to honor certificates which do not appear in a 19 log, effectively forcing CAs to add all issued certificates to the 20 logs. 22 Logs are network services which implement the protocol operations for 23 submissions and queries that are defined in this document. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on October 20, 2013. 42 Copyright Notice 44 Copyright (c) 2013 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. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Informal introduction . . . . . . . . . . . . . . . . . . . . 4 60 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 5 61 1.2. Data structures . . . . . . . . . . . . . . . . . . . . . 5 62 2. Cryptographic components . . . . . . . . . . . . . . . . . . . 6 63 2.1. Merkle Hash Trees . . . . . . . . . . . . . . . . . . . . 6 64 2.1.1. Merkle audit paths . . . . . . . . . . . . . . . . . . 6 65 2.1.2. Merkle consistency proofs . . . . . . . . . . . . . . 7 66 2.1.3. Example . . . . . . . . . . . . . . . . . . . . . . . 8 67 2.1.4. Signatures . . . . . . . . . . . . . . . . . . . . . . 10 68 3. Log Format and Operation . . . . . . . . . . . . . . . . . . . 11 69 3.1. Log Entries . . . . . . . . . . . . . . . . . . . . . . . 11 70 3.2. Structure of the Signed Certificate Timestamp . . . . . . 14 71 3.3. Including the Signed Certificate Timestamp in the TLS 72 Handshake . . . . . . . . . . . . . . . . . . . . . . . . 15 73 3.3.1. TLS Extension . . . . . . . . . . . . . . . . . . . . 16 74 3.4. Merkle Tree . . . . . . . . . . . . . . . . . . . . . . . 17 75 3.5. Signed Tree Head . . . . . . . . . . . . . . . . . . . . . 18 76 4. Log Client Messages . . . . . . . . . . . . . . . . . . . . . 19 77 4.1. Add Chain to Log . . . . . . . . . . . . . . . . . . . . . 19 78 4.2. Add PreCertChain to Log . . . . . . . . . . . . . . . . . 20 79 4.3. Retrieve Latest Signed Tree Head . . . . . . . . . . . . . 20 80 4.4. Retrieve Merkle Consistency Proof between two Signed 81 Tree Heads . . . . . . . . . . . . . . . . . . . . . . . . 20 82 4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash . . . . 21 83 4.6. Retrieve Entries from Log . . . . . . . . . . . . . . . . 21 84 4.7. Retrieve Accepted Root Certificates . . . . . . . . . . . 22 85 4.8. Retrieve Entry+Merkle Audit Proof from Log . . . . . . . . 22 86 5. Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 5.1. Submitters . . . . . . . . . . . . . . . . . . . . . . . . 24 88 5.2. TLS Client . . . . . . . . . . . . . . . . . . . . . . . . 24 89 5.3. Monitor . . . . . . . . . . . . . . . . . . . . . . . . . 24 90 5.4. Auditor . . . . . . . . . . . . . . . . . . . . . . . . . 25 91 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 27 93 7.1. Misissued Certificates . . . . . . . . . . . . . . . . . . 27 94 7.2. Detection of Misissue . . . . . . . . . . . . . . . . . . 27 95 7.3. Misbehaving logs . . . . . . . . . . . . . . . . . . . . . 27 96 8. Efficiency Considerations . . . . . . . . . . . . . . . . . . 29 97 9. Future Changes . . . . . . . . . . . . . . . . . . . . . . . . 30 98 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 99 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 32 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 102 1. Informal introduction 104 Certificate Transparency aims to mitigate the problem of misissued 105 certificates by providing publicly auditable, append-only, untrusted 106 logs of all issued certificates. The logs are publicly auditable so 107 that it is possible for anyone to verify the correctness of each log, 108 and to monitor when new certificates are added to it. The logs do 109 not themselves prevent misissue, but they ensure that interested 110 parties (particularly those named in certificates) can detect such 111 misissuance. Note that this is a general mechanism, but in this 112 document we only describe its use for public TLS server certificates 113 issued by public certificate authorities (CAs). 115 Each log consists of certificate chains, which can be submitted by 116 anyone. It is expected that public CAs will contribute all their 117 newly-issued certificates to one or more logs; it is also expected 118 that certificate holders will contribute their own certificate 119 chains. In order to avoid logs being spammed into uselessness, it is 120 required that each chain is rooted in a known CA certificate. When a 121 chain is submitted to a log, a signed timestamp is returned, which 122 can later be used to provide evidence to clients that the chain has 123 been submitted. TLS clients can thus require that all certificates 124 they see have been logged. 126 Those who are concerned about misissue can monitor the logs, asking 127 them regularly for all new entries, and can thus check whether 128 domains they are responsible for have had certificates issued that 129 they did not expect. What they do with this information, 130 particularly when they find that a misissuance has happened, is 131 beyond the scope of this document, but broadly speaking they can 132 invoke existing business mechanisms for dealing with misissued 133 certificates. Of course, anyone who wants can monitor the logs, and 134 if they believe a certificate is incorrectly issued, take action as 135 they see fit. 137 Similarly, those who have seen signed timestamps from a particular 138 log can later demand a proof of inclusion from that log. If the log 139 is unable to provide this (or, indeed, if the corresponding 140 certificate is absent from monitors' copies of that log), that is 141 evidence of the incorrect operation of the log. The checking 142 operation is asynchronous to allow TLS connections to proceed without 143 delay, despite network connectivity issues and the vagaries of 144 firewalls. 146 The append-only property of each log is technically achieved using 147 Merkle Trees, which can be used to show that any particular version 148 of the log is a superset of any particular previous version. 149 Likewise, Merkle Trees avoid the need to blindly trust logs: if a log 150 attempts to show different things to different people, this can be 151 efficiently detected by comparing tree roots and consistency proofs. 152 Similarly, other misbehaviours of any log (e.g., issuing signed 153 timestamps for certificates they then don't log) can be efficiently 154 detected and proved to the world at large. 156 1.1. Requirements Language 158 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 159 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 160 document are to be interpreted as described in RFC 2119 [RFC2119]. 162 1.2. Data structures 164 Data structures are defined according to the conventions laid out in 165 section 4 of [RFC5246]. 167 2. Cryptographic components 169 2.1. Merkle Hash Trees 171 Logs use a binary Merkle hash tree for efficient auditing. The 172 hashing algorithm is SHA-256 [FIPS.180-2.2002] (note that this is 173 fixed for this experiment but it is anticipated that each log would 174 be able to specify a hash algorithm). The input to the Merkle Tree 175 Hash is a list of data entries; these entries will be hashed to form 176 the leaves of the Merkle hash tree. The output is a single 32-byte 177 Merkle Tree Hash. Given an ordered list of n inputs, D[n] = {d(0), 178 d(1), ..., d(n-1)}, the Merkle Tree Hash (MTH) is thus defined as 179 follows: 181 The hash of an empty list is the hash of an empty string: 183 MTH({}) = SHA-256(). 185 The hash of a list with one entry (also known as a leaf hash) is: 187 MTH({d(0)}) = SHA-256(0x00 || d(0)). 189 For n > 1, let k be the largest power of two smaller than n (i.e., k 190 < n <= 2k). The Merkle Tree Hash of an n-element list D[n] is then 191 defined recursively as 193 MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])), 195 where || is concatenation and D[k1:k2] denotes the list {d(k1), 196 d(k1+1),..., d(k2-1)} of length (k2 - k1). (Note that the hash 197 calculation for leaves and nodes differ. This domain separation is 198 required to give second preimage resistance.) 200 Note that we do not require the length of the input list to be a 201 power of two. The resulting Merkle tree may thus not be balanced, 202 however, its shape is uniquely determined by the number of leaves. 203 [This Merkle tree is essentially the same as the history tree 204 [CrosbyWallach] proposal, except our definition handles non-full 205 trees differently.] 207 2.1.1. Merkle audit paths 209 A Merkle audit path for a leaf in a Merkle hash tree is the shortest 210 list of additional nodes in the Merkle tree required to compute the 211 Merkle Tree Hash for that tree. Each node in the tree is either a 212 leaf node, or is computed from the two nodes immediately below it 213 (i.e., towards the leaves). At each step up the tree (towards the 214 root), a node from the audit path is combined with the node computed 215 so far. In other words, the audit path consists of the list of 216 missing nodes required to compute the nodes leading from a leaf to 217 the root of the tree. If the root computed from the audit path 218 matches the true root, then the audit path is proof that the leaf 219 exists in the tree. 221 Given an ordered list of n inputs to the tree, D[n] = {d(0), ..., 222 d(n-1)}, the Merkle audit path PATH(m, D[n]) for the (m+1)th input 223 d(m), 0 <= m < n, is defined as follows: 225 The path for the single leaf in a tree with a one-element input list 226 D[1] = {d(0)} is empty: 228 PATH(0, {d(0)}) = {} 230 For n > 1, let k be the largest power of two smaller than n. The 231 path for the (m+1)th element d(m) in a list of n > m elements is then 232 defined recursively as 234 PATH(m, D[n]) = PATH(m, D[0:k]) : MTH(D[k:n]) for m < k; and 236 PATH(m, D[n]) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m >= k, 238 where : is concatenation of lists and D[k1:k2] denotes the length (k2 239 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before. 241 2.1.2. Merkle consistency proofs 243 Merkle consistency proofs prove the append-only property of the tree. 244 A Merkle consistency proof for a Merkle Tree Hash MTH(D[n]) and a 245 previously advertised hash MTH(D[0:m]) of the first m leaves, m <= n, 246 is the list of nodes in the Merkle tree required to verify that the 247 first m inputs D[0:m] are equal in both trees. Thus, a consistency 248 proof must contain a set of intermediate nodes (i.e., commitments to 249 inputs) sufficient to verify MTH(D[n]), such that (a subset of) the 250 same nodes can be used to verify MTH(D[0:m]). We define an algorithm 251 that outputs the (unique) minimal consistency proof. 253 Given an ordered list of n inputs to the tree, D[n] = {d(0), ..., 254 d(n-1)}, the Merkle consistency proof PROOF(m, D[n]) for a previous 255 Merkle Tree Hash MTH(D[0:m]), 0 < m < n, is defined as: 257 PROOF(m, D[n]) = SUBPROOF(m, D[n], true) 259 The subproof for m = n is empty if m is the value for which PROOF was 260 originally requested (meaning that the subtree Merkle Tree Hash 261 MTH(D[0:m]) is known): 263 SUBPROOF(m, D[m], true) = {} 265 The subproof for m = n is the Merkle Tree Hash committing inputs 266 D[0:m] otherwise: 268 SUBPROOF(m, D[m], false) = {MTH(D[m])} 270 For m < n, let k be the largest power of two smaller than n. The 271 subproof is then defined recursively. 273 If m <= k, the right subtree entries D[k:n] only exist in the current 274 tree. We prove that the left subtree entries D[0:k] are consistent 275 and add a commitment to D[k:n]: 277 SUBPROOF(m, D[n], b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n]). 279 If m > k, the left subtree entries D[0:k] are identical in both 280 trees. We prove that the right subtree entries D[k:n] are consistent 281 and add a commitment to D[0:k]. 283 SUBPROOF(m, D[n], b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k]). 285 Here : is concatenation of lists and D[k1:k2] denotes the length (k2 286 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before. 288 The number of nodes in the resulting proof is bounded above by 289 ceil(log2(n)) + 1. 291 2.1.3. Example 293 The binary Merkle tree with 7 leaves: 295 hash 296 / \ 297 / \ 298 / \ 299 / \ 300 / \ 301 k l 302 / \ / \ 303 / \ / \ 304 / \ / \ 305 g h i j 306 / \ / \ / \ | 307 a b c d e f d6 308 | | | | | | 309 d0 d1 d2 d3 d4 d5 310 The audit path for d0 is [b, h, l]. 312 The audit path for d3 is [c, g, l]. 314 The audit path for d4 is [f, j, k]. 316 The audit path for d6 is [i, k]. 318 The same tree, built incrementally in four steps: 320 hash0 hash1=k 321 / \ / \ 322 / \ / \ 323 / \ / \ 324 g c g h 325 / \ | / \ / \ 326 a b d2 a b c d 327 | | | | | | 328 d0 d1 d0 d1 d2 d3 330 hash2 hash 331 / \ / \ 332 / \ / \ 333 / \ / \ 334 / \ / \ 335 / \ / \ 336 k i k l 337 / \ / \ / \ / \ 338 / \ e f / \ / \ 339 / \ | | / \ / \ 340 g h d4 d5 g h i j 341 / \ / \ / \ / \ / \ | 342 a b c d a b c d e f d6 343 | | | | | | | | | | 344 d0 d1 d2 d3 d0 d1 d2 d3 d4 d5 346 The consistency proof between hash0 and hash is PROOF(3, D[7]) = [c, 347 d, g, l]. c, g are used to verify hash0, and d, l are additionally 348 used to show hash is consistent with hash0. 350 The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l]. 351 hash can be verified, using hash1=k and l. 353 The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i, 354 j, k]. k, i are used to verify hash2, and j is additionally used to 355 show hash is consistent with hash2. 357 2.1.4. Signatures 359 Various data structures are signed. A log MUST use either elliptic 360 curve signatures using the NIST P-256 curve (section D.1.2.3 of DSS 361 [DSS]) or RSA signatures (RSASSA-PKCS1-V1_5 with SHA-256, section 8.2 362 of [RFC3447]) using a key of at least 2048 bits. 364 3. Log Format and Operation 366 Anyone can submit certificates to certificate logs for public 367 auditing, however, since certificates will not be accepted by TLS 368 clients unless logged, it is expected that certificate owners or 369 their CAs will usually submit them. A log is a single, ever-growing, 370 append-only Merkle Tree of such certificates. 372 When a valid certificate is submitted to a log, the log MUST 373 immediately return a Signed Certificate Timestamp (SCT). The SCT is 374 the log's promise to incorporate the certificate in the Merkle Tree 375 within a fixed amount of time known as the Maximum Merge Delay (MMD). 376 If the log has previously seen the certificate, it MAY return the 377 same SCT as it returned before. TLS servers MUST present an SCT from 378 one or more logs to the TLS client together with the certificate. 379 TLS clients MUST reject certificates that do not have a valid SCT for 380 the end-entity certificate. 382 Periodically, each log appends all its new entries to the Merkle 383 Tree, and signs the root of the tree. Auditors can thus verify that 384 each certificate for which an SCT has been issued indeed appears in 385 the log. The log MUST incorporate a certificate in its Merkle Tree 386 within the Maximum Merge Delay period after the issuance of the SCT. 388 Log operators MUST NOT impose any conditions on retrieving or sharing 389 data from the log. 391 3.1. Log Entries 393 Anyone can submit a certificate to any log. In order to enable 394 attribution of each logged certificate to its issuer, the log SHALL 395 publish a list of acceptable root certificates (this list might 396 usefully be the union of root certificates trusted by major browser 397 vendors). Each submitted certificate MUST be accompanied by all 398 additional certificates required to verify the certificate chain up 399 to an accepted root certificate. The root certificate itself MAY be 400 omitted from the chain submitted to the log server. 402 Alternatively, (root as well as intermediate) Certificate Authorities 403 may submit a certificate to logs prior to issuance. To do so, the CA 404 submits a Precertificate that the log can use to create an entry that 405 will be valid against the issued certificate. The Precertificate is 406 constructed from the certificate to be issued by adding a special 407 critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3, whose 408 extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)) to the 409 end entity TBSCertificate (this extension is to ensure that the 410 Precertificate cannot be validated by a standard X.509v3 client), and 411 signing the resulting TBSCertificate [RFC5280] with either 412 o a special-purpose (CA:true, Extended Key Usage: Certificate 413 Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing 414 Certificate. The Precertificate Signing Certificate MUST be 415 directly certified by the (root or intermediate) CA certificate 416 that will ultimately sign the end entity TBSCertificate yielding 417 the end entity certificate (note that the log may relax standard 418 validation rules to allow this, so long as the issued certificate 419 will be valid), 421 o or, the CA certificate that will sign the final certificate. 423 As above, the Precertificate submission MUST be accompanied by the 424 Precertificate Signing Certificate, if used, and all additional 425 certificates required to verify the chain up to an accepted root 426 certificate. The signature on the TBSCertificate indicates the 427 Certificate Authority's intent to issue a certificate. This intent 428 is considered binding (i.e., misissuance of the Precertificate is 429 considered equal to misissuance of the final certificate). Each log 430 verifies the Precertificate signature chain, and issues a Signed 431 Certificate Timestamp on the corresponding TBSCertificate. 433 Logs MUST verify that the submitted end entity certificate or 434 Precertificate has a valid signature chain leading back to a trusted 435 root CA certificate, using the chain of intermediate CA certificates 436 provided by the submitter. Logs MAY accept certificates that have 437 expired, are not yet valid, have been revoked or are otherwise not 438 fully valid according to X.509 verification rules in order to 439 accommodate quirks of CA certificate issuing software. However, logs 440 MUST refuse to publish certificates without a valid chain to a known 441 root CA. If a certificate is accepted and an SCT issued, the 442 accepting log MUST store the entire chain used for verification 443 including the certificate or Precertificate itself, and including the 444 root certificate used to verify the chain (even if it was omitted 445 from the submission) and MUST present this chain for auditing upon 446 request. This chain is required to prevent a CA avoiding blame by 447 logging a partial or empty chain [Note: this effectively excludes 448 self-signed and DANE-based certificates until some mechanism to 449 control spam for those certificates is found - the authors welcome 450 suggestions]. 452 Each certificate entry in a log MUST include the following 453 components: 455 enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType; 457 struct { 458 LogEntryType entry_type; 459 select (entry_type) { 460 case x509_entry: X509ChainEntry; 461 case precert_entry: PrecertChainEntry; 462 } entry; 463 } LogEntry; 465 opaque ASN.1Cert<1..2^24-1>; 467 struct { 468 ASN.1Cert leaf_certificate; 469 ASN.1Cert certificate_chain<0..2^24-1>; 470 } X509ChainEntry; 472 struct { 473 ASN.1Cert pre_certificate; 474 ASN.1Cert precertificate_chain<0..2^24-1>; 475 } PrecertChainEntry; 477 Logs MAY limit the length of chain they will accept. 479 "entry_type" is the type of this entry. Future revisions of this 480 protocol version may add new LogEntryType values. Section 4 explains 481 how clients should handle unknown entry types. 483 "leaf_certificate" is the end-entity certificate submitted for 484 auditing. 486 "certificate_chain" is a chain of additional certificates required to 487 verify the end entity certificate. The first certificate MUST 488 certify the end entity certificate. Each following certificate MUST 489 directly certify the one preceding it. The final certificate MUST be 490 a root certificate accepted by the log. 492 "pre_certificate" is the Precertificate submited for auditing. 494 "precertificate_chain" is a chain of additional certificates required 495 to verify the Precertificate submission. The first certificate MAY 496 be a valid Precertificate Signing Certificate, and MUST certify the 497 first certificate. Each following certificate MUST directly certify 498 the one preceding it. The final certificate MUST be a root 499 certificate accepted by the log. 501 3.2. Structure of the Signed Certificate Timestamp 503 enum { certificate_timestamp(0), tree_hash(1), (255) } 504 SignatureType; 506 enum { v1(0), (255) } 507 Version; 509 struct { 510 opaque key_id[32]; 511 } LogID; 513 opaque TBSCertificate<1..2^24-1>; 515 struct { 516 opaque issuer_key_hash[32]; 517 TBSCertificate tbs_certificate; 518 } PreCert; 520 opaque CtExtensions<0..2^16-1>; 522 "key_id" is the SHA-256 hash of the log's public key, calculated over 523 the DER encoding of the key represented as SubjectPublicKeyInfo. 525 "issuer_key_hash" is the SHA-256 hash of the certificate issuer's 526 public key, calculated over the DER encoding of the key represented 527 as SubjectPublicKeyInfo. This is needed to bind the issuer to the 528 final certificate. 530 "tbs_certificate" is the DER encoded TBSCertificate (see [RFC5280]) 531 component of the Precertificate - that is, without the signature and 532 the poison extension. If the Precertificate is not signed with the 533 CA certificate that will issue the final certificate, then the 534 TBSCertificate also has its issuer changed to that of the CA that 535 will issue the final certificate. Note that it is also possible to 536 reconstruct this TBSCertificate from the final certificate by 537 extracting the TBSCertificate from it and deleting the SCT extension. 538 Also note that since the TBSCertificate contains an 539 AlgorithmIdentifier that must match both the pre-certificate 540 signature algorithm and final certificate signature algorithm, they 541 must be signed with the same algorithm and parameters. If the 542 Precertificate is issued using a Precertificate Signing Certificate, 543 and an Authority Key Identifier extension is present in the 544 TBSCertificate, the corresponding extension must also be present in 545 the Precertificate Signing Certificate - in this case, the 546 TBSCertificate also has its Authority Key Identifier changed to match 547 the final issuer. 549 struct { 550 Version sct_version; 551 LogID id; 552 uint64 timestamp; 553 CtExtensions extensions; 554 digitally-signed struct { 555 Version sct_version; 556 SignatureType signature_type = certificate_timestamp; 557 uint64 timestamp; 558 LogEntryType entry_type; 559 select(entry_type) { 560 case x509_entry: ASN.1Cert; 561 case precert_entry: PreCert; 562 } signed_entry; 563 CtExtensions extensions; 564 }; 565 } SignedCertificateTimestamp; 567 The encoding of the digitally-signed element is defined in [RFC5246]. 569 "sct_version" is the version of the protocol the SCT conforms to. 570 This version is v1. 572 "timestamp" is the current NTP Time [RFC5905], measured since the 573 epoch (January 1, 1970, 00:00), ignoring leap seconds, in 574 milliseconds. 576 "entry_type" may be implicit from the context in which the SCT is 577 presented. 579 "signed_entry" is the "leaf_certificate" (in case of an 580 X509ChainEntry), or is the PreCert (in case of a PrecertChainEntry), 581 as described above. 583 "extensions" are future extensions to this protocol version (v1). 584 Currently, no extensions are specified. 586 3.3. Including the Signed Certificate Timestamp in the TLS Handshake 588 The SCT data corresponding to the end entity certificate from at 589 least one log must be included in the TLS handshake, either by using 590 an X509v3 certificate extension as described below, by using a TLS 591 Extension (section 7.4.1.4 of [RFC5246]) with type [TBD], or by using 592 OCSP Stapling (section 8 of [RFC6066]), where the response includes 593 an OCSP extension with OID 1.3.6.1.4.1.11129.2.4.5 (see [RFC2560]) 594 and body: 596 SignedCertificateTimestampList ::= OCTET STRING 598 At least one SCT MUST be included. Server operators MAY include more 599 than one SCT. 601 Similarly, a Certificate Authority MAY submit a precertificate to 602 more than one log, and all obtained SCTs can be directly embedded in 603 the final certificate, by encoding the SignedCertificateTimestampList 604 structure as an ASN.1 OCTET STRING and inserting the resulting data 605 in the TBSCertificate as an X.509v3 certificate extension (OID 606 1.3.6.1.4.1.11129.2.4.2). Upon receiving the certificate, clients 607 can reconstruct the original TBSCertificate to verify the SCT 608 signature. 610 The contents of the ASN.1 OCTET STRING embedded in an OCSP extension 611 or X509v3 certificate extension are as follows: 613 opaque SerializedSCT<1..2^16-1>; 615 struct { 616 SerializedSCT sct_list <1..2^16-1>; 617 } SignedCertificateTimestampList; 619 Here "SerializedSCT" is an opaque bytestring that contains the 620 serialized TLS structure. This encoding ensures that TLS clients can 621 decode each SCT individually (i.e., if there is a version upgrade, 622 out of date clients can still parse old SCTs while skipping over new 623 SCTs whose version they don't understand). 625 Likewise, SCTs can be embedded in a TLS Extension. See below for 626 details. 628 TLS clients MUST implement all three mechanisms. Servers MUST 629 implement at least one of the three mechanisms. Note that existing 630 TLS servers can generally use the certificate extension mechanism 631 without modification. 633 TLS servers should send SCTs from multiple logs in case one or more 634 logs is not acceptable to the client (for example, if a log has been 635 struck off for misbehaviour or has had a key compromise). 637 3.3.1. TLS Extension 639 The SCT can be sent during the TLS handshake using a TLS extension, 640 type [TBD]. 642 Clients that support the extension SHOULD send a ClientHello 643 extension with the appropriate type and empty "extension_data". 645 Servers MUST only send SCTs to clients who have indicated support for 646 the extension in the ClientHello, in which case the SCTs are sent by 647 setting the "extension_data" to a "SignedCertificateTimestampList". 649 Session resumption uses the original session information: clients 650 SHOULD include the extension type in the ClientHello but if the 651 session is resumed, the server is not expected to process it or 652 include the extension in the ServerHello. 654 3.4. Merkle Tree 656 The hashing algorithm for the Merkle Tree Hash is SHA-256. 658 Structure of the Merkle Tree input: 660 enum { timestamped_entry(0), (255) } 661 MerkleLeafType; 663 struct { 664 uint64 timestamp; 665 LogEntryType entry_type; 666 select(entry_type) { 667 case x509_entry: ASN.1Cert; 668 case precert_entry: PreCert; 669 } signed_entry; 670 CtExtensions extensions; 671 } TimestampedEntry; 673 struct { 674 Version version; 675 MerkleLeafType leaf_type; 676 select (leaf_type) { 677 case timestamped_entry: TimestampedEntry; 678 } 679 } MerkleTreeLeaf; 681 Here "version" is the version of the protocol the MerkleTreeLeaf 682 corresponds to. This version is v1. 684 "leaf_type" is the type of the leaf input. Currently, only 685 "timestamped_entry" (corresponding to an SCT) is defined. Future 686 revisions of this protocol version may add new MerkleLeafType types. 687 Section 4 explains how clients should handle unknown leaf types. 689 "timestamp" is the timestamp of the corresponding SCT issued for this 690 certificate. 692 "signed_entry" is the "signed_entry" of the corresponding SCT. 694 "extensions" are "extensions" of the corresponding SCT. 696 The leaves of the Merkle Tree are the leaf hashes of the 697 corresponding "MerkleTreeLeaf" structures. 699 3.5. Signed Tree Head 701 Every time a log appends new entries to the tree, the log SHOULD sign 702 the corresponding tree hash and tree information (see the 703 corresponding Signed Tree Head client message in Section 4.3). The 704 signature for that data is structured as follows: 706 digitally-signed struct { 707 Version version; 708 SignatureType signature_type = tree_hash; 709 uint64 timestamp; 710 uint64 tree_size; 711 opaque sha256_root_hash[32]; 712 } TreeHeadSignature; 714 "version" is the version of the protocol the TreeHeadSignature 715 conforms to. This version is v1. 717 "timestamp" is the current time. The timestamp MUST be at least as 718 recent as the most recent SCT timestamp in the tree. Each subsequent 719 timestamp MUST be more recent than the timestamp of the previous 720 update. 722 "tree_size" equals the number of entries in the new tree. 724 "sha256_root_hash" is the root of the Merkle Hash Tree. 726 Each log MUST produce on demand a Signed Tree Head that is no older 727 than the Maximum Merge Delay. In the unlikely event that it receives 728 no new submissions during an MMD period, the log SHALL sign the same 729 Merkle Tree Hash with a fresh timestamp. 731 4. Log Client Messages 733 Messages are sent as HTTPS GET or POST requests. Parameters for 734 POSTs and all responses are encoded as JSON objects [RFC4627]. 735 Parameters for GETs are encoded as order independent key/value URL 736 parameters, using the "application/x-www-form-urlencoded" format 737 described in the "HTML 4.01 Specification" [HTML401]. Binary data is 738 base64 encoded [RFC4648] as specified in the individual messages. 740 Note that JSON objects and URL parameters may contain fields not 741 specified here. These extra fields should be ignored. 743 The prefix can include a path as well as a server name 744 and a port. 746 In general, where needed, the "version" is v1 and the "id" is the log 747 id for the log server queried. 749 Any errors will be returned as HTTP 4xx or 5xx responses, with human 750 readable error messages. 752 4.1. Add Chain to Log 754 POST https:///ct/v1/add-chain 756 Inputs 758 chain An array of base64 encoded certificates. The first element is 759 the end entity certificate, the second chains to the first and so 760 on to the last, which is either the root certificate or a 761 certificate that chains to a known root certificate. 763 Outputs 765 sct_version The version of the SignedCertificateTimestamp structure, 766 in decimal. A compliant v1 implementation MUST NOT expect this to 767 be 0 (i.e., v1). 769 id The log ID, base64 encoded. Since log clients who request an SCT 770 for inclusion in TLS handshakes are not required to verify it, we 771 do not assume they know the ID of the log. 773 timestamp The SCT timestamp, in decimal. 775 extensions An opaque type for future expansion. It is likely that 776 not all participants will need to understand data in this field. 777 Logs should set this to the empty string. Clients should decode 778 the base64 encoded data and include it in the SCT. 780 signature The SCT signature, base64 encoded. 782 If the "sct_version" is not v1, then a v1 client may be unable to 783 verify the signature. It MUST NOT construe this as an error. [Note: 784 log clients don't need to be able to verify this structure, only TLS 785 clients do - if we were to serve the structure binary, then we could 786 completely change it without requiring an upgrade to v1 clients]. 788 4.2. Add PreCertChain to Log 790 POST https:///ct/v1/add-pre-chain 792 Inputs 794 chain An array of base64 encoded precertificates. The first element 795 is the end entity certificate, the second chains to the first and 796 so on to the last, which is either the root certificate or a 797 certificate that chains to a known root certificate. 799 Outputs are the same as Section 4.1. 801 4.3. Retrieve Latest Signed Tree Head 803 GET https:///ct/v1/get-sth 805 No inputs. 807 Outputs 809 tree_size The size of the tree, in entries, in decimal. 811 timestamp The timestamp, in decimal. 813 sha256_root_hash The Merkle Tree Hash of the tree, in base64. 815 tree_head_signature A TreeHeadSignature for the above data. 817 4.4. Retrieve Merkle Consistency Proof between two Signed Tree Heads 819 GET https:///ct/v1/get-sth-consistency 821 Inputs 823 first The tree_size of the first tree, in decimal. 825 second The tree_size of the second tree, in decimal. 827 Both tree sizes must be from existing v1 STHs (Signed Tree Heads). 829 Outputs 831 consistency An array of Merkle tree nodes, base64 encoded. 833 Note that no signature is required on this data, as it is used to 834 verify an STH, which is signed. 836 4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash 838 GET https:///ct/v1/get-proof-by-hash 840 Inputs 842 hash A base64 encoded v1 leaf hash. 844 tree_size The tree_size of the tree to base the proof on, in 845 decimal. 847 The "hash" must be calculated as defined in Section 3.4. The 848 "tree_size" must designate an existing v1 STH. 850 Outputs 852 leaf_index The 0-based index of the end entity corresponding to the 853 "hash" parameter. 855 audit_path An array of base64 encoded Merkle tree nodes proving the 856 inclusion of the chosen certificate. 858 4.6. Retrieve Entries from Log 860 GET https:///ct/v1/get-entries 862 Inputs 864 start 0-based index of first entry to retrieve, in decimal. 866 end 0-based index of last entry to retrieve, in decimal. 868 Outputs 869 entries An array of objects, each consisting of 871 leaf_input The base64-encoded MerkleTreeLeaf structure. 873 extra_data The base64-encoded unsigned data pertaining to the log 874 entry. In the case of an X509ChainEntry, this is the 875 "certificate_chain". In the case of a PrecertChainEntry, this 876 is the whole "PrecertChainEntry". 878 Note that this message is not signed - the retrieved data can be 879 verified by constructing the Merkle Tree Hash corresponding to a 880 retrieved STH. All leaves MUST be v1. However, a compliant v1 881 client MUST NOT construe an unrecognized MerkleLeafType or 882 LogEntryType value as an error. This means it may be unable to parse 883 some entries, but note that each client can inspect the entries it 884 does recognize, as well as verify the integrity of the data by 885 treating unrecognized leaves as opaque input to the tree. 887 The "start" and "end" parameters SHOULD be within the range 0 <= x < 888 "tree_size" as returned by "get-sth" in Section 4.3. 890 Logs MAY honour requests where 0 <= "start" < "tree_size", and "end" 891 >= "tree_size" by returning a partial response covering only the 892 valid entries in the specified range. Note that the following 893 restriction may also apply: 895 Logs MAY restrict the number of entries which can be retrieved per 896 "get-entries" request. If a client requests more than the permitted 897 number of entries, the log SHALL return the maximum number of entries 898 permissible. These entries SHALL be sequential beginning with the 899 entry specified by "start". 901 4.7. Retrieve Accepted Root Certificates 903 GET https:///ct/v1/get-roots 905 No inputs. 907 Outputs 909 certificates An array of base64 encoded root certificates that are 910 acceptable to the log. 912 4.8. Retrieve Entry+Merkle Audit Proof from Log 914 GET https:///ct/v1/get-entry-and-proof 916 Inputs 917 leaf_index The index of the desired entry. 919 tree_size The tree_size of the tree for which the proof is desired. 921 The tree size must designate an existing STH. 923 Outputs 925 leaf_input The base64-encoded MerkleTreeLeaf structure. 927 extra_data The base64-encoded unsigned data, same as in Section 4.6. 929 audit_path An array of base64 encoded Merkle tree nodes proving the 930 inclusion of the chosen certificate. 932 This API is probably only useful for debugging. 934 5. Clients 936 There are various different functions clients of logs might perform. 937 We describe here some typical clients and how they could function. 938 Any inconsistency may be used as evidence that a log has not behaved 939 correctly, and the signatures on the data structures prevent the log 940 from denying that misbehaviour. 942 All clients should gossip with each other, exchanging STHs at least: 943 this is all that is required to ensure that they all have a 944 consistent view. The exact mechanism for gossip will be described in 945 an separate document, but it is expected there will be a variety. 947 5.1. Submitters 949 Submitters submit certificates or precertificates to the log as 950 described above. They may go on to use the returned SCT to construct 951 a certificate or use it directly in a TLS handshake. 953 5.2. TLS Client 955 TLS clients are not directly clients of the log, but they receive 956 SCTs alongside or in server certificates. In addition to normal 957 validation of the certificate and its chain, they should validate the 958 SCT by computing the signature input from the SCT data as well as the 959 certificate, and verifying the signature, using the corresponding 960 log's public key. Note that this document does not describe how 961 clients obtain the logs' public keys. 963 TLS clients MUST reject SCTs whose timestamp is in the future. 965 5.3. Monitor 967 Monitors watch logs and check that they behave correctly. They also 968 watch for certificates of interest. 970 A monitor needs to, at least, inspect every new entry in each log it 971 watches. It may also want to keep copies of entire logs. In order 972 to do this, it should follow these steps for each log: 974 1. Fetch the current STH using Section 4.3. 976 2. Verify the STH signature. 978 3. Fetch all the entries in the tree corresponding to the STH using 979 Section 4.6. 981 4. Confirm that the tree made from the fetched entries produces the 982 same hash as that in the STH. 984 5. Fetch the current STH using Section 4.3. Repeat until STH 985 changes. 987 6. Verify the STH signature. 989 7. Fetch all the new entries in the tree corresponding to the STH 990 using Section 4.6. If they remain unavailable for an extended 991 period, then this should be viewed as misbehaviour on the part of 992 the log. 994 8. Either: 996 1. Verify that the updated list of all entries generates a tree 997 with the same hash as the new STH. 999 Or, if it is not keeping all log entries: 1001 2. Fetch a consistency proof for the new STH with the previous 1002 STH using Section 4.4. 1004 3. Verify the consistency proof. 1006 4. Verify that the new entries generate the corresponding 1007 elements in the consistency proof. 1009 9. Go to Step 5. 1011 5.4. Auditor 1013 Auditors take partial information about a log as input and verify 1014 that this information is consistent with other partial information 1015 they have. An auditor might be an integral component of a TLS 1016 client, it might be a standalone service or it might be a secondary 1017 function of a monitor. 1019 Any pair of STHs from the same log can be verified by requesting a 1020 consistency proof using Section 4.4. 1022 A certificate accompanied by an SCT can be verified against any STH 1023 dated after the SCT timestamp + the Maximum Merge Delay by requesting 1024 a Merkle Audit Proof using Section 4.5. 1026 Auditors can fetch STHs from time to time of their own accord, of 1027 course, using Section 4.3. 1029 6. IANA Considerations 1031 IANA is requested to allocate an RFC 5246 ExtensionType Value for the 1032 CTS TLS extension. The Extension name is 1033 "signed_certificate_timestamp". 1035 7. Security Considerations 1037 With CAs, logs, and servers performing the actions described here, 1038 TLS clients can use logs and signed timestamps to reduce the 1039 likelihood that they will accept misissued certificates. If a server 1040 presents a valid signed timestamp for a certificate, then the client 1041 knows that the certificate has been published in a log. From this, 1042 the client knows that the subject of the certificate has had some 1043 time to notice the misissue and take some action, such as asking a CA 1044 to revoke a misissued certificate. A signed timestamp is not a 1045 guarantee that the certificate is not misissued, since the subject of 1046 the certificate might not have checked the logs or the CA might have 1047 refused to revoke the certificate. 1049 In addition, if TLS clients will not accept unlogged certificates, 1050 then site owners will have a greater incentive to submit certificates 1051 to logs, possibly with the assistance of their CA, increasing the 1052 overall transparency of the system. 1054 7.1. Misissued Certificates 1056 Misissued certificates that have not been publicly logged, and thus 1057 do not have a valid SCT, will be rejected by TLS clients. Misissued 1058 certificates that do have an SCT from a log will appear in that 1059 public log within the Maximum Merge Delay, assuming the log is 1060 operating correctly. Thus, the maximum period of time during which a 1061 misissued certificate can be used without being available for audit 1062 is the MMD. 1064 7.2. Detection of Misissue 1066 The logs do not themselves detect misissued certificates, they rely 1067 instead on interested parties, such as domain owners, to monitor them 1068 and take corrective action when a misissue is detected. 1070 7.3. Misbehaving logs 1072 A log can misbehave in two ways: (1), by failing to incorporate a 1073 certificate with an SCT in the Merkle Tree within the MMD; and (2), 1074 by violating its append-only property by presenting two different, 1075 conflicting views of the Merkle Tree at different times and/or to 1076 different parties. Both forms of violation will be promptly and 1077 publicly detectable. 1079 Violation of the MMD contract is detected by log clients requesting a 1080 Merkle audit proof for each observed SCT. These checks can be 1081 asynchronous, and need only be done once per each certificate. In 1082 order to protect the clients' privacy, these checks need not reveal 1083 the exact certificate to the log. Clients can instead request the 1084 proof from a trusted auditor (since anyone can compute the audit 1085 proofs from the log), or request Merkle proofs for a batch of 1086 certificates around the SCT timestamp. 1088 Violation of the append-only property is detected by global 1089 gossiping, i.e., everyone auditing logs comparing their versions of 1090 the latest signed tree heads. As soon as two conflicting signed tree 1091 heads for the same log are detected, this is cryptographic proof of 1092 that log's misbehaviour. 1094 8. Efficiency Considerations 1096 The Merkle tree design serves the purpose of keeping communication 1097 overhead low. 1099 Auditing logs for integrity does not require third parties to 1100 maintain a copy of each entire log. The Signed Tree Heads can be 1101 updated as new entries become available, without recomputing entire 1102 trees. Third party auditors need only fetch the Merkle consistency 1103 proofs against a log's existing STH to efficiently verify the append- 1104 only property of updates to their Merkle Trees, without auditing the 1105 entire tree. 1107 9. Future Changes 1109 This section lists things we might address in a Standards Track 1110 version of this document. 1112 Rather than forcing a log operator to create a new log in order to 1113 change the log signing key, we may allow some key roll mechanism. 1115 We may add hash and signing algorithm agility. 1117 We may describe some gossip protocols. 1119 10. Acknowledgements 1121 The authors would like to thank Erwann Abelea, Robin Alden, Al 1122 Cutter, Francis Dupont, Stephen Farrell, Brad Hill, Jeff Hodges, Paul 1123 Hoffman, Jeffrey Hutzelman, SM, Alexey Melnikov, Chris Palmer, Trevor 1124 Perrin, Ryan Sleevi, Rob Stradling, Carl Wallace for their valuable 1125 contributions. 1127 11. References 1129 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1130 Requirement Levels", BCP 14, RFC 2119, March 1997. 1132 [RFC2560] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. 1133 Adams, "X.509 Internet Public Key Infrastructure Online 1134 Certificate Status Protocol - OCSP", RFC 2560, June 1999. 1136 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 1137 Standards (PKCS) #1: RSA Cryptography Specifications 1138 Version 2.1", RFC 3447, February 2003. 1140 [RFC4627] Crockford, D., "The application/json Media Type for 1141 JavaScript Object Notation (JSON)", RFC 4627, July 2006. 1143 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 1144 Encodings", RFC 4648, October 2006. 1146 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1147 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1149 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 1150 Housley, R., and W. Polk, "Internet X.509 Public Key 1151 Infrastructure Certificate and Certificate Revocation List 1152 (CRL) Profile", RFC 5280, May 2008. 1154 [RFC5905] Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network 1155 Time Protocol Version 4: Protocol and Algorithms 1156 Specification", RFC 5905, June 2010. 1158 [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: 1159 Extension Definitions", RFC 6066, January 2011. 1161 [DSS] National Institute of Standards and Technology, U.S. 1162 Department of Commerce, "Digital Signature Standard", 1163 FIPS 186-3, June 2009. 1165 [CrosbyWallach] 1166 Crosby, S. and D. Wallach, "Efficient data structures for 1167 tamper-evident logging", 2009. 1169 [HTML401] Hors, A., Raggett, D., and I. Jacobs, "HTML 4.01 1170 Specification", World Wide Web Consortium 1171 Recommendation REC-html401-19991224, December 1999, 1172 . 1174 [FIPS.180-2.2002] 1175 National Institute of Standards and Technology, "Secure 1176 Hash Standard", FIPS PUB 180-2, August 2002, . 1179 Authors' Addresses 1181 Ben Laurie 1182 Google UK Ltd. 1184 Email: benl@google.com 1186 Adam Langley 1187 Google Inc. 1189 Email: agl@google.com 1191 Emilia Kasper 1192 Google Switzerland GmbH 1194 Email: ekasper@google.com