forked from google/certificate-transparency-rfcs
-
Notifications
You must be signed in to change notification settings - Fork 4
/
rfc6962.txt
1515 lines (966 loc) · 53.8 KB
/
rfc6962.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
Internet Engineering Task Force (IETF) B. Laurie
Request for Comments: 6962 A. Langley
Category: Experimental E. Kasper
ISSN: 2070-1721 Google
June 2013
Certificate Transparency
Abstract
This document describes an experimental protocol for publicly logging
the existence of Transport Layer Security (TLS) certificates as they
are issued or observed, in a manner that allows anyone to audit
certificate authority (CA) activity and notice the issuance of
suspect certificates as well as to audit the certificate logs
themselves. The intent is that eventually clients would refuse to
honor certificates that do not appear in a log, effectively forcing
CAs to add all issued certificates to the logs.
Logs are network services that implement the protocol operations for
submissions and queries that are defined in this document.
Status of This Memo
This document is not an Internet Standards Track specification; it is
published for examination, experimental implementation, and
evaluation.
This document defines an Experimental Protocol for the Internet
community. This document is a product of the Internet Engineering
Task Force (IETF). It represents the consensus of the IETF
community. It has received public review and has been approved for
publication by the Internet Engineering Steering Group (IESG). Not
all documents approved by the IESG are a candidate for any level of
Internet Standard; see Section 2 of RFC 5741.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6962.
Laurie, et al. Experimental [Page 1]
RFC 6962 Certificate Transparency June 2013
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Informal Introduction ...........................................3
1.1. Requirements Language ......................................4
1.2. Data Structures ............................................4
2. Cryptographic Components ........................................4
2.1. Merkle Hash Trees ..........................................4
2.1.1. Merkle Audit Paths ..................................5
2.1.2. Merkle Consistency Proofs ...........................6
2.1.3. Example .............................................7
2.1.4. Signatures ..........................................8
3. Log Format and Operation ........................................9
3.1. Log Entries ................................................9
3.2. Structure of the Signed Certificate Timestamp .............12
3.3. Including the Signed Certificate Timestamp in the
TLS Handshake .............................................13
3.3.1. TLS Extension ......................................15
3.4. Merkle Tree ...............................................15
3.5. Signed Tree Head ..........................................16
4. Log Client Messages ............................................17
4.1. Add Chain to Log ..........................................17
4.2. Add PreCertChain to Log ...................................18
4.3. Retrieve Latest Signed Tree Head ..........................18
4.4. Retrieve Merkle Consistency Proof between Two
Signed Tree Heads .........................................19
4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash .........19
4.6. Retrieve Entries from Log .................................20
4.7. Retrieve Accepted Root Certificates .......................21
4.8. Retrieve Entry+Merkle Audit Proof from Log ................21
5. Clients ........................................................21
5.1. Submitters ................................................22
5.2. TLS Client ................................................22
5.3. Monitor ...................................................22
Laurie, et al. Experimental [Page 2]
RFC 6962 Certificate Transparency June 2013
5.4. Auditor ...................................................23
6. IANA Considerations ............................................23
7. Security Considerations ........................................23
7.1. Misissued Certificates ....................................24
7.2. Detection of Misissue .....................................24
7.3. Misbehaving Logs ..........................................24
8. Efficiency Considerations ......................................25
9. Future Changes .................................................25
10. Acknowledgements ..............................................25
11. References ....................................................25
11.1. Normative Reference ......................................25
11.2. Informative References ...................................26
1. Informal Introduction
Certificate transparency aims to mitigate the problem of misissued
certificates by providing publicly auditable, append-only, untrusted
logs of all issued certificates. The logs are publicly auditable so
that it is possible for anyone to verify the correctness of each log
and to monitor when new certificates are added to it. The logs do
not themselves prevent misissue, but they ensure that interested
parties (particularly those named in certificates) can detect such
misissuance. Note that this is a general mechanism, but in this
document, we only describe its use for public TLS server certificates
issued by public certificate authorities (CAs).
Each log consists of certificate chains, which can be submitted by
anyone. It is expected that public CAs will contribute all their
newly issued certificates to one or more logs; it is also expected
that certificate holders will contribute their own certificate
chains. In order to avoid logs being spammed into uselessness, it is
required that each chain is rooted in a known CA certificate. When a
chain is submitted to a log, a signed timestamp is returned, which
can later be used to provide evidence to clients that the chain has
been submitted. TLS clients can thus require that all certificates
they see have been logged.
Those who are concerned about misissue can monitor the logs, asking
them regularly for all new entries, and can thus check whether
domains they are responsible for have had certificates issued that
they did not expect. What they do with this information,
particularly when they find that a misissuance has happened, is
beyond the scope of this document, but broadly speaking, they can
invoke existing business mechanisms for dealing with misissued
certificates. Of course, anyone who wants can monitor the logs and,
if they believe a certificate is incorrectly issued, take action as
they see fit.
Laurie, et al. Experimental [Page 3]
RFC 6962 Certificate Transparency June 2013
Similarly, those who have seen signed timestamps from a particular
log can later demand a proof of inclusion from that log. If the log
is unable to provide this (or, indeed, if the corresponding
certificate is absent from monitors' copies of that log), that is
evidence of the incorrect operation of the log. The checking
operation is asynchronous to allow TLS connections to proceed without
delay, despite network connectivity issues and the vagaries of
firewalls.
The append-only property of each log is technically achieved using
Merkle Trees, which can be used to show that any particular version
of the log is a superset of any particular previous version.
Likewise, Merkle Trees avoid the need to blindly trust logs: if a log
attempts to show different things to different people, this can be
efficiently detected by comparing tree roots and consistency proofs.
Similarly, other misbehaviors of any log (e.g., issuing signed
timestamps for certificates they then don't log) can be efficiently
detected and proved to the world at large.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
1.2. Data Structures
Data structures are defined according to the conventions laid out in
Section 4 of [RFC5246].
2. Cryptographic Components
2.1. Merkle Hash Trees
Logs use a binary Merkle Hash Tree for efficient auditing. The
hashing algorithm is SHA-256 [FIPS.180-4] (note that this is fixed
for this experiment, but it is anticipated that each log would be
able to specify a hash algorithm). The input to the Merkle Tree Hash
is a list of data entries; these entries will be hashed to form the
leaves of the Merkle Hash Tree. The output is a single 32-byte
Merkle Tree Hash. Given an ordered list of n inputs, D[n] = {d(0),
d(1), ..., d(n-1)}, the Merkle Tree Hash (MTH) is thus defined as
follows:
The hash of an empty list is the hash of an empty string:
MTH({}) = SHA-256().
Laurie, et al. Experimental [Page 4]
RFC 6962 Certificate Transparency June 2013
The hash of a list with one entry (also known as a leaf hash) is:
MTH({d(0)}) = SHA-256(0x00 || d(0)).
For n > 1, let k be the largest power of two smaller than n (i.e.,
k < n <= 2k). The Merkle Tree Hash of an n-element list D[n] is then
defined recursively as
MTH(D[n]) = SHA-256(0x01 || MTH(D[0:k]) || MTH(D[k:n])),
where || is concatenation and D[k1:k2] denotes the list {d(k1),
d(k1+1),..., d(k2-1)} of length (k2 - k1). (Note that the hash
calculations for leaves and nodes differ. This domain separation is
required to give second preimage resistance.)
Note that we do not require the length of the input list to be a
power of two. The resulting Merkle Tree may thus not be balanced;
however, its shape is uniquely determined by the number of leaves.
(Note: This Merkle Tree is essentially the same as the history tree
[CrosbyWallach] proposal, except our definition handles non-full
trees differently.)
2.1.1. Merkle Audit Paths
A Merkle audit path for a leaf in a Merkle Hash Tree is the shortest
list of additional nodes in the Merkle Tree required to compute the
Merkle Tree Hash for that tree. Each node in the tree is either a
leaf node or is computed from the two nodes immediately below it
(i.e., towards the leaves). At each step up the tree (towards the
root), a node from the audit path is combined with the node computed
so far. In other words, the audit path consists of the list of
missing nodes required to compute the nodes leading from a leaf to
the root of the tree. If the root computed from the audit path
matches the true root, then the audit path is proof that the leaf
exists in the tree.
Given an ordered list of n inputs to the tree, D[n] = {d(0), ...,
d(n-1)}, the Merkle audit path PATH(m, D[n]) for the (m+1)th input
d(m), 0 <= m < n, is defined as follows:
The path for the single leaf in a tree with a one-element input list
D[1] = {d(0)} is empty:
PATH(0, {d(0)}) = {}
Laurie, et al. Experimental [Page 5]
RFC 6962 Certificate Transparency June 2013
For n > 1, let k be the largest power of two smaller than n. The
path for the (m+1)th element d(m) in a list of n > m elements is then
defined recursively as
PATH(m, D[n]) = PATH(m, D[0:k]) : MTH(D[k:n]) for m < k; and
PATH(m, D[n]) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m >= k,
where : is concatenation of lists and D[k1:k2] denotes the length
(k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before.
2.1.2. Merkle Consistency Proofs
Merkle consistency proofs prove the append-only property of the tree.
A Merkle consistency proof for a Merkle Tree Hash MTH(D[n]) and a
previously advertised hash MTH(D[0:m]) of the first m leaves, m <= n,
is the list of nodes in the Merkle Tree required to verify that the
first m inputs D[0:m] are equal in both trees. Thus, a consistency
proof must contain a set of intermediate nodes (i.e., commitments to
inputs) sufficient to verify MTH(D[n]), such that (a subset of) the
same nodes can be used to verify MTH(D[0:m]). We define an algorithm
that outputs the (unique) minimal consistency proof.
Given an ordered list of n inputs to the tree, D[n] = {d(0), ...,
d(n-1)}, the Merkle consistency proof PROOF(m, D[n]) for a previous
Merkle Tree Hash MTH(D[0:m]), 0 < m < n, is defined as:
PROOF(m, D[n]) = SUBPROOF(m, D[n], true)
The subproof for m = n is empty if m is the value for which PROOF was
originally requested (meaning that the subtree Merkle Tree Hash
MTH(D[0:m]) is known):
SUBPROOF(m, D[m], true) = {}
The subproof for m = n is the Merkle Tree Hash committing inputs
D[0:m]; otherwise:
SUBPROOF(m, D[m], false) = {MTH(D[m])}
For m < n, let k be the largest power of two smaller than n. The
subproof is then defined recursively.
If m <= k, the right subtree entries D[k:n] only exist in the current
tree. We prove that the left subtree entries D[0:k] are consistent
and add a commitment to D[k:n]:
SUBPROOF(m, D[n], b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n])
Laurie, et al. Experimental [Page 6]
RFC 6962 Certificate Transparency June 2013
If m > k, the left subtree entries D[0:k] are identical in both
trees. We prove that the right subtree entries D[k:n] are consistent
and add a commitment to D[0:k].
SUBPROOF(m, D[n], b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k])
Here, : is a concatenation of lists, and D[k1:k2] denotes the length
(k2 - k1) list {d(k1), d(k1+1),..., d(k2-1)} as before.
The number of nodes in the resulting proof is bounded above by
ceil(log2(n)) + 1.
2.1.3. Example
The binary Merkle Tree with 7 leaves:
hash
/ \
/ \
/ \
/ \
/ \
k l
/ \ / \
/ \ / \
/ \ / \
g h i j
/ \ / \ / \ |
a b c d e f d6
| | | | | |
d0 d1 d2 d3 d4 d5
The audit path for d0 is [b, h, l].
The audit path for d3 is [c, g, l].
The audit path for d4 is [f, j, k].
The audit path for d6 is [i, k].
Laurie, et al. Experimental [Page 7]
RFC 6962 Certificate Transparency June 2013
The same tree, built incrementally in four steps:
hash0 hash1=k
/ \ / \
/ \ / \
/ \ / \
g c g h
/ \ | / \ / \
a b d2 a b c d
| | | | | |
d0 d1 d0 d1 d2 d3
hash2 hash
/ \ / \
/ \ / \
/ \ / \
/ \ / \
/ \ / \
k i k l
/ \ / \ / \ / \
/ \ e f / \ / \
/ \ | | / \ / \
g h d4 d5 g h i j
/ \ / \ / \ / \ / \ |
a b c d a b c d e f d6
| | | | | | | | | |
d0 d1 d2 d3 d0 d1 d2 d3 d4 d5
The consistency proof between hash0 and hash is PROOF(3, D[7]) = [c,
d, g, l]. c, g are used to verify hash0, and d, l are additionally
used to show hash is consistent with hash0.
The consistency proof between hash1 and hash is PROOF(4, D[7]) = [l].
hash can be verified using hash1=k and l.
The consistency proof between hash2 and hash is PROOF(6, D[7]) = [i,
j, k]. k, i are used to verify hash2, and j is additionally used to
show hash is consistent with hash2.
2.1.4. Signatures
Various data structures are signed. A log MUST use either elliptic
curve signatures using the NIST P-256 curve (Section D.1.2.3 of the
Digital Signature Standard [DSS]) or RSA signatures (RSASSA-PKCS1-
V1_5 with SHA-256, Section 8.2 of [RFC3447]) using a key of at least
2048 bits.
Laurie, et al. Experimental [Page 8]
RFC 6962 Certificate Transparency June 2013
3. Log Format and Operation
Anyone can submit certificates to certificate logs for public
auditing; however, since certificates will not be accepted by TLS
clients unless logged, it is expected that certificate owners or
their CAs will usually submit them. A log is a single, ever-growing,
append-only Merkle Tree of such certificates.
When a valid certificate is submitted to a log, the log MUST
immediately return a Signed Certificate Timestamp (SCT). The SCT is
the log's promise to incorporate the certificate in the Merkle Tree
within a fixed amount of time known as the Maximum Merge Delay (MMD).
If the log has previously seen the certificate, it MAY return the
same SCT as it returned before. TLS servers MUST present an SCT from
one or more logs to the TLS client together with the certificate.
TLS clients MUST reject certificates that do not have a valid SCT for
the end-entity certificate.
Periodically, each log appends all its new entries to the Merkle Tree
and signs the root of the tree. Auditors can thus verify that each
certificate for which an SCT has been issued indeed appears in the
log. The log MUST incorporate a certificate in its Merkle Tree
within the Maximum Merge Delay period after the issuance of the SCT.
Log operators MUST NOT impose any conditions on retrieving or sharing
data from the log.
3.1. Log Entries
Anyone can submit a certificate to any log. In order to enable
attribution of each logged certificate to its issuer, the log SHALL
publish a list of acceptable root certificates (this list might
usefully be the union of root certificates trusted by major browser
vendors). Each submitted certificate MUST be accompanied by all
additional certificates required to verify the certificate chain up
to an accepted root certificate. The root certificate itself MAY be
omitted from the chain submitted to the log server.
Alternatively, (root as well as intermediate) certificate authorities
may submit a certificate to logs prior to issuance. To do so, the CA
submits a Precertificate that the log can use to create an entry that
will be valid against the issued certificate. The Precertificate is
constructed from the certificate to be issued by adding a special
critical poison extension (OID 1.3.6.1.4.1.11129.2.4.3, whose
extnValue OCTET STRING contains ASN.1 NULL data (0x05 0x00)) to the
end-entity TBSCertificate (this extension is to ensure that the
Precertificate cannot be validated by a standard X.509v3 client) and
signing the resulting TBSCertificate [RFC5280] with either
Laurie, et al. Experimental [Page 9]
RFC 6962 Certificate Transparency June 2013
o a special-purpose (CA:true, Extended Key Usage: Certificate
Transparency, OID 1.3.6.1.4.1.11129.2.4.4) Precertificate Signing
Certificate. The Precertificate Signing Certificate MUST be
directly certified by the (root or intermediate) CA certificate
that will ultimately sign the end-entity TBSCertificate yielding
the end-entity certificate (note that the log may relax standard
validation rules to allow this, so long as the issued certificate
will be valid),
o or, the CA certificate that will sign the final certificate.
As above, the Precertificate submission MUST be accompanied by the
Precertificate Signing Certificate, if used, and all additional
certificates required to verify the chain up to an accepted root
certificate. The signature on the TBSCertificate indicates the
certificate authority's intent to issue a certificate. This intent
is considered binding (i.e., misissuance of the Precertificate is
considered equal to misissuance of the final certificate). Each log
verifies the Precertificate signature chain and issues a Signed
Certificate Timestamp on the corresponding TBSCertificate.
Logs MUST verify that the submitted end-entity certificate or
Precertificate has a valid signature chain leading back to a trusted
root CA certificate, using the chain of intermediate CA certificates
provided by the submitter. Logs MAY accept certificates that have
expired, are not yet valid, have been revoked, or are otherwise not
fully valid according to X.509 verification rules in order to
accommodate quirks of CA certificate-issuing software. However, logs
MUST refuse to publish certificates without a valid chain to a known
root CA. If a certificate is accepted and an SCT issued, the
accepting log MUST store the entire chain used for verification,
including the certificate or Precertificate itself and including the
root certificate used to verify the chain (even if it was omitted
from the submission), and MUST present this chain for auditing upon
request. This chain is required to prevent a CA from avoiding blame
by logging a partial or empty chain. (Note: This effectively
excludes self-signed and DANE-based certificates until some mechanism
to control spam for those certificates is found. The authors welcome
suggestions.)
Laurie, et al. Experimental [Page 10]
RFC 6962 Certificate Transparency June 2013
Each certificate entry in a log MUST include the following
components:
enum { x509_entry(0), precert_entry(1), (65535) } LogEntryType;
struct {
LogEntryType entry_type;
select (entry_type) {
case x509_entry: X509ChainEntry;
case precert_entry: PrecertChainEntry;
} entry;
} LogEntry;
opaque ASN.1Cert<1..2^24-1>;
struct {
ASN.1Cert leaf_certificate;
ASN.1Cert certificate_chain<0..2^24-1>;
} X509ChainEntry;
struct {
ASN.1Cert pre_certificate;
ASN.1Cert precertificate_chain<0..2^24-1>;
} PrecertChainEntry;
Logs MAY limit the length of chain they will accept.
"entry_type" is the type of this entry. Future revisions of this
protocol version may add new LogEntryType values. Section 4 explains
how clients should handle unknown entry types.
"leaf_certificate" is the end-entity certificate submitted for
auditing.
"certificate_chain" is a chain of additional certificates required to
verify the end-entity certificate. The first certificate MUST
certify the end-entity certificate. Each following certificate MUST
directly certify the one preceding it. The final certificate MUST be
a root certificate accepted by the log.
"pre_certificate" is the Precertificate submitted for auditing.
"precertificate_chain" is a chain of additional certificates required
to verify the Precertificate submission. The first certificate MAY
be a valid Precertificate Signing Certificate and MUST certify the
first certificate. Each following certificate MUST directly certify
the one preceding it. The final certificate MUST be a root
certificate accepted by the log.
Laurie, et al. Experimental [Page 11]
RFC 6962 Certificate Transparency June 2013
3.2. Structure of the Signed Certificate Timestamp
enum { certificate_timestamp(0), tree_hash(1), (255) }
SignatureType;
enum { v1(0), (255) }
Version;
struct {
opaque key_id[32];
} LogID;
opaque TBSCertificate<1..2^24-1>;
struct {
opaque issuer_key_hash[32];
TBSCertificate tbs_certificate;
} PreCert;
opaque CtExtensions<0..2^16-1>;
"key_id" is the SHA-256 hash of the log's public key, calculated over
the DER encoding of the key represented as SubjectPublicKeyInfo.
"issuer_key_hash" is the SHA-256 hash of the certificate issuer's
public key, calculated over the DER encoding of the key represented
as SubjectPublicKeyInfo. This is needed to bind the issuer to the
final certificate.
"tbs_certificate" is the DER-encoded TBSCertificate (see [RFC5280])
component of the Precertificate -- that is, without the signature and
the poison extension. If the Precertificate is not signed with the
CA certificate that will issue the final certificate, then the
TBSCertificate also has its issuer changed to that of the CA that
will issue the final certificate. Note that it is also possible to
reconstruct this TBSCertificate from the final certificate by
extracting the TBSCertificate from it and deleting the SCT extension.
Also note that since the TBSCertificate contains an
AlgorithmIdentifier that must match both the Precertificate signature
algorithm and final certificate signature algorithm, they must be
signed with the same algorithm and parameters. If the Precertificate
is issued using a Precertificate Signing Certificate and an Authority
Key Identifier extension is present in the TBSCertificate, the
corresponding extension must also be present in the Precertificate
Signing Certificate -- in this case, the TBSCertificate also has its
Authority Key Identifier changed to match the final issuer.
Laurie, et al. Experimental [Page 12]
RFC 6962 Certificate Transparency June 2013
struct {
Version sct_version;
LogID id;
uint64 timestamp;
CtExtensions extensions;
digitally-signed struct {
Version sct_version;
SignatureType signature_type = certificate_timestamp;
uint64 timestamp;
LogEntryType entry_type;
select(entry_type) {
case x509_entry: ASN.1Cert;
case precert_entry: PreCert;
} signed_entry;
CtExtensions extensions;
};
} SignedCertificateTimestamp;
The encoding of the digitally-signed element is defined in [RFC5246].
"sct_version" is the version of the protocol to which the SCT
conforms. This version is v1.
"timestamp" is the current NTP Time [RFC5905], measured since the
epoch (January 1, 1970, 00:00), ignoring leap seconds, in
milliseconds.
"entry_type" may be implicit from the context in which the SCT is
presented.
"signed_entry" is the "leaf_certificate" (in the case of an
X509ChainEntry) or is the PreCert (in the case of a
PrecertChainEntry), as described above.
"extensions" are future extensions to this protocol version (v1).
Currently, no extensions are specified.
3.3. Including the Signed Certificate Timestamp in the TLS Handshake
The SCT data corresponding to the end-entity certificate from at
least one log must be included in the TLS handshake, either by using
an X509v3 certificate extension as described below, by using a TLS
extension (Section 7.4.1.4 of [RFC5246]) with type
"signed_certificate_timestamp", or by using Online Certificate Status
Protocol (OCSP) Stapling (also known as the "Certificate Status
Laurie, et al. Experimental [Page 13]
RFC 6962 Certificate Transparency June 2013
Request" TLS extension; see [RFC6066]), where the response includes
an OCSP extension with OID 1.3.6.1.4.1.11129.2.4.5 (see [RFC2560])
and body:
SignedCertificateTimestampList ::= OCTET STRING
At least one SCT MUST be included. Server operators MAY include more
than one SCT.
Similarly, a certificate authority MAY submit a Precertificate to
more than one log, and all obtained SCTs can be directly embedded in
the final certificate, by encoding the SignedCertificateTimestampList
structure as an ASN.1 OCTET STRING and inserting the resulting data
in the TBSCertificate as an X.509v3 certificate extension (OID
1.3.6.1.4.1.11129.2.4.2). Upon receiving the certificate, clients
can reconstruct the original TBSCertificate to verify the SCT
signature.
The contents of the ASN.1 OCTET STRING embedded in an OCSP extension
or X509v3 certificate extension are as follows:
opaque SerializedSCT<1..2^16-1>;
struct {
SerializedSCT sct_list <1..2^16-1>;
} SignedCertificateTimestampList;
Here, "SerializedSCT" is an opaque byte string that contains the
serialized TLS structure. This encoding ensures that TLS clients can
decode each SCT individually (i.e., if there is a version upgrade,
out-of-date clients can still parse old SCTs while skipping over new
SCTs whose versions they don't understand).
Likewise, SCTs can be embedded in a TLS extension. See below for
details.
TLS clients MUST implement all three mechanisms. Servers MUST
implement at least one of the three mechanisms. Note that existing
TLS servers can generally use the certificate extension mechanism
without modification.
TLS servers should send SCTs from multiple logs in case one or more
logs are not acceptable to the client (for example, if a log has been
struck off for misbehavior or has had a key compromise).
Laurie, et al. Experimental [Page 14]
RFC 6962 Certificate Transparency June 2013
3.3.1. TLS Extension
The SCT can be sent during the TLS handshake using a TLS extension
with type "signed_certificate_timestamp".
Clients that support the extension SHOULD send a ClientHello
extension with the appropriate type and empty "extension_data".
Servers MUST only send SCTs to clients who have indicated support for
the extension in the ClientHello, in which case the SCTs are sent by
setting the "extension_data" to a "SignedCertificateTimestampList".
Session resumption uses the original session information: clients
SHOULD include the extension type in the ClientHello, but if the
session is resumed, the server is not expected to process it or
include the extension in the ServerHello.
3.4. Merkle Tree
The hashing algorithm for the Merkle Tree Hash is SHA-256.
Structure of the Merkle Tree input:
enum { timestamped_entry(0), (255) }
MerkleLeafType;
struct {
uint64 timestamp;
LogEntryType entry_type;
select(entry_type) {
case x509_entry: ASN.1Cert;
case precert_entry: PreCert;
} signed_entry;
CtExtensions extensions;
} TimestampedEntry;
struct {
Version version;
MerkleLeafType leaf_type;
select (leaf_type) {
case timestamped_entry: TimestampedEntry;
}
} MerkleTreeLeaf;
Here, "version" is the version of the protocol to which the
MerkleTreeLeaf corresponds. This version is v1.
Laurie, et al. Experimental [Page 15]
RFC 6962 Certificate Transparency June 2013
"leaf_type" is the type of the leaf input. Currently, only
"timestamped_entry" (corresponding to an SCT) is defined. Future
revisions of this protocol version may add new MerkleLeafType types.
Section 4 explains how clients should handle unknown leaf types.
"timestamp" is the timestamp of the corresponding SCT issued for this
certificate.
"signed_entry" is the "signed_entry" of the corresponding SCT.
"extensions" are "extensions" of the corresponding SCT.
The leaves of the Merkle Tree are the leaf hashes of the
corresponding "MerkleTreeLeaf" structures.
3.5. Signed Tree Head
Every time a log appends new entries to the tree, the log SHOULD sign
the corresponding tree hash and tree information (see the
corresponding Signed Tree Head client message in Section 4.3). The
signature for that data is structured as follows:
digitally-signed struct {
Version version;
SignatureType signature_type = tree_hash;
uint64 timestamp;
uint64 tree_size;
opaque sha256_root_hash[32];
} TreeHeadSignature;
"version" is the version of the protocol to which the
TreeHeadSignature conforms. This version is v1.
"timestamp" is the current time. The timestamp MUST be at least as
recent as the most recent SCT timestamp in the tree. Each subsequent
timestamp MUST be more recent than the timestamp of the previous
update.
"tree_size" equals the number of entries in the new tree.
"sha256_root_hash" is the root of the Merkle Hash Tree.
Each log MUST produce on demand a Signed Tree Head that is no older
than the Maximum Merge Delay. In the unlikely event that it receives
no new submissions during an MMD period, the log SHALL sign the same
Merkle Tree Hash with a fresh timestamp.
Laurie, et al. Experimental [Page 16]
RFC 6962 Certificate Transparency June 2013
4. Log Client Messages
Messages are sent as HTTPS GET or POST requests. Parameters for
POSTs and all responses are encoded as JavaScript Object Notation
(JSON) objects [RFC4627]. Parameters for GETs are encoded as order-
independent key/value URL parameters, using the "application/
x-www-form-urlencoded" format described in the "HTML 4.01
Specification" [HTML401]. Binary data is base64 encoded [RFC4648] as
specified in the individual messages.
Note that JSON objects and URL parameters may contain fields not
specified here. These extra fields should be ignored.
The <log server> prefix can include a path as well as a server name
and a port.
In general, where needed, the "version" is v1 and the "id" is the log
id for the log server queried.
Any errors will be returned as HTTP 4xx or 5xx responses, with human-
readable error messages.
4.1. Add Chain to Log
POST https://<log server>/ct/v1/add-chain
Inputs:
chain: An array of base64-encoded certificates. The first
element is the end-entity certificate; the second chains to the
first and so on to the last, which is either the root
certificate or a certificate that chains to a known root
certificate.
Outputs:
sct_version: The version of the SignedCertificateTimestamp
structure, in decimal. A compliant v1 implementation MUST NOT
expect this to be 0 (i.e., v1).
id: The log ID, base64 encoded. Since log clients who request an
SCT for inclusion in TLS handshakes are not required to verify
it, we do not assume they know the ID of the log.
timestamp: The SCT timestamp, in decimal.
Laurie, et al. Experimental [Page 17]
RFC 6962 Certificate Transparency June 2013
extensions: An opaque type for future expansion. It is likely
that not all participants will need to understand data in this
field. Logs should set this to the empty string. Clients
should decode the base64-encoded data and include it in the
SCT.
signature: The SCT signature, base64 encoded.
If the "sct_version" is not v1, then a v1 client may be unable to
verify the signature. It MUST NOT construe this as an error. (Note:
Log clients don't need to be able to verify this structure; only TLS
clients do. If we were to serve the structure as a binary blob, then
we could completely change it without requiring an upgrade to v1
clients.)
4.2. Add PreCertChain to Log
POST https://<log server>/ct/v1/add-pre-chain
Inputs:
chain: An array of base64-encoded Precertificates. The first
element is the end-entity certificate; the second chains to the
first and so on to the last, which is either the root
certificate or a certificate that chains to a known root
certificate.
Outputs are the same as in Section 4.1.
4.3. Retrieve Latest Signed Tree Head
GET https://<log server>/ct/v1/get-sth
No inputs.
Outputs:
tree_size: The size of the tree, in entries, in decimal.
timestamp: The timestamp, in decimal.
sha256_root_hash: The Merkle Tree Hash of the tree, in base64.