tls certificate transparency, experimental rfc

7/28/2019 TLS Certificate Transparency, Experimental RFC

http://slidepdf.com/reader/full/tls-certificate-transparency-experimental-rfc 1/28

Certificate Transparency

draft-laurie-pki-sunlight-12

Document IESG Evaluation Record IESG Writeups History

Active Internet-Draft (Individual)

Document Stream:IETFLast updated: 2013-04-18

Intended RFCstatus:

Experimental

Other versions: plain text, xml, pdf , html

Documentshepherd:

(None)

Shepherd writeup

Consensus: Yes

IESG State: Approved-announcement sentIANA Review State: IANA - Review Needed On agenda of 2013-03-28 IESG telechat

Responsible AD: Stephen Farrell

Send notices to: [email protected], [email protected], [email protected], [email protected]

Email Authors | IPR Disclosures | Dependencies to this draft | Check nits | Comments feed |

Search Mailing Lists

Network Worki ng Gr oup B. Laur i eI nt er net - Dr af t A. Langl eyI nt ended st atus: Exper i ment al E. KasperExpi r es: Oct ober 20, 2013 Googl e

Apr i l 18, 2013

Cer t i f i cat e Tr anspar encydr af t - l aur i e- pki - sunl i ght - 12

Abstract

Thi s document descr i bes an exper i ment al pr ot ocol f or publ i cl y l oggi ngt he exi st ence of TLS cer t i f i cat es as t hey ar e i ssued or obser ved, i na manner t hat al l ows anyone t o audi t cer t i f i cat e aut hor i t y act i vi t yand not i ce t he i ssuance of suspect cer t i f i cat es, as wel l as t o audi tt he cer t i f i cat e l ogs t hemsel ves. The i nt ent i s t hat event ual l ycl i ent s woul d r ef use t o honor cer t i f i cat es whi ch do not appear i n al og, ef f ecti vel y f or ci ng CAs t o add al l i ssued cer t i f i cat es t o t he

-laurie-pki-sunlight-12 http://datatracker.ietf.org/doc/draft-laurie-pki-sunlight/?includ



l ogs.

Logs ar e net wor k servi ces whi ch i mpl ement t he pr ot ocol oper at i ons f orsubmi ssi ons and quer i es t hat ar e def i ned i n t hi s document .

Status of this Memo

Thi s I nt er net - Dr af t i s submi t t ed i n f ul l conf or mance wi t h t heprovi si ons of BCP 78 and BCP 79.

I nt er net - Dr af t s ar e wor ki ng document s of t he I nt er net Engi neer i ngTask For ce ( I ETF) . Not e t hat ot her groups may al so di st r i but ewor ki ng document s as I nt er net - Dr af t s. The l i st of cur r ent I nt er net -Dr af t s i s at ht t p: / / dat at r acker . i et f . or g/ dr af t s/ cur r ent / .

I nt er net - Dr af t s ar e dr af t document s val i d f or a maxi mum of si x mont hsand may be updated, r epl aced, or obsol eted by ot her document s at anyt i me. I t i s i nappr opr i at e t o use I nt er net - Dr af t s as r ef er ence

mat er i al or t o ci t e t hem ot her t han as "wor k i n pr ogr ess. "

Thi s I nt er net - Dr af t wi l l expi r e on Oct ober 20, 2013.

Copyright Notice

Copyr i ght ( c) 2013 I ETF Tr ust and t he per sons i dent i f i ed as t hedocument aut hor s. Al l r i ght s r eserved.

Thi s document i s subj ect t o BCP 78 and t he I ETF Trust ' s Legal

Provi si ons Rel at i ng t o I ETF Document s

Laur i e, et al . Expi r es Oct ober 20, 2013 [ Page 1]I nt er net - Dr af t Cer t i f i cat e Tr anspar ency Apr i l 2013

( ht t p: / / t r ustee. i et f . or g/ l i cense- i nf o) i n ef f ect on t he dat e of publ i cat i on of t hi s document . Pl ease r evi ew t hese document scar ef ul l y, as t hey descr i be your r i ght s and r est r i ct i ons wi t h r espectt o t hi s document . Code Component s ext r act ed f r om t hi s document musti ncl ude Si mpl i f i ed BSD Li cense t ext as descr i bed i n Sect i on 4. e of t he Tr ust Legal Pr ovi si ons and ar e pr ovi ded wi t hout war r ant y asdescr i bed i n t he Si mpl i f i ed BSD Li cense.

Laur i e, et al . Expi r es Oct ober 20, 2013 [ ]I nt er net - Dr af t Cer t i f i cat e Tr anspar ency Apr i l 2013

Table of Contents

1. I nf or mal i nt r oduct i on . . . . . . . . . . . . . . . . . . . . 41. 1. Requi rement s Language . . . . . . . . . . . . . . . . . . 5




5. Cl i ent s . . . . . . . . . . . . . . . . . . . . . . . . . . . 245. 1. Submi t t er s . . . . . . . . . . . . . . . . . . . . . . . . 245. 2. TLS Cl i ent . . . . . . . . . . . . . . . . . . . . . . . . 24

5. 3. Moni t or . . . . . . . . . . . . . . . . . . . . . . . . . 245. 4. Audi t or . . . . . . . . . . . . . . . . . . . . . . . . . 25

6. I ANA Consi der at i ons . . . . . . . . . . . . . . . . . . . . . 267. Secur i t y Consi derat i ons . . . . . . . . . . . . . . . . . . . 27

7. 1. Mi si ssued Cer t i f i cat es . . . . . . . . . . . . . . . . . . 277. 2. Detect i on of Mi si ssue . . . . . . . . . . . . . . . . . . 277. 3. Mi sbehavi ng l ogs . . . . . . . . . . . . . . . . . . . . . 27

8. Ef f i ci ency Consi derat i ons . . . . . . . . . . . . . . . . . . 299. Fut ur e Changes . . . . . . . . . . . . . . . . . . . . . . . . 3010. Acknowl edgement s . . . . . . . . . . . . . . . . . . . . . . . 31

11. Ref er ences . . . . . . . . . . . . . . . . . . . . . . . . . . 32Aut hor s' Addr esses . . . . . . . . . . . . . . . . . . . . . . . . 34


1. Informal introduction

Cer t i f i cat e Tr anspar ency ai ms t o mi t i gat e t he pr obl em of mi si ssuedcer t i f i cat es by pr ovi di ng publ i cl y audi t abl e, append- onl y, unt r ust ed

1. 2. Dat a st r uct ur es . . . . . . . . . . . . . . . . . . . . . 52. Crypt ographi c component s . . . . . . . . . . . . . . . . . . . 6

2. 1. Mer kl e Hash Tr ees . . . . . . . . . . . . . . . . . . . . 62. 1. 1. Mer kl e audi t pat hs . . . . . . . . . . . . . . . . . . 62. 1. 2. Merkl e cons i stency proof s . . . . . . . . . . . . . . 72. 1. 3. Exampl e . . . . . . . . . . . . . . . . . . . . . . . 82. 1. 4. Si gnat ur es . . . . . . . . . . . . . . . . . . . . . . 10

3. Log Format and Oper at i on . . . . . . . . . . . . . . . . . . . 113. 1. Log Ent r i es . . . . . . . . . . . . . . . . . . . . . . . 113. 2. St r uctur e of t he Si gned Cer t i f i cat e Ti mest amp . . . . . . 143. 3. I ncl udi ng t he Si gned Cer t i f i cat e Ti mest amp i n t he TLS

Handshake . . . . . . . . . . . . . . . . . . . . . . . . 153. 3. 1. TLS Ext ensi on . . . . . . . . . . . . . . . . . . . . 16

3. 4. Mer kl e Tr ee . . . . . . . . . . . . . . . . . . . . . . . 173. 5. Si gned Tree Head . . . . . . . . . . . . . . . . . . . . . 18

4. Log Cl i ent Messages . . . . . . . . . . . . . . . . . . . . . 194. 1. Add Chai n t o Log . . . . . . . . . . . . . . . . . . . . . 194. 2. Add PreCert Chai n t o Log . . . . . . . . . . . . . . . . . 20

4. 3. Ret r i eve Lat est Si gned Tr ee Head . . . . . . . . . . . . . 204. 4. Ret r i eve Mer kl e Consi st ency Proof bet ween t wo Si gned

Tr ee Heads . . . . . . . . . . . . . . . . . . . . . . . . 204. 5. Ret r i eve Mer kl e Audi t Pr oof f r om Log by Leaf Hash . . . . 214. 6. Ret r i eve Ent r i es f romLog . . . . . . . . . . . . . . . . 214. 7. Ret r i eve Accept ed Root Cer t i f i cat es . . . . . . . . . . . 224. 8. Ret r i eve Ent r y+Mer kl e Audi t Pr oof f r om Log . . . . . . . . 22




l ogs of al l i ssued cer t i f i cat es. The l ogs ar e publ i cl y audi t abl e sot hat i t i s possi bl e f or anyone t o ver i f y t he cor r ect ness of each l og,and t o moni t or when new cer t i f i cat es ar e added t o i t . The l ogs donot t hemsel ves prevent mi si ssue, but t hey ensur e that i nt er est edpar t i es ( par t i cul ar l y t hose named i n cer t i f i cat es) can det ect suchmi si ssuance. Not e t hat t hi s i s a gener al mechani sm, but i n t hi sdocument we onl y descr i be i t s use f or publ i c TLS ser ver cer t i f i cat es

i ssued by publ i c cer t i f i cat e aut hor i t i es ( CAs) .

Each l og consi st s of cer t i f i cat e chai ns, whi ch can be submi t t ed byanyone. I t i s expected t hat publ i c CAs wi l l cont r i but e al l t hei rnewl y- i ssued cer t i f i cat es t o one or mor e l ogs; i t i s al so expect edt hat cer t i f i cat e hol der s wi l l cont r i but e t hei r own cer t i f i cat echai ns. I n or der t o avoi d l ogs bei ng spammed i nt o usel essness, i t i sr equi r ed t hat each chai n i s r oot ed i n a known CA cer t i f i cat e. When achai n i s submi t t ed t o a l og, a si gned t i mest amp i s r et ur ned, whi chcan l at er be used t o pr ovi de evi dence t o cl i ent s t hat t he chai n hasbeen submi t t ed. TLS cl i ent s can t hus r equi r e t hat al l cer t i f i cat es

t hey see have been l ogged.

Those who ar e concerned about mi si ssue can moni t or t he l ogs, aski ngt hem r egul ar l y f or al l new ent r i es, and can t hus check whet herdomai ns t hey ar e r esponsi bl e f or have had cer t i f i cat es i ssued t hatt hey di d not expect . What t hey do wi t h t hi s i nf or mat i on,par t i cul ar l y when t hey f i nd t hat a mi si ssuance has happened, i sbeyond the scope of t hi s document , but br oadl y speaki ng they cani nvoke exi st i ng busi ness mechani sms f or deal i ng wi t h mi si ssuedcer t i f i cat es. Of cour se, anyone who want s can moni t or t he l ogs, and

i f t hey bel i eve a cer t i f i cat e i s i ncor r ectl y i ssued, t ake acti on ast hey see f i t .

Si mi l ar l y, t hose who have seen si gned t i mest amps f r om a par t i cul arl og can l at er demand a pr oof of i ncl usi on f r om t hat l og. I f t he l ogi s unabl e t o pr ovi de t hi s ( or , i ndeed, i f t he cor r espondi ngcer t i f i cat e i s absent f r om moni t or s' copi es of t hat l og) , t hat i sevi dence of t he i ncor r ect oper at i on of t he l og. The checki ngoper at i on i s asynchr onous t o al l ow TLS connect i ons t o pr oceed wi t houtdel ay, despi t e net wor k connect i vi t y i ssues and t he vagar i es of f i rewal l s .

The append- onl y pr oper t y of each l og i s t echni cal l y achi eved usi ngMer kl e Tr ees, whi ch can be used t o show t hat any par t i cul ar ver si onof t he l og i s a super set of any par t i cul ar pr evi ous ver si on.Li kewi se, Mer kl e Tr ees avoi d t he need t o bl i ndl y t r ust l ogs: i f a l og





at t empt s t o show di f f er ent t hi ngs t o di f f er ent peopl e, t hi s can beef f i ci ent l y det ect ed by compar i ng t r ee r oot s and consi st ency pr oof s.Si mi l ar l y, ot her mi sbehavi our s of any l og ( e. g. , i ssui ng si gnedt i mest amps f or cer t i f i cat es t hey t hen don' t l og) can be ef f i ci ent l ydet ect ed and pr oved t o t he wor l d at l ar ge.

1.1. Requirements Language

The key wor ds "MUST" , "MUST NOT", "REQUI RED", "SHALL" , "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTI ONAL" i n t hi sdocument are t o be i nt erpr eted as descr i bed i n RFC 2119 [ RFC2119] .

1.2. Data structures

Dat a st r uct ur es are def i ned accor di ng t o t he convent i ons l ai d out i nsect i on 4 of [ RFC5246] .


2. Cryptographic components

2.1. Merkle Hash Trees

Logs use a bi nar y Mer kl e hash t r ee f or ef f i ci ent audi t i ng. Thehashi ng al gor i t hm i s SHA- 256 [ FI PS. 180- 2. 2002] ( not e t hat t hi s i sf i xed f or t hi s exper i ment but i t i s ant i ci pat ed t hat each l og woul dbe abl e t o speci f y a hash al gor i t hm) . The i nput t o t he Mer kl e Tr ee

Hash i s a l i st of dat a ent r i es; t hese ent r i es wi l l be hashed t o f or mt he l eaves of t he Mer kl e hash t r ee. The out put i s a si ngl e 32- byteMer kl e Tr ee Hash. Gi ven an or der ed l i st of n i nput s, D[ n] = {d( 0) ,d( 1) , . . . , d( n- 1) }, t he Mer kl e Tr ee Hash ( MTH) i s t hus def i ned asf ol l ows:

The hash of an empt y l i st i s t he hash of an empt y st r i ng:

MTH( {}) = SHA- 256( ) .

The hash of a l i st wi t h one ent r y (al so known as a l eaf hash) i s:

MTH( {d( 0) }) = SHA- 256( 0x00 | | d( 0) ) .

For n > 1, l et k be t he l ar gest power of t wo smal l er t han n ( i . e. , k< n <= 2k) . The Merkl e Tree Hash of an n- el ement l i st D[ n] i s t hendef i ned r ecur si vel y as

MTH( D[ n] ) = SHA- 256( 0x01 | | MTH( D[ 0: k] ) | | MTH( D[ k: n] ) ) ,




wher e | | i s concat enat i on and D[ k1: k2] denot es t he l i st {d( k1) ,d( k1+1) , . . . , d( k2- 1) } of l engt h ( k2 - k1) . ( Not e t hat t he hashcal cul at i on f or l eaves and nodes di f f er . Thi s domai n separ at i on i sr equi r ed to gi ve second pr ei mage resi st ance. )

Not e t hat we do not r equi r e t he l engt h of t he i nput l i st t o be apower of t wo. The r esul t i ng Merkl e t r ee may t hus not be bal anced,

however , i t s shape i s uni quel y determi ned by t he number of l eaves.[ Thi s Mer kl e t r ee i s essent i al l y t he same as t he hi st or y t r ee[ Cr osbyWal l ach] pr oposal , except our def i ni t i on handl es non- f ul lt r ees di f f er ent l y. ]

2.1.1. Merkle audit paths

A Mer kl e audi t pat h f or a l eaf i n a Mer kl e hash t r ee i s t he shor t estl i st of addi t i onal nodes i n t he Mer kl e t r ee r equi r ed t o comput e t heMer kl e Tr ee Hash f or t hat t r ee. Each node i n t he t r ee i s ei t her al eaf node, or i s comput ed f r om t he t wo nodes i mmedi at el y bel ow i t

( i . e. , t owar ds t he l eaves) . At each st ep up t he t r ee ( t owar ds ther oot ) , a node f r om t he audi t path i s combi ned wi t h t he node comput ed


so f ar . I n ot her wor ds, t he audi t pat h consi st s of t he l i st of mi ssi ng nodes r equi r ed t o comput e t he nodes l eadi ng f r oma l eaf t ot he r oot of t he t r ee. I f t he r oot comput ed f r om t he audi t pat hmat ches t he t r ue r oot , t hen t he audi t pat h i s pr oof t hat t he l eaf

exi st s i n t he t r ee.

Gi ven an or der ed l i st of n i nput s t o t he t r ee, D[ n] = {d( 0) , . . . ,d( n- 1) }, t he Mer kl e audi t pat h PATH( m, D[ n] ) f or t he ( m+1) t h i nputd( m) , 0 <= m < n, i s def i ned as f ol l ows:

The pat h f or t he si ngl e l eaf i n a t r ee wi t h a one- el ement i nput l i stD[ 1] = {d( 0) } i s empt y:

PATH( 0, {d( 0) }) = {}

For n > 1, l et k be t he l ar gest power of t wo smal l er t han n. Thepath f or t he ( m+1) t h el ement d( m) i n a l i st of n > m el ement s i s t hendef i ned r ecur si vel y as

PATH( m, D[ n] ) = PATH( m, D[ 0: k] ) : MTH( D[ k: n] ) f or m < k; and

PATH( m, D[ n] ) = PATH( m - k, D[ k: n] ) : MTH( D[ 0: k] ) f or m >= k,

wher e : i s concat enat i on of l i st s and D[ k1: k2] denot es t he l engt h ( k2




- k1) l i st {d( k1) , d( k1+1) , . . . , d( k2- 1) } as bef or e.

2.1.2. Merkle cons istency proofs

Mer kl e consi st ency pr oof s pr ove t he append- onl y pr oper t y of t he t r ee.A Merkl e consi st ency pr oof f or a Merkl e Tr ee Hash MTH( D[ n] ) and apr evi ousl y adver t i sed hash MTH( D[ 0: m] ) of t he f i r st m l eaves, m <= n,

i s t he l i st of nodes i n t he Mer kl e t r ee r equi r ed t o ver i f y t hat t hef i r st m i nput s D[ 0: m] ar e equal i n bot h t r ees. Thus, a consi st encypr oof must cont ai n a set of i nt er medi at e nodes ( i . e. , commi t ment s t oi nput s) suf f i ci ent t o ver i f y MTH( D[ n] ) , such t hat ( a subset of ) t hesame nodes can be used t o ver i f y MTH( D[ 0: m] ) . We def i ne an al gor i t hmt hat out put s t he (uni que) mi ni mal consi st ency pr oof .

Gi ven an or der ed l i st of n i nput s t o t he t r ee, D[ n] = {d( 0) , . . . ,d( n- 1) }, t he Mer kl e consi st ency pr oof PROOF( m, D[ n] ) f or a pr evi ousMerkl e Tr ee Hash MTH( D[ 0: m] ) , 0 < m < n, i s def i ned as:

PROOF( m, D[ n] ) = SUBPROOF( m, D[ n] , t r ue)

The subpr oof f or m = n i s empt y i f m i s t he val ue f or whi ch PROOF wasor i gi nal l y r equest ed ( meani ng t hat t he subt r ee Mer kl e Tr ee HashMTH( D[ 0: m] ) i s known) :


SUBPROOF( m, D[ m] , t r ue) = {}

The subpr oof f or m = n i s t he Merkl e Tree Hash commi t t i ng i nput sD[ 0: m] otherwi se:

SUBPROOF( m, D[ m] , f al se) = {MTH( D[ m] ) }

For m < n, l et k be t he l ar gest power of t wo smal l er t han n. Thesubpr oof i s t hen def i ned r ecur si vel y.

I f m <= k, t he r i ght subt r ee ent r i es D[ k: n] onl y exi st i n t he cur r entt r ee. We pr ove t hat t he l ef t subt r ee ent r i es D[ 0: k] are consi st entand add a commi t ment t o D[ k: n] :

SUBPROOF( m, D[ n] , b) = SUBPROOF( m, D[ 0: k] , b) : MTH( D[ k: n] ) .

I f m > k, t he l ef t subt r ee ent r i es D[ 0: k] ar e i dent i cal i n bot ht r ees. We pr ove t hat t he r i ght subt r ee ent r i es D[ k: n] ar e consi st entand add a commi t ment t o D[ 0: k] .

SUBPROOF( m, D[ n] , b) = SUBPROOF( m - k, D[ k: n] , f al se) : MTH( D[ 0: k] ) .




Her e : i s concat enat i on of l i st s and D[ k1: k2] denot es t he l engt h ( k2- k1) l i st {d( k1) , d( k1+1) , . . . , d( k2- 1) } as bef or e.

The number of nodes i n the resul t i ng pr oof i s bounded above bycei l ( l og2( n) ) + 1.

2.1.3. Example

The bi nar y Mer kl e t r ee wi t h 7 l eaves:

hash/ \

/ \/ \

/ \/ \

k l

/ \ / \/ \ / \

/ \ / \g h i j

/ \ / \ / \ |a b c d e f d6| | | | | |

d0 d1 d2 d3 d4 d5

Laur i e, et al . Expi r es Oct ober 20, 2013 [ ]

I nt er net - Dr af t Cer t i f i cat e Tr anspar ency Apr i l 2013

The audi t pat h f or d0 i s [ b, h, l ] .

The audi t pat h f or d3 i s [ c, g, l ] .

The audi t pat h f or d4 i s [ f , j , k] .

The audi t pat h f or d6 i s [ i , k] .

The same t r ee, bui l t i ncr ement al l y i n f our st eps:

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 consi st ency pr oof between hash0 and hash i s PROOF( 3, D[ 7] ) = [ c,d, g, l ] . c, g ar e used t o ver i f y hash0, and d, l ar e addi t i onal l yused t o show hash i s consi st ent wi t h hash0.

The consi st ency pr oof between hash1 and hash i s PROOF( 4, D[ 7] ) = [ l ] .hash can be ver i f i ed, usi ng hash1=k and l .

The consi st ency pr oof between hash2 and hash i s PROOF( 6, D[ 7] ) = [ i ,j , k] . k, i ar e used t o ver i f y hash2, and j i s addi t i onal l y used t oshow hash i s consi st ent wi t h hash2.


2.1.4. Signatures

Var i ous dat a st r uct ur es ar e si gned. A l og MUST use ei t her el l i pt i ccur ve si gnat ur es usi ng t he NI ST P- 256 cur ve ( sect i on D. 1. 2. 3 of DSS[ DSS] ) or RSA si gnatur es ( RSASSA- PKCS1- V1_5 wi t h SHA- 256, sect i on 8. 2of [ RFC3447] ) usi ng a key of at l east 2048 bi t s.


3. Log Format and Operation

Anyone can submi t cer t i f i cat es t o cer t i f i cat e l ogs f or publ i caudi t i ng, however , si nce cer t i f i cat es wi l l not be accept ed by TLScl i ent s unl ess l ogged, i t i s expect ed t hat cer t i f i cat e owner s ort hei r CAs wi l l usual l y submi t t hem. A l og i s a si ngl e, ever - gr owi ng,




append- onl y Mer kl e Tr ee of such cer t i f i cat es.

When a val i d cer t i f i cat e i s submi t t ed t o a l og, t he l og MUSTi mmedi at el y r et ur n a Si gned Cert i f i cat e Ti mest amp ( SCT) . The SCT i st he l og' s pr omi se t o i ncor por at e t he cer t i f i cat e i n t he Mer kl e Tr eewi t hi n a f i xed amount of t i me known as t he Maxi mumMerge Del ay ( MMD) .I f t he l og has pr evi ousl y seen t he cer t i f i cat e, i t MAY r et ur n t he

same SCT as i t r etur ned bef ore. TLS ser ver s MUST pr esent an SCT f r omone or mor e l ogs t o t he TLS cl i ent t oget her wi t h t he cer t i f i cat e.TLS cl i ent s MUST r ej ect cer t i f i cat es t hat do not have a val i d SCT f ort he end- ent i t y cer t i f i cat e.

Per i odi cal l y, each l og appends al l i t s new ent r i es t o t he Mer kl eTr ee, and si gns t he r oot of t he t r ee. Audi t or s can t hus ver i f y t hateach cer t i f i cat e f or whi ch an SCT has been i ssued i ndeed appear s i nt he l og. The l og MUST i ncor por at e a cer t i f i cat e i n i t s Mer kl e Tr eewi t hi n t he Maxi mum Merge Del ay per i od af t er t he i ssuance of t he SCT.

Log operators MUST NOT i mpose any condi t i ons on r et r i evi ng or shar i ngdat a f r om t he l og.

3.1. Log Entries

Anyone can submi t a cer t i f i cat e t o any l og. I n or der t o enabl eat t r i but i on of each l ogged cer t i f i cat e t o i t s i ssuer , t he l og SHALLpubl i sh a l i st of accept abl e r oot cer t i f i cat es ( t hi s l i st mi ghtusef ul l y be t he uni on of r oot cer t i f i cat es t r ust ed by maj or br owservendors) . Each submi t t ed cer t i f i cate MUST be accompani ed by al l

addi t i onal cer t i f i cat es r equi r ed t o ver i f y t he cer t i f i cat e chai n upt o an accept ed r oot cer t i f i cat e. The r oot cer t i f i cat e i t sel f MAY beomi t t ed f r om t he chai n submi t t ed t o t he l og server .

Al t er nat i vel y, ( r oot as wel l as i nt er medi at e) Cer t i f i cat e Aut hor i t i esmay submi t a cer t i f i cat e t o l ogs pr i or t o i ssuance. To do so, t he CAsubmi t s a Pr ecer t i f i cat e that t he l og can use to cr eat e an ent r y t hatwi l l be val i d agai nst t he i ssued cer t i f i cat e. The Pr ecer t i f i cat e i sconst r uct ed f r om t he cer t i f i cat e t o be i ssued by addi ng a speci alcr i t i cal poi son ext ensi on ( OI D 1. 3. 6. 1. 4. 1. 11129. 2. 4. 3, whoseext nVal ue OCTET STRI NG contai ns ASN. 1 NULL data ( 0x05 0x00) ) t o t heend ent i t y TBSCer t i f i cat e ( t hi s ext ensi on i s t o ensur e t hat t hePr ecer t i f i cat e cannot be val i dat ed by a st andar d X. 509v3 cl i ent ) , andsi gni ng t he r esul t i ng TBSCer t i f i cat e [ RFC5280] wi t h ei t her


o a speci al - pur pose ( CA: t r ue, Extended Key Usage: Cer t i f i cat eTr anspar ency, OI D 1. 3. 6. 1. 4. 1. 11129. 2. 4. 4) Pr ecer t i f i cat e Si gni ng




Cer t i f i cat e. The Pr ecer t i f i cat e Si gni ng Cer t i f i cat e MUST bedi r ectl y cer t i f i ed by t he ( r oot or i nt er medi at e) CA cer t i f i cat et hat wi l l ul t i mat el y si gn t he end ent i t y TBSCer t i f i cat e yi el di ngt he end ent i t y cer t i f i cat e ( not e t hat t he l og may r el ax st andar dval i dat i on r ul es t o al l ow t hi s, so l ong as t he i ssued cer t i f i cat ewi l l be val i d) ,

o or , t he CA cer t i f i cat e t hat wi l l s i gn t he f i nal cer t i f i cat e.

As above, t he Pr ecer t i f i cate submi ssi on MUST be accompani ed by t hePr ecer t i f i cat e Si gni ng Cer t i f i cat e, i f used, and al l addi t i onalcer t i f i cat es r equi r ed t o ver i f y t he chai n up t o an accept ed r ootcer t i f i cat e. The si gnat ur e on t he TBSCer t i f i cat e i ndi cat es theCer t i f i cat e Aut hor i t y' s i nt ent t o i ssue a cer t i f i cat e. Thi s i nt enti s consi der ed bi ndi ng ( i . e. , mi si ssuance of t he Pr ecer t i f i cat e i sconsi der ed equal t o mi si ssuance of t he f i nal cer t i f i cat e) . Each l ogver i f i es t he Pr ecer t i f i cat e si gnat ur e chai n, and i ssues a Si gnedCer t i f i cat e Ti mest amp on t he cor r espondi ng TBSCer t i f i cat e.

Logs MUST ver i f y t hat t he submi t t ed end ent i t y cer t i f i cat e orPr ecer t i f i cat e has a val i d si gnat ur e chai n l eadi ng back t o a t r ust edr oot CA cer t i f i cat e, usi ng t he chai n of i nt er medi at e CA cer t i f i cat espr ovi ded by t he submi t t er . Logs MAY accept cer t i f i cat es t hat haveexpi r ed, ar e not yet val i d, have been r evoked or ar e ot her wi se notf ul l y val i d accor di ng t o X. 509 ver i f i cat i on r ul es i n or der t oaccommodat e qui r ks of CA cer t i f i cat e i ssui ng sof t war e. However , l ogsMUST r ef use t o publ i sh cer t i f i cat es wi t hout a val i d chai n t o a knownr oot CA. I f a cer t i f i cat e i s accept ed and an SCT i ssued, t he

accept i ng l og MUST st or e t he ent i r e chai n used f or ver i f i cat i oni ncl udi ng t he cer t i f i cat e or Pr ecer t i f i cat e i t sel f , and i ncl udi ng t her oot cer t i f i cat e used t o ver i f y t he chai n ( even i f i t was omi t t edf r om t he submi ssi on) and MUST pr esent t hi s chai n f or audi t i ng uponr equest . Thi s chai n i s requi r ed t o pr event a CA avoi di ng bl ame byl oggi ng a par t i al or empt y chai n [ Not e: t hi s ef f ect i vel y excl udessel f - si gned and DANE- based cer t i f i cat es unt i l some mechani sm t ocont r ol spam f or t hose cer t i f i cat es i s f ound - t he aut hor s wel comesuggest i ons] .

Each cer t i f i cat e ent r y i n a l og MUST i ncl ude t he f ol l owi ngcomponents:


enum { x509_ent r y(0) , pr ecer t _ent r y(1) , ( 65535) } LogEnt r yType;

struct {LogEnt r yType ent r y_t ype;




sel ect ( ent r y_t ype) {case x509_ent r y: X509Chai nEnt r y;case pr ecer t _ent r y: Pr ecer t Chai nEnt r y;

} ent r y;} LogEnt r y;

opaque ASN. 1Cer t <1. . 2 2̂4- 1>;

struct {ASN. 1Cer t l eaf _cer t i f i cat e;ASN. 1Cer t cer t i f i cat e_chai n<0. . 2 2̂4- 1>;

} X509Chai nEnt r y;

struct {ASN. 1Cer t pr e_cer t i f i cat e;ASN. 1Cer t pr ecer t i f i cat e_chai n<0. . 2 2̂4- 1>;

} Pr ecer t Chai nEnt r y;

Logs MAY l i mi t t he l engt h of chai n t hey wi l l accept .

"ent r y_t ype" i s t he t ype of t hi s ent r y. Fut ur e r evi si ons of t hi spr otocol ver si on may add new LogEnt r yType val ues. Sect i on 4 expl ai nshow cl i ent s shoul d handl e unknown ent r y t ypes.

"l eaf _cer t i f i cat e" i s the end- ent i t y cer t i f i cat e submi t t ed f oraudi t i ng.

"cer t i f i cat e_chai n" i s a chai n of addi t i onal cer t i f i cat es requi r ed t o

ver i f y t he end ent i t y cer t i f i cat e. The f i r st cer t i f i cat e MUSTcer t i f y t he end ent i t y cer t i f i cat e. Each f ol l owi ng cer t i f i cat e MUSTdi r ect l y cer t i f y t he one pr ecedi ng i t . The f i nal cer t i f i cat e MUST bea r oot cer t i f i cat e accept ed by t he l og.

"pr e_cer t i f i cat e" i s t he Pr ecer t i f i cat e submi t ed f or audi t i ng.

"pr ecer t i f i cat e_chai n" i s a chai n of addi t i onal cer t i f i cat es requi r edt o ver i f y t he Pr ecer t i f i cat e submi ssi on. The f i r st cer t i f i cat e MAYbe a val i d Pr ecer t i f i cat e Si gni ng Cer t i f i cat e, and MUST cer t i f y thef i r st cer t i f i cat e. Each f ol l owi ng cer t i f i cat e MUST di r ect l y cer t i f yt he one pr ecedi ng i t . The f i nal cer t i f i cat e MUST be a r ootcer t i f i cat e accept ed by t he l og.


3.2. Structure of the Signed Certif icate Timestamp

enum { cer t i f i cat e_t i mest amp( 0) , t r ee_hash( 1) , ( 255) }




Si gnatur eType;

enum { v1( 0) , ( 255) }Ver si on;

struct {opaque key_i d[ 32] ;

} LogI D;

opaque TBSCer t i f i cat e<1. . 2 2̂4- 1>;

struct {opaque i ssuer_key_hash[ 32] ;TBSCer t i f i cat e t bs_cer t i f i cat e;

} PreCer t ;

opaque Ct Extensi ons<0. . 2 1̂6- 1>;

"key_i d" i s t he SHA- 256 hash of t he l og' s publ i c key, cal cul at ed overt he DER encodi ng of t he key r epr esent ed as Subj ect Publ i cKeyI nf o.

"i ssuer _key_hash" i s t he SHA- 256 hash of t he cer t i f i cat e i ssuer ' spubl i c key, cal cul at ed over t he DER encodi ng of t he key repr esent edas Subj ect Publ i cKeyI nf o. Thi s i s needed t o bi nd t he i ssuer t o t hef i nal cer t i f i cate.

" t bs_cer t i f i cat e" i s t he DER encoded TBSCer t i f i cat e ( see [ RFC5280] )component of t he Pr ecer t i f i cat e - t hat i s, wi t hout t he si gnat ur e and

t he poi son ext ensi on. I f t he Pr ecer t i f i cat e i s not si gned wi t h t heCA cer t i f i cat e t hat wi l l i ssue t he f i nal cer t i f i cat e, t hen t heTBSCer t i f i cat e al so has i t s i ssuer changed t o t hat of t he CA t hatwi l l i ssue t he f i nal cer t i f i cat e. Not e t hat i t i s al so possi bl e t or econstr uct t hi s TBSCer t i f i cat e f r om t he f i nal cer t i f i cat e byext r act i ng t he TBSCer t i f i cat e f r om i t and del et i ng t he SCT ext ensi on.Al so not e t hat si nce t he TBSCer t i f i cat e cont ai ns anAl gor i t hmI dent i f i er t hat must mat ch bot h t he pr e- cer t i f i cat esi gnat ur e al gor i t hm and f i nal cer t i f i cat e si gnat ur e al gor i t hm, t heymust be si gned wi t h t he same al gor i t hm and par amet er s. I f t hePr ecer t i f i cat e i s i ssued usi ng a Pr ecer t i f i cat e Si gni ng Cer t i f i cat e,and an Aut hor i t y Key I dent i f i er ext ensi on i s pr esent i n t heTBSCer t i f i cat e, t he cor r espondi ng extensi on must al so be pr esent i nt he Pr ecer t i f i cat e Si gni ng Cer t i f i cat e - i n t hi s case, t heTBSCer t i f i cat e al so has i t s Aut hor i t y Key I dent i f i er changed t o mat cht he f i nal i ssuer .





struct {Ver si on sct _ver si on;LogI D i d;ui nt 64 t i mest amp;Ct Extensi ons extensi ons;di gi t al l y- si gned str uct {

Ver si on sct _ver si on;

Si gnat ur eType si gnat ur e_t ype = cer t i f i cat e_t i mest amp;ui nt 64 t i mest amp;LogEnt r yType ent r y_t ype;sel ect ( ent r y_t ype) {

case x509_ent r y: ASN. 1Cer t ;case pr ecer t _ent r y: Pr eCer t ;

} si gned_ent r y;Ct Extensi ons extensi ons;

};} Si gnedCer t i f i cat eTi mest amp;

The encodi ng of t he di gi t al l y- si gned el ement i s def i ned i n [ RFC5246] .

"sct _ver si on" i s t he ver si on of t he pr ot ocol t he SCT conf or ms t o.Thi s ver si on i s v1.

" t i mest amp" i s t he cur r ent NTP Ti me [ RFC5905] , measured si nce t heepoch ( J anuar y 1, 1970, 00: 00) , i gnor i ng l eap seconds, i nmi l l i seconds.

"ent r y_t ype" may be i mpl i ci t f r om t he cont ext i n whi ch t he SCT i s

pr esent ed.

"si gned_ent r y" i s t he "l eaf _cer t i f i cat e" ( i n case of anX509Chai nEnt r y) , or i s t he Pr eCer t ( i n case of a Pr ecer t Chai nEnt r y) ,as descr i bed above.

"ext ensi ons" ar e f ut ur e ext ensi ons t o t hi s pr ot ocol ver si on ( v1) .Cur r ent l y, no ext ensi ons are speci f i ed.

3.3. Including the Signed Certif icate Timestamp in the TLS Handshake

The SCT dat a cor r espondi ng t o the end ent i t y cer t i f i cat e f r om atl east one l og must be i ncl uded i n t he TLS handshake, ei t her by usi ngan X509v3 cer t i f i cat e extensi on as descr i bed bel ow, by usi ng a TLSExt ensi on ( sect i on 7. 4. 1. 4 of [ RFC5246] ) wi t h t ype [TBD] , or by usi ngOCSP St apl i ng ( sect i on 8 of [ RFC6066] ) , wher e t he response i ncl udesan OCSP extensi on wi t h OI D 1. 3. 6. 1. 4. 1. 11129. 2. 4. 5 ( see [RFC2560] )and body:

Si gnedCer t i f i cat eTi mest ampLi st : : = OCTET STRI NG





At l east one SCT MUST be i ncl uded. Server operators MAY i ncl ude moret han one SCT.

Si mi l ar l y, a Cer t i f i cat e Aut hor i t y MAY submi t a pr ecer t i f i cat e t omore t han one l og, and al l obt ai ned SCTs can be di r ect l y embedded i nt he f i nal cer t i f i cat e, by encodi ng t he Si gnedCer t i f i cat eTi mest ampLi stst r uct ur e as an ASN. 1 OCTET STRI NG and i nser t i ng the resul t i ng dat ai n t he TBSCer t i f i cat e as an X. 509v3 cer t i f i cat e ext ensi on ( OI D1. 3. 6. 1. 4. 1. 11129. 2. 4. 2) . Upon r ecei vi ng t he cer t i f i cat e, cl i ent scan r econst r uct t he or i gi nal TBSCer t i f i cat e t o ver i f y t he SCTsi gnat ur e.

The cont ent s of t he ASN. 1 OCTET STRI NG embedded i n an OCSP extensi onor X509v3 cer t i f i cat e ext ensi on ar e as f ol l ows:

opaque Ser i al i zedSCT<1. . 2 1̂6- 1>;

struct {Ser i al i zedSCT sct _l i st <1. . 2 1̂6- 1>;

} Si gnedCer t i f i cat eTi mest ampLi st ;

Her e "Ser i al i zedSCT" i s an opaque bytest r i ng t hat cont ai ns t heser i al i zed TLS st r uct ur e. Thi s encodi ng ensur es t hat TLS cl i ent s candecode each SCT i ndi vi dual l y ( i . e. , i f t her e i s a ver si on upgr ade,

out of dat e cl i ent s can st i l l par se ol d SCTs whi l e ski ppi ng over newSCTs whose versi on t hey don' t underst and) .

Li kewi se, SCTs can be embedded i n a TLS Ext ensi on. See bel ow f ordet ai l s .

TLS cl i ent s MUST i mpl ement al l t hr ee mechani sms. Server s MUSTi mpl ement at l east one of t he t hr ee mechani sms. Not e t hat exi st i ngTLS server s can gener al l y use the cer t i f i cat e extensi on mechani smwi t hout modi f i cat i on.

TLS server s shoul d send SCTs f r om mul t i pl e l ogs i n case one or mor el ogs i s not accept abl e t o t he cl i ent ( f or exampl e, i f a l og has beenst r uck of f f or mi sbehavi our or has had a key compr omi se) .

3.3.1. TLS Extension

The SCT can be sent dur i ng t he TLS handshake usi ng a TLS ext ensi on,t ype [ TBD] .




Cl i ent s t hat suppor t t he extensi on SHOULD send a Cl i ent Hel l oext ensi on wi t h the appr opr i at e t ype and empt y "extensi on_dat a" .

Server s MUST onl y send SCTs t o cl i ent s who have i ndi cated support f or


t he extensi on i n t he Cl i ent Hel l o, i n whi ch case the SCTs are sent byset t i ng t he "ext ensi on_dat a" t o a "Si gnedCer t i f i cat eTi mest ampLi st " .

Sessi on r esumpt i on uses t he or i gi nal sessi on i nf or mat i on: cl i ent sSHOULD i ncl ude t he extensi on t ype i n t he Cl i ent Hel l o but i f t hesessi on i s r esumed, t he server i s not expect ed t o pr ocess i t ori ncl ude t he ext ensi on i n t he Ser ver Hel l o.

3.4. Merkle Tree

The hashi ng al gor i t hm f or t he Mer kl e Tr ee Hash i s SHA- 256.

St r uct ur e of t he Mer kl e Tr ee i nput :

enum { t i mest amped_ent r y( 0) , ( 255) }Merkl eLeaf Type;

struct {ui nt 64 t i mest amp;LogEnt r yType ent r y_t ype;

sel ect ( ent r y_t ype) {case x509_ent r y: ASN. 1Cert ;case pr ecer t _ent r y: Pr eCer t ;

} si gned_ent r y;Ct Extensi ons extensi ons;

} Ti mest ampedEnt r y;

struct {Ver si on ver si on;Mer kl eLeaf Type l eaf _t ype;sel ect ( l eaf _t ype) {

case t i mest amped_ent r y: Ti mest ampedEnt r y;}

} Merkl eTr eeLeaf ;

Her e "ver si on" i s t he ver si on of t he pr ot ocol t he Mer kl eTr eeLeaf cor r esponds t o. Thi s ver si on i s v1.

"l eaf _t ype" i s t he t ype of t he l eaf i nput . Cur r ent l y, onl y" t i mest amped_ent r y" ( cor r espondi ng t o an SCT) i s def i ned. Fut ur e




r evi si ons of t hi s prot ocol ver si on may add new Mer kl eLeaf Type t ypes.Sect i on 4 expl ai ns how cl i ent s shoul d handl e unknown l eaf t ypes.

" t i mest amp" i s t he t i mest amp of t he corr espondi ng SCT i ssued f or t hi scert i f i cat e.

"si gned_ent r y" i s t he "si gned_ent r y" of t he cor r espondi ng SCT.


"extensi ons" ar e "ext ensi ons" of t he cor r espondi ng SCT.

The l eaves of t he Mer kl e Tr ee ar e t he l eaf hashes of t hecor r espondi ng "Mer kl eTr eeLeaf " st r uct ur es.

3.5. Signed Tree Head

Ever y t i me a l og appends new ent r i es t o t he t r ee, t he l og SHOULD si gnt he cor r espondi ng t r ee hash and t r ee i nf or mat i on ( see t hecor r espondi ng Si gned Tr ee Head cl i ent message i n Sect i on 4. 3) . Thesi gnat ur e f or t hat dat a i s st r uct ur ed as f ol l ows:

di gi t al l y- si gned str uct {Ver si on ver si on;Si gnatur eType si gnatur e_t ype = t r ee_hash;ui nt 64 t i mest amp;ui nt 64 t r ee_si ze;

opaque sha256_r oot _hash[32] ;} TreeHeadSi gnatur e;

"ver si on" i s t he ver si on of t he pr ot ocol t he Tr eeHeadSi gnat ur econf or ms t o. Thi s ver si on i s v1.

" t i mest amp" i s t he cur r ent t i me. The t i mest amp MUST be at l east asr ecent as the most r ecent SCT t i mest amp i n t he t r ee. Each subsequentt i mest amp MUST be more r ecent t han t he t i mest amp of t he previ ousupdat e.

" t r ee_si ze" equal s t he number of ent r i es i n t he new t r ee.

"sha256_r oot _hash" i s t he r oot of t he Mer kl e Hash Tr ee.

Each l og MUST produce on demand a Si gned Tr ee Head t hat i s no ol dert han t he Maxi mum Mer ge Del ay. I n t he unl i kel y event t hat i t r ecei vesno new submi ssi ons dur i ng an MMD per i od, t he l og SHALL s i gn t he sameMerkl e Tr ee Hash wi t h a f r esh t i mest amp.





4. Log Client Messages

Messages ar e sent as HTTPS GET or POST r equest s. Paramet ers f orPOSTs and al l r esponses are encoded as J SON obj ect s [ RFC4627] .

Par ameters f or GETs are encoded as or der i ndependent key/ val ue URLpar amet er s, usi ng t he "appl i cat i on/ x- www- f or m- ur l encoded" f or matdescr i bed i n t he "HTML 4. 01 Speci f i cat i on" [ HTML401] . Bi nar y dat a i sbase64 encoded [ RFC4648] as speci f i ed i n t he i ndi vi dual messages.

Note t hat J SON obj ect s and URL parameters may cont ai n f i el ds notspeci f i ed her e. These ext r a f i el ds shoul d be i gnor ed.

The <l og ser ver > pr ef i x can i ncl ude a path as wel l as a ser ver nameand a por t .

I n gener al , wher e needed, t he "ver si on" i s v1 and t he " i d" i s t he l ogi d f or t he l og ser ver quer i ed.

Any er r ors wi l l be retur ned as HTTP 4xx or 5xx responses, wi t h humanr eadabl e err or messages.

4.1. Add Chain to Log

POST ht t ps: / / <l og ser ver >/ ct / v1/ add- chai n

I nput s

chai n An ar r ay of base64 encoded cer t i f i cat es. The f i r st el ement i st he end ent i t y cer t i f i cat e, t he second chai ns t o t he f i r st and soon t o t he l ast , whi ch i s ei t her t he r oot cer t i f i cat e or acer t i f i cat e t hat chai ns t o a known r oot cer t i f i cat e.

Output s

sct _ver si on The ver si on of t he Si gnedCer t i f i cat eTi mest amp st r uct ur e,i n deci mal . A compl i ant v1 i mpl ement at i on MUST NOT expect t hi s t obe 0 ( i . e. , v1) .

i d The l og I D, base64 encoded. Si nce l og cl i ent s who r equest an SCTf or i ncl usi on i n TLS handshakes ar e not r equi r ed t o ver i f y i t , wedo not assume they know t he I D of t he l og.

t i mest amp The SCT t i mest amp, i n deci mal .

ext ensi ons An opaque t ype f or f ut ur e expansi on. I t i s l i kel y t hat




not al l par t i ci pant s wi l l need t o under st and dat a i n t hi s f i el d.Logs shoul d set t hi s to t he empt y st r i ng. Cl i ent s shoul d decodet he base64 encoded data and i ncl ude i t i n the SCT.


si gnatur e The SCT si gnatur e, base64 encoded.

I f t he "sct _ver si on" i s not v1, t hen a v1 cl i ent may be unabl e t over i f y t he si gnat ur e. I t MUST NOT const r ue t hi s as an er r or . [ Not e:l og cl i ent s don' t need t o be abl e t o ver i f y thi s st r uctur e, onl y TLScl i ent s do - i f we wer e t o ser ve t he st r uct ur e bi nar y, t hen we coul dcompl et el y change i t wi t hout r equi r i ng an upgr ade t o v1 cl i ent s] .

4.2. Add PreCertChain to Log

POST ht t ps: / / <l og ser ver >/ ct / v1/ add- pr e- chai n

I nput s

chai n An ar r ay of base64 encoded pr ecer t i f i cat es. The f i r st el ementi s t he end ent i t y cer t i f i cat e, t he second chai ns t o t he f i r st andso on t o t he l ast , whi ch i s ei t her t he r oot cer t i f i cat e or acer t i f i cat e t hat chai ns t o a known r oot cer t i f i cat e.

Out put s ar e the same as Sect i on 4. 1.

4.3. Retrieve Latest Signed Tree Head

GET ht t ps: / / <l og ser ver >/ ct / v1/ get - st h

No i nput s.

Output s

t r ee_si ze The si ze of t he t r ee, i n ent r i es, i n deci mal .

t i mest amp The t i mest amp, i n deci mal .

sha256_r oot _hash The Merkl e Tree Hash of t he t r ee, i n base64.

t r ee_head_s i gnatur e A TreeHeadSi gnatur e f or t he above data.

4.4. Retrieve Merkle Consistency Proof between two Signed Tree Heads

GET ht t ps: / / <l og ser ver >/ ct / v1/ get - st h- consi st ency




I nput s

f i r st The t r ee_si ze of t he f i r st t r ee, i n deci mal .


second The t r ee_si ze of t he second t r ee, i n deci mal .

Bot h t r ee si zes must be f r om exi st i ng v1 STHs ( Si gned Tr ee Heads) .

Output s

consi st ency An arr ay of Merkl e t r ee nodes, base64 encoded.

Not e t hat no si gnat ur e i s r equi r ed on t hi s dat a, as i t i s used t over i f y an STH, whi ch i s si gned.

4.5. Retrieve Merkle Audit Proof from Log by Leaf Hash

GET ht t ps: / / <l og ser ver >/ ct / v1/ get - pr oof - by- hash

I nput s

hash A base64 encoded v1 l eaf hash.

t r ee_si ze The t r ee_si ze of t he t r ee t o base t he pr oof on, i ndeci mal .

The "hash" must be cal cul at ed as def i ned i n Sect i on 3. 4. The"t r ee_si ze" must desi gnat e an exi st i ng v1 STH.

Output s

l eaf _i ndex The 0- based i ndex of t he end ent i t y cor r espondi ng t o t he"hash" parameter .

audi t _pat h An arr ay of base64 encoded Merkl e t r ee nodes pr ovi ng t hei ncl usi on of t he chosen cer t i f i cat e.

4.6. Retrieve Entr ies from Log

GET ht t ps: / / <l og ser ver >/ ct / v1/ get - ent r i es

I nput s

st ar t 0- based i ndex of f i r st ent r y t o r et r i eve, i n deci mal .




end 0- based i ndex of l ast ent r y t o r et r i eve, i n deci mal .

Output s


ent r i es An ar r ay of obj ect s, each consi st i ng of

l eaf _i nput The base64- encoded Mer kl eTr eeLeaf st r uct ur e.

ext r a_data The base64- encoded unsi gned data pert ai ni ng t o t he l ogent r y. I n t he case of an X509Chai nEnt r y, t hi s i s the"cer t i f i cat e_chai n". I n t he case of a Pr ecer t Chai nEnt r y, t hi si s t he whol e "Precer t Chai nEnt r y" .

Not e t hat t hi s message i s not si gned - t he r et r i eved dat a can bever i f i ed by const r uct i ng t he Mer kl e Tr ee Hash cor r espondi ng t o a

r et r i eved STH. Al l l eaves MUST be v1. However , a compl i ant v1cl i ent MUST NOT const r ue an unr ecogni zed Merkl eLeaf Type orLogEnt r yType val ue as an err or . Thi s means i t may be unabl e t o parsesome ent r i es, but not e t hat each cl i ent can i nspect t he ent r i es i tdoes r ecogni ze, as wel l as ver i f y the i nt egr i t y of t he dat a byt r eat i ng unr ecogni zed l eaves as opaque i nput t o t he t r ee.

The "st ar t " and "end" par amet ers SHOULD be wi t hi n t he r ange 0 <= x <"t r ee_si ze" as r et ur ned by "get - st h" i n Sect i on 4. 3.

Logs MAY honour r equest s where 0 <= "st ar t " < " t r ee_si ze" , and "end">= "t r ee_si ze" by r et ur ni ng a par t i al r esponse cover i ng onl y t heval i d ent r i es i n t he speci f i ed r ange. Not e t hat t he f ol l owi ngr est r i ct i on may al so appl y:

Logs MAY rest r i ct t he number of ent r i es whi ch can be ret r i eved per"get - ent r i es" r equest . I f a cl i ent r equest s mor e t han t he per mi t t ednumber of ent r i es, t he l og SHALL r etur n t he maxi mum number of ent r i esper mi ssi bl e. These ent r i es SHALL be sequent i al begi nni ng wi t h t heent r y speci f i ed by "st ar t ".

4.7. Retrieve Accepted Root Certif icates

GET ht t ps: / / <l og ser ver >/ ct / v1/ get - r oot s

No i nput s.

Output s

cer t i f i cat es An ar r ay of base64 encoded r oot cer t i f i cat es t hat ar e




accept abl e t o t he l og.

4.8. Retrieve Entry+Merkle Audit Proof from Log

GET ht t ps: / / <l og ser ver >/ ct / v1/ get - ent r y- and- pr oof

I nput s


l eaf _i ndex The i ndex of t he desi r ed ent r y.

t r ee_si ze The t r ee_si ze of t he t r ee f or whi ch t he pr oof i s desi r ed.

The t r ee si ze must desi gnat e an exi st i ng STH.

Output s

l eaf _i nput The base64- encoded Mer kl eTr eeLeaf s t r uct ur e.

ext r a_dat a The base64- encoded unsi gned data, same as i n Sect i on 4. 6.

audi t _pat h An arr ay of base64 encoded Merkl e t r ee nodes pr ovi ng t hei ncl usi on of t he chosen cer t i f i cat e.

Thi s API i s pr obabl y onl y usef ul f or debuggi ng.


5. Clients

Ther e ar e var i ous di f f er ent f unct i ons cl i ent s of l ogs mi ght per f or m.We descr i be her e some t ypi cal cl i ent s and how t hey coul d f unct i on.Any i nconsi st ency may be used as evi dence t hat a l og has not behavedcor r ect l y, and t he si gnat ur es on t he dat a st r uct ur es pr event t he l ogf r om denyi ng that mi sbehavi our .

Al l cl i ent s shoul d gossi p wi t h each ot her , exchangi ng STHs at l east :t hi s i s al l t hat i s r equi r ed t o ensur e t hat t hey al l have aconsi st ent vi ew. The exact mechani sm f or gossi p wi l l be descr i bed i nan separ at e document , but i t i s expect ed t her e wi l l be a var i et y.

5.1. Submitters

Submi t t er s submi t cer t i f i cat es or pr ecer t i f i cat es t o t he l og asdescr i bed above. They may go on t o use t he r etur ned SCT t o const r uct




a cer t i f i cat e or use i t di r ect l y i n a TLS handshake.

5.2. TLS Client

TLS cl i ent s ar e not di r ect l y cl i ent s of t he l og, but t hey r ecei veSCTs al ongsi de or i n ser ver cer t i f i cat es. I n addi t i on t o nor malval i dat i on of t he cer t i f i cat e and i t s chai n, t hey shoul d val i dat e t he

SCT by comput i ng t he si gnat ur e i nput f r om t he SCT dat a as wel l as t hecer t i f i cat e, and ver i f yi ng t he si gnat ur e, usi ng t he cor r espondi ngl og' s publ i c key. Not e t hat t hi s document does not descr i be howcl i ent s obt ai n t he l ogs' publ i c keys.

TLS cl i ent s MUST rej ect SCTs whose t i mest amp i s i n the f ut ur e.

5.3. Monitor

Moni t or s wat ch l ogs and check t hat t hey behave cor r ect l y. They al sowat ch f or cer t i f i cat es of i nt er est .

A moni t or needs t o, at l east , i nspect ever y new ent r y i n each l og i twat ches. I t may al so want t o keep copi es of ent i r e l ogs. I n or dert o do t hi s, i t shoul d f ol l ow t hese st eps f or each l og:

1. Fet ch t he cur r ent STH usi ng Sect i on 4. 3.

2. Ver i f y t he STH si gnat ur e.

3. Fet ch al l t he ent r i es i n t he t r ee cor r espondi ng t o t he STH usi ng

Sect i on 4. 6.


4. Conf i r m t hat t he t r ee made f r om t he f et ched ent r i es pr oduces t hesame hash as t hat i n t he STH.

5. Fet ch t he cur r ent STH usi ng Sect i on 4. 3. Repeat unt i l STHchanges.

6. Ver i f y t he STH si gnat ur e.

7. Fet ch al l t he new ent r i es i n t he t r ee cor r espondi ng t o t he STHusi ng Sect i on 4. 6. I f t hey r emai n unavai l abl e f or an extendedper i od, t hen t hi s shoul d be vi ewed as mi sbehavi our on t he par t of t he l og.

8. Ei t her :




1. Ver i f y t hat t he updat ed l i st of al l ent r i es gener at es a t r eewi t h t he same hash as t he new STH.

Or , i f i t i s not keepi ng al l l og ent r i es:

2. Fet ch a consi st ency pr oof f or t he new STH wi t h t he pr evi ousSTH usi ng Sect i on 4. 4.

3. Ver i f y t he consi st ency pr oof .

4. Ver i f y t hat t he new ent r i es gener at e t he cor r espondi ngel ement s i n t he consi st ency pr oof .

9. Go t o St ep 5.

5.4. Auditor

Audi t or s t ake par t i al i nf or mat i on about a l og as i nput and ver i f y

t hat t hi s i nf or mat i on i s consi st ent wi t h ot her par t i al i nf or mat i ont hey have. An audi t or mi ght be an i nt egr al component of a TLScl i ent , i t mi ght be a st andal one ser vi ce or i t mi ght be a secondar yf unct i on of a moni t or .

Any pai r of STHs f r om t he same l og can be ver i f i ed by request i ng aconsi st ency pr oof usi ng Sect i on 4. 4.

A cer t i f i cat e accompani ed by an SCT can be ver i f i ed agai nst any STHdat ed af t er t he SCT t i mest amp + t he Maxi mumMerge Del ay by r equest i ng

a Mer kl e Audi t Pr oof usi ng Sect i on 4. 5.

Audi t or s can f et ch STHs f r om t i me t o t i me of t hei r own accor d, of cour se, usi ng Sect i on 4. 3.


6. IANA Considerations

I ANA i s r equest ed to al l ocat e an RFC 5246 Extensi onType Val ue f or t heCTS TLS ext ensi on. The Ext ensi on name i s"si gned_cer t i f i cat e_t i mest amp".


7. Security Considerations

Wi t h CAs, l ogs, and server s per f or mi ng t he act i ons descr i bed her e,




TLS cl i ent s can use l ogs and si gned t i mest amps t o r educe thel i kel i hood t hat t hey wi l l accept mi si ssued cer t i f i cat es. I f a ser verpr esent s a val i d si gned t i mest amp f or a cer t i f i cat e, t hen t he cl i entknows t hat t he cer t i f i cat e has been publ i shed i n a l og. From t hi s,t he cl i ent knows t hat t he subj ect of t he cer t i f i cat e has had somet i me t o not i ce t he mi si ssue and t ake some act i on, such as aski ng a CAt o r evoke a mi si ssued cer t i f i cat e. A si gned t i mest amp i s not a

guar ant ee t hat t he cer t i f i cat e i s not mi si ssued, si nce t he subj ect of t he cer t i f i cat e mi ght not have checked t he l ogs or t he CA mi ght haver ef used t o r evoke t he cer t i f i cat e.

I n addi t i on, i f TLS cl i ent s wi l l not accept unl ogged cer t i f i cat es,t hen si t e owner s wi l l have a gr eat er i ncent i ve t o submi t cer t i f i cat est o l ogs, possi bl y wi t h t he assi st ance of t hei r CA, i ncr easi ng t heover al l t r anspar ency of t he syst em.

7.1. Misissued Certificates

Mi si ssued cer t i f i cat es t hat have not been publ i cl y l ogged, and t husdo not have a val i d SCT, wi l l be r ej ect ed by TLS cl i ent s. Mi si ssuedcer t i f i cat es t hat do have an SCT f r om a l og wi l l appear i n t hatpubl i c l og wi t hi n t he Maxi mum Mer ge Del ay, assumi ng t he l og i soper at i ng cor r ect l y. Thus, t he maxi mum per i od of t i me dur i ng whi ch ami si ssued cer t i f i cat e can be used wi t hout bei ng avai l abl e f or audi ti s t he MMD.

7.2. Detection of Misissue

The l ogs do not t hemsel ves det ect mi si ssued cer t i f i cat es, t hey rel yi nst ead on i nt er est ed par t i es, such as domai n owner s, t o moni t or t hemand t ake corr ect i ve act i on when a mi si ssue i s det ect ed.

7.3. Misbehaving logs

A l og can mi sbehave i n t wo ways: ( 1) , by f ai l i ng t o i ncor por at e acer t i f i cat e wi t h an SCT i n t he Mer kl e Tr ee wi t hi n t he MMD; and ( 2) ,by vi ol at i ng i t s append- onl y pr oper t y by pr esent i ng t wo di f f er ent ,conf l i ct i ng vi ews of t he Mer kl e Tr ee at di f f er ent t i mes and/ or t o

di f f er ent par t i es. Bot h f or ms of vi ol at i on wi l l be pr ompt l y andpubl i cl y det ect abl e.

Vi ol at i on of t he MMD cont r act i s det ect ed by l og cl i ent s r equest i ng aMerkl e audi t pr oof f or each obser ved SCT. These checks can beasynchr onous, and need onl y be done once per each cer t i f i cat e. I nor der t o pr ot ect t he cl i ent s' pr i vacy, t hese checks need not r eveal





t he exact cer t i f i cat e t o t he l og. Cl i ent s can i nst ead r equest t hepr oof f r om a t r ust ed audi t or ( si nce anyone can comput e t he audi tpr oof s f r om t he l og) , or r equest Mer kl e pr oof s f or a bat ch of cer t i f i cat es around t he SCT t i mest amp.

Vi ol at i on of t he append- onl y pr oper t y i s det ect ed by gl obal

gossi pi ng, i . e. , ever yone audi t i ng l ogs compar i ng t hei r ver si ons of t he l at est si gned t r ee heads. As soon as t wo conf l i ct i ng si gned t r eeheads f or t he same l og ar e det ect ed, t hi s i s cr ypt ogr aphi c pr oof of t hat l og' s mi sbehavi our .


8. Efficiency Considerations

The Merkl e t r ee desi gn serves t he pur pose of keepi ng communi cat i on

over head l ow.

Audi t i ng l ogs f or i nt egr i t y does not r equi r e t hi r d par t i es t omai nt ai n a copy of each ent i r e l og. The Si gned Tree Heads can beupdat ed as new ent r i es become avai l abl e, wi t hout r ecomput i ng ent i r et r ees. Thi r d par t y audi t or s need onl y f et ch t he Mer kl e consi st encypr oof s agai nst a l og' s exi st i ng STH t o ef f i ci ent l y ver i f y t he append-onl y pr oper t y of updat es t o t hei r Mer kl e Tr ees, wi t hout audi t i ng t heent i r e t r ee.


9. Future Changes

Thi s sect i on l i st s t hi ngs we mi ght addr ess i n a St andar ds Tr ackver si on of t hi s document .

Rat her t han f or ci ng a l og oper at or t o cr eat e a new l og i n or der t ochange t he l og si gni ng key, we may al l ow some key r ol l mechani sm.

We may add hash and si gni ng al gor i t hm agi l i t y.

We may descr i be some gossi p prot ocol s.


10. Acknowledgements




The aut hors woul d l i ke t o t hank Er wann Abel ea, Robi n Al den, AlCut t er , Franci s Dupont , St ephen Far r el l , Br ad Hi l l , J ef f Hodges, PaulHof f man, J ef f r ey Hut zel man, SM, Al exey Mel ni kov, Chr i s Pal mer , Tr evorPer r i n, Ryan Sl eevi , Rob St r adl i ng, Car l Wal l ace f or t hei r val uabl econt r i but i ons.

Laur i e, et al . Expi r es Oct ober 20, 2013 [ Page 31]


11. References

[ RFC2119] Br adner , S. , "Key wor ds f or use i n RFCs t o I ndi cat eRequi r ement Level s" , BCP 14, RFC 2119, March 1997.

[ RFC2560] Myer s, M. , Ankney, R. , Mal pani , A. , Gal per i n, S. , and C.Adams, "X. 509 I nt er net Publ i c Key I nf r ast r uct ur e Onl i neCer t i f i cat e St at us Pr ot ocol - OCSP" , RFC 2560, J une 1999.

[ RFC3447] J onsson, J . and B. Kal i ski , "Publ i c- Key Cr ypt ogr aphySt andards ( PKCS) #1: RSA Cr ypt ogr aphy Speci f i cat i onsVersi on 2. 1" , RFC 3447, Febr uary 2003.

[ RFC4627] Cr ockf or d, D. , "The appl i cat i on/ j son Medi a Type f orJ avaScr i pt Obj ect Not at i on ( J SON) " , RFC 4627, J ul y 2006.

[ RFC4648] J osef sson, S. , "The Base16, Base32, and Base64 DataEncodi ngs" , RFC 4648, Oct ober 2006.

[ RFC5246] Di er ks, T. and E. Rescor l a, "The Tr anspor t Layer Secur i t y( TLS) Prot ocol Ver si on 1. 2" , RFC 5246, August 2008.

[ RFC5280] Cooper , D. , Sant esson, S. , Far r el l , S. , Boeyen, S. ,Housl ey, R. , and W. Pol k, " I nt er net X. 509 Publ i c KeyI nf r ast r uctur e Cer t i f i cat e and Cer t i f i cat e Revocat i on Li st( CRL) Prof i l e" , RFC 5280, May 2008.

[ RFC5905] Mi l l s, D. , Mar t i n, J . , Bur bank, J . , and W. Kasch, "Net wor kTi me Pr ot ocol Ver si on 4: Pr ot ocol and Al gor i t hmsSpeci f i cat i on" , RFC 5905, J une 2010.

[ RFC6066] East l ake, D. , "Tr anspor t Layer Secur i t y ( TLS) Extensi ons:Extensi on Def i ni t i ons" , RFC 6066, J anuar y 2011.

[ DSS] Nat i onal I nst i t ut e of St andar ds and Technol ogy, U. S.Depart ment of Commerce, "Di gi t al Si gnatur e St andard" ,FI PS 186- 3, J une 2009.

[ Cr osbyWal l ach]




Cr osby, S. and D. Wal l ach, "Ef f i ci ent dat a st r uct ur es f ort amper - evi dent l oggi ng" , 2009.

[ HTML401] Hor s, A. , Ragget t , D. , and I . J acobs, "HTML 4. 01Speci f i cat i on" , Wor l d Wi de Web Consor t i umRecommendat i on REC- ht ml 401- 19991224, December 1999,<ht t p: / / www. w3. org/ TR/ 1999/ REC- html 401- 19991224>.

[ FI PS. 180- 2. 2002]


Nat i onal I nst i t ut e of St andar ds and Technol ogy, "Secur eHash St andard" , FI PS PUB 180- 2, August 2002, <ht t p: / /csr c. ni st . gov/ publ i cat i ons/ f i ps/ f i ps180- 2/ f i ps180- 2. pdf >.



Authors' Addresses

Ben Laur i eGoogl e UK Lt d.

Emai l : benl @googl e. com

Adam Langl ey

Googl e I nc.

Emai l : agl @googl e. com

Emi l i a KasperGoogl e Swi t zer l and GmbH

Emai l : ekasper@googl e. com

