File: rfc9162.html

package info (click to toggle)
doc-rfc 20230121-1
links: PTS, VCS
area: non-free
in suites: bookworm, forky, sid, trixie
size: 1,609,944 kB
file content (5201 lines) | stat: -rw-r--r-- 293,964 bytes
<!DOCTYPE html>
<html lang="en" class="RFC">
<head>
<meta charset="utf-8">
<meta content="Common,Latin" name="scripts">
<meta content="initial-scale=1.0" name="viewport">
<title>RFC 9162: Certificate Transparency Version 2.0</title>
<meta content="Ben Laurie" name="author">
<meta content="Eran Messeri" name="author">
<meta content="Rob Stradling" name="author">
<meta content="
       This document describes version 2.0 of the Certificate Transparency (CT)
protocol for publicly logging the existence of Transport Layer Security (TLS)
server certificates as they are issued or observed, in a manner that allows
anyone to audit certification 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. 
       This document obsoletes RFC 6962.  It also specifies a new TLS extension that is
used to send various CT log artifacts. 
       Logs are network services that implement the protocol operations for submissions
and queries that are defined in this document. 
    " name="description">
<meta content="xml2rfc 3.12.0" name="generator">
<meta content="certificates" name="keyword">
<meta content="pkix" name="keyword">
<meta content="tls" name="keyword">
<meta content="website" name="keyword">
<meta content="webpki" name="keyword">
<meta content="browsers" name="keyword">
<meta content="9162" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.0
    Python 3.6.13
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9162.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

  NOTE: Changes at the bottom of this file overrides some earlier settings.

  Once the style has stabilized and has been adopted as an official RFC style,
  this can be consolidated so that style settings occur only in one place, but
  for now the contents of this file consists first of the initial CSS work as
  provided to the RFC Formatter (xml2rfc) work, followed by itemized and
  commented changes found necssary during the development of the v3
  formatters.

*/

/* fonts */
@import url('https://fonts.googleapis.com/css?family=Noto+Sans'); /* Sans-serif */
@import url('https://fonts.googleapis.com/css?family=Noto+Serif'); /* Serif (print) */
@import url('https://fonts.googleapis.com/css?family=Roboto+Mono'); /* Monospace */

@viewport {
  zoom: 1.0;
  width: extend-to-zoom;
}
@-ms-viewport {
  width: extend-to-zoom;
  zoom: 1.0;
}
/* general and mobile first */
html {
}
body {
  max-width: 90%;
  margin: 1.5em auto;
  color: #222;
  background-color: #fff;
  font-size: 14px;
  font-family: 'Noto Sans', Arial, Helvetica, sans-serif;
  line-height: 1.6;
  scroll-behavior: smooth;
}
.ears {
  display: none;
}

/* headings */
#title, h1, h2, h3, h4, h5, h6 {
  margin: 1em 0 0.5em;
  font-weight: bold;
  line-height: 1.3;
}
#title {
  clear: both;
  border-bottom: 1px solid #ddd;
  margin: 0 0 0.5em 0;
  padding: 1em 0 0.5em;
}
.author {
  padding-bottom: 4px;
}
h1 {
  font-size: 26px;
  margin: 1em 0;
}
h2 {
  font-size: 22px;
  margin-top: -20px;  /* provide offset for in-page anchors */
  padding-top: 33px;
}
h3 {
  font-size: 18px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h4 {
  font-size: 16px;
  margin-top: -36px;  /* provide offset for in-page anchors */
  padding-top: 42px;
}
h5, h6 {
  font-size: 14px;
}
#n-copyright-notice {
  border-bottom: 1px solid #ddd;
  padding-bottom: 1em;
  margin-bottom: 1em;
}
/* general structure */
p {
  padding: 0;
  margin: 0 0 1em 0;
  text-align: left;
}
div, span {
  position: relative;
}
div {
  margin: 0;
}
.alignRight.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignRight.art-text pre {
  padding: 0;
}
.alignRight {
  margin: 1em 0;
}
.alignRight > *:first-child {
  border: none;
  margin: 0;
  float: right;
  clear: both;
}
.alignRight > *:nth-child(2) {
  clear: both;
  display: block;
  border: none;
}
svg {
  display: block;
}
.alignCenter.art-text {
  background-color: #f9f9f9;
  border: 1px solid #eee;
  border-radius: 3px;
  padding: 1em 1em 0;
  margin-bottom: 1.5em;
}
.alignCenter.art-text pre {
  padding: 0;
}
.alignCenter {
  margin: 1em 0;
}
.alignCenter > *:first-child {
  border: none;
  /* this isn't optimal, but it's an existence proof.  PrinceXML doesn't
     support flexbox yet.
  */
  display: table;
  margin: 0 auto;
}

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.ulBare, li.ulBare {
  margin-left: 0em !important;
}
ul.compact, .ulCompact,
ol.compact, .olCompact {
  line-height: 100%;
  margin: 0 0 0 2em;
}

/* definition lists */
dl {
}
dl > dt {
  float: left;
  margin-right: 1em;
}
/* 
dl.nohang > dt {
  float: none;
}
*/
dl > dd {
  margin-bottom: .8em;
  min-height: 1.3em;
}
dl.compact > dd, .dlCompact > dd {
  margin-bottom: 0em;
}
dl > dd > dl {
  margin-top: 0.5em;
  margin-bottom: 0em;
}

/* links */
a {
  text-decoration: none;
}
a[href] {
  color: #22e; /* Arlen: WCAG 2019 */
}
a[href]:hover {
  background-color: #f2f2f2;
}
figcaption a[href],
a[href].selfRef {
  color: #222;
}
/* XXX probably not this:
a.selfRef:hover {
  background-color: transparent;
  cursor: default;
} */

/* Figures */
tt, code, pre, code {
  background-color: #f9f9f9;
  font-family: 'Roboto Mono', monospace;
}
pre {
  border: 1px solid #eee;
  margin: 0;
  padding: 1em;
}
img {
  max-width: 100%;
}
figure {
  margin: 0;
}
figure blockquote {
  margin: 0.8em 0.4em 0.4em;
}
figcaption {
  font-style: italic;
  margin: 0 0 1em 0;
}
@media screen {
  pre {
    overflow-x: auto;
    max-width: 100%;
    max-width: calc(100% - 22px);
  }
}

/* aside, blockquote */
aside, blockquote {
  margin-left: 0;
  padding: 1.2em 2em;
}
blockquote {
  background-color: #f9f9f9;
  color: #111; /* Arlen: WCAG 2019 */
  border: 1px solid #ddd;
  border-radius: 3px;
  margin: 1em 0;
}
cite {
  display: block;
  text-align: right;
  font-style: italic;
}

/* tables */
table {
  width: 100%;
  margin: 0 0 1em;
  border-collapse: collapse;
  border: 1px solid #eee;
}
th, td {
  text-align: left;
  vertical-align: top;
  padding: 0.5em 0.75em;
}
th {
  text-align: left;
  background-color: #e9e9e9;
}
tr:nth-child(2n+1) > td {
  background-color: #f5f5f5;
}
table caption {
  font-style: italic;
  margin: 0;
  padding: 0;
  text-align: left;
}
table p {
  /* XXX to avoid bottom margin on table row signifiers. If paragraphs should
     be allowed within tables more generally, it would be far better to select on a class. */
  margin: 0;
}

/* pilcrow */
a.pilcrow {
  color: #666; /* Arlen: AHDJ 2019 */
  text-decoration: none;
  visibility: hidden;
  user-select: none;
  -ms-user-select: none;
  -o-user-select:none;
  -moz-user-select: none;
  -khtml-user-select: none;
  -webkit-user-select: none;
  -webkit-touch-callout: none;
}
@media screen {
  aside:hover > a.pilcrow,
  p:hover > a.pilcrow,
  blockquote:hover > a.pilcrow,
  div:hover > a.pilcrow,
  li:hover > a.pilcrow,
  pre:hover > a.pilcrow {
    visibility: visible;
  }
  a.pilcrow:hover {
    background-color: transparent;
  }
}

/* misc */
hr {
  border: 0;
  border-top: 1px solid #eee;
}
.bcp14 {
  font-variant: small-caps;
}

.role {
  font-variant: all-small-caps;
}

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
/* Fix PDF info block run off issue */
@media print {
  #identifiers dd {
    float: none;
  }
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

/* The prepared/rendered info at the very bottom of the page */
.docInfo {
  color: #666; /* Arlen: WCAG 2019 */
  font-size: 0.9em;
  font-style: italic;
  margin-top: 2em;
}
.docInfo .prepared {
  float: left;
}
.docInfo .prepared {
  float: right;
}

/* table of contents */
#toc  {
  padding: 0.75em 0 2em 0;
  margin-bottom: 1em;
}
nav.toc ul {
  margin: 0 0.5em 0 0;
  padding: 0;
  list-style: none;
}
nav.toc li {
  line-height: 1.3em;
  margin: 0.75em 0;
  padding-left: 1.2em;
  text-indent: -1.2em;
}
/* references */
.references dt {
  text-align: right;
  font-weight: bold;
  min-width: 7em;
}
.references dd {
  margin-left: 8em;
  overflow: auto;
}

.refInstance {
  margin-bottom: 1.25em;
}

.references .ascii {
  margin-bottom: 0.25em;
}

/* index */
.index ul {
  margin: 0 0 0 1em;
  padding: 0;
  list-style: none;
}
.index ul ul {
  margin: 0;
}
.index li {
  margin: 0;
  text-indent: -2em;
  padding-left: 2em;
  padding-bottom: 5px;
}
.indexIndex {
  margin: 0.5em 0 1em;
}
.index a {
  font-weight: 700;
}
/* make the index two-column on all but the smallest screens */
@media (min-width: 600px) {
  .index ul {
    -moz-column-count: 2;
    -moz-column-gap: 20px;
  }
  .index ul ul {
    -moz-column-count: 1;
    -moz-column-gap: 0;
  }
}

/* authors */
address.vcard {
  font-style: normal;
  margin: 1em 0;
}

address.vcard .nameRole {
  font-weight: 700;
  margin-left: 0;
}
address.vcard .label {
  font-family: "Noto Sans",Arial,Helvetica,sans-serif;
  margin: 0.5em 0;
}
address.vcard .type {
  display: none;
}
.alternative-contact {
  margin: 1.5em 0 1em;
}
hr.addr {
  border-top: 1px dashed;
  margin: 0;
  color: #ddd;
  max-width: calc(100% - 16px);
}

/* temporary notes */
.rfcEditorRemove::before {
  position: absolute;
  top: 0.2em;
  right: 0.2em;
  padding: 0.2em;
  content: "The RFC Editor will remove this note";
  color: #9e2a00; /* Arlen: WCAG 2019 */
  background-color: #ffd; /* Arlen: WCAG 2019 */
}
.rfcEditorRemove {
  position: relative;
  padding-top: 1.8em;
  background-color: #ffd; /* Arlen: WCAG 2019 */
  border-radius: 3px;
}
.cref {
  background-color: #ffd; /* Arlen: WCAG 2019 */
  padding: 2px 4px;
}
.crefSource {
  font-style: italic;
}
/* alternative layout for smaller screens */
@media screen and (max-width: 1023px) {
  body {
    padding-top: 2em;
  }
  #title {
    padding: 1em 0;
  }
  h1 {
    font-size: 24px;
  }
  h2 {
    font-size: 20px;
    margin-top: -18px;  /* provide offset for in-page anchors */
    padding-top: 38px;
  }
  #identifiers dd {
    max-width: 60%;
  }
  #toc {
    position: fixed;
    z-index: 2;
    top: 0;
    right: 0;
    padding: 0;
    margin: 0;
    background-color: inherit;
    border-bottom: 1px solid #ccc;
  }
  #toc h2 {
    margin: -1px 0 0 0;
    padding: 4px 0 4px 6px;
    padding-right: 1em;
    min-width: 190px;
    font-size: 1.1em;
    text-align: right;
    background-color: #444;
    color: white;
    cursor: pointer;
  }
  #toc h2::before { /* css hamburger */
    float: right;
    position: relative;
    width: 1em;
    height: 1px;
    left: -164px;
    margin: 6px 0 0 0;
    background: white none repeat scroll 0 0;
    box-shadow: 0 4px 0 0 white, 0 8px 0 0 white;
    content: "";
  }
  #toc nav {
    display: none;
    padding: 0.5em 1em 1em;
    overflow: auto;
    height: calc(100vh - 48px);
    border-left: 1px solid #ddd;
  }
}

/* alternative layout for wide screens */
@media screen and (min-width: 1024px) {
  body {
    max-width: 724px;
    margin: 42px auto;
    padding-left: 1.5em;
    padding-right: 29em;
  }
  #toc {
    position: fixed;
    top: 42px;
    right: 42px;
    width: 25%;
    margin: 0;
    padding: 0 1em;
    z-index: 1;
  }
  #toc h2 {
    border-top: none;
    border-bottom: 1px solid #ddd;
    font-size: 1em;
    font-weight: normal;
    margin: 0;
    padding: 0.25em 1em 1em 0;
  }
  #toc nav {
    display: block;
    height: calc(90vh - 84px);
    bottom: 0;
    padding: 0.5em 0 0;
    overflow: auto;
  }
  img { /* future proofing */
    max-width: 100%;
    height: auto;
  }
}

/* pagination */
@media print {
  body {

    width: 100%;
  }
  p {
    orphans: 3;
    widows: 3;
  }
  #n-copyright-notice {
    border-bottom: none;
  }
  #toc, #n-introduction {
    page-break-before: always;
  }
  #toc {
    border-top: none;
    padding-top: 0;
  }
  figure, pre {
    page-break-inside: avoid;
  }
  figure {
    overflow: scroll;
  }
  h1, h2, h3, h4, h5, h6 {
    page-break-after: avoid;
  }
  h2+*, h3+*, h4+*, h5+*, h6+* {
    page-break-before: avoid;
  }
  pre {
    white-space: pre-wrap;
    word-wrap: break-word;
    font-size: 10pt;
  }
  table {
    border: 1px solid #ddd;
  }
  td {
    border-top: 1px solid #ddd;
  }
}

/* This is commented out here, as the string-set: doesn't
   pass W3C validation currently */
/*
.ears thead .left {
  string-set: ears-top-left content();
}

.ears thead .center {
  string-set: ears-top-center content();
}

.ears thead .right {
  string-set: ears-top-right content();
}

.ears tfoot .left {
  string-set: ears-bottom-left content();
}

.ears tfoot .center {
  string-set: ears-bottom-center content();
}

.ears tfoot .right {
  string-set: ears-bottom-right content();
}
*/

@page :first {
  padding-top: 0;
  @top-left {
    content: normal;
    border: none;
  }
  @top-center {
    content: normal;
    border: none;
  }
  @top-right {
    content: normal;
    border: none;
  }
}

@page {
  size: A4;
  margin-bottom: 45mm;
  padding-top: 20px;
  /* The follwing is commented out here, but set appropriately by in code, as
     the content depends on the document */
  /*
  @top-left {
    content: 'Internet-Draft';
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-left {
    content: string(ears-top-left);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-center {
    content: string(ears-top-center);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @top-right {
    content: string(ears-top-right);
    vertical-align: bottom;
    border-bottom: solid 1px #ccc;
  }
  @bottom-left {
    content: string(ears-bottom-left);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-center {
    content: string(ears-bottom-center);
    vertical-align: top;
    border-top: solid 1px #ccc;
  }
  @bottom-right {
      content: '[Page ' counter(page) ']';
      vertical-align: top;
      border-top: solid 1px #ccc;
  }
  */

}

/* Changes introduced to fix issues found during implementation */
/* Make sure links are clickable even if overlapped by following H* */
a {
  z-index: 2;
}
/* Separate body from document info even without intervening H1 */
section {
  clear: both;
}


/* Top align author divs, to avoid names without organization dropping level with org names */
.author {
  vertical-align: top;
}

/* Leave room in document info to show Internet-Draft on one line */
#identifiers dt {
  width: 8em;
}

/* Don't waste quite as much whitespace between label and value in doc info */
#identifiers dd {
  margin-left: 1em;
}

/* Give floating toc a background color (needed when it's a div inside section */
#toc {
  background-color: white;
}

/* Make the collapsed ToC header render white on gray also when it's a link */
@media screen and (max-width: 1023px) {
  #toc h2 a,
  #toc h2 a:link,
  #toc h2 a:focus,
  #toc h2 a:hover,
  #toc a.toplink,
  #toc a.toplink:hover {
    color: white;
    background-color: #444;
    text-decoration: none;
  }
}

/* Give the bottom of the ToC some whitespace */
@media screen and (min-width: 1024px) {
  #toc {
    padding: 0 0 1em 1em;
  }
}

/* Style section numbers with more space between number and title */
.section-number {
  padding-right: 0.5em;
}

/* prevent monospace from becoming overly large */
tt, code, pre, code {
  font-size: 95%;
}

/* Fix the height/width aspect for ascii art*/
pre.sourcecode,
.art-text pre {
  line-height: 1.12;
}


/* Add styling for a link in the ToC that points to the top of the document */
a.toplink {
  float: right;
  margin-right: 0.5em;
}

/* Fix the dl styling to match the RFC 7992 attributes */
dl > dt,
dl.dlParallel > dt {
  float: left;
  margin-right: 1em;
}
dl.dlNewline > dt {
  float: none;
}

/* Provide styling for table cell text alignment */
table td.text-left,
table th.text-left {
  text-align: left;
}
table td.text-center,
table th.text-center {
  text-align: center;
}
table td.text-right,
table th.text-right {
  text-align: right;
}

/* Make the alternative author contact informatio look less like just another
   author, and group it closer with the primary author contact information */
.alternative-contact {
  margin: 0.5em 0 0.25em 0;
}
address .non-ascii {
  margin: 0 0 0 2em;
}

/* With it being possible to set tables with alignment
  left, center, and right, { width: 100%; } does not make sense */
table {
  width: auto;
}

/* Avoid reference text that sits in a block with very wide left margin,
   because of a long floating dt label.*/
.references dd {
  overflow: visible;
}

/* Control caption placement */
caption {
  caption-side: bottom;
}

/* Limit the width of the author address vcard, so names in right-to-left
   script don't end up on the other side of the page. */

address.vcard {
  max-width: 30em;
  margin-right: auto;
}

/* For address alignment dependent on LTR or RTL scripts */
address div.left {
  text-align: left;
}
address div.right {
  text-align: right;
}

/* Provide table alignment support.  We can't use the alignX classes above
   since they do unwanted things with caption and other styling. */
table.right {
 margin-left: auto;
 margin-right: 0;
}
table.center {
 margin-left: auto;
 margin-right: auto;
}
table.left {
 margin-left: 0;
 margin-right: auto;
}

/* Give the table caption label the same styling as the figcaption */
caption a[href] {
  color: #222;
}

@media print {
  .toplink {
    display: none;
  }

  /* avoid overwriting the top border line with the ToC header */
  #toc {
    padding-top: 1px;
  }

  /* Avoid page breaks inside dl and author address entries */
  .vcard {
    page-break-inside: avoid;
  }

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9162" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-trans-rfc6962-bis-42" rel="prev">
  </head>
<body>
<script src="https://www.rfc-editor.org/js/metadata.min.js"></script>
<table class="ears">
<thead><tr>
<td class="left">RFC 9162</td>
<td class="center">Certificate Transparency Version 2.0</td>
<td class="right">December 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Laurie, et al.</td>
<td class="center">Experimental</td>
<td class="right">[Page]</td>
</tr></tfoot>
</table>
<div id="external-metadata" class="document-information"></div>
<div id="internal-metadata" class="document-information">
<dl id="identifiers">
<dt class="label-stream">Stream:</dt>
<dd class="stream">Internet Engineering Task Force (IETF)</dd>
<dt class="label-rfc">RFC:</dt>
<dd class="rfc"><a href="https://www.rfc-editor.org/rfc/rfc9162" class="eref">9162</a></dd>
<dt class="label-obsoletes">Obsoletes:</dt>
<dd class="obsoletes">
<a href="https://www.rfc-editor.org/rfc/rfc6962" class="eref">6962</a> </dd>
<dt class="label-category">Category:</dt>
<dd class="category">Experimental</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2021-12" class="published">December 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">B. Laurie</div>
<div class="org">Google</div>
</div>
<div class="author">
      <div class="author-name">E. Messeri</div>
<div class="org">Google</div>
</div>
<div class="author">
      <div class="author-name">R. Stradling</div>
<div class="org">Sectigo</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9162</h1>
<h1 id="title">Certificate Transparency Version 2.0</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes version 2.0 of the Certificate Transparency (CT)
protocol for publicly logging the existence of Transport Layer Security (TLS)
server certificates as they are issued or observed, in a manner that allows
anyone to audit certification 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.<a href="#section-abstract-1" class="pilcrow">¶</a></p>
<p id="section-abstract-2">This document obsoletes RFC 6962.  It also specifies a new TLS extension that is
used to send various CT log artifacts.<a href="#section-abstract-2" class="pilcrow">¶</a></p>
<p id="section-abstract-3">Logs are network services that implement the protocol operations for submissions
and queries that are defined in this document.<a href="#section-abstract-3" class="pilcrow">¶</a></p>
</section>
<div id="status-of-memo">
<section id="section-boilerplate.1">
        <h2 id="name-status-of-this-memo">
<a href="#name-status-of-this-memo" class="section-name selfRef">Status of This Memo</a>
        </h2>
<p id="section-boilerplate.1-1">
            This document is not an Internet Standards Track specification; it is
            published for examination, experimental implementation, and
            evaluation.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            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 candidates for any level of Internet
            Standard; see Section 2 of RFC 7841.<a href="#section-boilerplate.1-2" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <span><a href="https://www.rfc-editor.org/info/rfc9162">https://www.rfc-editor.org/info/rfc9162</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) 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 Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.2">
                <p id="section-toc.1-1.1.2.2.1" class="keepWithNext"><a href="#section-1.2" class="xref">1.2</a>.  <a href="#name-data-structures" class="xref">Data Structures</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1.2.3">
                <p id="section-toc.1-1.1.2.3.1" class="keepWithNext"><a href="#section-1.3" class="xref">1.3</a>.  <a href="#name-major-differences-from-ct-1" class="xref">Major Differences from CT 1.0</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1"><a href="#section-2" class="xref">2</a>.  <a href="#name-cryptographic-components" class="xref">Cryptographic Components</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-merkle-trees" class="xref">Merkle Trees</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.1">
                    <p id="section-toc.1-1.2.2.1.2.1.1"><a href="#section-2.1.1" class="xref">2.1.1</a>.  <a href="#name-definition-of-the-merkle-tr" class="xref">Definition of the Merkle Tree</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.2">
                    <p id="section-toc.1-1.2.2.1.2.2.1"><a href="#section-2.1.2" class="xref">2.1.2</a>.  <a href="#name-verifying-a-tree-head-given" class="xref">Verifying a Tree Head Given Entries</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.3">
                    <p id="section-toc.1-1.2.2.1.2.3.1"><a href="#section-2.1.3" class="xref">2.1.3</a>.  <a href="#name-merkle-inclusion-proofs" class="xref">Merkle Inclusion Proofs</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.4">
                    <p id="section-toc.1-1.2.2.1.2.4.1"><a href="#section-2.1.4" class="xref">2.1.4</a>.  <a href="#name-merkle-consistency-proofs" class="xref">Merkle Consistency Proofs</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.1.2.5">
                    <p id="section-toc.1-1.2.2.1.2.5.1"><a href="#section-2.1.5" class="xref">2.1.5</a>.  <a href="#name-example" class="xref">Example</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-signatures" class="xref">Signatures</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-submitters" class="xref">Submitters</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-certificates" class="xref">Certificates</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-precertificates" class="xref">Precertificates</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2.2.1">
                    <p id="section-toc.1-1.3.2.2.2.1.1"><a href="#section-3.2.1" class="xref">3.2.1</a>.  <a href="#name-binding-intent-to-issue" class="xref">Binding Intent to Issue</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-log-format-and-operation" class="xref">Log Format and Operation</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-log-parameters" class="xref">Log Parameters</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-evaluating-submissions" class="xref">Evaluating Submissions</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.1">
                    <p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="xref">4.2.1</a>.  <a href="#name-minimum-acceptance-criteria" class="xref">Minimum Acceptance Criteria</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2.2.2">
                    <p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="xref">4.2.2</a>.  <a href="#name-discretionary-acceptance-cr" class="xref">Discretionary Acceptance Criteria</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-log-entries" class="xref">Log Entries</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-log-id" class="xref">Log ID</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-transitem-structure" class="xref">TransItem Structure</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.6">
                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="xref">4.6</a>.  <a href="#name-log-artifact-extensions" class="xref">Log Artifact Extensions</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.7">
                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="xref">4.7</a>.  <a href="#name-merkle-tree-leaves" class="xref">Merkle Tree Leaves</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.8">
                <p id="section-toc.1-1.4.2.8.1"><a href="#section-4.8" class="xref">4.8</a>.  <a href="#name-signed-certificate-timestam" class="xref">Signed Certificate Timestamp (SCT)</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.9">
                <p id="section-toc.1-1.4.2.9.1"><a href="#section-4.9" class="xref">4.9</a>.  <a href="#name-merkle-tree-head" class="xref">Merkle Tree Head</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.10">
                <p id="section-toc.1-1.4.2.10.1"><a href="#section-4.10" class="xref">4.10</a>. <a href="#name-signed-tree-head-sth" class="xref">Signed Tree Head (STH)</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.11">
                <p id="section-toc.1-1.4.2.11.1"><a href="#section-4.11" class="xref">4.11</a>. <a href="#name-merkle-consistency-proofs-2" class="xref">Merkle Consistency Proofs</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.12">
                <p id="section-toc.1-1.4.2.12.1"><a href="#section-4.12" class="xref">4.12</a>. <a href="#name-merkle-inclusion-proofs-2" class="xref">Merkle Inclusion Proofs</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.13">
                <p id="section-toc.1-1.4.2.13.1"><a href="#section-4.13" class="xref">4.13</a>. <a href="#name-shutting-down-a-log" class="xref">Shutting Down a Log</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-log-client-messages" class="xref">Log Client Messages</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-submit-entry-to-log" class="xref">Submit Entry to Log</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-retrieve-latest-sth" class="xref">Retrieve Latest STH</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-retrieve-merkle-consistency" class="xref">Retrieve Merkle Consistency Proof between Two STHs</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-retrieve-merkle-inclusion-p" class="xref">Retrieve Merkle Inclusion Proof from Log by Leaf Hash</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.5">
                <p id="section-toc.1-1.5.2.5.1"><a href="#section-5.5" class="xref">5.5</a>.  <a href="#name-retrieve-merkle-inclusion-pr" class="xref">Retrieve Merkle Inclusion Proof, STH, and Consistency Proof by Leaf Hash</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.6">
                <p id="section-toc.1-1.5.2.6.1"><a href="#section-5.6" class="xref">5.6</a>.  <a href="#name-retrieve-entries-and-sth-fr" class="xref">Retrieve Entries and STH from Log</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.7">
                <p id="section-toc.1-1.5.2.7.1"><a href="#section-5.7" class="xref">5.7</a>.  <a href="#name-retrieve-accepted-trust-anc" class="xref">Retrieve Accepted Trust Anchors</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-tls-servers" class="xref">TLS Servers</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-tls-client-authentication" class="xref">TLS Client Authentication</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-multiple-scts" class="xref">Multiple SCTs</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-transitemlist-structure" class="xref">TransItemList Structure</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-presenting-scts-inclusions-" class="xref">Presenting SCTs, Inclusions Proofs, and STHs</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-transparency_info-tls-exten" class="xref">transparency_info TLS Extension</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-certification-authorities" class="xref">Certification Authorities</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1">
                <p id="section-toc.1-1.7.2.1.1"><a href="#section-7.1" class="xref">7.1</a>.  <a href="#name-transparency-information-x5" class="xref">Transparency Information X.509v3 Extension</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.1">
                    <p id="section-toc.1-1.7.2.1.2.1.1"><a href="#section-7.1.1" class="xref">7.1.1</a>.  <a href="#name-ocsp-response-extension" class="xref">OCSP Response Extension</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.1.2.2">
                    <p id="section-toc.1-1.7.2.1.2.2.1"><a href="#section-7.1.2" class="xref">7.1.2</a>.  <a href="#name-certificate-extension" class="xref">Certificate Extension</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.2">
                <p id="section-toc.1-1.7.2.2.1"><a href="#section-7.2" class="xref">7.2</a>.  <a href="#name-tls-feature-x509v3-extensio" class="xref">TLS Feature X.509v3 Extension</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#section-8" class="xref">8</a>.  <a href="#name-clients" class="xref">Clients</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#section-8.1" class="xref">8.1</a>.  <a href="#name-tls-client" class="xref">TLS Client</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1.2.1">
                    <p id="section-toc.1-1.8.2.1.2.1.1"><a href="#section-8.1.1" class="xref">8.1.1</a>.  <a href="#name-receiving-scts-and-inclusio" class="xref">Receiving SCTs and Inclusion Proofs</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1.2.2">
                    <p id="section-toc.1-1.8.2.1.2.2.1"><a href="#section-8.1.2" class="xref">8.1.2</a>.  <a href="#name-reconstructing-the-tbscerti" class="xref">Reconstructing the TBSCertificate</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1.2.3">
                    <p id="section-toc.1-1.8.2.1.2.3.1"><a href="#section-8.1.3" class="xref">8.1.3</a>.  <a href="#name-validating-scts" class="xref">Validating SCTs</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1.2.4">
                    <p id="section-toc.1-1.8.2.1.2.4.1"><a href="#section-8.1.4" class="xref">8.1.4</a>.  <a href="#name-fetching-inclusion-proofs" class="xref">Fetching Inclusion Proofs</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1.2.5">
                    <p id="section-toc.1-1.8.2.1.2.5.1"><a href="#section-8.1.5" class="xref">8.1.5</a>.  <a href="#name-validating-inclusion-proofs" class="xref">Validating Inclusion Proofs</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1.2.6">
                    <p id="section-toc.1-1.8.2.1.2.6.1"><a href="#section-8.1.6" class="xref">8.1.6</a>.  <a href="#name-evaluating-compliance" class="xref">Evaluating Compliance</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#section-8.2" class="xref">8.2</a>.  <a href="#name-monitor" class="xref">Monitor</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-auditing" class="xref">Auditing</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#section-9" class="xref">9</a>.  <a href="#name-algorithm-agility" class="xref">Algorithm Agility</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-additions-to-existing-regis" class="xref">Additions to Existing Registries</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1.2.1">
                    <p id="section-toc.1-1.10.2.1.2.1.1"><a href="#section-10.1.1" class="xref">10.1.1</a>.  <a href="#name-new-entry-to-the-tls-extens" class="xref">New Entry to the TLS ExtensionType Registry</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1.2.2">
                    <p id="section-toc.1-1.10.2.1.2.2.1"><a href="#section-10.1.2" class="xref">10.1.2</a>.  <a href="#name-urn-sub-namespace-for-trans" class="xref">URN Sub-namespace for TRANS (urn:ietf:params:trans)</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-new-ct-related-registries" class="xref">New CT-Related Registries</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.1">
                    <p id="section-toc.1-1.10.2.2.2.1.1"><a href="#section-10.2.1" class="xref">10.2.1</a>.  <a href="#name-hash-algorithms" class="xref">Hash Algorithms</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.2">
                    <p id="section-toc.1-1.10.2.2.2.2.1"><a href="#section-10.2.2" class="xref">10.2.2</a>.  <a href="#name-signature-algorithms" class="xref">Signature Algorithms</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.3">
                    <p id="section-toc.1-1.10.2.2.2.3.1"><a href="#section-10.2.3" class="xref">10.2.3</a>.  <a href="#name-versionedtranstypes" class="xref">VersionedTransTypes</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.4">
                    <p id="section-toc.1-1.10.2.2.2.4.1"><a href="#section-10.2.4" class="xref">10.2.4</a>.  <a href="#name-log-artifact-extensions-2" class="xref">Log Artifact Extensions</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.5">
                    <p id="section-toc.1-1.10.2.2.2.5.1"><a href="#section-10.2.5" class="xref">10.2.5</a>.  <a href="#name-log-ids" class="xref">Log IDs</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2.2.6">
                    <p id="section-toc.1-1.10.2.2.2.6.1"><a href="#section-10.2.6" class="xref">10.2.6</a>.  <a href="#name-error-types" class="xref">Error Types</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.3">
                <p id="section-toc.1-1.10.2.3.1"><a href="#section-10.3" class="xref">10.3</a>.  <a href="#name-oid-assignment" class="xref">OID Assignment</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-11" class="xref">11</a>. <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.1">
                <p id="section-toc.1-1.11.2.1.1"><a href="#section-11.1" class="xref">11.1</a>.  <a href="#name-misissued-certificates" class="xref">Misissued Certificates</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.2">
                <p id="section-toc.1-1.11.2.2.1"><a href="#section-11.2" class="xref">11.2</a>.  <a href="#name-detection-of-misissue" class="xref">Detection of Misissue</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.3">
                <p id="section-toc.1-1.11.2.3.1"><a href="#section-11.3" class="xref">11.3</a>.  <a href="#name-misbehaving-logs" class="xref">Misbehaving Logs</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.4">
                <p id="section-toc.1-1.11.2.4.1"><a href="#section-11.4" class="xref">11.4</a>.  <a href="#name-multiple-scts-2" class="xref">Multiple SCTs</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11.2.5">
                <p id="section-toc.1-1.11.2.5.1"><a href="#section-11.5" class="xref">11.5</a>.  <a href="#name-leakage-of-dns-information" class="xref">Leakage of DNS Information</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#section-12" class="xref">12</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.1">
                <p id="section-toc.1-1.12.2.1.1"><a href="#section-12.1" class="xref">12.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12.2.2">
                <p id="section-toc.1-1.12.2.2.1"><a href="#section-12.2" class="xref">12.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.13">
            <p id="section-toc.1-1.13.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-supporting-v1-and-v2-simult" class="xref">Supporting v1 and v2 Simultaneously (Informative)</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.14">
            <p id="section-toc.1-1.14.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-an-asn1-module-informative" class="xref">An ASN.1 Module (Informative)</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.15">
            <p id="section-toc.1-1.15.1"><a href="#appendix-C" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.16">
            <p id="section-toc.1-1.16.1"><a href="#appendix-D" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="introduction">
<section id="section-1">
      <h2 id="name-introduction">
<a href="#section-1" class="section-number selfRef">1. </a><a href="#name-introduction" class="section-name selfRef">Introduction</a>
      </h2>
<p id="section-1-1">Certificate Transparency aims to mitigate the problem of misissued certificates
by providing append-only logs of issued certificates. The logs do not themselves
prevent misissuance, but they ensure that interested parties (particularly those
named in certificates) can detect such misissuance. Note that this is a general
mechanism that could be used for transparently logging any form of binary data,
subject to some kind of inclusion criteria. In this document, we only describe
its use for public TLS server certificates (i.e., where the inclusion criteria
is a valid certificate issued by a public certification authority (CA)).
A typical definition of "public" can be found in <span>[<a href="#CABBR" class="xref">CABBR</a>]</span>.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Each log contains 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; however, certificate holders can also contribute their own
certificate chains, as can third parties. In order to avoid logs being rendered
useless by the submission of large numbers of spurious certificates, it is
required that each chain ends with a trust anchor that is accepted by the log.
A log may also limit the length of the chain it is willing to accept;
such chains must also end with an acceptable trust anchor.
When a chain is accepted by a log, a signed timestamp is returned, which can
later be used to provide evidence to TLS clients that the chain has been
submitted. TLS clients can thus require that all certificates they accept as
valid are accompanied by signed timestamps.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">Those who are concerned about misissuance can monitor the logs, asking them
regularly for all new entries, and can thus check whether domains for which they
are responsible 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. However, broadly speaking,
they can invoke existing business mechanisms for dealing with misissued
certificates, such as working with the CA to get the certificate revoked or
with maintainers of trust anchor lists to get the CA removed. Of course, anyone
who wants can monitor the logs and, if they believe a certificate is incorrectly
issued, take action as they see fit.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">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 clients to proceed without delay, despite
possible issues, such as network connectivity and the vagaries of firewalls.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">The append-only property of each log is achieved using Merkle Trees, which can
be used to efficiently prove that any particular instance of the log is a
superset of any particular previous instance and to efficiently detect various
misbehaviors of the log (e.g., issuing a signed timestamp for a certificate that
is not subsequently logged).<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">The log auditing mechanisms described in this document can
be circumvented by a misbehaving log that shows different, inconsistent
views of itself to different clients. Therefore, it is necessary to treat each log 
as a trusted third party. While mechanisms are being developed to address these
shortcomings and thereby avoid the need to blindly trust logs,
such mechanisms are outside the scope of this document.<a href="#section-1-6" class="pilcrow">¶</a></p>
<div id="requirements-language">
<section id="section-1.1">
        <h3 id="name-requirements-language">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-1.1-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="data_structures">
<section id="section-1.2">
        <h3 id="name-data-structures">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-data-structures" class="section-name selfRef">Data Structures</a>
        </h3>
<p id="section-1.2-1">Data structures are defined and encoded according to the conventions laid out
 in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-3" class="relref">Section 3</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<p id="section-1.2-2">This document uses object identifiers (OIDs) to identify Log IDs (see
 <a href="#log_id" class="xref">Section 4.4</a>), the precertificate Cryptographic Message
 Syntax (CMS) <code>eContentType</code> (see <a href="#precertificates" class="xref">Section 3.2</a>), X.509v3 extensions in certificates (see <a href="#cert_transinfo_extension" class="xref">Section 7.1.2</a>), and
 Online Certificate Status Protocol (OCSP) responses (see <a href="#ocsp_transinfo_extension" class="xref">Section 7.1.1</a>). The OIDs are defined in an
 arc that was selected due to its short encoding.<a href="#section-1.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="major-differences-from-ct-10">
<section id="section-1.3">
        <h3 id="name-major-differences-from-ct-1">
<a href="#section-1.3" class="section-number selfRef">1.3. </a><a href="#name-major-differences-from-ct-1" class="section-name selfRef">Major Differences from CT 1.0</a>
        </h3>
<p id="section-1.3-1">This document revises and obsoletes the CT 1.0 protocol <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span>, drawing on
 insights gained from CT 1.0 deployments and on feedback from the community. The
 major changes are:<a href="#section-1.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1.3-2.1">Hash and signature algorithm agility: Permitted algorithms are now specified
   in IANA registries.<a href="#section-1.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.2">Precertificate format: Precertificates are now CMS objects rather than X.509
   certificates, which avoids violating the certificate serial number uniqueness
   requirement in <span><a href="https://www.rfc-editor.org/rfc/rfc5280#section-4.1.2.2" class="relref">Section 4.1.2.2</a> of [<a href="#RFC5280" class="xref">RFC5280</a>]</span>.<a href="#section-1.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.3">Removal of precertificate signing certificates and the precertificate poison
   extension: The change of precertificate format means that these are no longer
   needed.<a href="#section-1.3-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.4">Logs IDs: Each log is now identified by an OID rather than by the hash of its
   public key. OID allocations are available from an IANA registry.<a href="#section-1.3-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.5">
            <code>TransItem</code> structure: This new data structure is used to encapsulate
   most types of CT data. A <code>TransItemList</code>, consisting of one or more
   <code>TransItem</code> structures, can be used anywhere that
   <code>SignedCertificateTimestampList</code> was
   used in <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span>.<a href="#section-1.3-2.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.6">Merkle Tree leaves: The <code>MerkleTreeLeaf</code> structure has been replaced by
   the <code>TransItem</code> structure, which eases extensibility and simplifies the leaf
   structure by removing one layer of abstraction.<a href="#section-1.3-2.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.7">Unified leaf format: The structure for both certificate and precertificate
   entries now includes only the TBSCertificate (whereas certificate entries in
   <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span> included the entire certificate).<a href="#section-1.3-2.7" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.8">Log artifact extensions: These are now typed and managed by an IANA registry,
   and they can now appear not only in Signed Certificate Timestamps (SCTs) but also
   in Signed Tree Heads (STHs).<a href="#section-1.3-2.8" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.9">API outputs: Complete <code>TransItem</code> structures are returned rather than
   the constituent parts of each structure.<a href="#section-1.3-2.9" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.10">
            <code>get-all-by-hash</code>: This is a new client API for obtaining an inclusion proof and
   the corresponding consistency proof at the same time.<a href="#section-1.3-2.10" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.11">
            <code>submit-entry</code>: This is a new client API, replacing <code>add-chain</code> and
   <code>add-pre-chain</code>.<a href="#section-1.3-2.11" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.12">Presenting SCTs with proofs: TLS servers may present SCTs together with the
   corresponding inclusion proofs, using any of the mechanisms that <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span>
   defined for presenting SCTs only. (Presenting SCTs only is still supported).<a href="#section-1.3-2.12" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.13">CT TLS extension: The <code>signed_certificate_timestamp</code> TLS extension has
   been replaced by the <code>transparency_info</code> TLS extension.<a href="#section-1.3-2.13" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.14">Verification algorithms: Detailed algorithms for verifying inclusion
   proofs, for verifying consistency between two STHs, and for verifying a root
   hash given a complete list of the relevant leaf input entries have been added.<a href="#section-1.3-2.14" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-1.3-2.15">Extensive clarifications and editorial work.<a href="#section-1.3-2.15" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="cryptographic-components">
<section id="section-2">
      <h2 id="name-cryptographic-components">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-cryptographic-components" class="section-name selfRef">Cryptographic Components</a>
      </h2>
<div id="mht">
<section id="section-2.1">
        <h3 id="name-merkle-trees">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-merkle-trees" class="section-name selfRef">Merkle Trees</a>
        </h3>
<p id="section-2.1-1">A full description of the Merkle Tree is beyond the scope of this
 document. Briefly, it is a binary tree where each non-leaf node is a
 hash of its children. For CT, the number of children is at most two.
 Additional information can be found in the Introduction and Reference
 sections of <span>[<a href="#RFC8391" class="xref">RFC8391</a>]</span>.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<div id="mht_definition">
<section id="section-2.1.1">
          <h4 id="name-definition-of-the-merkle-tr">
<a href="#section-2.1.1" class="section-number selfRef">2.1.1. </a><a href="#name-definition-of-the-merkle-tr" class="section-name selfRef">Definition of the Merkle Tree</a>
          </h4>
<p id="section-2.1.1-1">The log uses a binary Merkle Tree for efficient auditing. The hash
   algorithm used is one of the log's parameters (see <a href="#log_parameters" class="xref">Section 4.1</a>). This document establishes a registry of acceptable hash
   algorithms (see <a href="#hash_algorithms" class="xref">Section 10.2.1</a>). Throughout this
   document, the hash algorithm in use is referred to as HASH and the size of its
   output in bytes is referred to as HASH_SIZE. 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 Tree. The output is a single
   HASH_SIZE 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:<a href="#section-2.1.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1.1-2">The hash of an empty list is the hash of an empty string:<a href="#section-2.1.1-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.1-3">
<pre>
MTH({}) = HASH().
</pre><a href="#section-2.1.1-3" class="pilcrow">¶</a>
</div>
<p id="section-2.1.1-4">The hash of a list with one entry (also known as a leaf hash) is:<a href="#section-2.1.1-4" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.1-5">
<pre>
MTH({d[0]}) = HASH(0x00 || d[0]).
</pre><a href="#section-2.1.1-5" class="pilcrow">¶</a>
</div>
<p id="section-2.1.1-6">For n &gt; 1, let k be the largest power of two smaller than n
   (i.e., k &lt; n &lt;= 2k).
   The Merkle Tree Hash of an n-element list D_n is then defined recursively as:<a href="#section-2.1.1-6" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.1-7">
<pre>
MTH(D_n) = HASH(0x01 || MTH(D[0:k]) || MTH(D[k:n])),
</pre><a href="#section-2.1.1-7" class="pilcrow">¶</a>
</div>
<p id="section-2.1.1-8">where:<a href="#section-2.1.1-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.1.1-9.1">|| denotes concatenation<a href="#section-2.1.1-9.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.1-9.2">: denotes concatenation of lists<a href="#section-2.1.1-9.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.1.1-9.3">D[k1:k2] = D'_(k2-k1) denotes the list {d'[0] = d[k1], d'[1] = d[k1+1],
     ..., d'[k2-k1-1] = d[k2-1]} of length (k2 - k1).<a href="#section-2.1.1-9.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-2.1.1-10">Note that the hash calculations for leaves and nodes differ; this domain
separation is required to give second preimage resistance.<a href="#section-2.1.1-10" class="pilcrow">¶</a></p>
<p id="section-2.1.1-11">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 proposed by <span>[<a href="#CrosbyWallach" class="xref">CrosbyWallach</a>]</span>, except our
definition handles non-full trees differently.)<a href="#section-2.1.1-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="verify_hash">
<section id="section-2.1.2">
          <h4 id="name-verifying-a-tree-head-given">
<a href="#section-2.1.2" class="section-number selfRef">2.1.2. </a><a href="#name-verifying-a-tree-head-given" class="section-name selfRef">Verifying a Tree Head Given Entries</a>
          </h4>
<p id="section-2.1.2-1">When a client has a complete list of <code>entries</code> from <code>0</code> up to
<code>tree_size - 1</code> and wishes to verify this list against a tree head <code>root_hash</code>
returned by the log for the same <code>tree_size</code>, the following algorithm may be
used:<a href="#section-2.1.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-2.1.2-2">
     <li id="section-2.1.2-2.1">Set <code>stack</code> to an empty stack.<a href="#section-2.1.2-2.1" class="pilcrow">¶</a>
</li>
            <li id="section-2.1.2-2.2">
              <p id="section-2.1.2-2.2.1">For each <code>i</code> from <code>0</code> up to <code>tree_size - 1</code>:<a href="#section-2.1.2-2.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2.1.2-2.2.2">
 <li id="section-2.1.2-2.2.2.1">Push <code>HASH(0x00 || entries[i])</code> to <code>stack</code>.<a href="#section-2.1.2-2.2.2.1" class="pilcrow">¶</a>
</li>
                <li id="section-2.1.2-2.2.2.2">Set <code>merge_count</code> to the lowest value (<code>0</code> included)
 such that <code>LSB(i &gt;&gt; merge_count)</code> is not set, where
 <code>LSB</code> means the least significant
 bit. In other words, set <code>merge_count</code> to the number
 of consecutive <code>1</code>s found starting at the least significant bit of
 <code>i</code>.<a href="#section-2.1.2-2.2.2.2" class="pilcrow">¶</a>
</li>
                <li id="section-2.1.2-2.2.2.3">
                  <p id="section-2.1.2-2.2.2.3.1">Repeat <code>merge_count</code> times:<a href="#section-2.1.2-2.2.2.3.1" class="pilcrow">¶</a></p>
<ol start="1" type="i" class="normal type-i" id="section-2.1.2-2.2.2.3.2">
     <li id="section-2.1.2-2.2.2.3.2.1">Pop <code>right</code> from <code>stack</code>.<a href="#section-2.1.2-2.2.2.3.2.1" class="pilcrow">¶</a>
</li>
                    <li id="section-2.1.2-2.2.2.3.2.2">Pop <code>left</code> from <code>stack</code>.<a href="#section-2.1.2-2.2.2.3.2.2" class="pilcrow">¶</a>
</li>
                    <li id="section-2.1.2-2.2.2.3.2.3">Push <code>HASH(0x01 || left || right)</code> to <code>stack</code>.<a href="#section-2.1.2-2.2.2.3.2.3" class="pilcrow">¶</a>
</li>
                  </ol>
</li>
              </ol>
</li>
            <li id="section-2.1.2-2.3">If there is more than one element in the <code>stack</code>, repeat the same merge
procedure (the sub-items of Step 2(c) above) until only a single element
remains.<a href="#section-2.1.2-2.3" class="pilcrow">¶</a>
</li>
            <li id="section-2.1.2-2.4">The remaining element in <code>stack</code> is the Merkle Tree Hash for the given
<code>tree_size</code> and should be compared by equality against the supplied
<code>root_hash</code>.<a href="#section-2.1.2-2.4" class="pilcrow">¶</a>
</li>
          </ol>
</section>
</div>
<div id="merkle_inclusion_proof">
<section id="section-2.1.3">
          <h4 id="name-merkle-inclusion-proofs">
<a href="#section-2.1.3" class="section-number selfRef">2.1.3. </a><a href="#name-merkle-inclusion-proofs" class="section-name selfRef">Merkle Inclusion Proofs</a>
          </h4>
<p id="section-2.1.3-1">A Merkle inclusion proof for a leaf in a Merkle 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 inclusion proof is combined with
the node computed so far. In other words, the inclusion proof 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 inclusion proof matches the true
root, then the inclusion proof proves that the leaf exists in the tree.<a href="#section-2.1.3-1" class="pilcrow">¶</a></p>
<div id="generating-an-inclusion-proof">
<section id="section-2.1.3.1">
            <h5 id="name-generating-an-inclusion-pro">
<a href="#section-2.1.3.1" class="section-number selfRef">2.1.3.1. </a><a href="#name-generating-an-inclusion-pro" class="section-name selfRef">Generating an Inclusion Proof</a>
            </h5>
<p id="section-2.1.3.1-1">Given an ordered list of n inputs to the tree, D_n = {d[0], d[1], ...,
d[n-1]}, the Merkle inclusion proof PATH(m, D_n) for the (m+1)th input d[m],
0 &lt;= m &lt; n, is defined as follows:<a href="#section-2.1.3.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1.3.1-2">The proof for the single leaf in a tree with a one-element input list D[1] =
{d[0]} is empty:<a href="#section-2.1.3.1-2" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.3.1-3">
<pre>
PATH(0, {d[0]}) = {}
</pre><a href="#section-2.1.3.1-3" class="pilcrow">¶</a>
</div>
<p id="section-2.1.3.1-4">For n &gt; 1, let k be the largest power of two smaller than n. The proof for the
(m+1)th element d[m] in a list of n &gt; m elements is then defined recursively as:<a href="#section-2.1.3.1-4" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.3.1-5">
<pre>
PATH(m, D_n) = PATH(m, D[0:k]) : MTH(D[k:n]) for m &lt; k; and

PATH(m, D_n) = PATH(m - k, D[k:n]) : MTH(D[0:k]) for m &gt;= k,
</pre><a href="#section-2.1.3.1-5" class="pilcrow">¶</a>
</div>
<p id="section-2.1.3.1-6">The : operator and D[k1:k2] are defined the same as in <a href="#mht_definition" class="xref">Section 2.1.1</a>.<a href="#section-2.1.3.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="verify_inclusion">
<section id="section-2.1.3.2">
            <h5 id="name-verifying-an-inclusion-proo">
<a href="#section-2.1.3.2" class="section-number selfRef">2.1.3.2. </a><a href="#name-verifying-an-inclusion-proo" class="section-name selfRef">Verifying an Inclusion Proof</a>
            </h5>
<p id="section-2.1.3.2-1">When a client has received an inclusion proof (e.g., in a <code>TransItem</code> of type
<code>inclusion_proof_v2</code>) and wishes to verify inclusion of an input <code>hash</code> for a
given <code>tree_size</code> and <code>root_hash</code>, the following algorithm may be used to prove
the <code>hash</code> was included in the <code>root_hash</code>:<a href="#section-2.1.3.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-2.1.3.2-2">
       <li id="section-2.1.3.2-2.1">Compare <code>leaf_index</code> from the <code>inclusion_proof_v2</code> structure
       against <code>tree_size</code>. If <code>leaf_index</code> is greater than or
       equal to <code>tree_size</code>, then fail the proof verification.<a href="#section-2.1.3.2-2.1" class="pilcrow">¶</a>
</li>
              <li id="section-2.1.3.2-2.2">Set <code>fn</code> to <code>leaf_index</code> and <code>sn</code> to <code>tree_size -
       1</code>.<a href="#section-2.1.3.2-2.2" class="pilcrow">¶</a>
</li>
              <li id="section-2.1.3.2-2.3">Set <code>r</code> to <code>hash</code>.<a href="#section-2.1.3.2-2.3" class="pilcrow">¶</a>
</li>
              <li id="section-2.1.3.2-2.4">
                <p id="section-2.1.3.2-2.4.1">For each value <code>p</code> in the <code>inclusion_path</code> array:<a href="#section-2.1.3.2-2.4.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2.1.3.2-2.4.2">
                  <li id="section-2.1.3.2-2.4.2.1">If <code>sn</code> is 0, then stop the iteration and fail the proof verification.<a href="#section-2.1.3.2-2.4.2.1" class="pilcrow">¶</a>
</li>
                  <li id="section-2.1.3.2-2.4.2.2">
                    <p id="section-2.1.3.2-2.4.2.2.1">If <code>LSB(fn)</code> is set, or if <code>fn</code> is equal to <code>sn</code>, then:<a href="#section-2.1.3.2-2.4.2.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="i" class="normal type-i" id="section-2.1.3.2-2.4.2.2.2">
                      <li id="section-2.1.3.2-2.4.2.2.2.1">Set <code>r</code> to <code>HASH(0x01 || p || r)</code>.<a href="#section-2.1.3.2-2.4.2.2.2.1" class="pilcrow">¶</a>
</li>
                      <li id="section-2.1.3.2-2.4.2.2.2.2">If <code>LSB(fn)</code> is not set, then right-shift both <code>fn</code> and
                        <code>sn</code> equally until either <code>LSB(fn)</code> is set or <code>fn</code> is <code>0</code>.<a href="#section-2.1.3.2-2.4.2.2.2.2" class="pilcrow">¶</a>
</li>
                    </ol>
<p id="section-2.1.3.2-2.4.2.2.3">Otherwise:<a href="#section-2.1.3.2-2.4.2.2.3" class="pilcrow">¶</a></p>
<ol start="1" type="i" class="normal type-i" id="section-2.1.3.2-2.4.2.2.4">
                      <li id="section-2.1.3.2-2.4.2.2.4.1">Set <code>r</code> to <code>HASH(0x01 || r || p)</code>.<a href="#section-2.1.3.2-2.4.2.2.4.1" class="pilcrow">¶</a>
</li>
                    </ol>
</li>
                  <li id="section-2.1.3.2-2.4.2.3">Finally, right-shift both <code>fn</code> and <code>sn</code> one time.<a href="#section-2.1.3.2-2.4.2.3" class="pilcrow">¶</a>
</li>
                </ol>
</li>
              <li id="section-2.1.3.2-2.5">Compare <code>sn</code> to 0. Compare <code>r</code> against the
       <code>root_hash</code>. If <code>sn</code> is equal to
       0 and <code>r</code> and the <code>root_hash</code> are equal, then the log has proven
       the inclusion of <code>hash</code>. Otherwise, fail the proof verification.<a href="#section-2.1.3.2-2.5" class="pilcrow">¶</a>
</li>
            </ol>
</section>
</div>
</section>
</div>
<div id="consistency">
<section id="section-2.1.4">
          <h4 id="name-merkle-consistency-proofs">
<a href="#section-2.1.4" class="section-number selfRef">2.1.4. </a><a href="#name-merkle-consistency-proofs" class="section-name selfRef">Merkle Consistency Proofs</a>
          </h4>
<p id="section-2.1.4-1">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 &lt;= 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.<a href="#section-2.1.4-1" class="pilcrow">¶</a></p>
<div id="generating-a-consistency-proof">
<section id="section-2.1.4.1">
            <h5 id="name-generating-a-consistency-pr">
<a href="#section-2.1.4.1" class="section-number selfRef">2.1.4.1. </a><a href="#name-generating-a-consistency-pr" class="section-name selfRef">Generating a Consistency Proof</a>
            </h5>
<p id="section-2.1.4.1-1">Given an ordered list of n inputs to the tree, D_n = {d[0], d[1], ...,
d[n-1]}, the Merkle consistency proof PROOF(m, D_n) for a previous Merkle Tree
Hash MTH(D[0:m]), 0 &lt; m &lt; n, is defined as:<a href="#section-2.1.4.1-1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.4.1-2">
<pre>
PROOF(m, D_n) = SUBPROOF(m, D_n, true)
</pre><a href="#section-2.1.4.1-2" class="pilcrow">¶</a>
</div>
<p id="section-2.1.4.1-3">In SUBPROOF, the boolean value represents whether the subtree created from
     D[0:m] is a complete subtree of the Merkle Tree created from D_n and,
     consequently, whether the subtree Merkle Tree Hash MTH(D[0:m]) is known. The
     initial call to SUBPROOF sets this to be true, and SUBPROOF is then defined as
     follows:<a href="#section-2.1.4.1-3" class="pilcrow">¶</a></p>
<p id="section-2.1.4.1-4">The subproof for m = n is empty if m is the value for which PROOF was
     originally requested (meaning that the subtree created from D[0:m] is a complete
     subtree of the Merkle Tree created from the original D_n for which PROOF was
     requested and the subtree Merkle Tree Hash MTH(D[0:m]) is known):<a href="#section-2.1.4.1-4" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.4.1-5">
<pre>
SUBPROOF(m, D_m, true) = {}
</pre><a href="#section-2.1.4.1-5" class="pilcrow">¶</a>
</div>
<p id="section-2.1.4.1-6">Otherwise, the subproof for m = n is the Merkle Tree Hash committing inputs
     D[0:m]:<a href="#section-2.1.4.1-6" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.4.1-7">
<pre>
SUBPROOF(m, D_m, false) = {MTH(D_m)}
</pre><a href="#section-2.1.4.1-7" class="pilcrow">¶</a>
</div>
<p id="section-2.1.4.1-8">For m &lt; n, let k be the largest power of two smaller than n. The subproof is
     then defined recursively, using the appropriate step below:<a href="#section-2.1.4.1-8" class="pilcrow">¶</a></p>
<p id="section-2.1.4.1-9">If m &lt;= 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]:<a href="#section-2.1.4.1-9" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.4.1-10">
<pre>
SUBPROOF(m, D_n, b) = SUBPROOF(m, D[0:k], b) : MTH(D[k:n])
</pre><a href="#section-2.1.4.1-10" class="pilcrow">¶</a>
</div>
<p id="section-2.1.4.1-11">If m &gt; 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]:<a href="#section-2.1.4.1-11" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.4.1-12">
<pre>
SUBPROOF(m, D_n, b) = SUBPROOF(m - k, D[k:n], false) : MTH(D[0:k])
</pre><a href="#section-2.1.4.1-12" class="pilcrow">¶</a>
</div>
<p id="section-2.1.4.1-13">The number of nodes in the resulting proof is bounded above by ceil(log2(n)) +
1.<a href="#section-2.1.4.1-13" class="pilcrow">¶</a></p>
<p id="section-2.1.4.1-14">The : operator and D[k1:k2] are defined the same as in <a href="#mht_definition" class="xref">Section 2.1.1</a>.<a href="#section-2.1.4.1-14" class="pilcrow">¶</a></p>
</section>
</div>
<div id="verify_consistency">
<section id="section-2.1.4.2">
            <h5 id="name-verifying-consistency-betwe">
<a href="#section-2.1.4.2" class="section-number selfRef">2.1.4.2. </a><a href="#name-verifying-consistency-betwe" class="section-name selfRef">Verifying Consistency between Two Tree Heads</a>
            </h5>
<p id="section-2.1.4.2-1">When a client has a tree head <code>first_hash</code> for tree size
     <code>first</code>, has a tree head
     <code>second_hash</code> for tree size <code>second</code> where <code>0 &lt; first &lt;
     second</code>, and has received a consistency proof between the two (e.g., in a
     <code>TransItem</code> of type
     <code>consistency_proof_v2</code>), the following algorithm may be used to verify the
     consistency proof:<a href="#section-2.1.4.2-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-2.1.4.2-2">
       <li id="section-2.1.4.2-2.1">If <code>consistency_path</code> is an empty array, stop and fail the proof
       verification.<a href="#section-2.1.4.2-2.1" class="pilcrow">¶</a>
</li>
              <li id="section-2.1.4.2-2.2">If <code>first</code> is an exact power of 2, then prepend <code>first_hash</code>
       to the <code>consistency_path</code> array.<a href="#section-2.1.4.2-2.2" class="pilcrow">¶</a>
</li>
              <li id="section-2.1.4.2-2.3">Set <code>fn</code> to <code>first - 1</code> and <code>sn</code> to <code>second -
       1</code>.<a href="#section-2.1.4.2-2.3" class="pilcrow">¶</a>
</li>
              <li id="section-2.1.4.2-2.4">If <code>LSB(fn)</code> is set, then right-shift both <code>fn</code> and
       <code>sn</code> equally until <code>LSB(fn)</code> is not set.<a href="#section-2.1.4.2-2.4" class="pilcrow">¶</a>
</li>
              <li id="section-2.1.4.2-2.5">Set both <code>fr</code> and <code>sr</code> to the first value in the
       <code>consistency_path</code> array.<a href="#section-2.1.4.2-2.5" class="pilcrow">¶</a>
</li>
              <li id="section-2.1.4.2-2.6">
                <p id="section-2.1.4.2-2.6.1">For each subsequent value <code>c</code> in the <code>consistency_path</code> array:<a href="#section-2.1.4.2-2.6.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-2.1.4.2-2.6.2">
                  <li id="section-2.1.4.2-2.6.2.1">If <code>sn</code> is 0, then stop the iteration and fail the proof verification.<a href="#section-2.1.4.2-2.6.2.1" class="pilcrow">¶</a>
</li>
                  <li id="section-2.1.4.2-2.6.2.2">
                    <p id="section-2.1.4.2-2.6.2.2.1">If <code>LSB(fn)</code> is set, or if <code>fn</code> is equal to <code>sn</code>, then:<a href="#section-2.1.4.2-2.6.2.2.1" class="pilcrow">¶</a></p>
<ol start="1" type="i" class="normal type-i" id="section-2.1.4.2-2.6.2.2.2">
                      <li id="section-2.1.4.2-2.6.2.2.2.1">Set <code>fr</code> to <code>HASH(0x01 || c || fr)</code>.<a href="#section-2.1.4.2-2.6.2.2.2.1" class="pilcrow">¶</a>
</li>
                      <li id="section-2.1.4.2-2.6.2.2.2.2">Set <code>sr</code> to <code>HASH(0x01 || c || sr)</code>.<a href="#section-2.1.4.2-2.6.2.2.2.2" class="pilcrow">¶</a>
</li>
                      <li id="section-2.1.4.2-2.6.2.2.2.3">If <code>LSB(fn)</code> is not set, then right-shift both <code>fn</code> and <code>sn</code>
                        equally until either <code>LSB(fn)</code> is set or <code>fn</code> is <code>0</code>.<a href="#section-2.1.4.2-2.6.2.2.2.3" class="pilcrow">¶</a>
</li>
                    </ol>
<p id="section-2.1.4.2-2.6.2.2.3">Otherwise:<a href="#section-2.1.4.2-2.6.2.2.3" class="pilcrow">¶</a></p>
<ol start="1" type="i" class="normal type-i" id="section-2.1.4.2-2.6.2.2.4">
                      <li id="section-2.1.4.2-2.6.2.2.4.1">Set <code>sr</code> to <code>HASH(0x01 || sr || c)</code>.<a href="#section-2.1.4.2-2.6.2.2.4.1" class="pilcrow">¶</a>
</li>
                    </ol>
</li>
                  <li id="section-2.1.4.2-2.6.2.3">Finally, right-shift both <code>fn</code> and <code>sn</code> one time.<a href="#section-2.1.4.2-2.6.2.3" class="pilcrow">¶</a>
</li>
                </ol>
</li>
              <li id="section-2.1.4.2-2.7">After completing iterating through the <code>consistency_path</code> array as
       described above, verify that the <code>fr</code> calculated is equal to the
       <code>first_hash</code> supplied, that the <code>sr</code> calculated is equal to the
       <code>second_hash</code> supplied, and that <code>sn</code> is 0.<a href="#section-2.1.4.2-2.7" class="pilcrow">¶</a>
</li>
            </ol>
</section>
</div>
</section>
</div>
<div id="example">
<section id="section-2.1.5">
          <h4 id="name-example">
<a href="#section-2.1.5" class="section-number selfRef">2.1.5. </a><a href="#name-example" class="section-name selfRef">Example</a>
          </h4>
<p id="section-2.1.5-1">The following is a binary Merkle Tree with 7 leaves:<a href="#section-2.1.5-1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.5-2">
<pre>
            hash
           /    \
          /      \
         /        \
        /          \
       /            \
      k              l
     / \            / \
    /   \          /   \
   /     \        /     \
  g       h      i      j
 / \     / \    / \     |
 a b     c d    e f     d6
 | |     | |    | |
d0 d1   d2 d3  d4 d5
</pre><a href="#section-2.1.5-2" class="pilcrow">¶</a>
</div>
<p id="section-2.1.5-3">The inclusion proof for <code>d0</code> is [<code>b</code>, <code>h</code>, <code>l</code>].<a href="#section-2.1.5-3" class="pilcrow">¶</a></p>
<p id="section-2.1.5-4">The inclusion proof for <code>d3</code> is [<code>c</code>, <code>g</code>, <code>l</code>].<a href="#section-2.1.5-4" class="pilcrow">¶</a></p>
<p id="section-2.1.5-5">The inclusion proof for <code>d4</code> is [<code>f</code>, <code>j</code>, <code>k</code>].<a href="#section-2.1.5-5" class="pilcrow">¶</a></p>
<p id="section-2.1.5-6">The inclusion proof for <code>d6</code> is [<code>i</code>, <code>k</code>].<a href="#section-2.1.5-6" class="pilcrow">¶</a></p>
<p id="section-2.1.5-7">The same tree, built incrementally in four steps:<a href="#section-2.1.5-7" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-2.1.5-8">
<pre>
    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
</pre><a href="#section-2.1.5-8" class="pilcrow">¶</a>
</div>
<p id="section-2.1.5-9">The consistency proof between <code>hash0</code> and <code>hash</code> is PROOF(3, D[7]) = [<code>c</code>, <code>d</code>, <code>g</code>, <code>l</code>].
Non-leaf nodes <code>c</code>, <code>g</code> are used to verify <code>hash0</code>, and non-leaf nodes <code>d</code>, <code>l</code> are additionally used to show <code>hash</code> is
consistent with <code>hash0</code>.<a href="#section-2.1.5-9" class="pilcrow">¶</a></p>
<p id="section-2.1.5-10">The consistency proof between <code>hash1</code> and <code>hash</code> is PROOF(4, D[7]) = [<code>l</code>]. <code>hash</code> can
be verified using <code>hash1</code>=<code>k</code> and <code>l</code>.<a href="#section-2.1.5-10" class="pilcrow">¶</a></p>
<p id="section-2.1.5-11">The consistency proof between <code>hash2</code> and <code>hash</code> is PROOF(6, D[7]) = [<code>i</code>, <code>j</code>, <code>k</code>].
Non-leaf nodes <code>k</code>, <code>i</code> are used to verify <code>hash2</code>, and non-leaf node <code>j</code> is additionally used to show <code>hash</code> is
consistent with <code>hash2</code>.<a href="#section-2.1.5-11" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="signatures">
<section id="section-2.2">
        <h3 id="name-signatures">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-signatures" class="section-name selfRef">Signatures</a>
        </h3>
<p id="section-2.2-1">When signing data structures, a log <span class="bcp14">MUST</span> use one of
the signature algorithms from the IANA "Signature Algorithms" registry,
described in <a href="#signature_algorithms" class="xref">Section 10.2.2</a>.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="submitters">
<section id="section-3">
      <h2 id="name-submitters">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-submitters" class="section-name selfRef">Submitters</a>
      </h2>
<p id="section-3-1">Submitters submit certificates or preannouncements of certificates prior to
issuance (precertificates) to logs for public auditing, as described below. In
order to enable attribution of each logged certificate or precertificate to its
issuer, each submission <span class="bcp14">MUST</span> be accompanied by all additional certificates
required to verify the chain up to an accepted trust anchor (<a href="#get-anchors" class="xref">Section 5.7</a>).
The trust anchor (a root or intermediate CA certificate) <span class="bcp14">MAY</span> be omitted from the
submission.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">If a log accepts a submission, it will return a Signed Certificate Timestamp
(SCT) (see <a href="#sct" class="xref">Section 4.8</a>). The submitter <span class="bcp14">SHOULD</span> validate the returned SCT, as described
in <a href="#tls_clients" class="xref">Section 8.1</a>, if they understand its format and they intend to use it
directly in a TLS handshake or to construct a certificate. If the submitter does
not need the SCT (for example, the certificate is being submitted simply to make
it available in the log), it <span class="bcp14">MAY</span> validate the SCT.<a href="#section-3-2" class="pilcrow">¶</a></p>
<div id="certificates">
<section id="section-3.1">
        <h3 id="name-certificates">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-certificates" class="section-name selfRef">Certificates</a>
        </h3>
<p id="section-3.1-1">Any entity can submit a certificate (<a href="#submit-entry" class="xref">Section 5.1</a>) to a log. Since it is
anticipated that TLS clients will reject certificates that are not logged, it is
expected that certificate issuers and subjects will be strongly motivated to
submit them.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="precertificates">
<section id="section-3.2">
        <h3 id="name-precertificates">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-precertificates" class="section-name selfRef">Precertificates</a>
        </h3>
<p id="section-3.2-1">CAs may preannounce a certificate prior to issuance by submitting a
precertificate (<a href="#submit-entry" class="xref">Section 5.1</a>) that the log can use to create an entry that
will be valid against the issued certificate. The CA <span class="bcp14">MAY</span> incorporate the
returned SCT in the issued certificate. One example of where the returned SCT is
not incorporated in the issued certificate is when a CA sends the precertificate
to multiple logs but only incorporates the SCTs that are returned first.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">A precertificate is a CMS <span>[<a href="#RFC5652" class="xref">RFC5652</a>]</span> <code>signed-data</code> object that conforms to the
following profile:<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-3.1">It <span class="bcp14">MUST</span> be DER encoded, as described in <span>[<a href="#X690" class="xref">X690</a>]</span>.<a href="#section-3.2-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-3.2">
            <code>SignedData.version</code> <span class="bcp14">MUST</span> be v3(3).<a href="#section-3.2-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-3.3">
            <code>SignedData.digestAlgorithms</code> <span class="bcp14">MUST</span> be the same as the
   <code>SignerInfo.digestAlgorithm</code> OID value (see below).<a href="#section-3.2-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-3.4">
            <p id="section-3.2-3.4.1"><code>SignedData.encapContentInfo</code>:<a href="#section-3.2-3.4.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-3.4.2.1">
                <code>eContentType</code> <span class="bcp14">MUST</span> be the OID 1.3.101.78.<a href="#section-3.2-3.4.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2-3.4.2.2">
                <code>eContent</code> <span class="bcp14">MUST</span> contain a TBSCertificate <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span> that will be identical to
       the TBSCertificate in the issued certificate, except that the Transparency
       Information (<a href="#x509v3_transinfo_extension" class="xref">Section 7.1</a>)
       extension <span class="bcp14">MUST</span> be omitted.<a href="#section-3.2-3.4.2.2" class="pilcrow">¶</a>
</li>
            </ul>
</li>
          <li class="normal" id="section-3.2-3.5">
            <code>SignedData.certificates</code> <span class="bcp14">MUST</span> be omitted.<a href="#section-3.2-3.5" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-3.6">
            <code>SignedData.crls</code> <span class="bcp14">MUST</span> be omitted.<a href="#section-3.2-3.6" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.2-3.7">
            <p id="section-3.2-3.7.1"><code>SignedData.signerInfos</code> <span class="bcp14">MUST</span> contain one
   <code>SignerInfo</code>:<a href="#section-3.2-3.7.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-3.7.2.1">
                <code>version</code> <span class="bcp14">MUST</span> be v3(3).<a href="#section-3.2-3.7.2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2-3.7.2.2">
                <code>sid</code> <span class="bcp14">MUST</span> use the <code>subjectKeyIdentifier</code>
       option.<a href="#section-3.2-3.7.2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2-3.7.2.3">
                <code>digestAlgorithm</code> <span class="bcp14">MUST</span> be one of the hash algorithm
       OIDs listed in the IANA "Hash Algorithms" registry, described in
       <a href="#hash_algorithms" class="xref">Section 10.2.1</a>.<a href="#section-3.2-3.7.2.3" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2-3.7.2.4">
                <p id="section-3.2-3.7.2.4.1"><code>signedAttrs</code> <span class="bcp14">MUST</span> be present and
 <span class="bcp14">MUST</span> contain two attributes:<a href="#section-3.2-3.7.2.4.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2-3.7.2.4.2.1">a content-type attribute whose value is the same as
   <code>SignedData.encapContentInfo.eContentType</code> and<a href="#section-3.2-3.7.2.4.2.1" class="pilcrow">¶</a>
</li>
                  <li class="normal" id="section-3.2-3.7.2.4.2.2">a message-digest attribute whose value is the message digest of
   <code>SignedData.encapContentInfo.eContent</code>.<a href="#section-3.2-3.7.2.4.2.2" class="pilcrow">¶</a>
</li>
                </ul>
</li>
              <li class="normal" id="section-3.2-3.7.2.5">
                <code>signatureAlgorithm</code> <span class="bcp14">MUST</span> be the same OID as
       <code>TBSCertificate.signature</code>.<a href="#section-3.2-3.7.2.5" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2-3.7.2.6">
                <code>signature</code> <span class="bcp14">MUST</span> be from the same (root or
       intermediate) CA that intends to
       issue the corresponding certificate (see <a href="#binding_intent_to_issue" class="xref">Section 3.2.1</a>).<a href="#section-3.2-3.7.2.6" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-3.2-3.7.2.7">
                <code>unsignedAttrs</code> <span class="bcp14">MUST</span> be omitted.<a href="#section-3.2-3.7.2.7" class="pilcrow">¶</a>
</li>
            </ul>
</li>
        </ul>
<p id="section-3.2-4"><code>SignerInfo.signedAttrs</code> is included in the message digest calculation process
(see <span><a href="https://www.rfc-editor.org/rfc/rfc5652#section-5.4" class="relref">Section 5.4</a> of [<a href="#RFC5652" class="xref">RFC5652</a>]</span>), which ensures that the <code>SignerInfo.signature</code>
value will not be a valid X.509v3 signature that could be used in conjunction
with the TBSCertificate (from <code>SignedData.encapContentInfo.eContent</code>) to
construct a valid certificate.<a href="#section-3.2-4" class="pilcrow">¶</a></p>
<div id="binding_intent_to_issue">
<section id="section-3.2.1">
          <h4 id="name-binding-intent-to-issue">
<a href="#section-3.2.1" class="section-number selfRef">3.2.1. </a><a href="#name-binding-intent-to-issue" class="section-name selfRef">Binding Intent to Issue</a>
          </h4>
<p id="section-3.2.1-1">Under normal circumstances, there will be a short delay between precertificate
submission and issuance of the corresponding certificate. Longer delays are to
be expected occasionally (e.g., due to log server downtime); in some cases,
the CA might not actually issue the corresponding certificate. Nevertheless, a
precertificate's <code>signature</code> indicates the CA's binding intent to issue the
corresponding certificate, which means that:<a href="#section-3.2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.2.1-2.1">Misissuance of a precertificate is considered equivalent to misissuance of
     the corresponding certificate. The CA should expect to be held accountable,
     even if the corresponding certificate has not actually been issued.<a href="#section-3.2.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.1-2.2">Upon observing a precertificate, a client can reasonably presume that the
     corresponding certificate has been issued. A client may wish to obtain status
     information (e.g., by using the Online Certificate Status Protocol <span>[<a href="#RFC6960" class="xref">RFC6960</a>]</span>
     or by checking a Certificate Revocation List <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span>) about a certificate
     that is presumed to exist, especially if there is evidence or suspicion that
     the corresponding precertificate was misissued.<a href="#section-3.2.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.2.1-2.3">TLS clients may have policies that require CAs to be able to revoke and to
     provide certificate status services for each certificate that is presumed to
     exist based on the existence of a corresponding precertificate.<a href="#section-3.2.1-2.3" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="log-format-and-operation">
<section id="section-4">
      <h2 id="name-log-format-and-operation">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-log-format-and-operation" class="section-name selfRef">Log Format and Operation</a>
      </h2>
<p id="section-4-1">A log is a single, append-only Merkle Tree of submitted certificate and
precertificate entries.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">When it receives and accepts a valid submission, the log <span class="bcp14">MUST</span> return an SCT that
corresponds to the submitted certificate or precertificate. If the log has
previously seen this valid submission, it <span class="bcp14">SHOULD</span> return the same SCT as it
returned before, as discussed in <a href="#misbehaving_logs" class="xref">Section 11.3</a>.
If different SCTs are produced for the same
submission, multiple log entries will have to be created, one for each SCT (as
the timestamp is a part of the leaf structure). Note that if a certificate was
previously logged as a precertificate, then the precertificate's SCT of type
<code>precert_sct_v2</code> would not be appropriate; instead, a fresh SCT of type
<code>x509_sct_v2</code> should be generated.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">An SCT is the log's promise to append to its Merkle Tree an entry for the
      accepted submission. Upon producing an SCT, the log <span class="bcp14">MUST</span> fulfill this
      promise by performing the following actions within a fixed amount of time known as the
      Maximum Merge Delay (MMD), which is one of the log's parameters (see
      <a href="#log_parameters" class="xref">Section 4.1</a>):<a href="#section-4-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4-4.1">Allocate a tree index to the entry representing the accepted submission.<a href="#section-4-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-4.2">Calculate the root of the tree.<a href="#section-4-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-4-4.3">Sign the root of the tree (see <a href="#sth" class="xref">Section 4.10</a>).<a href="#section-4-4.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-4-5">The log may append multiple entries before signing the root of the tree.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">Log operators <span class="bcp14">SHOULD NOT</span> impose any conditions on retrieving or sharing data
from the log.<a href="#section-4-6" class="pilcrow">¶</a></p>
<div id="log_parameters">
<section id="section-4.1">
        <h3 id="name-log-parameters">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-log-parameters" class="section-name selfRef">Log Parameters</a>
        </h3>
<p id="section-4.1-1">A log is defined by a collection of immutable parameters, which are used by
clients to communicate with the log and to verify log artifacts. Except for the
Final STH, each of these parameters <span class="bcp14">MUST</span> be established
before the log operator begins to operate the log.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.1-2">
          <dt id="section-4.1-2.1">Base URL:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.2">The prefix used to construct URLs <span>[<a href="#RFC3986" class="xref">RFC3986</a>]</span>
   for client messages (see <a href="#client_messages" class="xref">Section 5</a>). The
   base URL <span class="bcp14">MUST</span> be an "https" URL, <span class="bcp14">MAY</span> contain a port,
   and <span class="bcp14">MAY</span> contain a path with any number of path segments but
   <span class="bcp14">MUST NOT</span> contain a query string, fragment, or trailing "/".
   Example: https://ct.example.org/blue.<a href="#section-4.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.3">Hash Algorithm:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.4">The hash algorithm used for the Merkle Tree (see <a href="#hash_algorithms" class="xref">Section 10.2.1</a>).<a href="#section-4.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.5">Signature Algorithm:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.6">The signature algorithm used (see <a href="#signatures" class="xref">Section 2.2</a>).<a href="#section-4.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.7">Public Key:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.8">The public key used to verify signatures generated by the log. A log
   <span class="bcp14">MUST NOT</span> use the same keypair as any other log.<a href="#section-4.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.9">Log ID:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.10">The OID that uniquely identifies the log.<a href="#section-4.1-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.11">Maximum Merge Delay:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.12">The MMD the log has committed to. This document deliberately does not specify
   any limits on the value to allow for experimentation.<a href="#section-4.1-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.13">Version:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.14">The version of the protocol supported by the log (currently 1 or 2).<a href="#section-4.1-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.15">Maximum Chain Length:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.16">The longest certificate chain submission the log is willing to accept, if the
   log imposes any limit.<a href="#section-4.1-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.17">STH Frequency Count:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.18">The maximum number of STHs the log may produce in any period equal to the
   <code>Maximum Merge Delay</code> (see <a href="#sth" class="xref">Section 4.10</a>).<a href="#section-4.1-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-4.1-2.19">Final STH:</dt>
          <dd style="margin-left: 1.5em" id="section-4.1-2.20">If a log has been closed down (i.e., no longer accepts new entries), existing
   entries may still be valid. In this case, the client should know the final
   valid STH in the log to ensure no new entries can be added without detection.
   This value <span class="bcp14">MUST</span> be provided in the form of a <code>TransItem</code> of
   type <code>signed_tree_head_v2</code>.
   If a log is still accepting entries, this value should not be provided.<a href="#section-4.1-2.20" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.1-3"><span>[<a href="#JSON.Metadata" class="xref">JSON.Metadata</a>]</span> is an example of a metadata format
 that includes the above elements.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="evaluating-submissions">
<section id="section-4.2">
        <h3 id="name-evaluating-submissions">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-evaluating-submissions" class="section-name selfRef">Evaluating Submissions</a>
        </h3>
<p id="section-4.2-1">A log determines whether to accept or reject a submission by evaluating it
against the minimum acceptance criteria (see <a href="#minimum_criteria" class="xref">Section 4.2.1</a>) and against
the log's discretionary acceptance criteria (see <a href="#discretionary_criteria" class="xref">Section 4.2.2</a>).<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">If the acceptance criteria are met, the log <span class="bcp14">SHOULD</span> accept the submission. (A log
may decide, for example, to temporarily reject acceptable submissions to protect
itself against denial-of-service attacks.)<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">The log <span class="bcp14">SHALL</span> allow retrieval of its list of accepted trust anchors (see
<a href="#get-anchors" class="xref">Section 5.7</a>), each of which is a root or intermediate CA certificate. This
list might usefully be the union of root certificates trusted by major browser
vendors.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<div id="minimum_criteria">
<section id="section-4.2.1">
          <h4 id="name-minimum-acceptance-criteria">
<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-minimum-acceptance-criteria" class="section-name selfRef">Minimum Acceptance Criteria</a>
          </h4>
<p id="section-4.2.1-1">To ensure that logged certificates and precertificates are attributable to an
accepted trust anchor, to set clear expectations for what monitors would
find in the log, and to avoid being overloaded by invalid submissions, the log
<span class="bcp14">MUST</span> reject a submission if any of the following conditions are not met:<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2.1-2.1">The <code>submission</code>, <code>type</code>, and <code>chain</code> inputs
     <span class="bcp14">MUST</span> be set as described in
     <a href="#submit-entry" class="xref">Section 5.1</a>. The log <span class="bcp14">MUST NOT</span>
     accommodate misordered CA certificates or
     use any other source of intermediate CA certificates to attempt certification
     path construction.<a href="#section-4.2.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.2.1-2.2">
              <p id="section-4.2.1-2.2.1">Each of the zero or more intermediate CA certificates in the chain
       <span class="bcp14">MUST</span> have one or both of the following features:<a href="#section-4.2.1-2.2.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.2.1-2.2.2.1">The Basic Constraints extension with the cA boolean asserted.<a href="#section-4.2.1-2.2.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-4.2.1-2.2.2.2">The Key Usage extension with the keyCertSign bit asserted.<a href="#section-4.2.1-2.2.2.2" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="normal" id="section-4.2.1-2.3">Each certificate in the chain <span class="bcp14">MUST</span> fall within the limits
     imposed by the zero
     or more Basic Constraints pathLenConstraint values found higher up the chain.<a href="#section-4.2.1-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.2.1-2.4">Precertificate submissions <span class="bcp14">MUST</span> conform to all of the
     requirements in
     <a href="#precertificates" class="xref">Section 3.2</a>.<a href="#section-4.2.1-2.4" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="discretionary_criteria">
<section id="section-4.2.2">
          <h4 id="name-discretionary-acceptance-cr">
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-discretionary-acceptance-cr" class="section-name selfRef">Discretionary Acceptance Criteria</a>
          </h4>
<p id="section-4.2.2-1">If the minimum acceptance criteria are met but the submission is not fully
   valid according to <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span> verification rules
   (e.g., the certificate or
   precertificate has expired, is not yet valid, has been revoked, exhibits ASN.1
   DER encoding errors but the log can still parse it, etc.), then the acceptability
   of the submission is left to the log's discretion. It is useful for logs to
   accept such submissions in order to accommodate quirks of CA certificate-issuing
   software and to facilitate monitoring of CA compliance with applicable policies
   and technical standards. However, it is impractical for this document to
   enumerate, and for logs to consider, all of the ways that a submission might
   fail to comply with <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span>.<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2.2-2">Logs <span class="bcp14">SHOULD</span> limit the length of chain they will accept. The
   maximum chain length is one of the log's parameters (see <a href="#log_parameters" class="xref">Section 4.1</a>).<a href="#section-4.2.2-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="log_entries">
<section id="section-4.3">
        <h3 id="name-log-entries">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-log-entries" class="section-name selfRef">Log Entries</a>
        </h3>
<p id="section-4.3-1">If a submission is accepted and an SCT is issued, the accepting log <span class="bcp14">MUST</span> store the
entire chain used for verification. This chain <span class="bcp14">MUST</span> include the certificate or
precertificate itself, the zero or more intermediate CA certificates provided by
the submitter, and the trust anchor used to verify the chain (even if it was
omitted from the submission). The log <span class="bcp14">MUST</span> provide this chain for auditing upon
request (see <a href="#get-entries" class="xref">Section 5.6</a>) so that the CA cannot avoid blame by
logging a partial or empty chain.
Each log entry is a <code>TransItem</code> structure of type <code>x509_entry_v2</code> or
<code>precert_entry_v2</code>. However, a log may store its entries in any format. If a
log does not store this <code>TransItem</code> in full, it must store the <code>timestamp</code>
and <code>sct_extensions</code> of the corresponding <code>TimestampedCertificateEntryDataV2</code>
structure. The <code>TransItem</code> can be reconstructed from these fields and the entire
chain that the log used to verify the submission.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="log_id">
<section id="section-4.4">
        <h3 id="name-log-id">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-log-id" class="section-name selfRef">Log ID</a>
        </h3>
<p id="section-4.4-1">Each log is identified by an OID, which is one of the log's parameters (see
<a href="#log_parameters" class="xref">Section 4.1</a>) and which <span class="bcp14">MUST NOT</span> be used to identify any other log. A
log's operator <span class="bcp14">MUST</span> either allocate the OID themselves or request an OID from
the Log ID registry (see <a href="#log_id_registry" class="xref">Section 10.2.5</a>).
One way to get an OID arc, from which OIDs can be allocated, is to request
a Private Enterprise Number from IANA by completing the
<a href="https://pen.iana.org/pen/PenApplication.page">registration form</a>.
The only advantage of the registry is that the DER encoding can be small.
(Recall that OID allocations do not require a central registration, although
logs will most likely want to make themselves known to potential clients
through out-of-band means.)
Various data structures include
the DER encoding of this OID, excluding the ASN.1 tag and length bytes, in an
opaque vector:<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<div id="section-4.4-2">
<pre class="lang-tls-presentation sourcecode">
    opaque LogID&lt;2..127&gt;;
</pre><a href="#section-4.4-2" class="pilcrow">¶</a>
</div>
<p id="section-4.4-3">Note that the ASN.1 length and the opaque vector length are identical in size (1
byte) and value, so the full DER encoding (including the tag and length)
of the OID can be reproduced simply by
prepending an OBJECT IDENTIFIER tag (0x06) to the opaque vector length and
contents.<a href="#section-4.4-3" class="pilcrow">¶</a></p>
<p id="section-4.4-4">The OID used to identify a log is limited such that the DER encoding of its
value, excluding the tag and length, <span class="bcp14">MUST</span> be no longer than 127 octets.<a href="#section-4.4-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="transitem-structure">
<section id="section-4.5">
        <h3 id="name-transitem-structure">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-transitem-structure" class="section-name selfRef">TransItem Structure</a>
        </h3>
<p id="section-4.5-1">Various data structures are encapsulated in the <code>TransItem</code> structure to ensure
that the type and version of each one is identified in a common fashion:<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<div id="section-4.5-2">
<pre class="lang-tls-presentation sourcecode">
    enum {
        x509_entry_v2(0x0100), precert_entry_v2(0x0101),
        x509_sct_v2(0x0102), precert_sct_v2(0x0103),
        signed_tree_head_v2(0x0104), consistency_proof_v2(0x0105),
        inclusion_proof_v2(0x0106),

        /* Reserved Code Points */
        reserved_rfc6962(0x0000..0x00FF),
        reserved_experimentaluse(0xE000..0xEFFF),
        reserved_privateuse(0xF000..0xFFFF),
        (0xFFFF)
    } VersionedTransType;

    struct {
        VersionedTransType versioned_type;
        select (versioned_type) {
            case x509_entry_v2: TimestampedCertificateEntryDataV2;
            case precert_entry_v2: TimestampedCertificateEntryDataV2;
            case x509_sct_v2: SignedCertificateTimestampDataV2;
            case precert_sct_v2: SignedCertificateTimestampDataV2;
            case signed_tree_head_v2: SignedTreeHeadDataV2;
            case consistency_proof_v2: ConsistencyProofDataV2;
            case inclusion_proof_v2: InclusionProofDataV2;
        } data;
    } TransItem;
</pre><a href="#section-4.5-2" class="pilcrow">¶</a>
</div>
<p id="section-4.5-3"><code>versioned_type</code> is a value from the IANA registry in <a href="#versioned_trans_types" class="xref">Section 10.2.3</a>
that identifies the type of the encapsulated data structure and the earliest
version of this protocol to which it conforms. This document is v2.<a href="#section-4.5-3" class="pilcrow">¶</a></p>
<p id="section-4.5-4"><code>data</code> is the encapsulated data structure. The various structures named with the
<code>DataV2</code> suffix are defined in later sections of this document.<a href="#section-4.5-4" class="pilcrow">¶</a></p>
<p id="section-4.5-5">Note that <code>VersionedTransType</code> combines the v1 type enumerations
<code>Version</code>, <code>LogEntryType</code>, <code>SignatureType</code>, and <code>MerkleLeafType</code> <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span>. Note also that
v1 did not define <code>TransItem</code>, but this document provides guidelines (see
<a href="#v1_coexistence" class="xref">Appendix A</a>) on how v2 implementations can coexist with v1
implementations.<a href="#section-4.5-5" class="pilcrow">¶</a></p>
<p id="section-4.5-6">Future versions of this protocol may reuse <code>VersionedTransType</code> values defined
in this document as long as the corresponding data structures are not modified
and may add new <code>VersionedTransType</code> values for new or modified data structures.<a href="#section-4.5-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="log-artifact-extensions">
<section id="section-4.6">
        <h3 id="name-log-artifact-extensions">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-log-artifact-extensions" class="section-name selfRef">Log Artifact Extensions</a>
        </h3>
<div id="section-4.6-1">
<pre class="lang-tls-presentation sourcecode">
    enum {
        reserved(65535)
    } ExtensionType;

    struct {
        ExtensionType extension_type;
        opaque extension_data&lt;0..2^16-1&gt;;
    } Extension;
</pre><a href="#section-4.6-1" class="pilcrow">¶</a>
</div>
<p id="section-4.6-2">The <code>Extension</code> structure provides a generic extensibility for log artifacts,
including SCTs (<a href="#sct" class="xref">Section 4.8</a>) and STHs
(<a href="#sth" class="xref">Section 4.10</a>). The interpretation of the <code>extension_data</code> field is determined solely
by the value of the <code>extension_type</code> field.<a href="#section-4.6-2" class="pilcrow">¶</a></p>
<p id="section-4.6-3">This document does not define any extensions, but it does establish a registry
for future <code>ExtensionType</code> values (see <a href="#log_artifact_extension_registry" class="xref">Section 10.2.4</a>).
Each document that registers a new <code>ExtensionType</code> must specify the context in
which it may be used (e.g., SCT, STH, or both) and describe how to interpret the
corresponding <code>extension_data</code>.<a href="#section-4.6-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tree_leaves">
<section id="section-4.7">
        <h3 id="name-merkle-tree-leaves">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-merkle-tree-leaves" class="section-name selfRef">Merkle Tree Leaves</a>
        </h3>
<p id="section-4.7-1">The leaves of a log's Merkle Tree correspond to the log's entries (see
<a href="#log_entries" class="xref">Section 4.3</a>). Each leaf is the leaf hash (<a href="#mht" class="xref">Section 2.1</a>) of a <code>TransItem</code>
structure of type <code>x509_entry_v2</code> or <code>precert_entry_v2</code>, which encapsulates a
<code>TimestampedCertificateEntryDataV2</code> structure. Note that leaf hashes are
calculated as <code>HASH(0x00 || TransItem)</code>, where the hash algorithm is one of the
log's parameters.<a href="#section-4.7-1" class="pilcrow">¶</a></p>
<div id="section-4.7-2">
<pre class="lang-tls-presentation sourcecode">
    opaque TBSCertificate&lt;1..2^24-1&gt;;

    struct {
        uint64 timestamp;
        opaque issuer_key_hash&lt;32..2^8-1&gt;;
        TBSCertificate tbs_certificate;
        Extension sct_extensions&lt;0..2^16-1&gt;;
    } TimestampedCertificateEntryDataV2;
</pre><a href="#section-4.7-2" class="pilcrow">¶</a>
</div>
<p id="section-4.7-3"><code>timestamp</code> is the date and time at which the certificate or precertificate
 was accepted by the log, in the form of a 64-bit unsigned number of milliseconds
 elapsed since the Unix Epoch (1 January 1970 00:00:00 UTC -- see <span>[<a href="#UNIXTIME" class="xref">UNIXTIME</a>]</span>),
 ignoring leap seconds, in network byte order. Note that the leaves of a log's
 Merkle Tree are not required to be in strict chronological order.<a href="#section-4.7-3" class="pilcrow">¶</a></p>
<p id="section-4.7-4"><code>issuer_key_hash</code> is the HASH of the public key of the CA that issued the
certificate or precertificate, calculated over the DER encoding of the key
represented as SubjectPublicKeyInfo <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span>. This is needed to bind the CA to
the certificate or precertificate, making it impossible for the corresponding
SCT to be valid for any other certificate or precertificate whose TBSCertificate
matches <code>tbs_certificate</code>. The length of the <code>issuer_key_hash</code> <span class="bcp14">MUST</span> match
HASH_SIZE.<a href="#section-4.7-4" class="pilcrow">¶</a></p>
<p id="section-4.7-5"><code>tbs_certificate</code> is the DER-encoded TBSCertificate from the submission.
 (Note that a precertificate's TBSCertificate can be reconstructed from the
 corresponding certificate, as described in <a href="#reconstructing_tbscertificate" class="xref">Section 8.1.2</a>).<a href="#section-4.7-5" class="pilcrow">¶</a></p>
<p id="section-4.7-6"><code>sct_extensions</code> is byte-for-byte identical to the SCT extensions of the
 corresponding SCT.<a href="#section-4.7-6" class="pilcrow">¶</a></p>
<p id="section-4.7-7">The type of the <code>TransItem</code> corresponds to the value of the <code>type</code> parameter
supplied in the <a href="#submit-entry" class="xref">Section 5.1</a> call.<a href="#section-4.7-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sct">
<section id="section-4.8">
        <h3 id="name-signed-certificate-timestam">
<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-signed-certificate-timestam" class="section-name selfRef">Signed Certificate Timestamp (SCT)</a>
        </h3>
<p id="section-4.8-1">An SCT is a <code>TransItem</code> structure of type <code>x509_sct_v2</code> or <code>precert_sct_v2</code>,
which encapsulates a <code>SignedCertificateTimestampDataV2</code> structure:<a href="#section-4.8-1" class="pilcrow">¶</a></p>
<div id="section-4.8-2">
<pre class="lang-tls-presentation sourcecode">
    struct {
        LogID log_id;
        uint64 timestamp;
        Extension sct_extensions&lt;0..2^16-1&gt;;
        opaque signature&lt;1..2^16-1&gt;;
    } SignedCertificateTimestampDataV2;
</pre><a href="#section-4.8-2" class="pilcrow">¶</a>
</div>
<p id="section-4.8-3"><code>log_id</code> is this log's unique ID, encoded in an opaque vector, as described
 in <a href="#log_id" class="xref">Section 4.4</a>.<a href="#section-4.8-3" class="pilcrow">¶</a></p>
<p id="section-4.8-4"><code>timestamp</code> is equal to the timestamp from the corresponding
 <code>TimestampedCertificateEntryDataV2</code> structure.<a href="#section-4.8-4" class="pilcrow">¶</a></p>
<p id="section-4.8-5"><code>sct_extensions</code> is a vector of 0 or more SCT extensions. This vector
 <span class="bcp14">MUST NOT</span> include more than one extension with the same
 <code>extension_type</code>. The
 extensions in the vector <span class="bcp14">MUST</span> be ordered by the value of the
 <code>extension_type</code> field, smallest value first.
 All SCT extensions are similar to noncritical X.509v3 extensions (i.e.,
 the <code>mustUnderstand</code> field is not set), and a recipient <span class="bcp14">SHOULD</span>
 ignore any extension it does not understand.
 Furthermore, an implementation <span class="bcp14">MAY</span> choose to ignore any extension(s)
 that it does understand.<a href="#section-4.8-5" class="pilcrow">¶</a></p>
<p id="section-4.8-6"><code>signature</code> is computed over a <code>TransItem</code> structure of type
 <code>x509_entry_v2</code> or <code>precert_entry_v2</code> (see <a href="#tree_leaves" class="xref">Section 4.7</a>) using the signature algorithm
 declared in the log's parameters (see <a href="#log_parameters" class="xref">Section 4.1</a>).<a href="#section-4.8-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tree_head">
<section id="section-4.9">
        <h3 id="name-merkle-tree-head">
<a href="#section-4.9" class="section-number selfRef">4.9. </a><a href="#name-merkle-tree-head" class="section-name selfRef">Merkle Tree Head</a>
        </h3>
<p id="section-4.9-1">The log stores information about its Merkle Tree in a <code>TreeHeadDataV2</code>:<a href="#section-4.9-1" class="pilcrow">¶</a></p>
<div id="section-4.9-2">
<pre class="lang-tls-presentation sourcecode">
    opaque NodeHash&lt;32..2^8-1&gt;;

    struct {
        uint64 timestamp;
        uint64 tree_size;
        NodeHash root_hash;
        Extension sth_extensions&lt;0..2^16-1&gt;;
    } TreeHeadDataV2;
</pre><a href="#section-4.9-2" class="pilcrow">¶</a>
</div>
<p id="section-4.9-3">The length of NodeHash <span class="bcp14">MUST</span> match HASH_SIZE of the log.<a href="#section-4.9-3" class="pilcrow">¶</a></p>
<p id="section-4.9-4"><code>timestamp</code> is the current date and time, using the format defined in
<a href="#tree_leaves" class="xref">Section 4.7</a>.<a href="#section-4.9-4" class="pilcrow">¶</a></p>
<p id="section-4.9-5"><code>tree_size</code> is the number of entries currently in the log's Merkle Tree.<a href="#section-4.9-5" class="pilcrow">¶</a></p>
<p id="section-4.9-6"><code>root_hash</code> is the root of the Merkle Tree.<a href="#section-4.9-6" class="pilcrow">¶</a></p>
<p id="section-4.9-7"><code>sth_extensions</code> is a vector of 0 or more STH extensions. This vector <span class="bcp14">MUST NOT</span>
include more than one extension with the same <code>extension_type</code>. The
extensions in the vector <span class="bcp14">MUST</span> be ordered by the value of the
<code>extension_type</code> field, smallest value first. If an implementation sees an
extension that it does not understand, it <span class="bcp14">SHOULD</span> ignore that extension.
Furthermore, an implementation <span class="bcp14">MAY</span> choose to ignore any extension(s) that it
does understand.<a href="#section-4.9-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="sth">
<section id="section-4.10">
        <h3 id="name-signed-tree-head-sth">
<a href="#section-4.10" class="section-number selfRef">4.10. </a><a href="#name-signed-tree-head-sth" class="section-name selfRef">Signed Tree Head (STH)</a>
        </h3>
<p id="section-4.10-1">Periodically, each log <span class="bcp14">SHOULD</span> sign its current tree head
 information (see <a href="#tree_head" class="xref">Section 4.9</a>) to produce an STH. When
 a client requests a log's latest STH (see
 <a href="#get-sth" class="xref">Section 5.2</a>), the log <span class="bcp14">MUST</span> return an STH
 that is no older than the log's MMD.
 However, since STHs could be used to mark individual clients (by producing a new
 STH for each query), a log <span class="bcp14">MUST NOT</span> produce STHs more frequently than
 its parameters declare (see <a href="#log_parameters" class="xref">Section 4.1</a>). In
 general, there is no need to
 produce a new STH unless there are new entries in the log; however, in the event
 that a log does not accept any submissions during an MMD period, the log
 <span class="bcp14">MUST</span> sign the same Merkle Tree Hash with a fresh timestamp.<a href="#section-4.10-1" class="pilcrow">¶</a></p>
<p id="section-4.10-2">An STH is a <code>TransItem</code> structure of type <code>signed_tree_head_v2</code>,
 which encapsulates a <code>SignedTreeHeadDataV2</code> structure:<a href="#section-4.10-2" class="pilcrow">¶</a></p>
<div id="section-4.10-3">
<pre class="lang-tls-presentation sourcecode">
    struct {
        LogID log_id;
        TreeHeadDataV2 tree_head;
        opaque signature&lt;1..2^16-1&gt;;
    } SignedTreeHeadDataV2;
</pre><a href="#section-4.10-3" class="pilcrow">¶</a>
</div>
<p id="section-4.10-4"><code>log_id</code> is this log's unique ID encoded in an opaque vector, as described
 in <a href="#log_id" class="xref">Section 4.4</a>.<a href="#section-4.10-4" class="pilcrow">¶</a></p>
<p id="section-4.10-5">The <code>timestamp</code> in <code>tree_head</code> <span class="bcp14">MUST</span> be at least as
 recent as the most recent SCT
 timestamp in the tree. Each subsequent timestamp <span class="bcp14">MUST</span> be more recent
 than the timestamp of the previous update.<a href="#section-4.10-5" class="pilcrow">¶</a></p>
<p id="section-4.10-6"><code>tree_head</code> contains the latest tree head information (see <a href="#tree_head" class="xref">Section 4.9</a>).<a href="#section-4.10-6" class="pilcrow">¶</a></p>
<p id="section-4.10-7"><code>signature</code> is computed over the <code>tree_head</code> field using the signature algorithm
declared in the log's parameters (see <a href="#log_parameters" class="xref">Section 4.1</a>).<a href="#section-4.10-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="merkle-consistency-proofs">
<section id="section-4.11">
        <h3 id="name-merkle-consistency-proofs-2">
<a href="#section-4.11" class="section-number selfRef">4.11. </a><a href="#name-merkle-consistency-proofs-2" class="section-name selfRef">Merkle Consistency Proofs</a>
        </h3>
<p id="section-4.11-1">To prepare a Merkle consistency proof for distribution to clients, the log
produces a <code>TransItem</code> structure of type <code>consistency_proof_v2</code>, which
encapsulates a <code>ConsistencyProofDataV2</code> structure:<a href="#section-4.11-1" class="pilcrow">¶</a></p>
<div id="section-4.11-2">
<pre class="lang-tls-presentation sourcecode">
    struct {
        LogID log_id;
        uint64 tree_size_1;
        uint64 tree_size_2;
        NodeHash consistency_path&lt;0..2^16-1&gt;;
    } ConsistencyProofDataV2;
</pre><a href="#section-4.11-2" class="pilcrow">¶</a>
</div>
<p id="section-4.11-3"><code>log_id</code> is this log's unique ID encoded in an opaque vector, as described
 in <a href="#log_id" class="xref">Section 4.4</a>.<a href="#section-4.11-3" class="pilcrow">¶</a></p>
<p id="section-4.11-4"><code>tree_size_1</code> is the size of the older tree.<a href="#section-4.11-4" class="pilcrow">¶</a></p>
<p id="section-4.11-5"><code>tree_size_2</code> is the size of the newer tree.<a href="#section-4.11-5" class="pilcrow">¶</a></p>
<p id="section-4.11-6"><code>consistency_path</code> is a vector of Merkle Tree nodes proving the consistency
 of two STHs, as described in <a href="#consistency" class="xref">Section 2.1.4</a>.<a href="#section-4.11-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="merkle-inclusion-proofs">
<section id="section-4.12">
        <h3 id="name-merkle-inclusion-proofs-2">
<a href="#section-4.12" class="section-number selfRef">4.12. </a><a href="#name-merkle-inclusion-proofs-2" class="section-name selfRef">Merkle Inclusion Proofs</a>
        </h3>
<p id="section-4.12-1">To prepare a Merkle inclusion proof for distribution to clients, the log
produces a <code>TransItem</code> structure of type <code>inclusion_proof_v2</code>, which
encapsulates an <code>InclusionProofDataV2</code> structure:<a href="#section-4.12-1" class="pilcrow">¶</a></p>
<div id="section-4.12-2">
<pre class="lang-tls-presentation sourcecode">
    struct {
        LogID log_id;
        uint64 tree_size;
        uint64 leaf_index;
        NodeHash inclusion_path&lt;0..2^16-1&gt;;
    } InclusionProofDataV2;
</pre><a href="#section-4.12-2" class="pilcrow">¶</a>
</div>
<p id="section-4.12-3"><code>log_id</code> is this log's unique ID encoded in an opaque vector, as described
 in <a href="#log_id" class="xref">Section 4.4</a>.<a href="#section-4.12-3" class="pilcrow">¶</a></p>
<p id="section-4.12-4"><code>tree_size</code> is the size of the tree on which this inclusion proof is
 based.<a href="#section-4.12-4" class="pilcrow">¶</a></p>
<p id="section-4.12-5"><code>leaf_index</code> is the 0-based index of the log entry corresponding to this
inclusion proof.<a href="#section-4.12-5" class="pilcrow">¶</a></p>
<p id="section-4.12-6"><code>inclusion_path</code> is a vector of Merkle Tree nodes proving the inclusion of the
chosen certificate or precertificate, as described in <a href="#merkle_inclusion_proof" class="xref">Section 2.1.3</a>.<a href="#section-4.12-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="log_shutdown">
<section id="section-4.13">
        <h3 id="name-shutting-down-a-log">
<a href="#section-4.13" class="section-number selfRef">4.13. </a><a href="#name-shutting-down-a-log" class="section-name selfRef">Shutting Down a Log</a>
        </h3>
<p id="section-4.13-1">Log operators may decide to shut down a log for various reasons, such as
deprecation of the signature algorithm. If there are entries in the log for
certificates that have not yet expired, simply making TLS clients stop
recognizing that log will have the effect of invalidating SCTs from that log.
In order to avoid that, the following actions <span class="bcp14">SHOULD</span> be taken:<a href="#section-4.13-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.13-2.1">Make it known to clients and monitors that the log will be frozen.
   This is not part of the API, so it will have to be done via a relevant
   out-of-band mechanism.<a href="#section-4.13-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.13-2.2">Stop accepting new submissions (the error code "shutdown" should be returned
   for such requests).<a href="#section-4.13-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.13-2.3">Once MMD from the last accepted submission has passed and all pending
   submissions are incorporated, issue a final STH and publish it as one of the
   log's parameters. Having an STH with a timestamp that is after the MMD has
   passed from the last SCT issuance allows clients to audit this log regularly
   without special handling for the final STH. At this point, the log's private
   key is no longer needed and can be destroyed.<a href="#section-4.13-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.13-2.4">Keep the log running until the certificates in all of its entries have expired
   or exist in other logs (this can be determined by scanning other logs or
   connecting to domains mentioned in the certificates and inspecting the SCTs
   served).<a href="#section-4.13-2.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
</section>
</div>
<div id="client_messages">
<section id="section-5">
      <h2 id="name-log-client-messages">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-log-client-messages" class="section-name selfRef">Log Client Messages</a>
      </h2>
<p id="section-5-1">Messages are sent as HTTPS GET or POST requests. Parameters for POSTs and all
responses are encoded as JavaScript Object Notation (JSON) objects <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span>.
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" <span>[<a href="#HTML401" class="xref">HTML401</a>]</span>. Binary data is base64 encoded according to
<span><a href="https://www.rfc-editor.org/rfc/rfc4648#section-4" class="relref">Section 4</a> of [<a href="#RFC4648" class="xref">RFC4648</a>]</span>, as specified
in the individual messages.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">Clients are configured with a log's base URL, which is one of the log's
parameters. Clients construct URLs for requests by appending suffixes to this
base URL. This structure places some degree of restriction on how log operators
can deploy these services, as noted in <span>[<a href="#RFC8820" class="xref">RFC8820</a>]</span>. However, operational
experience with version 1 of this protocol has not indicated that these
restrictions are a problem in practice.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">Note that JSON objects and URL parameters may contain fields not specified here
to allow for experimentation. Any fields that are not understood <span class="bcp14">SHOULD</span>
be ignored.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">In practice, log servers may include multiple front-end machines. Since it is
impractical to keep these machines in perfect sync, errors that are 
caused by skew between the machines may occur. Where such errors are possible, the
front end will return additional information (as specified below), making it
possible for clients to make progress, if progress is possible. Front ends <span class="bcp14">MUST</span>
only serve data that is free of gaps (that is, for example, no front end will
respond with an STH unless it is also able to prove consistency from all log
entries logged within that STH).<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">For example, when a consistency proof between two STHs is requested, the
front end reached may not yet be aware of one or both STHs. In the case where it
is unaware of both, it will return the latest STH it is aware of. Where it is
aware of the first but not the second, it will return the latest STH it is aware
of and a consistency proof from the first STH to the returned STH. The case
where it knows the second but not the first should not arise (see the "no gaps"
requirement above).<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">If the log is unable to process a client's request, it <span class="bcp14">MUST</span> return an HTTP
response code of 4xx/5xx (see <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span>), and, in place of the responses
outlined in the subsections below, the body <span class="bcp14">SHOULD</span> be a JSON problem details
object (see <span><a href="https://www.rfc-editor.org/rfc/rfc7807#section-3" class="relref">Section 3</a> of [<a href="#RFC7807" class="xref">RFC7807</a>]</span>) containing:<a href="#section-5-6" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5-7">
        <dt id="section-5-7.1">type:</dt>
        <dd style="margin-left: 1.5em" id="section-5-7.2">A URN reference identifying the problem. To facilitate automated response
 to errors, this document defines a set of standard tokens for use in the
 <code>type</code> field within the URN namespace of: "urn:ietf:params:trans:error:".<a href="#section-5-7.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-5-7.3">detail:</dt>
        <dd style="margin-left: 1.5em" id="section-5-7.4">A human-readable string describing the error that prevented the log from
 processing the request, ideally with sufficient detail to enable the error to
 be rectified.<a href="#section-5-7.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-5-8">For example, in response to a request of
<code>&lt;Base URL&gt;/ct/v2/get-entries?start=100&amp;end=99</code>, the log would return a
<code>400 Bad Request</code> response code with a body similar to the following:<a href="#section-5-8" class="pilcrow">¶</a></p>
<div id="section-5-9">
<pre class="lang-json sourcecode">
    {
        "type": "urn:ietf:params:trans:error:endBeforeStart",
        "detail": "'start' cannot be greater than 'end'"
    }
</pre><a href="#section-5-9" class="pilcrow">¶</a>
</div>
<p id="section-5-10">Most error types are specific to the type of request and are defined in the
respective subsections below. The one exception is the "malformed" error type,
which indicates that the log server could not parse the client's request because
it did not comply with this document:<a href="#section-5-10" class="pilcrow">¶</a></p>
<table class="center" id="table-1">
        <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">type</th>
            <th class="text-left" rowspan="1" colspan="1">detail</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">malformed</td>
            <td class="text-left" rowspan="1" colspan="1">The request could not be parsed.</td>
          </tr>
        </tbody>
      </table>
<p id="section-5-12">Clients <span class="bcp14">SHOULD</span> treat <code>500 Internal Server Error</code> and <code>503
      Service Unavailable</code>
      responses as transient failures and <span class="bcp14">MAY</span> retry the same request without
      modification at a later date. Note that in the case of a 503 response, the log 
      <span class="bcp14">MAY</span> include a <code>Retry-After</code> header field per <span>[<a href="#RFC7231" class="xref">RFC7231</a>]</span> in
      order to request a minimum time for the client to wait before retrying the request.
      In the absence of this header field, this document does not specify a minimum.<a href="#section-5-12" class="pilcrow">¶</a></p>
<p id="section-5-13">Clients <span class="bcp14">SHOULD</span> treat any 4xx error as a problem with the request and
      not attempt to resubmit without some modification to the request. The full
      status code <span class="bcp14">MAY</span> provide additional details.<a href="#section-5-13" class="pilcrow">¶</a></p>
<p id="section-5-14">This document deliberately does not provide more specific guidance
      on the use of HTTP status codes.<a href="#section-5-14" class="pilcrow">¶</a></p>
<div id="submit-entry">
<section id="section-5.1">
        <h3 id="name-submit-entry-to-log">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-submit-entry-to-log" class="section-name selfRef">Submit Entry to Log</a>
        </h3>
<p id="section-5.1-1">POST &lt;Base URL&gt;/ct/v2/submit-entry<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.1-2">
          <dt id="section-5.1-2.1">Inputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-2.2">
            <span class="break"></span><dl class="dlParallel" id="section-5.1-2.2.1">
              <dt id="section-5.1-2.2.1.1">submission:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-2.2.1.2">The base64-encoded certificate or precertificate.<a href="#section-5.1-2.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.1-2.2.1.3">type:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-2.2.1.4">The <code>VersionedTransType</code> integer value that indicates the type of the
       <code>submission</code>: 1 for <code>x509_entry_v2</code> or 2 for
       <code>precert_entry_v2</code>.<a href="#section-5.1-2.2.1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.1-2.2.1.5">chain:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-2.2.1.6">An array of zero or more JSON strings,
       each of which is a base64-encoded CA certificate. The first element
       is the certifier of the <code>submission</code>, the second certifies the first,
       etc. The last element of <code>chain</code> (or, if <code>chain</code> is an empty
       array, the <code>submission</code>) is certified by an accepted trust anchor.<a href="#section-5.1-2.2.1.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-5.1-2.3">Outputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.1-2.4">
            <span class="break"></span><dl class="dlParallel" id="section-5.1-2.4.1">
              <dt id="section-5.1-2.4.1.1">sct:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-2.4.1.2">
                <p id="section-5.1-2.4.1.2.1">A base64-encoded <code>TransItem</code> of type <code>x509_sct_v2</code> or
       <code>precert_sct_v2</code>, signed by this log, that corresponds to the
       <code>submission</code>.<a href="#section-5.1-2.4.1.2.1" class="pilcrow">¶</a></p>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-5.1-2.4.2">If the submitted entry is immediately appended to (or already exists in) this
       log's tree, then the log <span class="bcp14">SHOULD</span> also output:<a href="#section-5.1-2.4.2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.1-2.4.3">
              <dt id="section-5.1-2.4.3.1">sth:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-2.4.3.2">A base64-encoded <code>TransItem</code> of type <code>signed_tree_head_v2</code>
       signed by this log.<a href="#section-5.1-2.4.3.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.1-2.4.3.3">inclusion:</dt>
              <dd style="margin-left: 1.5em" id="section-5.1-2.4.3.4">A base64-encoded <code>TransItem</code> of type <code>inclusion_proof_v2</code>
       whose <code>inclusion_path</code> array of Merkle Tree nodes proves the inclusion
       of the <code>submission</code> in the returned <code>sth</code>.<a href="#section-5.1-2.4.3.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.1-3">Error codes:<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<table class="center" id="table-2">
          <caption><a href="#table-2" class="selfRef">Table 2</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">type</th>
              <th class="text-left" rowspan="1" colspan="1">detail</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">badSubmission</td>
              <td class="text-left" rowspan="1" colspan="1">
                <code>submission</code> is neither a valid certificate nor a valid precertificate.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">badType</td>
              <td class="text-left" rowspan="1" colspan="1">
                <code>type</code> is neither 1 nor 2.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">badChain</td>
              <td class="text-left" rowspan="1" colspan="1">The first element of <code>chain</code> is not the certifier of the <code>submission</code>, or the second element does not certify the first, etc.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">badCertificate</td>
              <td class="text-left" rowspan="1" colspan="1">One or more certificates in <code>chain</code> are not valid (e.g., not properly encoded).</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">unknownAnchor</td>
              <td class="text-left" rowspan="1" colspan="1">The last element of <code>chain</code> (or, if <code>chain</code> is an empty array, the <code>submission</code>) is not, nor is it certified by, an accepted trust anchor.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">shutdown</td>
              <td class="text-left" rowspan="1" colspan="1">The log is no longer accepting submissions.</td>
            </tr>
          </tbody>
        </table>
<p id="section-5.1-5">If the version of <code>sct</code> is not v2, then a v2 client may be unable to verify the
signature. It <span class="bcp14">MUST NOT</span> construe this as an error. This is to avoid forcing an
upgrade of compliant v2 clients that do not use the returned SCTs.<a href="#section-5.1-5" class="pilcrow">¶</a></p>
<p id="section-5.1-6">If a log detects bad encoding in a chain that otherwise verifies correctly, then
the log <span class="bcp14">MUST</span> either log the certificate or return the "badCertificate" error.
If the certificate is logged, an SCT <span class="bcp14">MUST</span> be issued. Logging the certificate is
useful, because monitors (<a href="#monitor" class="xref">Section 8.2</a>) can then detect these encoding errors,
which may be accepted by some TLS clients.<a href="#section-5.1-6" class="pilcrow">¶</a></p>
<p id="section-5.1-7">If <code>submission</code> is an accepted trust anchor whose certifier is neither an
accepted trust anchor nor the first element of <code>chain</code>, then the log <span class="bcp14">MUST</span> return
the "unknownAnchor" error. A log is not able to generate an SCT for a
submission if it
does not have access to the issuer's public key.<a href="#section-5.1-7" class="pilcrow">¶</a></p>
<p id="section-5.1-8">If the returned <code>sct</code> is intended to be provided to TLS clients, then <code>sth</code> and
<code>inclusion</code> (if returned) <span class="bcp14">SHOULD</span> also be provided to TLS clients. For
example, if
<code>type</code> was 2 (indicating <code>precert_sct_v2</code>), then all three <code>TransItem</code>s could be
embedded in the certificate.<a href="#section-5.1-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="get-sth">
<section id="section-5.2">
        <h3 id="name-retrieve-latest-sth">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-retrieve-latest-sth" class="section-name selfRef">Retrieve Latest STH</a>
        </h3>
<p id="section-5.2-1">GET &lt;Base URL&gt;/ct/v2/get-sth<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">No inputs.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.2-3">
          <dt id="section-5.2-3.1">Outputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.2-3.2">
            <span class="break"></span><dl class="dlParallel" id="section-5.2-3.2.1">
              <dt id="section-5.2-3.2.1.1">sth:</dt>
              <dd style="margin-left: 1.5em" id="section-5.2-3.2.1.2">A base64-encoded <code>TransItem</code> of type <code>signed_tree_head_v2</code>
       signed by this log that is no older than the log's MMD.<a href="#section-5.2-3.2.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="get-sth-consistency">
<section id="section-5.3">
        <h3 id="name-retrieve-merkle-consistency">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-retrieve-merkle-consistency" class="section-name selfRef">Retrieve Merkle Consistency Proof between Two STHs</a>
        </h3>
<p id="section-5.3-1">GET &lt;Base URL&gt;/ct/v2/get-sth-consistency<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.3-2">
          <dt id="section-5.3-2.1">Inputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-2.2">
            <span class="break"></span><dl class="dlParallel" id="section-5.3-2.2.1">
              <dt id="section-5.3-2.2.1.1">first:</dt>
              <dd style="margin-left: 1.5em" id="section-5.3-2.2.1.2">The <code>tree_size</code> of the older tree, in decimal.<a href="#section-5.3-2.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.3-2.2.1.3">second:</dt>
              <dd style="margin-left: 1.5em" id="section-5.3-2.2.1.4">The <code>tree_size</code> of the newer tree, in decimal (optional).<a href="#section-5.3-2.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-5.3-2.2.2">Both tree sizes must be from existing v2 STHs. However, because of skew, the
   receiving front end may not know one or both of the existing STHs. If both are
   known, then only the <code>consistency</code> output is returned. If the first is known
   but the second is not (or has been omitted), then the latest known STH is
   returned, along with a consistency proof between the first STH and the latest.
   If neither are known, then the latest known STH is returned without a
   consistency proof.<a href="#section-5.3-2.2.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlNewline" id="section-5.3-3">
          <dt id="section-5.3-3.1">Outputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.3-3.2">
            <span class="break"></span><dl class="dlParallel" id="section-5.3-3.2.1">
              <dt id="section-5.3-3.2.1.1">consistency:</dt>
              <dd style="margin-left: 1.5em" id="section-5.3-3.2.1.2">A base64-encoded <code>TransItem</code> of type <code>consistency_proof_v2</code>
       whose <code>tree_size_1</code> <span class="bcp14">MUST</span> match the <code>first</code> input.
       If the <code>sth</code> output is omitted,
       then <code>tree_size_2</code> <span class="bcp14">MUST</span> match the <code>second</code> input.
       If <code>first</code> and <code>second</code> are equal and correspond to a known STH,
       the returned consistency proof <span class="bcp14">MUST</span> be empty (a
       <code>consistency_path</code> array with zero elements).<a href="#section-5.3-3.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.3-3.2.1.3">sth:</dt>
              <dd style="margin-left: 1.5em" id="section-5.3-3.2.1.4">A base64-encoded <code>TransItem</code> of type <code>signed_tree_head_v2</code>,
       signed by this log.<a href="#section-5.3-3.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-5.3-3.2.2">Note that no signature is required for the <code>consistency</code> output, as it is
   used to verify the consistency between two signed STHs.<a href="#section-5.3-3.2.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.3-4">Error codes:<a href="#section-5.3-4" class="pilcrow">¶</a></p>
<table class="center" id="table-3">
          <caption><a href="#table-3" class="selfRef">Table 3</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">type</th>
              <th class="text-left" rowspan="1" colspan="1">detail</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">firstUnknown</td>
              <td class="text-left" rowspan="1" colspan="1">
                <code>first</code> is before the latest known STH but is not from
       an existing STH.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">secondUnknown</td>
              <td class="text-left" rowspan="1" colspan="1">
                <code>second</code> is before the latest known STH but is not from
       an existing STH.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">secondBeforeFirst</td>
              <td class="text-left" rowspan="1" colspan="1">
                <code>second</code> is smaller than <code>first</code>.</td>
            </tr>
          </tbody>
        </table>
<p id="section-5.3-6">See <a href="#verify_consistency" class="xref">Section 2.1.4.2</a> for an outline of how to use the <code>consistency</code>
output.<a href="#section-5.3-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="get-proof-by-hash">
<section id="section-5.4">
        <h3 id="name-retrieve-merkle-inclusion-p">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-retrieve-merkle-inclusion-p" class="section-name selfRef">Retrieve Merkle Inclusion Proof from Log by Leaf Hash</a>
        </h3>
<p id="section-5.4-1">GET &lt;Base URL&gt;/ct/v2/get-proof-by-hash<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.4-2">
          <dt id="section-5.4-2.1">Inputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-2.2">
            <span class="break"></span><dl class="dlParallel" id="section-5.4-2.2.1">
              <dt id="section-5.4-2.2.1.1">hash:</dt>
              <dd style="margin-left: 1.5em" id="section-5.4-2.2.1.2">A base64-encoded v2 leaf hash.<a href="#section-5.4-2.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.4-2.2.1.3">tree_size:</dt>
              <dd style="margin-left: 1.5em" id="section-5.4-2.2.1.4">The <code>tree_size</code> of the tree on which to base the proof, in decimal.<a href="#section-5.4-2.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-5.4-2.2.2">The <code>hash</code> must be calculated as defined in <a href="#tree_leaves" class="xref">Section 4.7</a>. A v2 STH must
   exist for the <code>tree_size</code>.  Because of skew, the front end may not know
   the requested tree head. In that case, it will return the latest STH it knows, along
   with an inclusion proof to that STH. If the front end knows the requested tree head,
   then only <code>inclusion</code> is returned.<a href="#section-5.4-2.2.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<span class="break"></span><dl class="dlNewline" id="section-5.4-3">
          <dt id="section-5.4-3.1">Outputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.4-3.2">
            <span class="break"></span><dl class="dlParallel" id="section-5.4-3.2.1">
              <dt id="section-5.4-3.2.1.1">inclusion:</dt>
              <dd style="margin-left: 1.5em" id="section-5.4-3.2.1.2">A base64-encoded <code>TransItem</code> of type <code>inclusion_proof_v2</code>
       whose <code>inclusion_path</code> array of Merkle Tree nodes proves the inclusion
       of the certificate (as specified by the <code>hash</code> parameter) in the
       selected STH.<a href="#section-5.4-3.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.4-3.2.1.3">sth:</dt>
              <dd style="margin-left: 1.5em" id="section-5.4-3.2.1.4">A base64-encoded <code>TransItem</code> of type <code>signed_tree_head_v2</code>,
       signed by this log.<a href="#section-5.4-3.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-5.4-3.2.2">Note that no signature is required for the <code>inclusion</code> output, as it is
     used to verify inclusion in the selected STH, which is signed.<a href="#section-5.4-3.2.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.4-4">Error codes:<a href="#section-5.4-4" class="pilcrow">¶</a></p>
<table class="center" id="table-4">
          <caption><a href="#table-4" class="selfRef">Table 4</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">type</th>
              <th class="text-left" rowspan="1" colspan="1">detail</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">hashUnknown</td>
              <td class="text-left" rowspan="1" colspan="1">
                <code>hash</code> is not the hash of a known leaf (may be caused by skew or by a known certificate not yet merged).</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">treeSizeUnknown</td>
              <td class="text-left" rowspan="1" colspan="1">
                <code>hash</code> is before the latest known STH but is not from an existing STH.</td>
            </tr>
          </tbody>
        </table>
<p id="section-5.4-6">See <a href="#verify_inclusion" class="xref">Section 2.1.3.2</a> for an outline of how to use the <code>inclusion</code> output.<a href="#section-5.4-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="get-all-by-hash">
<section id="section-5.5">
        <h3 id="name-retrieve-merkle-inclusion-pr">
<a href="#section-5.5" class="section-number selfRef">5.5. </a><a href="#name-retrieve-merkle-inclusion-pr" class="section-name selfRef">Retrieve Merkle Inclusion Proof, STH, and Consistency Proof by Leaf Hash</a>
        </h3>
<p id="section-5.5-1">GET &lt;Base URL&gt;/ct/v2/get-all-by-hash<a href="#section-5.5-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.5-2">
          <dt id="section-5.5-2.1">Inputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.5-2.2">
            <span class="break"></span><dl class="dlParallel" id="section-5.5-2.2.1">
              <dt id="section-5.5-2.2.1.1">hash:</dt>
              <dd style="margin-left: 1.5em" id="section-5.5-2.2.1.2">A base64-encoded v2 leaf hash.<a href="#section-5.5-2.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.5-2.2.1.3">tree_size:</dt>
              <dd style="margin-left: 1.5em" id="section-5.5-2.2.1.4">The <code>tree_size</code> of the tree on which to base the proofs, in decimal.<a href="#section-5.5-2.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-5.5-2.2.2">The <code>hash</code> must be calculated as defined in <a href="#tree_leaves" class="xref">Section 4.7</a>. A v2 STH must exist for the <code>tree_size</code>.<a href="#section-5.5-2.2.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.5-3">Because of skew, the front end may not know the requested tree head or the
 requested hash, which leads to a number of cases:<a href="#section-5.5-3" class="pilcrow">¶</a></p>
<table class="center" id="table-5">
          <caption><a href="#table-5" class="selfRef">Table 5</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Case</th>
              <th class="text-left" rowspan="1" colspan="1">Response</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">latest STH &lt; requested tree head</td>
              <td class="text-left" rowspan="1" colspan="1">Return latest STH.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">latest STH &gt; requested tree head</td>
              <td class="text-left" rowspan="1" colspan="1">Return latest STH and a consistency proof between it and the requested tree head (see <a href="#get-sth-consistency" class="xref">Section 5.3</a>).</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">index of requested hash &lt; latest STH</td>
              <td class="text-left" rowspan="1" colspan="1">Return <code>inclusion</code>.</td>
            </tr>
          </tbody>
        </table>
<p id="section-5.5-5">Note that more than one case can be true; in which case, the returned data is
their union. It is also possible for none to be true; in which case, the
front end <span class="bcp14">MUST</span> return an empty response.<a href="#section-5.5-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.5-6">
          <dt id="section-5.5-6.1">Outputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.5-6.2">
            <span class="break"></span><dl class="dlParallel" id="section-5.5-6.2.1">
              <dt id="section-5.5-6.2.1.1">inclusion:</dt>
              <dd style="margin-left: 1.5em" id="section-5.5-6.2.1.2">A base64-encoded <code>TransItem</code> of type <code>inclusion_proof_v2</code>
       whose <code>inclusion_path</code> array of Merkle Tree nodes proves the inclusion
       of the certificate (as specified by the <code>hash</code> parameter) in the
       selected STH.<a href="#section-5.5-6.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.5-6.2.1.3">sth:</dt>
              <dd style="margin-left: 1.5em" id="section-5.5-6.2.1.4">A base64-encoded <code>TransItem</code> of type <code>signed_tree_head_v2</code>,
       signed by this log.<a href="#section-5.5-6.2.1.4" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.5-6.2.1.5">consistency:</dt>
              <dd style="margin-left: 1.5em" id="section-5.5-6.2.1.6">A base64-encoded <code>TransItem</code> of type <code>consistency_proof_v2</code>
       that proves the consistency of the requested tree head and the returned
       STH.<a href="#section-5.5-6.2.1.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-5.5-6.2.2">Note that no signature is required for the <code>inclusion</code> or
     <code>consistency</code> outputs, as they are used to verify inclusion in and
     consistency of signed STHs.<a href="#section-5.5-6.2.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.5-7">Errors are the same as in <a href="#get-proof-by-hash" class="xref">Section 5.4</a>.<a href="#section-5.5-7" class="pilcrow">¶</a></p>
<p id="section-5.5-8">See <a href="#verify_inclusion" class="xref">Section 2.1.3.2</a> for an outline of how to use the <code>inclusion</code> output,
and see <a href="#verify_consistency" class="xref">Section 2.1.4.2</a> for an outline of how to use the <code>consistency</code>
output.<a href="#section-5.5-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="get-entries">
<section id="section-5.6">
        <h3 id="name-retrieve-entries-and-sth-fr">
<a href="#section-5.6" class="section-number selfRef">5.6. </a><a href="#name-retrieve-entries-and-sth-fr" class="section-name selfRef">Retrieve Entries and STH from Log</a>
        </h3>
<p id="section-5.6-1">GET &lt;Base URL&gt;/ct/v2/get-entries<a href="#section-5.6-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.6-2">
          <dt id="section-5.6-2.1">Inputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-2.2">
            <span class="break"></span><dl class="dlParallel" id="section-5.6-2.2.1">
              <dt id="section-5.6-2.2.1.1">start:</dt>
              <dd style="margin-left: 1.5em" id="section-5.6-2.2.1.2">0-based index of first entry to retrieve, in decimal.<a href="#section-5.6-2.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.6-2.2.1.3">end:</dt>
              <dd style="margin-left: 1.5em" id="section-5.6-2.2.1.4">0-based index of last entry to retrieve, in decimal.<a href="#section-5.6-2.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
          <dd class="break"></dd>
<dt id="section-5.6-2.3">Outputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.6-2.4">
            <span class="break"></span><dl class="dlParallel" id="section-5.6-2.4.1">
              <dt id="section-5.6-2.4.1.1">entries:</dt>
              <dd style="margin-left: 1.5em" id="section-5.6-2.4.1.2">
                <p id="section-5.6-2.4.1.2.1">An array of objects, each consisting of:<a href="#section-5.6-2.4.1.2.1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-5.6-2.4.1.2.2">
                  <dt id="section-5.6-2.4.1.2.2.1">log_entry:</dt>
                  <dd style="margin-left: 1.5em" id="section-5.6-2.4.1.2.2.2">The base64-encoded <code>TransItem</code> structure of type
   <code>x509_entry_v2</code> or
   <code>precert_entry_v2</code> (see <a href="#log_entries" class="xref">Section 4.3</a>).<a href="#section-5.6-2.4.1.2.2.2" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-5.6-2.4.1.2.2.3">submitted_entry:</dt>
                  <dd style="margin-left: 1.5em" id="section-5.6-2.4.1.2.2.4">JSON object equivalent to inputs that were submitted to
   <code>submit-entry</code>, with the addition of the trust anchor to the
   <code>chain</code> field if the submission did not include it.<a href="#section-5.6-2.4.1.2.2.4" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-5.6-2.4.1.2.2.5">sct:</dt>
                  <dd style="margin-left: 1.5em" id="section-5.6-2.4.1.2.2.6">The base64-encoded <code>TransItem</code> of type <code>x509_sct_v2</code> or
   <code>precert_sct_v2</code>, corresponding to this log entry.<a href="#section-5.6-2.4.1.2.2.6" class="pilcrow">¶</a>
</dd>
                  <dd class="break"></dd>
<dt id="section-5.6-2.4.1.2.2.7">sth:</dt>
                  <dd style="margin-left: 1.5em" id="section-5.6-2.4.1.2.2.8">A base64-encoded <code>TransItem</code> of type
   <code>signed_tree_head_v2</code>, signed by this log.<a href="#section-5.6-2.4.1.2.2.8" class="pilcrow">¶</a>
</dd>
                <dd class="break"></dd>
</dl>
</dd>
            <dd class="break"></dd>
</dl>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-5.6-3">Note that this message is not signed -- the <code>entries</code> data can be verified by
constructing the Merkle Tree Hash corresponding to a retrieved STH. All leaves
<span class="bcp14">MUST</span> be v2. However, a compliant v2 client <span class="bcp14">MUST NOT</span> construe an unrecognized
<code>TransItem</code> type as an error. This means it may be unable to parse some entries,
but note that each client can inspect the entries it does recognize as well as
verify the integrity of the data by treating unrecognized leaves as opaque input
to the tree.<a href="#section-5.6-3" class="pilcrow">¶</a></p>
<p id="section-5.6-4">The <code>start</code> and <code>end</code> parameters <span class="bcp14">SHOULD</span> be within the range 0 &lt;= x &lt; <code>tree_size</code>,
as returned by <code>get-sth</code> in <a href="#get-sth" class="xref">Section 5.2</a>.<a href="#section-5.6-4" class="pilcrow">¶</a></p>
<p id="section-5.6-5">The <code>start</code> parameter <span class="bcp14">MUST</span> be less than or equal to the <code>end</code> parameter.<a href="#section-5.6-5" class="pilcrow">¶</a></p>
<p id="section-5.6-6">Each <code>submitted_entry</code> output parameter <span class="bcp14">MUST</span> include the trust anchor that the
log used to verify the <code>submission</code>, even if that trust anchor was not provided
to <code>submit-entry</code> (see <a href="#submit-entry" class="xref">Section 5.1</a>). If the <code>submission</code> does not certify
itself, then the first element of <code>chain</code> <span class="bcp14">MUST</span> be present and <span class="bcp14">MUST</span> certify the
<code>submission</code>.<a href="#section-5.6-6" class="pilcrow">¶</a></p>
<p id="section-5.6-7">Log servers <span class="bcp14">MUST</span> honor requests where 0 &lt;= <code>start</code> &lt; <code>tree_size</code> and <code>end</code> &gt;=
<code>tree_size</code> by returning a partial response covering only the valid entries in
the specified range. <code>end</code> &gt;= <code>tree_size</code> could be caused by skew. Note that the
following restriction may also apply:<a href="#section-5.6-7" class="pilcrow">¶</a></p>
<p id="section-5.6-8">Logs <span class="bcp14">MAY</span> restrict the number of entries that can be retrieved per <code>get-entries</code>
request. If a client requests more than the permitted number of entries, the log
<span class="bcp14">SHALL</span> return the maximum number of entries permissible. These entries <span class="bcp14">SHALL</span> be
sequential beginning with the entry specified by <code>start</code>.
Note that a limit on the number of entries is not immutable, and therefore
the restriction may be changed or lifted at any time and is not listed
with the other Log Parameters in <a href="#log_parameters" class="xref">Section 4.1</a>.<a href="#section-5.6-8" class="pilcrow">¶</a></p>
<p id="section-5.6-9">Because of skew, it is possible the log server will not have any entries between
<code>start</code> and <code>end</code>. In this case, it <span class="bcp14">MUST</span> return an empty <code>entries</code> array.<a href="#section-5.6-9" class="pilcrow">¶</a></p>
<p id="section-5.6-10">In any case, the log server <span class="bcp14">MUST</span> return the latest STH it knows about.<a href="#section-5.6-10" class="pilcrow">¶</a></p>
<p id="section-5.6-11">See <a href="#verify_hash" class="xref">Section 2.1.2</a> for an outline of how to use a complete list of <code>log_entry</code>
entries to verify the <code>root_hash</code>.<a href="#section-5.6-11" class="pilcrow">¶</a></p>
<p id="section-5.6-12">Error codes:<a href="#section-5.6-12" class="pilcrow">¶</a></p>
<table class="center" id="table-6">
          <caption><a href="#table-6" class="selfRef">Table 6</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">type</th>
              <th class="text-left" rowspan="1" colspan="1">detail</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">startUnknown</td>
              <td class="text-left" rowspan="1" colspan="1">
                <code>start</code> is greater than the number of entries in the Merkle Tree.</td>
            </tr>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">endBeforeStart</td>
              <td class="text-left" rowspan="1" colspan="1">
                <code>start</code> cannot be greater than <code>end</code>.</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
<div id="get-anchors">
<section id="section-5.7">
        <h3 id="name-retrieve-accepted-trust-anc">
<a href="#section-5.7" class="section-number selfRef">5.7. </a><a href="#name-retrieve-accepted-trust-anc" class="section-name selfRef">Retrieve Accepted Trust Anchors</a>
        </h3>
<p id="section-5.7-1">GET &lt;Base URL&gt;/ct/v2/get-anchors<a href="#section-5.7-1" class="pilcrow">¶</a></p>
<p id="section-5.7-2">No inputs.<a href="#section-5.7-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-5.7-3">
          <dt id="section-5.7-3.1">Outputs:</dt>
          <dd style="margin-left: 1.5em" id="section-5.7-3.2">
            <span class="break"></span><dl class="dlParallel" id="section-5.7-3.2.1">
              <dt id="section-5.7-3.2.1.1">certificates:</dt>
              <dd style="margin-left: 1.5em" id="section-5.7-3.2.1.2">An array of JSON strings, each of which
       is a base64-encoded CA certificate that is acceptable to the log.<a href="#section-5.7-3.2.1.2" class="pilcrow">¶</a>
</dd>
              <dd class="break"></dd>
<dt id="section-5.7-3.2.1.3">max_chain_length:</dt>
              <dd style="margin-left: 1.5em" id="section-5.7-3.2.1.4">If the server has chosen to limit the length of chains it accepts, this is
       the maximum number of certificates in the chain, in decimal. If there is no
       limit, this is omitted.<a href="#section-5.7-3.2.1.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
<p id="section-5.7-3.2.2">This data is not signed, and the protocol depends on the security guarantees
     of TLS to ensure correctness.<a href="#section-5.7-3.2.2" class="pilcrow">¶</a></p>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="tls_servers">
<section id="section-6">
      <h2 id="name-tls-servers">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-tls-servers" class="section-name selfRef">TLS Servers</a>
      </h2>
<p id="section-6-1">CT-using TLS servers <span class="bcp14">MUST</span> use at least one of the mechanisms described below
to present one or more SCTs from one or more logs to each TLS client during full
TLS handshakes, when requested by the client, where each SCT corresponds to the server certificate.
(Of course, a server can only send a TLS extension if the client has
specified it first.)
Servers
<span class="bcp14">SHOULD</span> also present corresponding inclusion proofs and STHs.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">A server can provide SCTs using
a TLS 1.3 extension (<span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.2" class="relref">Section 4.2</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>) with type <code>transparency_info</code>
(see <a href="#tls_transinfo_extension" class="xref">Section 6.5</a>). This mechanism allows TLS servers to
participate in CT without the cooperation of CAs, unlike the other two
mechanisms. It also allows SCTs and inclusion proofs to be updated on the fly.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">The server may also use an Online Certificate Status Protocol (OCSP)
<span>[<a href="#RFC6960" class="xref">RFC6960</a>]</span> response extension (see <a href="#ocsp_transinfo_extension" class="xref">Section 7.1.1</a>),
providing the OCSP response as part of the TLS handshake. Providing
a response during a TLS handshake is popularly known as "OCSP stapling".
For TLS
1.3, the information is encoded as an extension in the <code>status_request</code>
extension data; see <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2.1" class="relref">Section 4.4.2.1</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>. For TLS 1.2 <span>[<a href="#RFC5246" class="xref">RFC5246</a>]</span>, the information
is encoded in the <code>CertificateStatus</code> message; see <span><a href="https://www.rfc-editor.org/rfc/rfc6066#section-8" class="relref">Section 8</a> of [<a href="#RFC6066" class="xref">RFC6066</a>]</span>.  Using stapling also
allows SCTs and inclusion proofs to be updated on the fly.<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">CT information can also be encoded as an extension in the X.509v3 certificate
(see <a href="#cert_transinfo_extension" class="xref">Section 7.1.2</a>). This
mechanism allows the use of unmodified TLS servers, but the SCTs and inclusion
proofs cannot be updated on the fly. Since the logs from which the SCTs and
inclusion proofs originated won't necessarily be accepted by TLS clients for
the full lifetime of the certificate, there is a risk that TLS clients may
subsequently consider the certificate to be noncompliant. In such an event, one of
the other two mechanisms will need to be used to deliver CT information, or, if this is
not possible, the certificate will need to be reissued.<a href="#section-6-4" class="pilcrow">¶</a></p>
<div id="tls-client-authentication">
<section id="section-6.1">
        <h3 id="name-tls-client-authentication">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-tls-client-authentication" class="section-name selfRef">TLS Client Authentication</a>
        </h3>
<p id="section-6.1-1">This specification includes no description of how a TLS server can
use CT for TLS client certificates.
While this may be useful, it is not documented here for the following
reasons:<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.1-2.1">The greater security exposure is for clients to end up interacting with an
   illegitimate server.<a href="#section-6.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-2.2">In general, TLS client certificates are not expected to be submitted to
   CT logs, particularly those intended for general public use.<a href="#section-6.1-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.1-3">A future version could include such information.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="multiple-scts">
<section id="section-6.2">
        <h3 id="name-multiple-scts">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-multiple-scts" class="section-name selfRef">Multiple SCTs</a>
        </h3>
<p id="section-6.2-1">CT-using TLS servers <span class="bcp14">SHOULD</span> send SCTs from multiple logs because:<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2-2.1">The set of logs trusted by TLS clients is neither unified nor static; each
          client vendor may maintain an independent list of trusted logs, and, over time, new logs
          may become trusted and current logs may become distrusted.
   Note that client discovery, trust, and distrust of logs are expected to
   be handled out of band and are out of scope of this document.<a href="#section-6.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.2">If a CA and a log collude, it is possible to temporarily hide misissuance from
   clients. When a TLS client requires SCTs from multiple logs to be provided, it
   is more difficult to mount this attack.<a href="#section-6.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.3">If a log misbehaves or suffers a key compromise, a consequence may be that
   clients cease to trust it. Since the time an SCT may be in use can be
   considerable (several years is common in current practice when embedded in a
   certificate), including SCTs from multiple logs reduces the probability of the
   certificate being rejected by TLS clients.<a href="#section-6.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.4">TLS clients may have policies related to the above risks requiring TLS servers
   to present multiple SCTs. For example, at the time of writing, Chromium
   <span>[<a href="#Chromium.Log.Policy" class="xref">Chromium.Log.Policy</a>]</span> requires multiple SCTs to be
   presented with Extended Validation (EV)
   certificates in order for the EV indicator to be shown.<a href="#section-6.2-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.2-3">To select the logs from which to obtain SCTs, a TLS server can, for example,
examine the set of logs popular TLS clients accept and recognize.<a href="#section-6.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="transitemlist-structure">
<section id="section-6.3">
        <h3 id="name-transitemlist-structure">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-transitemlist-structure" class="section-name selfRef">TransItemList Structure</a>
        </h3>
<p id="section-6.3-1">Multiple SCTs, inclusion proofs, and indeed <code>TransItem</code> structures of any
 type are combined into a list as follows:<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<div id="section-6.3-2">
<pre class="lang-tls-presentation sourcecode">
      opaque SerializedTransItem&lt;1..2^16-1&gt;;

      struct {
          SerializedTransItem trans_item_list&lt;1..2^16-1&gt;;
      } TransItemList;
</pre><a href="#section-6.3-2" class="pilcrow">¶</a>
</div>
<p id="section-6.3-3">Here, <code>SerializedTransItem</code> is an opaque byte string that contains the
 serialized <code>TransItem</code> structure. This encoding ensures that TLS clients can
 decode each <code>TransItem</code> individually (so, for example, if there is a version
 upgrade, out-of-date clients can still parse old <code>TransItem</code> structures while
 skipping over new <code>TransItem</code> structures whose versions they don't
 understand).<a href="#section-6.3-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="presenting_transitems">
<section id="section-6.4">
        <h3 id="name-presenting-scts-inclusions-">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-presenting-scts-inclusions-" class="section-name selfRef">Presenting SCTs, Inclusions Proofs, and STHs</a>
        </h3>
<p id="section-6.4-1">In each <code>TransItemList</code> that is sent during a TLS handshake, the TLS
server <span class="bcp14">MUST</span> include a <code>TransItem</code> structure of type <code>x509_sct_v2</code> or
<code>precert_sct_v2</code>.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
<p id="section-6.4-2">Presenting inclusion proofs and STHs in the TLS handshake helps to protect the
client's privacy (see <a href="#fetching_inclusion_proofs" class="xref">Section 8.1.4</a>) and reduces load on log
servers. Therefore, if the TLS server can obtain them, it <span class="bcp14">SHOULD</span> also include
<code>TransItem</code>s of type <code>inclusion_proof_v2</code> and <code>signed_tree_head_v2</code> in the
<code>TransItemList</code>.<a href="#section-6.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="tls_transinfo_extension">
<section id="section-6.5">
        <h3 id="name-transparency_info-tls-exten">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-transparency_info-tls-exten" class="section-name selfRef">transparency_info TLS Extension</a>
        </h3>
<p id="section-6.5-1">Provided that a TLS client includes the <code>transparency_info</code> extension type in
the ClientHello and the TLS server supports the <code>transparency_info</code> extension:<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.5-2.1">The TLS server <span class="bcp14">MUST</span> verify that the received
   <code>extension_data</code> is empty.<a href="#section-6.5-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.5-2.2">The TLS server <span class="bcp14">MUST</span> construct a <code>TransItemList</code> of
   relevant <code>TransItem</code>s (see
   <a href="#presenting_transitems" class="xref">Section 6.4</a>), which
   <span class="bcp14">SHOULD</span> omit any <code>TransItem</code>s that are
   already embedded in the server certificate or the stapled OCSP response (see
   <a href="#x509v3_transinfo_extension" class="xref">Section 7.1</a>). If the constructed
   <code>TransItemList</code> is not
   empty, then the TLS server <span class="bcp14">MUST</span> include the
   <code>transparency_info</code> extension with
   the <code>extension_data</code> set to this <code>TransItemList</code>. If the list is
   empty, then the server <span class="bcp14">SHOULD</span> omit the <code>extension_data</code>
   element but <span class="bcp14">MAY</span> send it with an empty array.<a href="#section-6.5-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.5-3">TLS servers <span class="bcp14">MUST</span> only include this extension in the following messages:<a href="#section-6.5-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.5-4.1">the ServerHello message (for TLS 1.2 or earlier)<a href="#section-6.5-4.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.5-4.2">the Certificate or CertificateRequest message (for TLS 1.3)<a href="#section-6.5-4.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.5-5">TLS servers <span class="bcp14">MUST NOT</span> process or include this extension when a TLS session is
resumed, since session resumption uses the original session information.<a href="#section-6.5-5" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="certification-authorities">
<section id="section-7">
      <h2 id="name-certification-authorities">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-certification-authorities" class="section-name selfRef">Certification Authorities</a>
      </h2>
<div id="x509v3_transinfo_extension">
<section id="section-7.1">
        <h3 id="name-transparency-information-x5">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-transparency-information-x5" class="section-name selfRef">Transparency Information X.509v3 Extension</a>
        </h3>
<p id="section-7.1-1">The Transparency Information X.509v3 extension, which has OID 1.3.101.75 and
 <span class="bcp14">SHOULD</span> be noncritical, contains one or more <code>TransItem</code>
 structures in a <code>TransItemList</code>. This extension <span class="bcp14">MAY</span> be
 included in OCSP responses (see
 <a href="#ocsp_transinfo_extension" class="xref">Section 7.1.1</a>) and certificates (see
 <a href="#cert_transinfo_extension" class="xref">Section 7.1.2</a>). Since <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span> requires the <code>extnValue</code> field (an
 OCTET STRING) of each X.509v3 extension to include the DER encoding of an ASN.1
 value, a <code>TransItemList</code> <span class="bcp14">MUST NOT</span> be included directly.
 Instead, it <span class="bcp14">MUST</span> be
 wrapped inside an additional OCTET STRING, which is then put into the
 <code>extnValue</code> field:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<div id="section-7.1-2">
<pre class="lang-asn.1 sourcecode">
    TransparencyInformationSyntax ::= OCTET STRING
</pre><a href="#section-7.1-2" class="pilcrow">¶</a>
</div>
<p id="section-7.1-3"><code>TransparencyInformationSyntax</code> contains a <code>TransItemList</code>.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
<div id="ocsp_transinfo_extension">
<section id="section-7.1.1">
          <h4 id="name-ocsp-response-extension">
<a href="#section-7.1.1" class="section-number selfRef">7.1.1. </a><a href="#name-ocsp-response-extension" class="section-name selfRef">OCSP Response Extension</a>
          </h4>
<p id="section-7.1.1-1">A certification authority <span class="bcp14">MAY</span> include a Transparency Information
   X.509v3 extension in the <code>singleExtensions</code> of a <code>SingleResponse</code> in
   an OCSP response. All included SCTs and inclusion proofs <span class="bcp14">MUST</span> be for
   the certificate identified by the <code>certID</code> of that <code>SingleResponse</code>
   or for a precertificate that corresponds to that certificate.<a href="#section-7.1.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="cert_transinfo_extension">
<section id="section-7.1.2">
          <h4 id="name-certificate-extension">
<a href="#section-7.1.2" class="section-number selfRef">7.1.2. </a><a href="#name-certificate-extension" class="section-name selfRef">Certificate Extension</a>
          </h4>
<p id="section-7.1.2-1">A certification authority <span class="bcp14">MAY</span> include a Transparency Information X.509v3
extension in a certificate. All included SCTs and inclusion proofs <span class="bcp14">MUST</span> be for a
precertificate that corresponds to this certificate.<a href="#section-7.1.2-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="tls-feature-x509v3-extension">
<section id="section-7.2">
        <h3 id="name-tls-feature-x509v3-extensio">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-tls-feature-x509v3-extensio" class="section-name selfRef">TLS Feature X.509v3 Extension</a>
        </h3>
<p id="section-7.2-1">A certification authority <span class="bcp14">SHOULD NOT</span> issue any certificate that identifies the
<code>transparency_info</code> TLS extension in a TLS feature extension <span>[<a href="#RFC7633" class="xref">RFC7633</a>]</span>, because
TLS servers are not required to support the <code>transparency_info</code> TLS extension in
order to participate in CT (see <a href="#tls_servers" class="xref">Section 6</a>).<a href="#section-7.2-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="clients">
<section id="section-8">
      <h2 id="name-clients">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-clients" class="section-name selfRef">Clients</a>
      </h2>
<p id="section-8-1">There are various different functions clients of logs might perform. We describe
      here some typical clients and how they should function. Any inconsistency may be
      used as evidence that a log has not behaved correctly, and the signatures on the
      data structures prevent the log from denying that misbehavior.<a href="#section-8-1" class="pilcrow">¶</a></p>
<p id="section-8-2">All clients need various parameters in order to communicate with logs and verify
      their responses. These parameters are described in <a href="#log_parameters" class="xref">Section 4.1</a>, but note
      that this document does not describe how the parameters are obtained, which is
      implementation dependent (for example, see <span>[<a href="#Chromium.Policy" class="xref">Chromium.Policy</a>]</span>).<a href="#section-8-2" class="pilcrow">¶</a></p>
<div id="tls_clients">
<section id="section-8.1">
        <h3 id="name-tls-client">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-tls-client" class="section-name selfRef">TLS Client</a>
        </h3>
<div id="receiving_transitems">
<section id="section-8.1.1">
          <h4 id="name-receiving-scts-and-inclusio">
<a href="#section-8.1.1" class="section-number selfRef">8.1.1. </a><a href="#name-receiving-scts-and-inclusio" class="section-name selfRef">Receiving SCTs and Inclusion Proofs</a>
          </h4>
<p id="section-8.1.1-1">TLS clients receive SCTs and inclusion proofs alongside or in certificates.
   CT-using TLS clients <span class="bcp14">MUST</span> implement all of the three mechanisms by
   which TLS servers may present SCTs (see <a href="#tls_servers" class="xref">Section 6</a>).<a href="#section-8.1.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1.1-2">TLS clients that support the <code>transparency_info</code> TLS extension
   (see <a href="#tls_transinfo_extension" class="xref">Section 6.5</a>)
   <span class="bcp14">SHOULD</span> include it in ClientHello messages,
   with empty <code>extension_data</code>. If a TLS server includes the
   <code>transparency_info</code> TLS extension when resuming a TLS session, the TLS
   client <span class="bcp14">MUST</span> abort the handshake.<a href="#section-8.1.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="reconstructing_tbscertificate">
<section id="section-8.1.2">
          <h4 id="name-reconstructing-the-tbscerti">
<a href="#section-8.1.2" class="section-number selfRef">8.1.2. </a><a href="#name-reconstructing-the-tbscerti" class="section-name selfRef">Reconstructing the TBSCertificate</a>
          </h4>
<p id="section-8.1.2-1">Validation of an SCT for a certificate (where the <code>type</code> of the <code>TransItem</code> is
<code>x509_sct_v2</code>) uses the unmodified TBSCertificate component of the certificate.<a href="#section-8.1.2-1" class="pilcrow">¶</a></p>
<p id="section-8.1.2-2">Before an SCT for a precertificate (where the <code>type</code> of the <code>TransItem</code> is
<code>precert_sct_v2</code>) can be validated, the TBSCertificate component of the
precertificate needs to be reconstructed from the TBSCertificate component of
the certificate as follows:<a href="#section-8.1.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.1.2-3.1">Remove the Transparency Information extension
     (see <a href="#x509v3_transinfo_extension" class="xref">Section 7.1</a>).<a href="#section-8.1.2-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-8.1.2-3.2">Remove embedded v1 SCTs, identified by OID 1.3.6.1.4.1.11129.2.4.2 (see
     <span><a href="https://www.rfc-editor.org/rfc/rfc6962#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC6962" class="xref">RFC6962</a>]</span>). This allows embedded
     v1 and v2 SCTs to co-exist in
     a certificate (see <a href="#v1_coexistence" class="xref">Appendix A</a>).<a href="#section-8.1.2-3.2" class="pilcrow">¶</a>
</li>
          </ul>
</section>
</div>
<div id="validating-scts">
<section id="section-8.1.3">
          <h4 id="name-validating-scts">
<a href="#section-8.1.3" class="section-number selfRef">8.1.3. </a><a href="#name-validating-scts" class="section-name selfRef">Validating SCTs</a>
          </h4>
<p id="section-8.1.3-1">In order to make use of a received SCT, the TLS client <span class="bcp14">MUST</span> first validate it as
follows:<a href="#section-8.1.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.1.3-2.1">
              <p id="section-8.1.3-2.1.1">Compute the signature input by constructing a <code>TransItem</code> of type
       <code>x509_entry_v2</code> or <code>precert_entry_v2</code>, depending on the SCT's
       <code>TransItem</code>
       type. The <code>TimestampedCertificateEntryDataV2</code> structure is constructed
       in the following manner:<a href="#section-8.1.3-2.1.1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.1.3-2.1.2.1">
                  <code>timestamp</code> is copied from the SCT.<a href="#section-8.1.3-2.1.2.1" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-8.1.3-2.1.2.2">
                  <code>tbs_certificate</code> is the reconstructed TBSCertificate portion of
 the server certificate, as described in <a href="#reconstructing_tbscertificate" class="xref">Section 8.1.2</a>.<a href="#section-8.1.3-2.1.2.2" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-8.1.3-2.1.2.3">
                  <code>issuer_key_hash</code> is computed as described in <a href="#tree_leaves" class="xref">Section 4.7</a>.<a href="#section-8.1.3-2.1.2.3" class="pilcrow">¶</a>
</li>
                <li class="normal" id="section-8.1.3-2.1.2.4">
                  <code>sct_extensions</code> is copied from the SCT.<a href="#section-8.1.3-2.1.2.4" class="pilcrow">¶</a>
</li>
              </ul>
</li>
            <li class="normal" id="section-8.1.3-2.2">Verify the SCT's <code>signature</code> against the computed signature input using the
public key of the corresponding log, which is identified by the <code>log_id</code>. The
required signature algorithm is one of the log's parameters.<a href="#section-8.1.3-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-8.1.3-3">If the TLS client does not have the corresponding log's parameters, it cannot
attempt to validate the SCT. When evaluating compliance (see
<a href="#evaluating_compliance" class="xref">Section 8.1.6</a>), the TLS client will consider only those SCTs that it
was able to validate.<a href="#section-8.1.3-3" class="pilcrow">¶</a></p>
<p id="section-8.1.3-4">Note that SCT validation is not a substitute for the normal validation of the
server certificate and its chain.<a href="#section-8.1.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="fetching_inclusion_proofs">
<section id="section-8.1.4">
          <h4 id="name-fetching-inclusion-proofs">
<a href="#section-8.1.4" class="section-number selfRef">8.1.4. </a><a href="#name-fetching-inclusion-proofs" class="section-name selfRef">Fetching Inclusion Proofs</a>
          </h4>
<p id="section-8.1.4-1">When a TLS client has validated a received SCT but does not yet possess
a corresponding inclusion proof, the TLS client <span class="bcp14">MAY</span> request the inclusion
proof directly from a log using <code>get-proof-by-hash</code> (<a href="#get-proof-by-hash" class="xref">Section 5.4</a>) or
<code>get-all-by-hash</code> (<a href="#get-all-by-hash" class="xref">Section 5.5</a>).<a href="#section-8.1.4-1" class="pilcrow">¶</a></p>
<p id="section-8.1.4-2">Note that fetching inclusion proofs directly from a log will disclose to the
log which TLS server the client has been communicating with. This may be
regarded as a significant privacy concern, and so it is preferable for the TLS
server to send the inclusion proofs (see <a href="#presenting_transitems" class="xref">Section 6.4</a>).<a href="#section-8.1.4-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="validating_inclusion_proofs">
<section id="section-8.1.5">
          <h4 id="name-validating-inclusion-proofs">
<a href="#section-8.1.5" class="section-number selfRef">8.1.5. </a><a href="#name-validating-inclusion-proofs" class="section-name selfRef">Validating Inclusion Proofs</a>
          </h4>
<p id="section-8.1.5-1">When a TLS client has received, or fetched, an inclusion proof (and an STH),
it <span class="bcp14">SHOULD</span> proceed to verify the inclusion proof to the provided STH.
The TLS client <span class="bcp14">SHOULD</span> also verify consistency between the provided STH
and an STH it knows about.<a href="#section-8.1.5-1" class="pilcrow">¶</a></p>
<p id="section-8.1.5-2">If the TLS client holds an STH that predates the SCT, it <span class="bcp14">MAY</span>, in the process of
auditing, request a new STH from the log (<a href="#get-sth" class="xref">Section 5.2</a>) and then verify it by
requesting a consistency proof (<a href="#get-sth-consistency" class="xref">Section 5.3</a>). Note that if the TLS
client uses <code>get-all-by-hash</code>, then it will already have the new STH.<a href="#section-8.1.5-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="evaluating_compliance">
<section id="section-8.1.6">
          <h4 id="name-evaluating-compliance">
<a href="#section-8.1.6" class="section-number selfRef">8.1.6. </a><a href="#name-evaluating-compliance" class="section-name selfRef">Evaluating Compliance</a>
          </h4>
<p id="section-8.1.6-1">It is up to a client's local policy to specify the quantity and form of
evidence (SCTs, inclusion proofs, or a combination) needed to achieve
compliance and how to handle noncompliance.<a href="#section-8.1.6-1" class="pilcrow">¶</a></p>
<p id="section-8.1.6-2">A TLS client can only evaluate compliance if it has given the TLS server the
opportunity to send SCTs and inclusion proofs by any of the three mechanisms
that are mandatory to implement for CT-using TLS clients (see
<a href="#receiving_transitems" class="xref">Section 8.1.1</a>). Therefore, a TLS client <span class="bcp14">MUST NOT</span> evaluate compliance
if it did not include both the <code>transparency_info</code> and <code>status_request</code> TLS
extensions in the ClientHello.<a href="#section-8.1.6-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="monitor">
<section id="section-8.2">
        <h3 id="name-monitor">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-monitor" class="section-name selfRef">Monitor</a>
        </h3>
<p id="section-8.2-1">Monitors watch logs to check for correct behavior, for certificates of
interest, or for both. For example, a monitor may be configured to report on all
certificates that apply to a specific domain name when fetching new entries for
consistency validation.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<p id="section-8.2-2">A monitor <span class="bcp14">MUST</span> at least inspect every new entry in every log it watches, and it
<span class="bcp14">MAY</span> also choose to keep copies of entire logs.<a href="#section-8.2-2" class="pilcrow">¶</a></p>
<p id="section-8.2-3">To inspect all of the existing entries, the monitor <span class="bcp14">SHOULD</span> follow these steps
once for each log:<a href="#section-8.2-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-8.2-4">
   <li id="section-8.2-4.1">Fetch the current STH (<a href="#get-sth" class="xref">Section 5.2</a>).<a href="#section-8.2-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-8.2-4.2">Verify the STH signature.<a href="#section-8.2-4.2" class="pilcrow">¶</a>
</li>
          <li id="section-8.2-4.3">Fetch all the entries in the tree corresponding to the STH (<a href="#get-entries" class="xref">Section 5.6</a>).<a href="#section-8.2-4.3" class="pilcrow">¶</a>
</li>
          <li id="section-8.2-4.4">If applicable, check each entry to see if it's a certificate of interest.<a href="#section-8.2-4.4" class="pilcrow">¶</a>
</li>
          <li id="section-8.2-4.5">Confirm that the tree made from the fetched entries produces the same hash as
   that in the STH.<a href="#section-8.2-4.5" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-8.2-5">To inspect new entries, the monitor <span class="bcp14">SHOULD</span> follow these steps
 repeatedly for each log:<a href="#section-8.2-5" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-8.2-6">
   <li id="section-8.2-6.1">Fetch the current STH (<a href="#get-sth" class="xref">Section 5.2</a>). Repeat until
   the STH changes. To allow for experimentation, this document does not specify the polling frequency.<a href="#section-8.2-6.1" class="pilcrow">¶</a>
</li>
          <li id="section-8.2-6.2">Verify the STH signature.<a href="#section-8.2-6.2" class="pilcrow">¶</a>
</li>
          <li id="section-8.2-6.3">Fetch all the new entries in the tree corresponding to the STH
   (<a href="#get-entries" class="xref">Section 5.6</a>). If they remain unavailable for an
   extended period, then this should be viewed as misbehavior on the part of the
   log.<a href="#section-8.2-6.3" class="pilcrow">¶</a>
</li>
          <li id="section-8.2-6.4">If applicable, check each entry to see if it's a certificate of interest.<a href="#section-8.2-6.4" class="pilcrow">¶</a>
</li>
          <li id="section-8.2-6.5">
            <p id="section-8.2-6.5.1">Either:<a href="#section-8.2-6.5.1" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-8.2-6.5.2">
       <li id="section-8.2-6.5.2.1">Verify that the updated list of all entries generates a tree with the
       same hash as the new STH.<a href="#section-8.2-6.5.2.1" class="pilcrow">¶</a>
</li>
            </ol>
<p id="section-8.2-6.5.3">Or, if it is not keeping all log entries:<a href="#section-8.2-6.5.3" class="pilcrow">¶</a></p>
<ol start="1" type="a" class="normal type-a" id="section-8.2-6.5.4">
       <li id="section-8.2-6.5.4.1">Fetch a consistency proof for the new STH with the previous STH
       (<a href="#get-sth-consistency" class="xref">Section 5.3</a>).<a href="#section-8.2-6.5.4.1" class="pilcrow">¶</a>
</li>
              <li id="section-8.2-6.5.4.2">Verify the consistency proof.<a href="#section-8.2-6.5.4.2" class="pilcrow">¶</a>
</li>
              <li id="section-8.2-6.5.4.3">Verify that the new entries generate the corresponding elements in the
       consistency proof.<a href="#section-8.2-6.5.4.3" class="pilcrow">¶</a>
</li>
            </ol>
</li>
          <li id="section-8.2-6.6">Repeat from Step 1.<a href="#section-8.2-6.6" class="pilcrow">¶</a>
</li>
        </ol>
</section>
</div>
<div id="auditing">
<section id="section-8.3">
        <h3 id="name-auditing">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-auditing" class="section-name selfRef">Auditing</a>
        </h3>
<p id="section-8.3-1">Auditing ensures that the current published state of a log is reachable from
previously published states that are known to be good and that the promises
made by the log, in the form of SCTs, have been kept. Audits are performed by
monitors or TLS clients.<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<p id="section-8.3-2">In particular, there are four properties of log behavior that should be checked:<a href="#section-8.3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-8.3-3.1">the Maximum Merge Delay (MMD)<a href="#section-8.3-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.3-3.2">the STH Frequency Count<a href="#section-8.3-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.3-3.3">the append-only property<a href="#section-8.3-3.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-8.3-3.4">the consistency of the log view presented to all query sources<a href="#section-8.3-3.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-8.3-4">A benign, conformant log publishes a series of STHs over time, each derived from
the previous STH and the submitted entries incorporated into the log since
publication of the previous STH. This can be proven through auditing of STHs.
SCTs returned to TLS clients can be audited by verifying against the
accompanying certificate and using Merkle inclusion proofs against the log's
Merkle Tree.<a href="#section-8.3-4" class="pilcrow">¶</a></p>
<p id="section-8.3-5">The action taken by the auditor, if an audit fails, is not specified, but note
that in general, if an audit fails, the auditor is in possession of signed proof of
the log's misbehavior.<a href="#section-8.3-5" class="pilcrow">¶</a></p>
<p id="section-8.3-6">A monitor (<a href="#monitor" class="xref">Section 8.2</a>) can audit by verifying the consistency of STHs it
receives, ensuring that each entry can be fetched and that the STH is indeed the
result of making a tree from all fetched entries.<a href="#section-8.3-6" class="pilcrow">¶</a></p>
<p id="section-8.3-7">A TLS client (<a href="#tls_clients" class="xref">Section 8.1</a>) can audit by verifying an SCT against any STH
dated after the SCT timestamp + the Maximum Merge Delay by requesting a Merkle
inclusion proof (<a href="#get-proof-by-hash" class="xref">Section 5.4</a>). It can also verify that the SCT
corresponds to the server certificate it arrived with (i.e., the log entry is
that certificate or is a precertificate corresponding to that certificate).<a href="#section-8.3-7" class="pilcrow">¶</a></p>
<p id="section-8.3-8">Checking of the consistency of the log view presented to all entities is more
difficult to perform because it requires a way to share log responses among a
set of CT-using entities and is discussed in <a href="#misbehaving_logs" class="xref">Section 11.3</a>.<a href="#section-8.3-8" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="algorithm-agility">
<section id="section-9">
      <h2 id="name-algorithm-agility">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-algorithm-agility" class="section-name selfRef">Algorithm Agility</a>
      </h2>
<p id="section-9-1">It is not possible for a log to change either of its algorithms part way through
its lifetime:<a href="#section-9-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-9-2">
        <dt id="section-9-2.1">Signature algorithm:</dt>
        <dd style="margin-left: 1.5em" id="section-9-2.2">SCT signatures must remain valid so signature algorithms can only be added,
 not removed.<a href="#section-9-2.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-9-2.3">Hash algorithm:</dt>
        <dd style="margin-left: 1.5em" id="section-9-2.4">A log would have to support the old and new hash algorithms to allow
 backwards compatibility with clients that are not aware of a hash algorithm
 change.<a href="#section-9-2.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-9-3">Allowing multiple signature or hash algorithms for a log would require that all
data structures support it and would significantly complicate client
implementation, which is why it is not supported by this document.<a href="#section-9-3" class="pilcrow">¶</a></p>
<p id="section-9-4">If it should become necessary to deprecate an algorithm used by a live log, then
the log <span class="bcp14">MUST</span> be frozen, as specified in <a href="#log_shutdown" class="xref">Section 4.13</a>, and a new log <span class="bcp14">SHOULD</span> be
started. Certificates in the frozen log that have not yet expired and require
new SCTs <span class="bcp14">SHOULD</span> be submitted to the new log and the SCTs from that log used
instead.<a href="#section-9-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana-considerations">
<section id="section-10">
      <h2 id="name-iana-considerations">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<p id="section-10-1">The assignment policy criteria mentioned in this section refer to the policies
outlined in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-10-1" class="pilcrow">¶</a></p>
<div id="additions-to-existing-registries">
<section id="section-10.1">
        <h3 id="name-additions-to-existing-regis">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-additions-to-existing-regis" class="section-name selfRef">Additions to Existing Registries</a>
        </h3>
<p id="section-10.1-1">This subsection defines additions to existing registries.<a href="#section-10.1-1" class="pilcrow">¶</a></p>
<div id="new-entry-to-the-tls-extensiontype-registry">
<section id="section-10.1.1">
          <h4 id="name-new-entry-to-the-tls-extens">
<a href="#section-10.1.1" class="section-number selfRef">10.1.1. </a><a href="#name-new-entry-to-the-tls-extens" class="section-name selfRef">New Entry to the TLS ExtensionType Registry</a>
          </h4>
<p id="section-10.1.1-1">IANA has added the following entry
to the "TLS ExtensionType Values" registry defined in <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>,
with an assigned Value:<a href="#section-10.1.1-1" class="pilcrow">¶</a></p>
<table class="center" id="table-7">
            <caption><a href="#table-7" class="selfRef">Table 7</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Value</th>
                <th class="text-left" rowspan="1" colspan="1">Extension Name</th>
                <th class="text-left" rowspan="1" colspan="1">TLS 1.3</th>
                <th class="text-left" rowspan="1" colspan="1">DTLS-Only</th>
                <th class="text-left" rowspan="1" colspan="1">Recommended</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">52</td>
                <td class="text-left" rowspan="1" colspan="1">transparency_info</td>
                <td class="text-left" rowspan="1" colspan="1">CH, CR, CT</td>
                <td class="text-left" rowspan="1" colspan="1">N</td>
                <td class="text-left" rowspan="1" colspan="1">Y</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
            </tbody>
          </table>
</section>
</div>
<div id="urn-sub-namespace-for-trans-urnietfparamstrans">
<section id="section-10.1.2">
          <h4 id="name-urn-sub-namespace-for-trans">
<a href="#section-10.1.2" class="section-number selfRef">10.1.2. </a><a href="#name-urn-sub-namespace-for-trans" class="section-name selfRef">URN Sub-namespace for TRANS (urn:ietf:params:trans)</a>
          </h4>
<p id="section-10.1.2-1">IANA has added a new entry in the
   "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers"
   registry, following the template in <span>[<a href="#RFC3553" class="xref">RFC3553</a>]</span>:<a href="#section-10.1.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlCompact dlParallel" id="section-10.1.2-2">
            <dt id="section-10.1.2-2.1">Registry name:</dt>
            <dd style="margin-left: 1.5em" id="section-10.1.2-2.2">trans<a href="#section-10.1.2-2.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-10.1.2-2.3">Specification:</dt>
            <dd style="margin-left: 1.5em" id="section-10.1.2-2.4">RFC 9162<a href="#section-10.1.2-2.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-10.1.2-2.5">Repository:</dt>
            <dd style="margin-left: 1.5em" id="section-10.1.2-2.6">
              <span>&lt;<a href="https://www.iana.org/assignments/trans">https://www.iana.org/assignments/trans</a>&gt;</span><a href="#section-10.1.2-2.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-10.1.2-2.7">Index value:</dt>
            <dd style="margin-left: 1.5em" id="section-10.1.2-2.8">No transformation needed.<a href="#section-10.1.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="new-ct-related-registries">
<section id="section-10.2">
        <h3 id="name-new-ct-related-registries">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-new-ct-related-registries" class="section-name selfRef">New CT-Related Registries</a>
        </h3>
<p id="section-10.2-1">IANA has added a new protocol registry, "Public Notary
Transparency", to the list that appears at
<span>&lt;<a href="https://www.iana.org/assignments/">https://www.iana.org/assignments/</a>&gt;</span><a href="#section-10.2-1" class="pilcrow">¶</a></p>
<p id="section-10.2-2">The rest of this section defines the subregistries that have been created within the new "Public Notary Transparency" registry.<a href="#section-10.2-2" class="pilcrow">¶</a></p>
<div id="hash_algorithms">
<section id="section-10.2.1">
          <h4 id="name-hash-algorithms">
<a href="#section-10.2.1" class="section-number selfRef">10.2.1. </a><a href="#name-hash-algorithms" class="section-name selfRef">Hash Algorithms</a>
          </h4>
<p id="section-10.2.1-1">IANA has established a registry of hash algorithm values, named
"Hash Algorithms", with the following registration procedures:<a href="#section-10.2.1-1" class="pilcrow">¶</a></p>
<table class="center" id="table-8">
            <caption><a href="#table-8" class="selfRef">Table 8</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Range</th>
                <th class="text-left" rowspan="1" colspan="1">Registration Procedures</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x00-0xDF</td>
                <td class="text-left" rowspan="1" colspan="1">Specification Required</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xE0-0xEF</td>
                <td class="text-left" rowspan="1" colspan="1">Experimental Use</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xF0-0xFF</td>
                <td class="text-left" rowspan="1" colspan="1">Private Use</td>
              </tr>
            </tbody>
          </table>
<p id="section-10.2.1-3">The "Hash Algorithms" registry initially consists of:<a href="#section-10.2.1-3" class="pilcrow">¶</a></p>
<table class="center" id="table-9">
            <caption><a href="#table-9" class="selfRef">Table 9</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Value</th>
                <th class="text-left" rowspan="1" colspan="1">Hash Algorithm</th>
                <th class="text-left" rowspan="1" colspan="1">OID</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x00</td>
                <td class="text-left" rowspan="1" colspan="1">SHA-256</td>
                <td class="text-left" rowspan="1" colspan="1">2.16.840.1.101.3.4.2.1</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6234" class="xref">RFC6234</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x01 - 0xDF</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1"> </td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xE0 - 0xEF</td>
                <td class="text-left" rowspan="1" colspan="1">Reserved for Experimental Use</td>
                <td class="text-left" rowspan="1" colspan="1"> </td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xF0 - 0xFF</td>
                <td class="text-left" rowspan="1" colspan="1">Reserved for Private Use</td>
                <td class="text-left" rowspan="1" colspan="1"> </td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
            </tbody>
          </table>
<p id="section-10.2.1-5">The designated expert(s) should ensure that the proposed algorithm has a public
specification and is suitable for use as a cryptographic hash algorithm with no
known preimage or collision attacks. These attacks can damage the integrity of
the log.<a href="#section-10.2.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="signature_algorithms">
<section id="section-10.2.2">
          <h4 id="name-signature-algorithms">
<a href="#section-10.2.2" class="section-number selfRef">10.2.2. </a><a href="#name-signature-algorithms" class="section-name selfRef">Signature Algorithms</a>
          </h4>
<p id="section-10.2.2-1">IANA has established a registry of signature algorithm values, named
"Signature Algorithms".<a href="#section-10.2.2-1" class="pilcrow">¶</a></p>
<p id="section-10.2.2-2">The following notes have been added to the registry:<a href="#section-10.2.2-2" class="pilcrow">¶</a></p>
<blockquote id="section-10.2.2-3">
            <span class="break"></span><dl class="dlNewline" id="section-10.2.2-3.1">
              <dt id="section-10.2.2-3.1.1"><strong>Note:</strong></dt>
              <dd style="margin-left: 1.5em" id="section-10.2.2-3.1.2">This is a subset of the "TLS SignatureScheme" registry, limited to those
     algorithms that are appropriate for CT. A major advantage of this is
     leveraging the expertise of the TLS Working Group and its designated
     expert(s).<a href="#section-10.2.2-3.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</blockquote>
<blockquote id="section-10.2.2-4">
            <span class="break"></span><dl class="dlNewline" id="section-10.2.2-4.1">
              <dt id="section-10.2.2-4.1.1"><strong>Note:</strong></dt>
              <dd style="margin-left: 1.5em" id="section-10.2.2-4.1.2">The value <code>0x0403</code> appears twice. While this may be confusing,
     it is okay because the verification
     process is the same for both algorithms, and the choice of which to use
     when generating a signature is purely internal to the log server.<a href="#section-10.2.2-4.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</blockquote>
<p id="section-10.2.2-5">The "Signature Algorithms" registry has the following registration procedures:<a href="#section-10.2.2-5" class="pilcrow">¶</a></p>
<table class="center" id="table-10">
            <caption><a href="#table-10" class="selfRef">Table 10</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Range</th>
                <th class="text-left" rowspan="1" colspan="1">Registration Procedures</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0000-0x0807</td>
                <td class="text-left" rowspan="1" colspan="1">Specification Required</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0808-0xFDFF</td>
                <td class="text-left" rowspan="1" colspan="1">Expert Review</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xFE00-0xFEFF</td>
                <td class="text-left" rowspan="1" colspan="1">Experimental Use</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xFF00-0xFFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Private Use</td>
              </tr>
            </tbody>
          </table>
<p id="section-10.2.2-7">The "Signature Algorithms" registry initially consists of:<a href="#section-10.2.2-7" class="pilcrow">¶</a></p>
<table class="center" id="table-11">
            <caption><a href="#table-11" class="selfRef">Table 11</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">SignatureScheme Value</th>
                <th class="text-left" rowspan="1" colspan="1">Signature Algorithm</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0000 - 0x0402</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1"> </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">ecdsa_secp256r1_sha256 (0x0403)</td>
                <td class="text-left" rowspan="1" colspan="1">ECDSA (NIST P-256) with SHA-256</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#FIPS186-4" class="xref">FIPS186-4</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">ecdsa_secp256r1_sha256 (0x0403)</td>
                <td class="text-left" rowspan="1" colspan="1">Deterministic ECDSA (NIST P-256) with HMAC-SHA256</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6979" class="xref">RFC6979</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0404 - 0x0806</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1"> </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">ed25519 (0x0807)</td>
                <td class="text-left" rowspan="1" colspan="1">Ed25519 (PureEdDSA with the edwards25519 curve)</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC8032" class="xref">RFC8032</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0808 - 0xFDFF</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1"> </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xFE00 - 0xFEFF</td>
                <td class="text-left" rowspan="1" colspan="1">Reserved for Experimental Use</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xFF00 - 0xFFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Reserved for Private Use</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
            </tbody>
          </table>
<p id="section-10.2.2-9">The designated expert(s) should ensure that the proposed algorithm has a public
specification, has a value assigned to it in the "TLS SignatureScheme" registry
(which was established by <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>), and is suitable for use as a
cryptographic signature algorithm.<a href="#section-10.2.2-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="versioned_trans_types">
<section id="section-10.2.3">
          <h4 id="name-versionedtranstypes">
<a href="#section-10.2.3" class="section-number selfRef">10.2.3. </a><a href="#name-versionedtranstypes" class="section-name selfRef">VersionedTransTypes</a>
          </h4>
<p id="section-10.2.3-1">IANA has established a registry of <code>VersionedTransType</code> values, named
"VersionedTransTypes".<a href="#section-10.2.3-1" class="pilcrow">¶</a></p>
<p id="section-10.2.3-2">The following note has been added:<a href="#section-10.2.3-2" class="pilcrow">¶</a></p>
<blockquote id="section-10.2.3-3">
            <span class="break"></span><dl class="dlNewline" id="section-10.2.3-3.1">
              <dt id="section-10.2.3-3.1.1"><strong>Note:</strong></dt>
              <dd style="margin-left: 1.5em" id="section-10.2.3-3.1.2">The range 0x0000..0x00FF is reserved so that v1 SCTs are distinguishable from
     v2 SCTs and other <code>TransItem</code> structures.<a href="#section-10.2.3-3.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</blockquote>
<p id="section-10.2.3-4">The registration procedures for the "VersionedTransTypes" registry are the following:<a href="#section-10.2.3-4" class="pilcrow">¶</a></p>
<table class="center" id="table-12">
            <caption><a href="#table-12" class="selfRef">Table 12</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Range</th>
                <th class="text-left" rowspan="1" colspan="1">Registration Procedures</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0100-0xDFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Specification Required</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xE000-0xEFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Experimental Use</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xF000-0xFFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Private Use</td>
              </tr>
            </tbody>
          </table>
<p id="section-10.2.3-6">The "VersionedTransTypes" registry initially consists of:<a href="#section-10.2.3-6" class="pilcrow">¶</a></p>
<table class="center" id="table-13">
            <caption><a href="#table-13" class="selfRef">Table 13</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Value</th>
                <th class="text-left" rowspan="1" colspan="1">Type and Version</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0000 - 0x00FF</td>
                <td class="text-left" rowspan="1" colspan="1">Reserved</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0100</td>
                <td class="text-left" rowspan="1" colspan="1">x509_entry_v2</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0101</td>
                <td class="text-left" rowspan="1" colspan="1">precert_entry_v2</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0102</td>
                <td class="text-left" rowspan="1" colspan="1">x509_sct_v2</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0103</td>
                <td class="text-left" rowspan="1" colspan="1">precert_sct_v2</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0104</td>
                <td class="text-left" rowspan="1" colspan="1">signed_tree_head_v2</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0105</td>
                <td class="text-left" rowspan="1" colspan="1">consistency_proof_v2</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0106</td>
                <td class="text-left" rowspan="1" colspan="1">inclusion_proof_v2</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0107 - 0xDFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1"> </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xE000 - 0xEFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Reserved for Experimental Use</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xF000 - 0xFFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Reserved for Private Use</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
            </tbody>
          </table>
<p id="section-10.2.3-8">The designated expert(s) should review the public specification to ensure that it is
detailed enough to ensure implementation interoperability.<a href="#section-10.2.3-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="log_artifact_extension_registry">
<section id="section-10.2.4">
          <h4 id="name-log-artifact-extensions-2">
<a href="#section-10.2.4" class="section-number selfRef">10.2.4. </a><a href="#name-log-artifact-extensions-2" class="section-name selfRef">Log Artifact Extensions</a>
          </h4>
<p id="section-10.2.4-1">IANA has established a registry of <code>ExtensionType</code> values, named "Log
Artifact Extensions".<a href="#section-10.2.4-1" class="pilcrow">¶</a></p>
<p id="section-10.2.4-2">The registration procedures for the "Log Artifact Extensions" registry are the following:<a href="#section-10.2.4-2" class="pilcrow">¶</a></p>
<table class="center" id="table-14">
            <caption><a href="#table-14" class="selfRef">Table 14</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Range</th>
                <th class="text-left" rowspan="1" colspan="1">Registration Procedures</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0000-0xDFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Specification Required</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xE000-0xEFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Experimental Use</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xF000-0xFFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Private Use</td>
              </tr>
            </tbody>
          </table>
<p id="section-10.2.4-4">The "Log Artifact Extensions" registry initially consists of:<a href="#section-10.2.4-4" class="pilcrow">¶</a></p>
<table class="center" id="table-15">
            <caption><a href="#table-15" class="selfRef">Table 15</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">ExtensionType</th>
                <th class="text-left" rowspan="1" colspan="1">Status</th>
                <th class="text-left" rowspan="1" colspan="1">Use</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0x0000 - 0xDFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1">n/a</td>
                <td class="text-left" rowspan="1" colspan="1"> </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xE000 - 0xEFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Reserved for Experimental Use</td>
                <td class="text-left" rowspan="1" colspan="1">n/a</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">0xF000 - 0xFFFF</td>
                <td class="text-left" rowspan="1" colspan="1">Reserved for Private Use</td>
                <td class="text-left" rowspan="1" colspan="1">n/a</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
            </tbody>
          </table>
<p id="section-10.2.4-6">The "Use" column should contain one or both of the following values:<a href="#section-10.2.4-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.2.4-7.1">"SCT", for extensions specified for use in Signed Certificate Timestamps.<a href="#section-10.2.4-7.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-10.2.4-7.2">"STH", for extensions specified for use in Signed Tree Heads.<a href="#section-10.2.4-7.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-10.2.4-8">The designated expert(s) should review the public specification to ensure that it is
detailed enough to ensure implementation interoperability. They should
also verify that the extension is appropriate to the contexts in which it is
specified to be used (SCT, STH, or both).<a href="#section-10.2.4-8" class="pilcrow">¶</a></p>
</section>
</div>
<div id="log_id_registry">
<section id="section-10.2.5">
          <h4 id="name-log-ids">
<a href="#section-10.2.5" class="section-number selfRef">10.2.5. </a><a href="#name-log-ids" class="section-name selfRef">Log IDs</a>
          </h4>
<p id="section-10.2.5-1">IANA has established a registry of Log IDs, named "Log IDs".<a href="#section-10.2.5-1" class="pilcrow">¶</a></p>
<p id="section-10.2.5-2">The registry's registration procedure is First Come First Served.<a href="#section-10.2.5-2" class="pilcrow">¶</a></p>
<p id="section-10.2.5-3">The "Log IDs" registry initially consists of:<a href="#section-10.2.5-3" class="pilcrow">¶</a></p>
<table class="center" id="table-16">
            <caption><a href="#table-16" class="selfRef">Table 16</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Log ID</th>
                <th class="text-left" rowspan="1" colspan="1">Log Base URL</th>
                <th class="text-left" rowspan="1" colspan="1">Log Operator</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">1.3.101.8192 - 1.3.101.16383</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1"> </td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">1.3.101.80.0 - 1.3.101.80.*</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
                <td class="text-left" rowspan="1" colspan="1"> </td>
              </tr>
            </tbody>
          </table>
<p id="section-10.2.5-5">The following notes have been added to the registry:<a href="#section-10.2.5-5" class="pilcrow">¶</a></p>
<blockquote id="section-10.2.5-6">
            <span class="break"></span><dl class="dlNewline" id="section-10.2.5-6.1">
              <dt id="section-10.2.5-6.1.1"><strong>Note:</strong></dt>
              <dd style="margin-left: 1.5em" id="section-10.2.5-6.1.2">All OIDs in the range from 1.3.101.8192 to 1.3.101.16383 have been set aside
for Log IDs.
This is a limited resource of 8,192 OIDs, each of which has an encoded length of
4 octets.<a href="#section-10.2.5-6.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</blockquote>
<blockquote id="section-10.2.5-7">
            <span class="break"></span><dl class="dlNewline" id="section-10.2.5-7.1">
              <dt id="section-10.2.5-7.1.1"><strong>Note:</strong></dt>
              <dd style="margin-left: 1.5em" id="section-10.2.5-7.1.2">The 1.3.101.80 arc has also been set aside for Log IDs.
This is an unlimited resource, but only
the 128 OIDs from 1.3.101.80.0 to 1.3.101.80.127 have an encoded length of only
4 octets.<a href="#section-10.2.5-7.1.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
</dl>
</blockquote>
<p id="section-10.2.5-8">Each application for the allocation of a Log ID <span class="bcp14">MUST</span> be accompanied by:<a href="#section-10.2.5-8" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-10.2.5-9.1">the Log's Base URL (see <a href="#log_parameters" class="xref">Section 4.1</a>) and<a href="#section-10.2.5-9.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-10.2.5-9.2">the Log Operator's contact details.<a href="#section-10.2.5-9.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-10.2.5-10">IANA is asked to reject any request to update a Log ID or Log Base URL in this
registry because these fields are immutable (see <a href="#log_parameters" class="xref">Section 4.1</a>).<a href="#section-10.2.5-10" class="pilcrow">¶</a></p>
<p id="section-10.2.5-11">IANA is asked to accept requests from log operators to update their contact
details in this registry.<a href="#section-10.2.5-11" class="pilcrow">¶</a></p>
<p id="section-10.2.5-12">Since log operators can choose to not use this registry (see <a href="#log_id" class="xref">Section 4.4</a>), it is
not expected to be a global directory of all logs.<a href="#section-10.2.5-12" class="pilcrow">¶</a></p>
</section>
</div>
<div id="error-types-registry">
<section id="section-10.2.6">
          <h4 id="name-error-types">
<a href="#section-10.2.6" class="section-number selfRef">10.2.6. </a><a href="#name-error-types" class="section-name selfRef">Error Types</a>
          </h4>
<p id="section-10.2.6-1">IANA has created a new registry for errors,
the "Error Types" registry.<a href="#section-10.2.6-1" class="pilcrow">¶</a></p>
<p id="section-10.2.6-2">The registration procedure for this registry is Specification Required.<a href="#section-10.2.6-2" class="pilcrow">¶</a></p>
<p id="section-10.2.6-3">This registry has the following three fields:<a href="#section-10.2.6-3" class="pilcrow">¶</a></p>
<table class="center" id="table-17">
            <caption><a href="#table-17" class="selfRef">Table 17</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Field Name</th>
                <th class="text-left" rowspan="1" colspan="1">Type</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Identifier</td>
                <td class="text-left" rowspan="1" colspan="1">string</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Meaning</td>
                <td class="text-left" rowspan="1" colspan="1">string</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">Reference</td>
                <td class="text-left" rowspan="1" colspan="1">string</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
            </tbody>
          </table>
<p id="section-10.2.6-5">The initial values of the "Error Types" registry, which are taken from the text in <a href="#client_messages" class="xref">Section 5</a>, are as follows:<a href="#section-10.2.6-5" class="pilcrow">¶</a></p>
<table class="center" id="table-18">
            <caption><a href="#table-18" class="selfRef">Table 18</a></caption>
<thead>
              <tr>
                <th class="text-left" rowspan="1" colspan="1">Identifier</th>
                <th class="text-left" rowspan="1" colspan="1">Meaning</th>
                <th class="text-left" rowspan="1" colspan="1">Reference</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">malformed</td>
                <td class="text-left" rowspan="1" colspan="1">The request could not be parsed.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">badSubmission</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>submission</code> is neither a valid certificate nor a
 valid precertificate.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">badType</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>type</code> is neither 1 nor 2.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">badChain</td>
                <td class="text-left" rowspan="1" colspan="1">The first element of <code>chain</code> is not the certifier of
 the <code>submission</code>, or the second element does not certify the first,
 etc.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">badCertificate</td>
                <td class="text-left" rowspan="1" colspan="1">One or more certificates in <code>chain</code> are not valid
 (e.g., not properly encoded).</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">unknownAnchor</td>
                <td class="text-left" rowspan="1" colspan="1">The last element of <code>chain</code> (or, if <code>chain</code> is
 an empty array, the <code>submission</code>) is not, nor is it certified
 by, an accepted trust anchor.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">shutdown</td>
                <td class="text-left" rowspan="1" colspan="1">The log is no longer accepting submissions.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">firstUnknown</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>first</code> is before the latest known STH but is not
 from an existing STH.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">secondUnknown</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>second</code> is before the latest known STH but is not
 from an existing STH.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">secondBeforeFirst</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>second</code> is smaller than <code>first</code>.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">hashUnknown</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>hash</code> is not the hash of a known leaf (may be caused
 by skew or by a known certificate not yet merged).</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">treeSizeUnknown</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>hash</code> is before the latest known STH but is not from
 an existing STH.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">startUnknown</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>start</code> is greater than the number of entries in the
 Merkle Tree.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
              <tr>
                <td class="text-left" rowspan="1" colspan="1">endBeforeStart</td>
                <td class="text-left" rowspan="1" colspan="1">
                  <code>start</code> cannot be greater than <code>end</code>.</td>
                <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
              </tr>
            </tbody>
          </table>
</section>
</div>
</section>
</div>
<div id="oid-assignment">
<section id="section-10.3">
        <h3 id="name-oid-assignment">
<a href="#section-10.3" class="section-number selfRef">10.3. </a><a href="#name-oid-assignment" class="section-name selfRef">OID Assignment</a>
        </h3>
<p id="section-10.3-1">IANA has assigned an object identifier from the "SMI
Security for PKIX Module Identifier" registry to identify the
ASN.1 module in <a href="#asn1_module" class="xref">Appendix B</a> of this document.<a href="#section-10.3-1" class="pilcrow">¶</a></p>
<table class="center" id="table-19">
          <caption><a href="#table-19" class="selfRef">Table 19</a></caption>
<thead>
            <tr>
              <th class="text-left" rowspan="1" colspan="1">Decimal</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-left" rowspan="1" colspan="1">References</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-left" rowspan="1" colspan="1">102</td>
              <td class="text-left" rowspan="1" colspan="1">id-mod-public-notary-v2</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9162</td>
            </tr>
          </tbody>
        </table>
</section>
</div>
</section>
</div>
<div id="security-considerations">
<section id="section-11">
      <h2 id="name-security-considerations">
<a href="#section-11" class="section-number selfRef">11. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-11-1">With CAs, logs, and servers performing the actions described here, TLS clients
can use logs and signed timestamps to reduce the likelihood that they will
accept misissued certificates. If a server presents a valid signed timestamp for
a certificate, then the client knows that a log has committed to publishing the
certificate. From this, the client knows that monitors acting for the subject of
the certificate have had some time to notice the misissuance and take some
action, such as asking a CA to revoke a misissued certificate. A signed
timestamp does not guarantee this, though, since appropriate monitors might not
have checked the logs or the CA might have refused to revoke the certificate.<a href="#section-11-1" class="pilcrow">¶</a></p>
<p id="section-11-2">In addition, if TLS clients will not accept unlogged certificates, then site
owners will have a greater incentive to submit certificates to logs, possibly
with the assistance of their CA, increasing the overall transparency of the
system.<a href="#section-11-2" class="pilcrow">¶</a></p>
<div id="misissued-certificates">
<section id="section-11.1">
        <h3 id="name-misissued-certificates">
<a href="#section-11.1" class="section-number selfRef">11.1. </a><a href="#name-misissued-certificates" class="section-name selfRef">Misissued Certificates</a>
        </h3>
<p id="section-11.1-1">Misissued certificates that have not been publicly logged, and thus do not have
a valid SCT, are not considered compliant. Misissued certificates that do have
an SCT from a log will appear in that public log within the Maximum Merge Delay,
assuming the log is operating correctly. Since a log is allowed to serve an STH
of any age up to the MMD, the maximum period of time during which a misissued
certificate can be used without being available for audit is twice the MMD.<a href="#section-11.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="detection-of-misissue">
<section id="section-11.2">
        <h3 id="name-detection-of-misissue">
<a href="#section-11.2" class="section-number selfRef">11.2. </a><a href="#name-detection-of-misissue" class="section-name selfRef">Detection of Misissue</a>
        </h3>
<p id="section-11.2-1">The logs do not themselves detect misissued certificates; they rely instead on
interested parties, such as domain owners, to monitor them and take corrective
action when a misissue is detected.<a href="#section-11.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="misbehaving_logs">
<section id="section-11.3">
        <h3 id="name-misbehaving-logs">
<a href="#section-11.3" class="section-number selfRef">11.3. </a><a href="#name-misbehaving-logs" class="section-name selfRef">Misbehaving Logs</a>
        </h3>
<p id="section-11.3-1">A log can misbehave in several ways. Examples include the following: failing to incorporate a
certificate with an SCT in the Merkle Tree within the MMD; presenting different,
conflicting views of the Merkle Tree at different times and/or to different
parties; issuing STHs too frequently; mutating the signature of a logged
certificate; and failing to present a chain containing the certifier of a logged
certificate.<a href="#section-11.3-1" class="pilcrow">¶</a></p>
<p id="section-11.3-2">Violation of the MMD contract is detected by log clients requesting a Merkle
inclusion proof (<a href="#get-proof-by-hash" class="xref">Section 5.4</a>) for each observed SCT. These checks can
be asynchronous and need only be done once per certificate. However, note that
there may be privacy concerns (see <a href="#fetching_inclusion_proofs" class="xref">Section 8.1.4</a>).<a href="#section-11.3-2" class="pilcrow">¶</a></p>
<p id="section-11.3-3">Violation of the append-only property or the STH issuance rate limit can be
 detected by multiple clients comparing their instances of the STHs.
 This technique, known as "gossip", is an active area of research and not
 defined here.
 Proof of misbehavior in such cases would be either a series of STHs that were
 issued too closely together, proving violation of the STH issuance rate limit,
 or an STH with a root hash that does not match the one calculated from a copy of
 the log, proving violation of the append-only property.<a href="#section-11.3-3" class="pilcrow">¶</a></p>
<p id="section-11.3-4">Clients that report back SCTs can be tracked or traced if a log
produces multiple STHs or SCTs with the same timestamp and data but different
signatures. Logs <span class="bcp14">SHOULD</span> mitigate this risk by either:<a href="#section-11.3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-11.3-5.1">using deterministic signature schemes or<a href="#section-11.3-5.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-11.3-5.2">producing no more than one SCT for each distinct submission and no more than one
   STH for each distinct <code>tree_size</code>. Each of these SCTs and STHs can be stored by
   the log and served to other clients that submit the same certificate or request
   the same STH.<a href="#section-11.3-5.2" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<div id="requiring_multiple_scts">
<section id="section-11.4">
        <h3 id="name-multiple-scts-2">
<a href="#section-11.4" class="section-number selfRef">11.4. </a><a href="#name-multiple-scts-2" class="section-name selfRef">Multiple SCTs</a>
        </h3>
<p id="section-11.4-1">By requiring TLS servers to offer multiple SCTs, each from a different log, TLS
clients reduce the effectiveness of an attack where a CA and a log collude
(see <a href="#multiple-scts" class="xref">Section 6.2</a>).<a href="#section-11.4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="leakage-of-dns-information">
<section id="section-11.5">
        <h3 id="name-leakage-of-dns-information">
<a href="#section-11.5" class="section-number selfRef">11.5. </a><a href="#name-leakage-of-dns-information" class="section-name selfRef">Leakage of DNS Information</a>
        </h3>
<p id="section-11.5-1">Malicious monitors can use logs to learn about the existence of domain names
that might not otherwise be easy to discover. Some subdomain labels may reveal
information about the service and software for which the subdomain is used,
which in turn might facilitate targeted attacks.<a href="#section-11.5-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<section id="section-12">
      <h2 id="name-references">
<a href="#section-12" class="section-number selfRef">12. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-12.1">
        <h3 id="name-normative-references">
<a href="#section-12.1" class="section-number selfRef">12.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="FIPS186-4">[FIPS186-4]</dt>
        <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Digital Signature Standard (DSS)"</span>, <span class="seriesInfo">FIPS PUB 186-4</span>, <time datetime="2013-07" class="refDate">July 2013</time>, <span>&lt;<a href="http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf">http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="HTML401">[HTML401]</dt>
        <dd>
<span class="refAuthor">Raggett, D.</span>, <span class="refAuthor">Le Hors, A.</span>, and <span class="refAuthor">I. Jacobs</span>, <span class="refTitle">"HTML 4.01 Specification"</span>, <span class="seriesInfo">W3C Recommendation SPSD-html401-20180327</span>, <time datetime="2018-03" class="refDate">March 2018</time>, <span>&lt;<a href="https://www.w3.org/TR/2018/SPSD-html401-20180327">https://www.w3.org/TR/2018/SPSD-html401-20180327</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3553">[RFC3553]</dt>
        <dd>
<span class="refAuthor">Mealling, M.</span>, <span class="refAuthor">Masinter, L.</span>, <span class="refAuthor">Hardie, T.</span>, and <span class="refAuthor">G. Klyne</span>, <span class="refTitle">"An IETF URN Sub-namespace for Registered Protocol Parameters"</span>, <span class="seriesInfo">BCP 73</span>, <span class="seriesInfo">RFC 3553</span>, <span class="seriesInfo">DOI 10.17487/RFC3553</span>, <time datetime="2003-06" class="refDate">June 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3553">https://www.rfc-editor.org/info/rfc3553</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3986">[RFC3986]</dt>
        <dd>
<span class="refAuthor">Berners-Lee, T.</span>, <span class="refAuthor">Fielding, R.</span>, and <span class="refAuthor">L. Masinter</span>, <span class="refTitle">"Uniform Resource Identifier (URI): Generic Syntax"</span>, <span class="seriesInfo">STD 66</span>, <span class="seriesInfo">RFC 3986</span>, <span class="seriesInfo">DOI 10.17487/RFC3986</span>, <time datetime="2005-01" class="refDate">January 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3986">https://www.rfc-editor.org/info/rfc3986</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4648">[RFC4648]</dt>
        <dd>
<span class="refAuthor">Josefsson, S.</span>, <span class="refTitle">"The Base16, Base32, and Base64 Data Encodings"</span>, <span class="seriesInfo">RFC 4648</span>, <span class="seriesInfo">DOI 10.17487/RFC4648</span>, <time datetime="2006-10" class="refDate">October 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4648">https://www.rfc-editor.org/info/rfc4648</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5246">[RFC5246]</dt>
        <dd>
<span class="refAuthor">Dierks, T.</span> and <span class="refAuthor">E. Rescorla</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.2"</span>, <span class="seriesInfo">RFC 5246</span>, <span class="seriesInfo">DOI 10.17487/RFC5246</span>, <time datetime="2008-08" class="refDate">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5246">https://www.rfc-editor.org/info/rfc5246</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5280">[RFC5280]</dt>
        <dd>
<span class="refAuthor">Cooper, D.</span>, <span class="refAuthor">Santesson, S.</span>, <span class="refAuthor">Farrell, S.</span>, <span class="refAuthor">Boeyen, S.</span>, <span class="refAuthor">Housley, R.</span>, and <span class="refAuthor">W. Polk</span>, <span class="refTitle">"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"</span>, <span class="seriesInfo">RFC 5280</span>, <span class="seriesInfo">DOI 10.17487/RFC5280</span>, <time datetime="2008-05" class="refDate">May 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5280">https://www.rfc-editor.org/info/rfc5280</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5652">[RFC5652]</dt>
        <dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"Cryptographic Message Syntax (CMS)"</span>, <span class="seriesInfo">STD 70</span>, <span class="seriesInfo">RFC 5652</span>, <span class="seriesInfo">DOI 10.17487/RFC5652</span>, <time datetime="2009-09" class="refDate">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5652">https://www.rfc-editor.org/info/rfc5652</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6066">[RFC6066]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Transport Layer Security (TLS) Extensions: Extension Definitions"</span>, <span class="seriesInfo">RFC 6066</span>, <span class="seriesInfo">DOI 10.17487/RFC6066</span>, <time datetime="2011-01" class="refDate">January 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6066">https://www.rfc-editor.org/info/rfc6066</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6234">[RFC6234]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span> and <span class="refAuthor">T. Hansen</span>, <span class="refTitle">"US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)"</span>, <span class="seriesInfo">RFC 6234</span>, <span class="seriesInfo">DOI 10.17487/RFC6234</span>, <time datetime="2011-05" class="refDate">May 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6234">https://www.rfc-editor.org/info/rfc6234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6960">[RFC6960]</dt>
        <dd>
<span class="refAuthor">Santesson, S.</span>, <span class="refAuthor">Myers, M.</span>, <span class="refAuthor">Ankney, R.</span>, <span class="refAuthor">Malpani, A.</span>, <span class="refAuthor">Galperin, S.</span>, and <span class="refAuthor">C. Adams</span>, <span class="refTitle">"X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"</span>, <span class="seriesInfo">RFC 6960</span>, <span class="seriesInfo">DOI 10.17487/RFC6960</span>, <time datetime="2013-06" class="refDate">June 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6960">https://www.rfc-editor.org/info/rfc6960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6979">[RFC6979]</dt>
        <dd>
<span class="refAuthor">Pornin, T.</span>, <span class="refTitle">"Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)"</span>, <span class="seriesInfo">RFC 6979</span>, <span class="seriesInfo">DOI 10.17487/RFC6979</span>, <time datetime="2013-08" class="refDate">August 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6979">https://www.rfc-editor.org/info/rfc6979</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7231">[RFC7231]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span> and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content"</span>, <span class="seriesInfo">RFC 7231</span>, <span class="seriesInfo">DOI 10.17487/RFC7231</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7231">https://www.rfc-editor.org/info/rfc7231</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7633">[RFC7633]</dt>
        <dd>
<span class="refAuthor">Hallam-Baker, P.</span>, <span class="refTitle">"X.509v3 Transport Layer Security (TLS) Feature Extension"</span>, <span class="seriesInfo">RFC 7633</span>, <span class="seriesInfo">DOI 10.17487/RFC7633</span>, <time datetime="2015-10" class="refDate">October 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7633">https://www.rfc-editor.org/info/rfc7633</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7807">[RFC7807]</dt>
        <dd>
<span class="refAuthor">Nottingham, M.</span> and <span class="refAuthor">E. Wilde</span>, <span class="refTitle">"Problem Details for HTTP APIs"</span>, <span class="seriesInfo">RFC 7807</span>, <span class="seriesInfo">DOI 10.17487/RFC7807</span>, <time datetime="2016-03" class="refDate">March 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7807">https://www.rfc-editor.org/info/rfc7807</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8032">[RFC8032]</dt>
        <dd>
<span class="refAuthor">Josefsson, S.</span> and <span class="refAuthor">I. Liusvaara</span>, <span class="refTitle">"Edwards-Curve Digital Signature Algorithm (EdDSA)"</span>, <span class="seriesInfo">RFC 8032</span>, <span class="seriesInfo">DOI 10.17487/RFC8032</span>, <time datetime="2017-01" class="refDate">January 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8032">https://www.rfc-editor.org/info/rfc8032</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8174">[RFC8174]</dt>
        <dd>
<span class="refAuthor">Leiba, B.</span>, <span class="refTitle">"Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 8174</span>, <span class="seriesInfo">DOI 10.17487/RFC8174</span>, <time datetime="2017-05" class="refDate">May 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8174">https://www.rfc-editor.org/info/rfc8174</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8259">[RFC8259]</dt>
        <dd>
<span class="refAuthor">Bray, T., Ed.</span>, <span class="refTitle">"The JavaScript Object Notation (JSON) Data Interchange Format"</span>, <span class="seriesInfo">STD 90</span>, <span class="seriesInfo">RFC 8259</span>, <span class="seriesInfo">DOI 10.17487/RFC8259</span>, <time datetime="2017-12" class="refDate">December 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8259">https://www.rfc-editor.org/info/rfc8259</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8391">[RFC8391]</dt>
        <dd>
<span class="refAuthor">Huelsing, A.</span>, <span class="refAuthor">Butin, D.</span>, <span class="refAuthor">Gazdag, S.</span>, <span class="refAuthor">Rijneveld, J.</span>, and <span class="refAuthor">A. Mohaisen</span>, <span class="refTitle">"XMSS: eXtended Merkle Signature Scheme"</span>, <span class="seriesInfo">RFC 8391</span>, <span class="seriesInfo">DOI 10.17487/RFC8391</span>, <time datetime="2018-05" class="refDate">May 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8391">https://www.rfc-editor.org/info/rfc8391</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8446">[RFC8446]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="UNIXTIME">[UNIXTIME]</dt>
        <dd>
<span class="refAuthor">IEEE</span>, <span class="refTitle">"The Open Group Base Specifications Issue 7"</span>, <span class="refContent">Section 4.16 Seconds Since the Epoch</span>, <span class="seriesInfo">IEEE Std 1003.1-2008</span>, <time datetime="2016" class="refDate">2016</time>, <span>&lt;<a href="http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/basedefs/V1_chap04.html#tag_04_16">http://pubs.opengroup.org/onlinepubs/9699919799.2016edition/basedefs/V1_chap04.html#tag_04_16</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="X690">[X690]</dt>
      <dd>
<span class="refAuthor">ITU-T</span>, <span class="refTitle">"Information technology - ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)"</span>, <span class="seriesInfo">ITU-T Recommendation X.690</span>, <span class="seriesInfo">ISO/IEC 8825-1</span>, <time datetime="2021-02" class="refDate">February 2021</time>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-12.2">
        <h3 id="name-informative-references">
<a href="#section-12.2" class="section-number selfRef">12.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="CABBR">[CABBR]</dt>
        <dd>
<span class="refAuthor">CA/Browser Forum</span>, <span class="refTitle">"Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates"</span>, <span class="seriesInfo">Version 1.7.3</span>, <time datetime="2020-10" class="refDate">October 2020</time>, <span>&lt;<a href="https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf">https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.7.3.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Chromium.Log.Policy">[Chromium.Log.Policy]</dt>
        <dd>
<span class="refAuthor">The Chromium Projects</span>, <span class="refTitle">"Chromium Certificate Transparency Log Policy"</span>, <span>&lt;<a href="https://googlechrome.github.io/CertificateTransparency/log_policy.html">https://googlechrome.github.io/CertificateTransparency/log_policy.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="Chromium.Policy">[Chromium.Policy]</dt>
        <dd>
<span class="refAuthor">The Chromium Projects</span>, <span class="refTitle">"Chromium Certificate Transparency Policy"</span>, <span>&lt;<a href="https://googlechrome.github.io/CertificateTransparency/ct_policy.html">https://googlechrome.github.io/CertificateTransparency/ct_policy.html</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="CrosbyWallach">[CrosbyWallach]</dt>
        <dd>
<span class="refAuthor">Crosby, S.</span> and <span class="refAuthor">D. Wallach</span>, <span class="refTitle">"Efficient Data Structures for Tamper-Evident Logging"</span>, <span class="refContent">Proceedings of the 18th USENIX Security Symposium, Montreal</span>, <time datetime="2009-08" class="refDate">August 2009</time>, <span>&lt;<a href="http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf">http://static.usenix.org/event/sec09/tech/full_papers/crosby.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="JSON.Metadata">[JSON.Metadata]</dt>
        <dd>
<span class="refAuthor">The Chromium Projects</span>, <span class="refTitle">"Chromium Log Metadata JSON Schema"</span>, <span>&lt;<a href="https://www.gstatic.com/ct/log_list/log_list_schema.json">https://www.gstatic.com/ct/log_list/log_list_schema.json</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5912">[RFC5912]</dt>
        <dd>
<span class="refAuthor">Hoffman, P.</span> and <span class="refAuthor">J. Schaad</span>, <span class="refTitle">"New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)"</span>, <span class="seriesInfo">RFC 5912</span>, <span class="seriesInfo">DOI 10.17487/RFC5912</span>, <time datetime="2010-06" class="refDate">June 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5912">https://www.rfc-editor.org/info/rfc5912</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6268">[RFC6268]</dt>
        <dd>
<span class="refAuthor">Schaad, J.</span> and <span class="refAuthor">S. Turner</span>, <span class="refTitle">"Additional New ASN.1 Modules for the Cryptographic Message Syntax (CMS) and the Public Key Infrastructure Using X.509 (PKIX)"</span>, <span class="seriesInfo">RFC 6268</span>, <span class="seriesInfo">DOI 10.17487/RFC6268</span>, <time datetime="2011-07" class="refDate">July 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6268">https://www.rfc-editor.org/info/rfc6268</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6962">[RFC6962]</dt>
        <dd>
<span class="refAuthor">Laurie, B.</span>, <span class="refAuthor">Langley, A.</span>, and <span class="refAuthor">E. Kasper</span>, <span class="refTitle">"Certificate Transparency"</span>, <span class="seriesInfo">RFC 6962</span>, <span class="seriesInfo">DOI 10.17487/RFC6962</span>, <time datetime="2013-06" class="refDate">June 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6962">https://www.rfc-editor.org/info/rfc6962</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
        <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8820">[RFC8820]</dt>
        <dd>
<span class="refAuthor">Nottingham, M.</span>, <span class="refTitle">"URI Design and Ownership"</span>, <span class="seriesInfo">BCP 190</span>, <span class="seriesInfo">RFC 8820</span>, <span class="seriesInfo">DOI 10.17487/RFC8820</span>, <time datetime="2020-06" class="refDate">June 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8820">https://www.rfc-editor.org/info/rfc8820</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="X.680">[X.680]</dt>
      <dd>
<span class="refAuthor">ITU-T</span>, <span class="refTitle">"Information technology - Abstract Syntax Notation One (ASN.1): Specification of basic notation"</span>, <span class="seriesInfo">ITU-T Recommendation X.680</span>, <time datetime="2021-02" class="refDate">February 2021</time>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="v1_coexistence">
<section id="appendix-A">
      <h2 id="name-supporting-v1-and-v2-simult">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-supporting-v1-and-v2-simult" class="section-name selfRef">Supporting v1 and v2 Simultaneously (Informative)</a>
      </h2>
<p id="appendix-A-1">Certificate Transparency logs have to be either v1 (conforming to <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span>) or
v2 (conforming to this document), as the data structures are incompatible, and so
a v2 log could not issue a valid v1 SCT.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">CT clients, however, can support v1 and v2 SCTs for the same certificate
simultaneously, as v1 SCTs are delivered in different TLS, X.509, and OCSP
extensions than v2 SCTs.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3">v1 and v2 SCTs for X.509 certificates can be validated independently. For
precertificates, v2 SCTs should be embedded in the TBSCertificate before
submission of the TBSCertificate (inside a v1 precertificate, as described in
<span><a href="https://www.rfc-editor.org/rfc/rfc6962#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC6962" class="xref">RFC6962</a>]</span>) to a v1 log so that TLS clients conforming to
<span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span> but not this document are oblivious to the embedded v2 SCTs. An issuer
can follow these steps to produce an X.509 certificate with embedded v1 and v2
SCTs:<a href="#appendix-A-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-A-4.1">Create a CMS precertificate, as described in <a href="#precertificates" class="xref">Section 3.2</a>, and submit it to v2 logs.<a href="#appendix-A-4.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-A-4.2">Embed the obtained v2 SCTs in the TBSCertificate, as described in
 <a href="#cert_transinfo_extension" class="xref">Section 7.1.2</a>.<a href="#appendix-A-4.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-A-4.3">Use that TBSCertificate to create a v1 precertificate, as described in
 <span><a href="https://www.rfc-editor.org/rfc/rfc6962#section-3.1" class="relref">Section 3.1</a> of [<a href="#RFC6962" class="xref">RFC6962</a>]</span>, and submit it to v1
 logs.<a href="#appendix-A-4.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-A-4.4">Embed the v1 SCTs in the TBSCertificate, as described in
 <span><a href="https://www.rfc-editor.org/rfc/rfc6962#section-3.3" class="relref">Section 3.3</a> of [<a href="#RFC6962" class="xref">RFC6962</a>]</span>.<a href="#appendix-A-4.4" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-A-4.5">Sign that TBSCertificate (which now contains v1 and v2 SCTs) to issue the
 final X.509 certificate.<a href="#appendix-A-4.5" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="asn1_module">
<section id="appendix-B">
      <h2 id="name-an-asn1-module-informative">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-an-asn1-module-informative" class="section-name selfRef">An ASN.1 Module (Informative)</a>
      </h2>
<p id="appendix-B-1">The following ASN.1 <span>[<a href="#X.680" class="xref">X.680</a>]</span> module may be useful to implementors. This module references <span>[<a href="#RFC5912" class="xref">RFC5912</a>]</span> and <span>[<a href="#RFC6268" class="xref">RFC6268</a>]</span>.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<div id="appendix-B-2">
<pre class="lang-asn.1 sourcecode">
CertificateTransparencyV2Module-2021
 -- { id-mod-public-notary-v2 from above, in
        iso(1) identified-organization(3) ...
    form }
DEFINITIONS IMPLICIT TAGS ::= BEGIN

-- EXPORTS ALL --

IMPORTS
  EXTENSION
  FROM PKIX-CommonTypes-2009 -- RFC 5912
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkixCommon-02(57) }

  CONTENT-TYPE
  FROM CryptographicMessageSyntax-2010  -- RFC 6268
    { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
      pkcs-9(9) smime(16) modules(0) id-mod-cms-2009(58) }

  TBSCertificate
  FROM PKIX1Explicit-2009 -- RFC 5912
    { iso(1) identified-organization(3) dod(6) internet(1)
      security(5) mechanisms(5) pkix(7) id-mod(0)
      id-mod-pkix1-explicit-02(51) }
;

--
-- Section 3.2.  Precertificates
--

ct-tbsCertificate CONTENT-TYPE ::= {
  TYPE TBSCertificate
  IDENTIFIED BY id-ct-tbsCertificate }

id-ct-tbsCertificate OBJECT IDENTIFIER ::= { 1 3 101 78 }

--
-- Section 7.1.  Transparency Information X.509v3 Extension
--

ext-transparencyInfo EXTENSION ::= {
   SYNTAX TransparencyInformationSyntax
   IDENTIFIED BY id-ce-transparencyInfo
   CRITICALITY { FALSE } }

id-ce-transparencyInfo OBJECT IDENTIFIER ::= { 1 3 101 75 }

TransparencyInformationSyntax ::= OCTET STRING

--
-- Section 7.1.1.  OCSP Response Extension
--

ext-ocsp-transparencyInfo EXTENSION ::= {
   SYNTAX TransparencyInformationSyntax
   IDENTIFIED BY id-pkix-ocsp-transparencyInfo
   CRITICALITY { FALSE } }

id-pkix-ocsp-transparencyInfo OBJECT IDENTIFIER ::=
   id-ce-transparencyInfo

--
-- Section 8.1.2.  Reconstructing the TBSCertificate
--

ext-embeddedSCT-CTv1 EXTENSION ::= {
   SYNTAX SignedCertificateTimestampList
   IDENTIFIED BY id-ce-embeddedSCT-CTv1
   CRITICALITY { FALSE } }

id-ce-embeddedSCT-CTv1 OBJECT IDENTIFIER ::= {
   1 3 6 1 4 1 11129 2 4 2 }

SignedCertificateTimestampList ::= OCTET STRING

END

</pre><a href="#appendix-B-2" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="acknowledgements">
<section id="appendix-C">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-C-1">The authors would like to thank <span class="contact-name">Erwann Abelea</span>, <span class="contact-name">Robin Alden</span>, <span class="contact-name">Andrew Ayer</span>, <span class="contact-name">Richard       Barnes</span>, <span class="contact-name">Al Cutter</span>, <span class="contact-name">David Drysdale</span>,
      <span class="contact-name">Francis Dupont</span>, <span class="contact-name">Adam Eijdenberg</span>, <span class="contact-name">Stephen Farrell</span>, <span class="contact-name">Daniel Kahn Gillmor</span>, <span class="contact-name">Paul Hadfield</span>, <span class="contact-name">Brad Hill</span>, <span class="contact-name">Jeff       Hodges</span>, <span class="contact-name">Paul       Hoffman</span>, <span class="contact-name">Jeffrey Hutzelman</span>, <span class="contact-name">Kat Joyce</span>,
      <span class="contact-name">Emilia Kasper</span>, <span class="contact-name">Stephen Kent</span>, <span class="contact-name">Adam Langley</span>, <span class="contact-name">SM</span>, <span class="contact-name">Alexey       Melnikov</span>, <span class="contact-name">Linus       Nordberg</span>, <span class="contact-name">Chris Palmer</span>, <span class="contact-name">Trevor Perrin</span>,
      <span class="contact-name">Pierre Phaneuf</span>, <span class="contact-name">Eric Rescorla</span>, <span class="contact-name">Rich Salz</span>, <span class="contact-name">Melinda Shore</span>, <span class="contact-name">Ryan       Sleevi</span>, <span class="contact-name">Martin Smith</span>, <span class="contact-name">Carl Wallace</span>,
      and <span class="contact-name">Paul Wouters</span> for their valuable contributions.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<p id="appendix-C-2">A big thank you to Symantec for kindly donating the OIDs from the 1.3.101 arc
      that are used in this document.<a href="#appendix-C-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-D">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Ben Laurie</span></div>
<div dir="auto" class="left"><span class="org">Google UK Ltd.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:benl@google.com" class="email">benl@google.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Eran Messeri</span></div>
<div dir="auto" class="left"><span class="org">Google UK Ltd.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:eranm@google.com" class="email">eranm@google.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Rob Stradling</span></div>
<div dir="auto" class="left"><span class="org">Sectigo Ltd.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:rob@sectigo.com" class="email">rob@sectigo.com</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>