File: rfc9163.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 (2571 lines) | stat: -rw-r--r-- 121,890 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 9163: Expect-CT Extension for HTTP</title>
<meta content="Emily Stark" name="author">
<meta content='
       This document defines a new HTTP header field named "Expect-CT", which
      allows web host operators to instruct user agents (UAs) to expect valid
      Signed Certificate Timestamps (SCTs) to be served on connections to
      these hosts. Expect-CT allows web host operators to discover
      misconfigurations in their Certificate Transparency (CT)
      deployments. Further, web host operators can use Expect-CT to ensure
      that if a UA that supports Expect-CT accepts a misissued certificate,
      that certificate will be discoverable in Certificate Transparency
      logs. 
    ' name="description">
<meta content="xml2rfc 3.12.10" name="generator">
<meta content="Certificate Transparency" name="keyword">
<meta content="Expect-CT" name="keyword">
<meta content="9163" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.10
    Python 3.6.15
    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.7.1
    MarkupSafe 2.0.1
    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="rfc9163.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;
  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;
  }
  pre.breakable {
    break-inside: auto;
  }
  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/rfc9163" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-httpbis-expect-ct-08" 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 9163</td>
<td class="center">Expect-CT</td>
<td class="right">June 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Stark</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/rfc9163" class="eref">9163</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Experimental</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-06" class="published">June 2022</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Author:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">E. Stark</div>
<div class="org">Google</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9163</h1>
<h1 id="title">Expect-CT Extension for HTTP</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document defines a new HTTP header field named "Expect-CT", which
      allows web host operators to instruct user agents (UAs) to expect valid
      Signed Certificate Timestamps (SCTs) to be served on connections to
      these hosts. Expect-CT allows web host operators to discover
      misconfigurations in their Certificate Transparency (CT)
      deployments. Further, web host operators can use Expect-CT to ensure
      that if a UA that supports Expect-CT accepts a misissued certificate,
      that certificate will be discoverable in Certificate Transparency
      logs.<a href="#section-abstract-1" 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/rfc9163">https://www.rfc-editor.org/info/rfc9163</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) 2022 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" class="keepWithNext"><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-terminology" class="xref">Terminology</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-server-and-client-behavior" class="xref">Server and Client Behavior</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-response-header-field-synta" class="xref">Response Header Field Syntax</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-the-report-uri-directive" class="xref">The report-uri Directive</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-the-enforce-directive" class="xref">The enforce Directive</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-the-max-age-directive" class="xref">The max-age Directive</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-examples" class="xref">Examples</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-host-processing-model" class="xref">Host Processing Model</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2.2.1">
                    <p id="section-toc.1-1.2.2.2.2.1.1"><a href="#section-2.2.1" class="xref">2.2.1</a>.  <a href="#name-http-over-secure-transport-" class="xref">HTTP-over-Secure-Transport Request Type</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.2.2.2">
                    <p id="section-toc.1-1.2.2.2.2.2.1"><a href="#section-2.2.2" class="xref">2.2.2</a>.  <a href="#name-http-request-type" class="xref">HTTP Request Type</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3">
                <p id="section-toc.1-1.2.2.3.1"><a href="#section-2.3" class="xref">2.3</a>.  <a href="#name-user-agent-processing-model" class="xref">User Agent Processing Model</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3.2.1">
                    <p id="section-toc.1-1.2.2.3.2.1.1"><a href="#section-2.3.1" class="xref">2.3.1</a>.  <a href="#name-missing-or-malformed-expect" class="xref">Missing or Malformed Expect-CT Header Fields</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3.2.2">
                    <p id="section-toc.1-1.2.2.3.2.2.1"><a href="#section-2.3.2" class="xref">2.3.2</a>.  <a href="#name-expect-ct-header-field-proc" class="xref">Expect-CT Header Field Processing</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.3.2.3">
                    <p id="section-toc.1-1.2.2.3.2.3.1"><a href="#section-2.3.3" class="xref">2.3.3</a>.  <a href="#name-reporting" class="xref">Reporting</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4">
                <p id="section-toc.1-1.2.2.4.1"><a href="#section-2.4" class="xref">2.4</a>.  <a href="#name-evaluating-expect-ct-connec" class="xref">Evaluating Expect-CT Connections for CT Compliance</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2.2.4.2.1">
                    <p id="section-toc.1-1.2.2.4.2.1.1"><a href="#section-2.4.1" class="xref">2.4.1</a>.  <a href="#name-skipping-ct-compliance-chec" class="xref">Skipping CT Compliance Checks</a></p>
</li>
                </ul>
</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-reporting-expect-ct-failure" class="xref">Reporting Expect-CT Failure</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-generating-a-violation-repo" class="xref">Generating a Violation Report</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-sending-a-violation-report" class="xref">Sending a Violation Report</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-receiving-a-violation-repor" class="xref">Receiving a Violation Report</a></p>
</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-usability-considerations" class="xref">Usability Considerations</a></p>
</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-authoring-considerations" class="xref">Authoring Considerations</a></p>
</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-privacy-considerations" class="xref">Privacy Considerations</a></p>
</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-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.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-hostile-header-attacks" class="xref">Hostile Header Attacks</a></p>
</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-maximum-max-age" class="xref">Maximum max-age</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.3">
                <p id="section-toc.1-1.7.2.3.1"><a href="#section-7.3" class="xref">7.3</a>.  <a href="#name-amplification-attacks" class="xref">Amplification Attacks</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-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.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-header-field-registry" class="xref">Header Field Registry</a></p>
</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-media-types-registry" class="xref">Media Types Registry</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-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9.2.1">
                <p id="section-toc.1-1.9.2.1.1"><a href="#section-9.1" class="xref">9.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.9.2.2">
                <p id="section-toc.1-1.9.2.2.1"><a href="#section-9.2" class="xref">9.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.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-A" class="xref"></a><a href="#name-authors-address" class="xref">Author's Address</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">This document defines a new HTTP header field (<span>[<a href="#RFC9110" class="xref">RFC9110</a>], <a href="https://www.rfc-editor.org/rfc/rfc9110#section-6.3" class="relref">Section 6.3</a></span>) that enables UAs to
      identify web hosts that expect the presence of Signed Certificate
      Timestamps (SCTs) <span>[<a href="#RFC9162" class="xref">RFC9162</a>]</span> in
      subsequent Transport Layer Security (TLS) <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> connections.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">Web hosts that serve the Expect-CT header field are noted by the
      UA as "Known Expect-CT Hosts". The UA evaluates each connection to a Known
      Expect-CT Host for compliance with the UA's Certificate Transparency
      (CT) Policy. If the connection violates the CT Policy, the UA sends a
      report to a URI configured by the Expect-CT Host and/or fails the
      connection, depending on the configuration that the Expect-CT Host has
      chosen.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">If misconfigured, Expect-CT can cause unwanted connection failures
      (for example, if a host deploys Expect-CT but then switches to a
      legitimate certificate that is not logged in Certificate Transparency
      logs or if a web host operator believes their certificate to conform to
      all UAs' CT policies but is mistaken). Web host operators are advised to
      deploy Expect-CT with precautions by using the reporting feature and
      gradually increasing the time interval during which the UA regards the
      host as a Known Expect-CT Host. These precautions can help web host
      operators gain confidence that their Expect-CT deployment is not causing
      unwanted connection failures.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">Expect-CT is a trust-on-first-use (TOFU) mechanism. The first time a
      UA connects to a host, it lacks the information necessary to require
      SCTs for the connection. Thus, the UA will not be able to detect and
      thwart an attack on the UA's first connection to the host. Still,
      Expect-CT provides value by 1) allowing UAs to detect the use of
      unlogged certificates after the initial communication, and 2) allowing
      web hosts to be confident that UAs are only trusting publicly auditable
      certificates.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">Expect-CT is similar to HTTP Strict Transport Security (HSTS) <span>[<a href="#RFC6797" class="xref">RFC6797</a>]</span> and HTTP Public Key Pinning (HPKP)
      <span>[<a href="#RFC7469" class="xref">RFC7469</a>]</span>. HSTS allows websites to
      declare themselves accessible only via secure connections, and HPKP
      allows websites to declare their cryptographic identifies. Similarly,
      Expect-CT allows websites to declare themselves accessible only via
      connections that are compliant with CT Policy.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">This Expect-CT specification is compatible with <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span> and <span>[<a href="#RFC9162" class="xref">RFC9162</a>]</span>, but not necessarily with future versions of Certificate
      Transparency.

      UAs will ignore Expect-CT header fields from web hosts that use future
      versions of Certificate Transparency, unless a future version of this
      document specifies how they should be processed.<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="terminology">
<section id="section-1.2">
        <h3 id="name-terminology">
<a href="#section-1.2" class="section-number selfRef">1.2. </a><a href="#name-terminology" class="section-name selfRef">Terminology</a>
        </h3>
<p id="section-1.2-1">Terminology is defined in this section.<a href="#section-1.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-1.2-2">
          <dt id="section-1.2-2.1">"Certificate Transparency Policy"
</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-2.2">A policy defined by the UA concerning the number, sources, and delivery
mechanisms of Signed Certificate Timestamps that are associated with TLS
connections. The policy defines the properties of a connection that must be
met in order for the UA to consider it CT qualified.<a href="#section-1.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.3">"Certificate Transparency Qualified"
</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-2.4">Describes a TLS connection for which the UA has determined that a
sufficient quantity and quality of Signed Certificate Timestamps have been provided.<a href="#section-1.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.5">"CT Qualified"
</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-2.6">An abbreviation for "Certificate Transparency Qualified".<a href="#section-1.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.7">"CT Policy"
</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-2.8">An abbreviation for "Certificate Transparency Policy".<a href="#section-1.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.9">"Effective Expect-CT Date"
</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-2.10">The time at which a UA observed a valid Expect-CT header field for a given host.<a href="#section-1.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.11">"Expect-CT Host"
</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-2.12">A conformant host implementing the HTTP server aspects of Expect-CT. This
means that an Expect-CT Host returns the Expect-CT response header
field in its HTTP response messages sent over secure transport. The term
"host" is equivalent to "server" in this specification.<a href="#section-1.2-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.13">"Known Expect-CT Host"
</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-2.14">An Expect-CT Host that the UA has noted as such. See <a href="#noting-expect-ct" class="xref">Section 2.3.2.1</a> for particulars.<a href="#section-1.2-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.15">"User Agent (UA)"
</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-2.16">For the purposes of this specification, a UA is an HTTP client application
typically actively manipulated by a user <span>[<a href="#RFC9110" class="xref">RFC9110</a>]</span>.<a href="#section-1.2-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-1.2-2.17">"Unknown Expect-CT Host"
</dt>
          <dd style="margin-left: 1.5em" id="section-1.2-2.18">An Expect-CT Host that the UA has not noted.<a href="#section-1.2-2.18" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<div id="server-and-client-behavior">
<section id="section-2">
      <h2 id="name-server-and-client-behavior">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-server-and-client-behavior" class="section-name selfRef">Server and Client Behavior</a>
      </h2>
<div id="response-header-field-syntax">
<section id="section-2.1">
        <h3 id="name-response-header-field-synta">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-response-header-field-synta" class="section-name selfRef">Response Header Field Syntax</a>
        </h3>
<p id="section-2.1-1">The Expect-CT response header field is a new field defined in
        this specification. It is used by a server to indicate that UAs should
        evaluate connections to the host emitting the header field for CT
        compliance (<a href="#expect-ct-compliance" class="xref">Section 2.4</a>).<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2"><a href="#expect-ct-syntax" class="xref">Figure 1</a> describes the
        syntax (Augmented Backus-Naur Form) of the header field, using the
        grammar defined in <span>[<a href="#RFC5234" class="xref">RFC5234</a>]</span> and the
        rules defined in <span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-5" class="relref">Section 5</a> of [<a href="#RFC9110" class="xref">RFC9110</a>]</span>. The "#" ABNF extension is specified in <span><a href="https://www.rfc-editor.org/rfc/rfc9110#section-5.6.1" class="relref">Section 5.6.1</a> of [<a href="#RFC9110" class="xref">RFC9110</a>]</span>.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<span id="name-syntax-of-the-expect-ct-hea"></span><div id="expect-ct-syntax">
<figure id="figure-1">
          <div id="section-2.1-3.1">
<pre class="lang-abnf sourcecode">
Expect-CT           = 1#expect-ct-directive
expect-ct-directive = directive-name [ "=" directive-value ]
directive-name      = token
directive-value     = token / quoted-string
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-syntax-of-the-expect-ct-hea" class="selfRef">Syntax of the Expect-CT Header Field</a>
          </figcaption></figure>
</div>
<p id="section-2.1-4">The directives defined in this specification are described below. The overall
requirements for directives are:<a href="#section-2.1-4" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-2.1-5">
  <li id="section-2.1-5.1">The order of appearance of directives is not significant.<a href="#section-2.1-5.1" class="pilcrow">¶</a>
</li>
          <li id="section-2.1-5.2">A given directive <span class="bcp14">MUST NOT</span> appear more than once in a given header
field. Directives are either optional or required, as stipulated in their
definitions.<a href="#section-2.1-5.2" class="pilcrow">¶</a>
</li>
          <li id="section-2.1-5.3">Directive names are case insensitive.<a href="#section-2.1-5.3" class="pilcrow">¶</a>
</li>
          <li id="section-2.1-5.4">UAs <span class="bcp14">MUST</span> ignore any header fields containing
          directives, or other header field value data that does not conform to
          the syntax defined in this specification.  In particular, UAs
          <span class="bcp14">MUST NOT</span> attempt to fix malformed header fields.<a href="#section-2.1-5.4" class="pilcrow">¶</a>
</li>
          <li id="section-2.1-5.5">If a header field contains any directive(s) the UA does not
          recognize, the UA <span class="bcp14">MUST</span> ignore those directives.<a href="#section-2.1-5.5" class="pilcrow">¶</a>
</li>
          <li id="section-2.1-5.6">If the Expect-CT header field otherwise satisfies the above
          requirements (1 through 5), and Expect-CT is not disabled for local
          policy reasons (as discussed in <a href="#skipping-ct-compliance-checks" class="xref">Section 2.4.1</a>), the UA
          <span class="bcp14">MUST</span> process the directives it recognizes.<a href="#section-2.1-5.6" class="pilcrow">¶</a>
</li>
        </ol>
<div id="the-report-uri-directive">
<section id="section-2.1.1">
          <h4 id="name-the-report-uri-directive">
<a href="#section-2.1.1" class="section-number selfRef">2.1.1. </a><a href="#name-the-report-uri-directive" class="section-name selfRef">The report-uri Directive</a>
          </h4>
<p id="section-2.1.1-1">The <span class="bcp14">OPTIONAL</span> <code>report-uri</code> directive
          indicates the URI to which the UA <span class="bcp14">SHOULD</span> report
          Expect-CT failures (<a href="#expect-ct-compliance" class="xref">Section 2.4</a>). The UA POSTs the reports to the given URI as
          described in <a href="#reporting-expect-ct-failure" class="xref">Section 3</a>.<a href="#section-2.1.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1.1-2">The <code>report-uri</code> directive is <span class="bcp14">REQUIRED</span> to
          have a directive value, for which the syntax is defined in <a href="#reporturi-syntax" class="xref">Figure 2</a>.<a href="#section-2.1.1-2" class="pilcrow">¶</a></p>
<span id="name-syntax-of-the-report-uri-di"></span><div id="reporturi-syntax">
<figure id="figure-2">
            <div id="section-2.1.1-3.1">
<pre class="lang-abnf sourcecode">
report-uri-value = (DQUOTE absolute-URI DQUOTE) / absolute-URI
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-syntax-of-the-report-uri-di" class="selfRef">Syntax of the report-uri Directive Value</a>
            </figcaption></figure>
</div>
<p id="section-2.1.1-4">The 'report-uri-value' <span class="bcp14">MUST</span> be quoted if it contains any
   character not allowed in 'token'.<a href="#section-2.1.1-4" class="pilcrow">¶</a></p>
<p id="section-2.1.1-5"><code>absolute-URI</code> is defined in <span><a href="https://www.rfc-editor.org/rfc/rfc3986#section-4.3" class="relref">Section 4.3</a> of [<a href="#RFC3986" class="xref">RFC3986</a>]</span>.<a href="#section-2.1.1-5" class="pilcrow">¶</a></p>
<p id="section-2.1.1-6">UAs <span class="bcp14">MUST</span> ignore any <code>report-uri</code> that does
          not use the HTTPS scheme. UAs <span class="bcp14">MUST</span> check Expect-CT
          compliance when the host in the <code>report-uri</code> is a Known
          Expect-CT Host; similarly, UAs <span class="bcp14">MUST</span> apply HSTS <span>[<a href="#RFC6797" class="xref">RFC6797</a>]</span> if the host in the
          <code>report-uri</code> is a Known HSTS Host.<a href="#section-2.1.1-6" class="pilcrow">¶</a></p>
<p id="section-2.1.1-7">UAs <span class="bcp14">SHOULD</span> make their best effort to report
          Expect-CT failures to the <code>report-uri</code>, but they may fail to
          report in exceptional conditions.  For example, if connecting to the
          <code>report-uri</code> itself incurs an Expect-CT failure or other
          certificate validation failure, the UA <span class="bcp14">MUST</span> cancel
          the connection.  Similarly, if Expect-CT Host A sets a
          <code>report-uri</code> referring to Expect-CT Host B, and if B sets a
          <code>report-uri</code> referring to A, and if both hosts fail to comply
          to the UA's CT Policy, the UA <span class="bcp14">SHOULD</span> detect and break
          the loop by failing to send reports to and about those hosts.<a href="#section-2.1.1-7" class="pilcrow">¶</a></p>
<p id="section-2.1.1-8">Note that the <code>report-uri</code> need not necessarily be in the same
          Internet domain or web origin as the host being reported
          about. Hosts are in fact encouraged to use a separate host as the
          <code>report-uri</code> so that CT failures on the Expect-CT Host do not prevent
          reports from being sent.<a href="#section-2.1.1-8" class="pilcrow">¶</a></p>
<p id="section-2.1.1-9">UAs <span class="bcp14">SHOULD</span> limit the rate at which they send reports. For example, it is
unnecessary to send the same report to the same <code>report-uri</code> more than once in
the same web-browsing session.<a href="#section-2.1.1-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-enforce-directive">
<section id="section-2.1.2">
          <h4 id="name-the-enforce-directive">
<a href="#section-2.1.2" class="section-number selfRef">2.1.2. </a><a href="#name-the-enforce-directive" class="section-name selfRef">The enforce Directive</a>
          </h4>
<p id="section-2.1.2-1">The <span class="bcp14">OPTIONAL</span> <code>enforce</code> directive is a valueless directive that, if present
(i.e., it is "asserted"), signals to the UA that compliance to the CT Policy
should be enforced (rather than report-only) and that the UA should refuse
future connections that violate its CT Policy. When both the <code>enforce</code> directive
and <code>report-uri</code> directive (as defined in <a href="#reporturi-syntax" class="xref">Figure 2</a>) are present, the
configuration is referred to as an "enforce-and-report" configuration,
signaling to the UA that both compliance to the CT Policy should be enforced
and violations should be reported.<a href="#section-2.1.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-max-age-directive">
<section id="section-2.1.3">
          <h4 id="name-the-max-age-directive">
<a href="#section-2.1.3" class="section-number selfRef">2.1.3. </a><a href="#name-the-max-age-directive" class="section-name selfRef">The max-age Directive</a>
          </h4>
<p id="section-2.1.3-1">The <code>max-age</code> directive specifies the number of seconds after the reception of
the Expect-CT header field during which the UA <span class="bcp14">SHOULD</span> regard the host from whom
the message was received as a Known Expect-CT Host.<a href="#section-2.1.3-1" class="pilcrow">¶</a></p>
<p id="section-2.1.3-2">If a response contains an Expect-CT header field, then the response <span class="bcp14">MUST</span>
contain an Expect-CT header field with a <code>max-age</code> directive. (A <code>max-age</code>
directive need not appear in every Expect-CT header field in the response.)
The <code>max-age</code> directive is <span class="bcp14">REQUIRED</span> to have a directive value, for which the
syntax (after quoted-string unescaping, if necessary) is defined in
   <a href="#maxage-syntax" class="xref">Figure 3</a>.<a href="#section-2.1.3-2" class="pilcrow">¶</a></p>
<span id="name-syntax-of-the-max-age-direc"></span><div id="maxage-syntax">
<figure id="figure-3">
            <div id="section-2.1.3-3.1">
<pre class="lang-abnf sourcecode">
max-age-value = delta-seconds
delta-seconds = 1*DIGIT
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-syntax-of-the-max-age-direc" class="selfRef">Syntax of the max-age Directive Value</a>
            </figcaption></figure>
</div>
<p id="section-2.1.3-4"><code>delta-seconds</code> is used as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc9111#section-1.3" class="relref">Section 1.3</a> of [<a href="#RFC9111" class="xref">RFC9111</a>]</span>.<a href="#section-2.1.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="examples">
<section id="section-2.1.4">
          <h4 id="name-examples">
<a href="#section-2.1.4" class="section-number selfRef">2.1.4. </a><a href="#name-examples" class="section-name selfRef">Examples</a>
          </h4>
<p id="section-2.1.4-1">The following three examples demonstrate valid Expect-CT response header fields
(where the second splits the directives into two field instances):<a href="#section-2.1.4-1" class="pilcrow">¶</a></p>
<span id="name-examples-of-valid-expect-ct"></span><div id="example-header-fields">
<figure id="figure-4">
            <div class="alignLeft art-http-headers art-text artwork" id="section-2.1.4-2.1">
<pre>
Expect-CT: max-age=86400, enforce

Expect-CT: max-age=86400,enforce
Expect-CT: report-uri="https://foo.example/report"

Expect-CT: max-age=86400,report-uri="https://foo.example/report"
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-examples-of-valid-expect-ct" class="selfRef">Examples of Valid Expect-CT ResponseHeader Fields</a>
            </figcaption></figure>
</div>
</section>
</div>
</section>
</div>
<div id="host-processing-model">
<section id="section-2.2">
        <h3 id="name-host-processing-model">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-host-processing-model" class="section-name selfRef">Host Processing Model</a>
        </h3>
<p id="section-2.2-1">This section describes the processing model that Expect-CT Hosts implement.  The
model has 2 parts: (1) the processing rules for HTTP request messages received
over a secure transport (e.g., authenticated, non-anonymous TLS); and (2) the
processing rules for HTTP request messages received over non-secure transports,
such as TCP.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<div id="http-over-secure-transport-request-type">
<section id="section-2.2.1">
          <h4 id="name-http-over-secure-transport-">
<a href="#section-2.2.1" class="section-number selfRef">2.2.1. </a><a href="#name-http-over-secure-transport-" class="section-name selfRef">HTTP-over-Secure-Transport Request Type</a>
          </h4>
<p id="section-2.2.1-1">An Expect-CT Host includes an Expect-CT header field in its response. The header
field <span class="bcp14">MUST</span> satisfy the grammar specified in <a href="#response-header-field-syntax" class="xref">Section 2.1</a>.<a href="#section-2.2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.2.1-2">Establishing a given host as an Expect-CT Host, in the context of a given UA,
is accomplished as follows:<a href="#section-2.2.1-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-2.2.1-3">
  <li id="section-2.2.1-3.1">Over the HTTP protocol running over secure transport, by correctly returning
(per this specification) a valid Expect-CT header field to the UA.<a href="#section-2.2.1-3.1" class="pilcrow">¶</a>
</li>
            <li id="section-2.2.1-3.2">Through other mechanisms such as a client-side preloaded Expect-CT Host
list.<a href="#section-2.2.1-3.2" class="pilcrow">¶</a>
</li>
          </ol>
</section>
</div>
<div id="http-request-type">
<section id="section-2.2.2">
          <h4 id="name-http-request-type">
<a href="#section-2.2.2" class="section-number selfRef">2.2.2. </a><a href="#name-http-request-type" class="section-name selfRef">HTTP Request Type</a>
          </h4>
<p id="section-2.2.2-1">Expect-CT Hosts <span class="bcp14">SHOULD NOT</span> include the Expect-CT header field in HTTP responses
conveyed over non-secure transport.<a href="#section-2.2.2-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="user-agent-processing-model">
<section id="section-2.3">
        <h3 id="name-user-agent-processing-model">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-user-agent-processing-model" class="section-name selfRef">User Agent Processing Model</a>
        </h3>
<p id="section-2.3-1">The UA processing model relies on parsing domain names.  Note that
internationalized domain names <span class="bcp14">SHALL</span> be canonicalized by the UA according to the
scheme in <span><a href="https://www.rfc-editor.org/rfc/rfc6797#section-10" class="relref">Section 10</a> of [<a href="#RFC6797" class="xref">RFC6797</a>]</span>.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">The UA stores Known Expect-CT Hosts and their associated Expect-CT
directives. This data is collectively known as a host's "Expect-CT metadata".<a href="#section-2.3-2" class="pilcrow">¶</a></p>
<div id="missing-or-malformed-expect-ct-header-fields">
<section id="section-2.3.1">
          <h4 id="name-missing-or-malformed-expect">
<a href="#section-2.3.1" class="section-number selfRef">2.3.1. </a><a href="#name-missing-or-malformed-expect" class="section-name selfRef">Missing or Malformed Expect-CT Header Fields</a>
          </h4>
<p id="section-2.3.1-1">If an HTTP response does not include an Expect-CT header field that conforms to
the grammar specified in <a href="#response-header-field-syntax" class="xref">Section 2.1</a>, then the UA <span class="bcp14">MUST NOT</span>
update any Expect-CT metadata.<a href="#section-2.3.1-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="expect-ct-header-field-processing">
<section id="section-2.3.2">
          <h4 id="name-expect-ct-header-field-proc">
<a href="#section-2.3.2" class="section-number selfRef">2.3.2. </a><a href="#name-expect-ct-header-field-proc" class="section-name selfRef">Expect-CT Header Field Processing</a>
          </h4>
<p id="section-2.3.2-1">If the UA receives an HTTP response over a secure transport that includes an
Expect-CT header field conforming to the grammar specified in
<a href="#response-header-field-syntax" class="xref">Section 2.1</a>, the UA <span class="bcp14">MUST</span> evaluate the connection on which
the header field was received for compliance with the UA's CT Policy, and then
process the Expect-CT header field as follows. UAs <span class="bcp14">MUST</span> ignore any Expect-CT
header field received in an HTTP response conveyed over non-secure transport.<a href="#section-2.3.2-1" class="pilcrow">¶</a></p>
<p id="section-2.3.2-2">If the connection does not comply with the UA's CT Policy (i.e., the connection
is not CT qualified), then the UA <span class="bcp14">MUST NOT</span> update any Expect-CT metadata. If the
header field includes a <code>report-uri</code> directive, the UA <span class="bcp14">SHOULD</span> send a report to
the specified <code>report-uri</code> (<a href="#header-field-processing-reporting" class="xref">Section 2.3.3</a>).<a href="#section-2.3.2-2" class="pilcrow">¶</a></p>
<p id="section-2.3.2-3">If the connection complies with the UA's CT Policy (i.e., the
          connection is CT qualified), then the UA <span class="bcp14">MUST</span>
          either:<a href="#section-2.3.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3.2-4.1">Note the host as a Known Expect-CT Host if it is not already so noted (see
<a href="#noting-expect-ct" class="xref">Section 2.3.2.1</a>) or<a href="#section-2.3.2-4.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-2.3.2-4.2">Update the UA's cached information for the Known Expect-CT
            Host if the <code>enforce</code>, <code>max-age</code>, or
            <code>report-uri</code> header field value directives convey
            information different from that already maintained by the UA. If
            the <code>max-age</code> directive has a value of 0, the UA
            <span class="bcp14">MUST</span> remove its cached Expect-CT information if the
            host was previously noted as a Known Expect-CT Host and
            <span class="bcp14">MUST NOT</span> note this host as a Known Expect-CT Host
            if it is not already noted.<a href="#section-2.3.2-4.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-2.3.2-5">If a UA receives an Expect-CT header field over a CT-compliant
          connection that uses a version of Certificate Transparency other
          than <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span> or <span>[<a href="#RFC9162" class="xref">RFC9162</a>]</span>, the UA <span class="bcp14">MUST</span>
          ignore the Expect-CT header field and clear any Expect-CT metadata
          associated with the host.<a href="#section-2.3.2-5" class="pilcrow">¶</a></p>
<div id="noting-expect-ct">
<section id="section-2.3.2.1">
            <h5 id="name-noting-expect-ct">
<a href="#section-2.3.2.1" class="section-number selfRef">2.3.2.1. </a><a href="#name-noting-expect-ct" class="section-name selfRef">Noting Expect-CT</a>
            </h5>
<p id="section-2.3.2.1-1">Upon receipt of the Expect-CT response header field over an error-free TLS
connection (with X.509 certificate chain validation as described in
<span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span>, as well as the validation described in <a href="#expect-ct-compliance" class="xref">Section 2.4</a> of this document),
the UA <span class="bcp14">MUST</span> note the host as a Known Expect-CT Host, storing the host's domain
name and its associated Expect-CT directives in non-volatile storage.<a href="#section-2.3.2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.3.2.1-2">To note a host as a Known Expect-CT Host, the UA
            <span class="bcp14">MUST</span> set its Expect-CT metadata in its Known
            Expect-CT Host cache (as specified in <a href="#storage-model" class="xref">Section 2.3.2.2</a>), using the metadata given in the most recently
            received valid Expect-CT header field.<a href="#section-2.3.2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.3.2.1-3">For forward compatibility, the UA <span class="bcp14">MUST</span> ignore any unrecognized Expect-CT header
field directives while still processing those directives it does
recognize. <a href="#response-header-field-syntax" class="xref">Section 2.1</a> specifies the directives <code>enforce</code>,
<code>max-age</code>, and <code>report-uri</code>, but future specifications and implementations might
use additional directives.<a href="#section-2.3.2.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="storage-model">
<section id="section-2.3.2.2">
            <h5 id="name-storage-model">
<a href="#section-2.3.2.2" class="section-number selfRef">2.3.2.2. </a><a href="#name-storage-model" class="section-name selfRef">Storage Model</a>
            </h5>
<p id="section-2.3.2.2-1">If the substring matching the host production from the Request-URI (of the
message to which the host responded) does not exactly match an existing Known
Expect-CT Host's domain name, per the matching procedure for a Congruent Match
specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6797#section-8.2" class="relref">Section 8.2</a> of [<a href="#RFC6797" class="xref">RFC6797</a>]</span>, then the UA <span class="bcp14">MUST</span> add this host to the
     Known Expect-CT Host cache. The UA caches:<a href="#section-2.3.2.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-2.3.2.2-2.1">the Expect-CT Host's domain name.<a href="#section-2.3.2.2-2.1" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-2.3.2.2-2.2">whether the <code>enforce</code> directive is present.<a href="#section-2.3.2.2-2.2" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-2.3.2.2-2.3">the Effective Expiration Date, which is the Effective
              Expect-CT Date plus the value of the <code>max-age</code>
              directive. Alternatively, the UA <span class="bcp14">MAY</span> cache enough
              information to calculate the Effective Expiration Date. The
              Effective Expiration Date is calculated from when the UA
              observed the Expect-CT header field and is independent of when
              the response was generated.<a href="#section-2.3.2.2-2.3" class="pilcrow">¶</a>
</li>
              <li class="normal" id="section-2.3.2.2-2.4">the value of the <code>report-uri</code> directive, if present.<a href="#section-2.3.2.2-2.4" class="pilcrow">¶</a>
</li>
            </ul>
<p id="section-2.3.2.2-3">If any other metadata from optional or future Expect-CT header
            directives are present in the Expect-CT header field, and the UA
            understands them, the UA <span class="bcp14">MAY</span> note them as well.<a href="#section-2.3.2.2-3" class="pilcrow">¶</a></p>
<p id="section-2.3.2.2-4">UAs <span class="bcp14">MAY</span> set an upper limit on the value of
            <code>max-age</code> so that UAs that have noted erroneous Expect-CT Hosts
            (whether by accident or due to attack) have some chance of
            recovering over time.  If the server sets a <code>max-age</code> greater than
            the UA's upper limit, the UA may behave as if the server set the
            <code>max-age</code> to the UA's upper limit.  For example, if the UA caps
            <code>max-age</code> at 5,184,000 seconds (60 days), and an Expect-CT Host sets
            a <code>max-age directive</code> of 90 days in its Expect-CT header field, the
            UA may behave as if the <code>max-age</code> were effectively 60 days. (One way
            to achieve this behavior is for the UA to simply store a value of
            60 days instead of the 90-day value provided by the Expect-CT
            Host.)<a href="#section-2.3.2.2-4" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="header-field-processing-reporting">
<section id="section-2.3.3">
          <h4 id="name-reporting">
<a href="#section-2.3.3" class="section-number selfRef">2.3.3. </a><a href="#name-reporting" class="section-name selfRef">Reporting</a>
          </h4>
<p id="section-2.3.3-1">If the UA receives, over a secure transport, an HTTP response that includes an
Expect-CT header field with a <code>report-uri</code> directive, and the connection does
not comply with the UA's CT Policy (i.e., the connection is not CT qualified),
and the UA has not already sent an Expect-CT report for this connection, then
the UA <span class="bcp14">SHOULD</span> send a report to the specified <code>report-uri</code> as specified in
<a href="#reporting-expect-ct-failure" class="xref">Section 3</a>.<a href="#section-2.3.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="expect-ct-compliance">
<section id="section-2.4">
        <h3 id="name-evaluating-expect-ct-connec">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-evaluating-expect-ct-connec" class="section-name selfRef">Evaluating Expect-CT Connections for CT Compliance</a>
        </h3>
<p id="section-2.4-1">When a UA sets up a TLS connection, the UA determines whether the
        host is a Known Expect-CT Host according to its Known Expect-CT Host
        cache. An Expect-CT Host is "expired" if the Effective Expiration Date
        refers to a date in the past. The UA <span class="bcp14">MUST</span> ignore any
        expired Expect-CT Hosts in its cache and not treat such hosts as Known
        Expect-CT Hosts.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<p id="section-2.4-2">When a UA connects to a Known Expect-CT Host using a TLS
        connection, if the TLS connection has no errors, then the UA will
        apply an additional correctness check: compliance with a CT Policy. A
        UA should evaluate compliance with its CT Policy whenever connecting
        to a Known Expect-CT Host. However, the check can be skipped for local
        policy reasons (as discussed in <a href="#skipping-ct-compliance-checks" class="xref">Section 2.4.1</a>) or in the
        event that other checks cause the UA to terminate the connection
        before CT compliance is evaluated. For example, a Public Key Pinning
        failure <span>[<a href="#RFC7469" class="xref">RFC7469</a>]</span> could cause the UA
        to terminate the connection before CT compliance is
        checked. Similarly, if the UA terminates the connection due to an
        Expect-CT failure, this could cause the UA to skip subsequent
        correctness checks. When the CT compliance check is skipped or
        bypassed, Expect-CT reports (<a href="#reporting-expect-ct-failure" class="xref">Section 3</a>) will not be
        sent.<a href="#section-2.4-2" class="pilcrow">¶</a></p>
<p id="section-2.4-3">When CT compliance is evaluated for a Known Expect-CT Host, the UA
        <span class="bcp14">MUST</span> evaluate compliance when setting up the TLS
        session, before beginning an HTTP conversation over the TLS
        channel.<a href="#section-2.4-3" class="pilcrow">¶</a></p>
<p id="section-2.4-4">If a connection to a Known Expect-CT Host violates the UA's CT
        Policy (i.e., the connection is not CT qualified), and if the Known
        Expect-CT Host's Expect-CT metadata indicates an <code>enforce</code>
        configuration, the UA <span class="bcp14">MUST</span> treat the CT compliance
        failure as an error. The UA <span class="bcp14">MAY</span> allow the user to
        bypass the error unless connection errors should have no user recourse
        due to other policies in effect (such as HSTS, as described in <span><a href="https://www.rfc-editor.org/rfc/rfc6797#section-12.1" class="relref">Section 12.1</a> of [<a href="#RFC6797" class="xref">RFC6797</a>]</span>).<a href="#section-2.4-4" class="pilcrow">¶</a></p>
<p id="section-2.4-5">If a connection to a Known Expect-CT Host violates the UA's CT
        Policy, and if the Known Expect-CT Host's Expect-CT metadata includes
        a <code>report-uri</code>, the UA <span class="bcp14">SHOULD</span> send an Expect-CT
        report to that <code>report-uri</code> (<a href="#reporting-expect-ct-failure" class="xref">Section 3</a>).<a href="#section-2.4-5" class="pilcrow">¶</a></p>
<div id="skipping-ct-compliance-checks">
<section id="section-2.4.1">
          <h4 id="name-skipping-ct-compliance-chec">
<a href="#section-2.4.1" class="section-number selfRef">2.4.1. </a><a href="#name-skipping-ct-compliance-chec" class="section-name selfRef">Skipping CT Compliance Checks</a>
          </h4>
<p id="section-2.4.1-1">It is acceptable for a UA to skip CT compliance checks for some
          hosts according to local policy. For example, a UA
          <span class="bcp14">MAY</span> disable CT compliance checks for hosts whose
          validated certificate chain terminates at a user-defined trust
          anchor rather than a trust anchor built in to the UA (or underlying
          platform).<a href="#section-2.4.1-1" class="pilcrow">¶</a></p>
<p id="section-2.4.1-2">If the UA does not evaluate CT compliance, e.g., because the user
          has elected to disable it, or because a presented certificate chain
          chains up to a user-defined trust anchor, UAs <span class="bcp14">SHOULD NOT</span> send Expect-CT reports.<a href="#section-2.4.1-2" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="reporting-expect-ct-failure">
<section id="section-3">
      <h2 id="name-reporting-expect-ct-failure">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-reporting-expect-ct-failure" class="section-name selfRef">Reporting Expect-CT Failure</a>
      </h2>
<p id="section-3-1">When the UA attempts to connect to a Known Expect-CT Host and the
      connection is not CT qualified, the UA <span class="bcp14">SHOULD</span> report
      Expect-CT failures to the <code>report-uri</code>, if any, in the Known
      Expect-CT Host's Expect-CT metadata.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">When the UA receives an Expect-CT response header field over a connection that
is not CT qualified, if the UA has not already sent an Expect-CT report for this
connection, then the UA <span class="bcp14">SHOULD</span> report Expect-CT failures to the configured
<code>report-uri</code>, if any.<a href="#section-3-2" class="pilcrow">¶</a></p>
<div id="generating-a-violation-report">
<section id="section-3.1">
        <h3 id="name-generating-a-violation-repo">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-generating-a-violation-repo" class="section-name selfRef">Generating a Violation Report</a>
        </h3>
<p id="section-3.1-1">To generate a violation <code>report object</code>, the UA constructs a JSON
        <span>[<a href="#RFC8259" class="xref">RFC8259</a>]</span> object with the following
        keys and values:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-3.1-2">
          <dt id="section-3.1-2.1">"date-time"</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.2"> The value for this key indicates the UTC
          time that the UA observed the CT compliance failure. The value is a
          string formatted according to <span><a href="https://www.rfc-editor.org/rfc/rfc3339#section-5.6" class="relref">Section 5.6</a> of [<a href="#RFC3339" class="xref">RFC3339</a>]</span>, "Internet Date/Time Format".<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.3">"hostname"</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.4">The value is the hostname to which the UA
          made the original request that failed the CT compliance check. The
          value is provided as a string.<a href="#section-3.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.5">"port"</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.6">The value is the port to which the UA made the
          original request that failed the CT compliance check. The value is
          provided as an integer.<a href="#section-3.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.7">"scheme"</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.8">(optional) The value is the scheme with which
          the UA made the original request that failed the CT compliance
          check. The value is provided as a string. This key is optional and
          is assumed to be "https" if not present.<a href="#section-3.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.9">"effective-expiration-date"</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.10">The value indicates the
   Effective Expiration Date (see <a href="#storage-model" class="xref">Section 2.3.2.2</a>) for the Expect-CT Host that failed the CT
   compliance check, in UTC. The value is provided as a string
   formatted according to <span><a href="https://www.rfc-editor.org/rfc/rfc3339#section-5.6" class="relref">Section 5.6</a> of [<a href="#RFC3339" class="xref">RFC3339</a>]</span>, "Internet Date/Time Format".<a href="#section-3.1-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.11">"served-certificate-chain"</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.12">The value is the
          certificate chain as served by the Expect-CT Host during TLS session
          setup. The value is provided as an array of strings, which
          <span class="bcp14">MUST</span> appear in the order that the certificates were
          served; each string in the array is the Privacy-Enhanced Mail (PEM)
          representation of each X.509 certificate as described in <span>[<a href="#RFC7468" class="xref">RFC7468</a>]</span>.<a href="#section-3.1-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.13">"validated-certificate-chain"</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.14">The value is the certificate chain
as constructed by the UA during certificate chain verification. (This may
differ from the value of the "served-certificate-chain" key.) The value is
provided as an array of strings, which <span class="bcp14">MUST</span> appear in the order
matching the chain that the UA validated; each string in the array is the
PEM representation of each X.509 certificate as
described in <span>[<a href="#RFC7468" class="xref">RFC7468</a>]</span>. The first certificate
in the chain represents the end-entity certificate being verified.  UAs that
build certificate chains in more than one way during the validation process
<span class="bcp14">SHOULD</span> send the last chain built.<a href="#section-3.1-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-2.15">"scts"</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-2.16">The value represents the SCTs (if any) that the UA received for the
  Expect-CT Host and their validation statuses. The value is provided as an array
  of JSON objects. The SCTs may appear in any order. Each JSON object in the array
  has the following keys:<a href="#section-3.1-2.16" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
<ul class="normal">
<li style="margin-left: 1.0em;" class="normal" id="section-3.1-3.1">A "version" key, with an integer value. The UA <span class="bcp14">MUST</span> set
  this value to 1 if the SCT is in the format defined in <span><a href="https://www.rfc-editor.org/rfc/rfc6962#section-3.2" class="relref">Section 3.2</a> of [<a href="#RFC6962" class="xref">RFC6962</a>]</span> or 2 if it is
  in the format defined in <span><a href="https://www.rfc-editor.org/rfc/rfc9162#section-4.5" class="relref">Section 4.5</a> of [<a href="#RFC9162" class="xref">RFC9162</a>]</span>.<a href="#section-3.1-3.1" class="pilcrow">¶</a>
</li>
          <li style="margin-left: 1.0em;" class="normal" id="section-3.1-3.2">The "status" key, with a string value that the UA <span class="bcp14">MUST</span>
  set to one of the following values: "unknown" (indicating that the UA does
  not have or does not trust the public key of the log from which the SCT was
  issued); "valid" (indicating that the UA successfully validated the SCT as
  described in <span><a href="https://www.rfc-editor.org/rfc/rfc6962#section-5.2" class="relref">Section 5.2</a> of [<a href="#RFC6962" class="xref">RFC6962</a>]</span> or
  <span><a href="https://www.rfc-editor.org/rfc/rfc9162#section-8.1.3" class="relref">Section 8.1.3</a> of [<a href="#RFC9162" class="xref">RFC9162</a>]</span>); or "invalid"
  (indicating that the SCT validation failed because of a bad signature or an
  invalid timestamp).<a href="#section-3.1-3.2" class="pilcrow">¶</a>
</li>
          <li style="margin-left: 1.0em;" class="normal" id="section-3.1-3.3">The "source" key, with a string value that indicates from where the UA
  obtained the SCT, as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc6962#section-3" class="relref">Section 3</a> of [<a href="#RFC6962" class="xref">RFC6962</a>]</span> and <span><a href="https://www.rfc-editor.org/rfc/rfc9162#section-6" class="relref">Section 6</a> of [<a href="#RFC9162" class="xref">RFC9162</a>]</span>. The UA <span class="bcp14">MUST</span> set the value to one of
  the following: "tls-extension", "ocsp", or "embedded". These correspond to the three
  methods of delivering SCTs in the TLS handshake that are 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="#section-3.1-3.3" class="pilcrow">¶</a>
</li>
          <li style="margin-left: 1.0em;" class="normal" id="section-3.1-3.4">The "serialized_sct" key, with a string value. If the value of the
  "version" key is 1, the UA <span class="bcp14">MUST</span> set this value to
  the base64-encoded <span>[<a href="#RFC4648" class="xref">RFC4648</a>]</span> serialized
  <code>SignedCertificateTimestamp</code> structure from <span><a href="https://www.rfc-editor.org/rfc/rfc6962#section-3.2" class="relref">Section 3.2</a> of [<a href="#RFC6962" class="xref">RFC6962</a>]</span>. The base64 encoding is defined in <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>.  If the value of the
  "version" key is 2, the UA <span class="bcp14">MUST</span> set this value to
  the base64-encoded <span>[<a href="#RFC4648" class="xref">RFC4648</a>]</span> serialized
  <code>TransItem</code> structure representing the SCT, as defined in <span><a href="https://www.rfc-editor.org/rfc/rfc9162#section-4.5" class="relref">Section 4.5</a> of [<a href="#RFC9162" class="xref">RFC9162</a>]</span>.<a href="#section-3.1-3.4" class="pilcrow">¶</a>
</li>
        </ul>
<span class="break"></span><dl class="dlNewline" id="section-3.1-4">
          <dt id="section-3.1-4.1">"failure-mode"</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-4.2">The value indicates whether the Expect-CT
          report was triggered by an Expect-CT policy in enforce or
          report-only mode. The value is provided as a string. The UA
          <span class="bcp14">MUST</span> set this value to "enforce" if the Expect-CT
          metadata indicates an <code>enforce</code> configuration, and
          "report-only" otherwise.<a href="#section-3.1-4.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.1-4.3">"test-report"</dt>
          <dd style="margin-left: 1.5em" id="section-3.1-4.4">(optional) The value is set to true if the report is
          being sent by a testing client to verify that the report server
          behaves correctly. The value is provided as a boolean and
          <span class="bcp14">MUST</span> be set to true if the report serves to test the
          server's behavior and can be discarded.<a href="#section-3.1-4.4" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="sending-report">
<section id="section-3.2">
        <h3 id="name-sending-a-violation-report">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-sending-a-violation-report" class="section-name selfRef">Sending a Violation Report</a>
        </h3>
<p id="section-3.2-1">The UA <span class="bcp14">SHOULD</span> report Expect-CT failures for Known
        Expect-CT Hosts: that is, when a connection to a Known Expect-CT Host
        does not comply with the UA's CT Policy and the host's Expect-CT
        metadata contains a <code>report-uri</code>.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2">Additionally, the UA <span class="bcp14">SHOULD</span> report Expect-CT
        failures for hosts for which it does not have any stored Expect-CT
        metadata; that is, when the UA connects to a host and receives an
        Expect-CT header field that contains the <code>report-uri</code>
        directive, the UA <span class="bcp14">SHOULD</span> report an Expect-CT failure if
        the connection does not comply with the UA's CT Policy.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">The steps to report an Expect-CT failure are as follows.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.2-4">
   <li id="section-3.2-4.1">Prepare a JSON object <code>report object</code> with the single key
   "expect-ct-report", whose value is the result of generating a
   violation <code>report object</code> as described in <a href="#generating-a-violation-report" class="xref">Section 3.1</a>.<a href="#section-3.2-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-3.2-4.2">Let <code>report body</code> be the JSON stringification of <code>report object</code>.<a href="#section-3.2-4.2" class="pilcrow">¶</a>
</li>
          <li id="section-3.2-4.3">Let <code>report-uri</code> be the value of the <code>report-uri</code> directive in the Expect-CT
header field.<a href="#section-3.2-4.3" class="pilcrow">¶</a>
</li>
          <li id="section-3.2-4.4">Send an HTTP POST request to <code>report-uri</code> with a
          <code>Content-Type</code> header field of
          <code>application/expect-ct-report+json</code> and an entity body
          consisting of <code>report body</code>.<a href="#section-3.2-4.4" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-3.2-5">The UA <span class="bcp14">MAY</span> perform other operations as part of
        sending the HTTP POST request, such as sending a Cross-Origin
        Resource Sharing (CORS) preflight as part of <span>[<a href="#FETCH" class="xref">FETCH</a>]</span>.<a href="#section-3.2-5" class="pilcrow">¶</a></p>
<p id="section-3.2-6">Future versions of this specification may need to modify or extend
        the Expect-CT report format. They may do so by defining a new
        top-level key to contain the report, replacing the "expect-ct-report"
        key. <a href="#receiving-report" class="xref">Section 3.3</a> defines how
        report servers should handle report formats that they do not
        support.<a href="#section-3.2-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="receiving-report">
<section id="section-3.3">
        <h3 id="name-receiving-a-violation-repor">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-receiving-a-violation-repor" class="section-name selfRef">Receiving a Violation Report</a>
        </h3>
<p id="section-3.3-1">Upon receiving an Expect-CT violation report, the report server
        <span class="bcp14">MUST</span> respond with a 2xx (Successful) status code if it
        can parse the request body as valid JSON, the report conforms to the
        format described in <a href="#generating-a-violation-report" class="xref">Section 3.1</a>, and it recognizes the scheme, hostname, and port
        in the "scheme", "hostname", and "port" fields of the report. If the
        <code>report body</code> cannot be parsed or does not conform to the
        format described in <a href="#generating-a-violation-report" class="xref">Section 3.1</a>, or the report server does not expect to receive
        reports for the scheme, hostname, or port in the report, then the
        report server <span class="bcp14">MUST</span> respond with a 400 Bad Request
        status code.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">As described in <a href="#sending-report" class="xref">Section 3.2</a>,
        future versions of this specification may define new report formats
        that are sent with a different top-level key. If the report server
        does not recognize the report format, the report server
        <span class="bcp14">MUST</span> respond with a 501 Not Implemented status
        code.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">If the report's "test-report" key is set to true, the server <span class="bcp14">MAY</span> discard the
report without further processing but <span class="bcp14">MUST</span> still return a 2xx (Successful)
status code. If the "test-report" key is absent or set to false, the server
<span class="bcp14">SHOULD</span> store the report for processing and analysis by the owner of the
Expect-CT Host.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="usability-considerations">
<section id="section-4">
      <h2 id="name-usability-considerations">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-usability-considerations" class="section-name selfRef">Usability Considerations</a>
      </h2>
<p id="section-4-1">When the UA detects a Known Expect-CT Host in violation of the UA's CT Policy,
end users will experience denials of service. It is advisable for UAs to explain
to users why they cannot access the Expect-CT Host, e.g., in a user interface
that explains that the host's certificate cannot be validated.<a href="#section-4-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authoring-considerations">
<section id="section-5">
      <h2 id="name-authoring-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-authoring-considerations" class="section-name selfRef">Authoring Considerations</a>
      </h2>
<p id="section-5-1">Expect-CT could be specified as a TLS extension or X.509 certificate
      extension instead of an HTTP response header field. Using an HTTP header
      field as the mechanism for Expect-CT introduces a layering mismatch; for
      example, the software that terminates TLS and validates Certificate
      Transparency information might know nothing about HTTP. Nevertheless, an
      HTTP header field was chosen primarily for ease of deployment. In
      practice, deploying new certificate extensions requires certificate
      authorities to support them, and new TLS extensions require server
      software updates, including possibly to servers outside of the site
      owner's direct control (such as in the case of a third-party Content
      Delivery Network (CDN)). Ease
      of deployment is a high priority for Expect-CT because it is intended as
      a temporary transition mechanism for user agents that are transitioning
      to universal Certificate Transparency requirements.<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="privacy-considerations">
<section id="section-6">
      <h2 id="name-privacy-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<p id="section-6-1">Expect-CT can be used to infer what Certificate Transparency Policy a
      UA is using by attempting to retrieve specially configured websites
      that pass one user agent's policies but not another's. Note that this
      consideration is true of UAs that enforce CT policies without Expect-CT
      as well.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">Additionally, reports submitted to the <code>report-uri</code> could
      reveal information to a third party about which web page is being
      accessed and by which IP address, by using individual
      <code>report-uri</code> values for individually tracked pages. This
      information could be leaked even if client-side scripting were
      disabled.<a href="#section-6-2" class="pilcrow">¶</a></p>
<p id="section-6-3">Implementations store state about Known Expect-CT Hosts and, hence,
      which domains the UA has contacted. Implementations may choose to not
      store this state subject to local policy (e.g., in the private browsing
      mode of a web browser).<a href="#section-6-3" class="pilcrow">¶</a></p>
<p id="section-6-4">Violation reports, as noted in <a href="#reporting-expect-ct-failure" class="xref">Section 3</a>, contain
information about the certificate chain that has violated the CT Policy. In some
cases, such as an organization-wide compromise of the end-to-end security of TLS,
this may include information about the interception tools and design used by the
organization that the organization would otherwise prefer not be disclosed.<a href="#section-6-4" class="pilcrow">¶</a></p>
<p id="section-6-5">Because Expect-CT causes remotely detectable behavior, it's advisable
      that UAs offer a way for privacy-sensitive end users to clear currently
      noted Expect-CT Hosts and allow users to query the current state of
      Known Expect-CT Hosts.<a href="#section-6-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="security-considerations">
<section id="section-7">
      <h2 id="name-security-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<div id="hostile-header-attacks">
<section id="section-7.1">
        <h3 id="name-hostile-header-attacks">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-hostile-header-attacks" class="section-name selfRef">Hostile Header Attacks</a>
        </h3>
<p id="section-7.1-1">When UAs support the Expect-CT header field, it becomes a potential
        vector for hostile header attacks against site owners. If a site owner
        uses a certificate issued by a certificate authority that does not
        embed SCTs nor serve SCTs via the Online Certificate Status Protocol
        (OCSP) or TLS extension, a malicious server operator or attacker could
        temporarily reconfigure the host to comply with the UA's CT Policy
        and add the Expect-CT header field in enforcing mode with a long
        <code>max-age</code>.  Implementing user agents would note this as an
        Expect-CT Host (see <a href="#noting-expect-ct" class="xref">Section 2.3.2.1</a>). After having done this, the configuration could
        then be reverted to not comply with the CT Policy, prompting
        failures. Note that this scenario would require the attacker to have
        substantial control over the infrastructure in question, being able to
        obtain different certificates, change server software, or act as a
        man in the middle in connections.<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<p id="section-7.1-2"> Site operators can mitigate this situation by one of the following:
        reconfiguring their web server to transmit SCTs using the TLS
        extension defined in <span><a href="https://www.rfc-editor.org/rfc/rfc9162#section-6.5" class="relref">Section 6.5</a> of [<a href="#RFC9162" class="xref">RFC9162</a>]</span>; obtaining a certificate from an alternative
        certificate authority that provides SCTs by one of the other methods;
        or by waiting for the user agent's persisted notation of this as an
        Expect-CT Host to reach its <code>max-age</code>. User agents may choose
        to implement mechanisms for users to cure this situation, as noted in
        <a href="#usability-considerations" class="xref">Section 4</a>.<a href="#section-7.1-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="maximum-max-age">
<section id="section-7.2">
        <h3 id="name-maximum-max-age">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-maximum-max-age" class="section-name selfRef">Maximum max-age</a>
        </h3>
<p id="section-7.2-1">There is a security trade-off in that low maximum values provide a
        narrow window of protection for users that visit the Known Expect-CT
        Host only infrequently, while high maximum values might result in a
        denial of service to a UA in the event of a hostile header attack or
        simply an error on the part of the site owner.<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<p id="section-7.2-2">There is probably no ideal maximum for the <code>max-age</code>
        directive. Since Expect-CT is primarily a policy-expansion and
        investigation technology rather than an end-user protection, a value
        on the order of 30 days (2,592,000 seconds) may be considered a
        balance between these competing security concerns.<a href="#section-7.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="amplification-attacks">
<section id="section-7.3">
        <h3 id="name-amplification-attacks">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-amplification-attacks" class="section-name selfRef">Amplification Attacks</a>
        </h3>
<p id="section-7.3-1">Another kind of hostile header attack uses the <code>report-uri</code> mechanism on many
hosts not currently exposing SCTs as a method to cause a denial of service to
the host receiving the reports. If some highly trafficked websites emitted
a non-enforcing Expect-CT header field with a <code>report-uri</code>, implementing UAs' reports
could flood the reporting host. It is noted in <a href="#the-report-uri-directive" class="xref">Section 2.1.1</a> that UAs
should limit the rate at which they emit reports, but an attacker may alter the
Expect-CT header fields to induce UAs to submit different reports to different
URIs to still cause the same effect.<a href="#section-7.3-1" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
<div id="iana-considerations">
<section id="section-8">
      <h2 id="name-iana-considerations">
<a href="#section-8" class="section-number selfRef">8. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="header-field-registry">
<section id="section-8.1">
        <h3 id="name-header-field-registry">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-header-field-registry" class="section-name selfRef">Header Field Registry</a>
        </h3>
<p id="section-8.1-1">This document registers the "Expect-CT" header field in the
        "Hypertext Transfer Protocol (HTTP) Field Name Registry" registry
        located at <span>&lt;<a href="https://www.iana.org/assignments/http-fields">https://www.iana.org/assignments/http-fields</a>&gt;</span>.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.1-2">
          <dt id="section-8.1-2.1">Header field name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.2">
  Expect-CT<a href="#section-8.1-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.3">Applicable protocol:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.4">
  http<a href="#section-8.1-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.5">Status:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.6">
  permanent<a href="#section-8.1-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.7">Author/Change controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.8">
  IETF<a href="#section-8.1-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.9">Specification document(s):</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.10">
  This document<a href="#section-8.1-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.1-2.11">Related information:</dt>
          <dd style="margin-left: 1.5em" id="section-8.1-2.12">
  (empty)<a href="#section-8.1-2.12" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
<div id="media-types-registry">
<section id="section-8.2">
        <h3 id="name-media-types-registry">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-media-types-registry" class="section-name selfRef">Media Types Registry</a>
        </h3>
<p id="section-8.2-1">This document registers the <code>application/expect-ct-report+json</code> media type (which uses the suffix established in <span>[<a href="#RFC6839" class="xref">RFC6839</a>]</span>) for Expect-CT violation reports in the "Media Types" registry as follows.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-8.2-2">
          <dt id="section-8.2-2.1">Type name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.2">
  application<a href="#section-8.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.3">Subtype name:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.4">
  expect-ct-report+json<a href="#section-8.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.5">Required parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.6">
  n/a<a href="#section-8.2-2.6" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.7">Optional parameters:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.8">
  n/a<a href="#section-8.2-2.8" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.9">Encoding considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.10">
  binary<a href="#section-8.2-2.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.11">Security considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.12">
  See <a href="#security-considerations" class="xref">Section 7</a><a href="#section-8.2-2.12" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.13">Interoperability considerations:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.14">
  n/a<a href="#section-8.2-2.14" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.15">Published specification:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.16">
  This document<a href="#section-8.2-2.16" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.17">Applications that use this media type:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.18">
  UAs that implement Certificate Transparency compliance checks and reporting<a href="#section-8.2-2.18" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.19">Additional information:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.20"></dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.21"></dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.22">Deprecated alias names for this type: n/a<a href="#section-8.2-2.22" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.23"></dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.24">Magic number(s): n/a<a href="#section-8.2-2.24" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.25"></dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.26">File extension(s): n/a<a href="#section-8.2-2.26" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.27"></dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.28">Macintosh file type code(s): n/a<a href="#section-8.2-2.28" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.29">Person &amp; email address to contact for further information:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.30">
            <br>
  Emily Stark (estark@google.com)<a href="#section-8.2-2.30" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.31">Intended usage:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.32">
  COMMON<a href="#section-8.2-2.32" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.33">Restrictions on usage:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.34">
  none<a href="#section-8.2-2.34" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.35">Author:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.36">
  Emily Stark (estark@google.com)<a href="#section-8.2-2.36" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-8.2-2.37">Change controller:</dt>
          <dd style="margin-left: 1.5em" id="section-8.2-2.38">
  IETF<a href="#section-8.2-2.38" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
</dl>
</section>
</div>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<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="RFC3339">[RFC3339]</dt>
        <dd>
<span class="refAuthor">Klyne, G.</span> and <span class="refAuthor">C. Newman</span>, <span class="refTitle">"Date and Time on the Internet: Timestamps"</span>, <span class="seriesInfo">RFC 3339</span>, <span class="seriesInfo">DOI 10.17487/RFC3339</span>, <time datetime="2002-07" class="refDate">July 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3339">https://www.rfc-editor.org/info/rfc3339</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="RFC5234">[RFC5234]</dt>
        <dd>
<span class="refAuthor">Crocker, D., Ed.</span> and <span class="refAuthor">P. Overell</span>, <span class="refTitle">"Augmented BNF for Syntax Specifications: ABNF"</span>, <span class="seriesInfo">STD 68</span>, <span class="seriesInfo">RFC 5234</span>, <span class="seriesInfo">DOI 10.17487/RFC5234</span>, <time datetime="2008-01" class="refDate">January 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5234">https://www.rfc-editor.org/info/rfc5234</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="RFC6797">[RFC6797]</dt>
        <dd>
<span class="refAuthor">Hodges, J.</span>, <span class="refAuthor">Jackson, C.</span>, and <span class="refAuthor">A. Barth</span>, <span class="refTitle">"HTTP Strict Transport Security (HSTS)"</span>, <span class="seriesInfo">RFC 6797</span>, <span class="seriesInfo">DOI 10.17487/RFC6797</span>, <time datetime="2012-11" class="refDate">November 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6797">https://www.rfc-editor.org/info/rfc6797</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6839">[RFC6839]</dt>
        <dd>
<span class="refAuthor">Hansen, T.</span> and <span class="refAuthor">A. Melnikov</span>, <span class="refTitle">"Additional Media Type Structured Syntax Suffixes"</span>, <span class="seriesInfo">RFC 6839</span>, <span class="seriesInfo">DOI 10.17487/RFC6839</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6839">https://www.rfc-editor.org/info/rfc6839</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="RFC7468">[RFC7468]</dt>
        <dd>
<span class="refAuthor">Josefsson, S.</span> and <span class="refAuthor">S. Leonard</span>, <span class="refTitle">"Textual Encodings of PKIX, PKCS, and CMS Structures"</span>, <span class="seriesInfo">RFC 7468</span>, <span class="seriesInfo">DOI 10.17487/RFC7468</span>, <time datetime="2015-04" class="refDate">April 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7468">https://www.rfc-editor.org/info/rfc7468</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7469">[RFC7469]</dt>
        <dd>
<span class="refAuthor">Evans, C.</span>, <span class="refAuthor">Palmer, C.</span>, and <span class="refAuthor">R. Sleevi</span>, <span class="refTitle">"Public Key Pinning Extension for HTTP"</span>, <span class="seriesInfo">RFC 7469</span>, <span class="seriesInfo">DOI 10.17487/RFC7469</span>, <time datetime="2015-04" class="refDate">April 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7469">https://www.rfc-editor.org/info/rfc7469</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="RFC9110">[RFC9110]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP Semantics"</span>, <span class="seriesInfo">STD 97</span>, <span class="seriesInfo">RFC 9110</span>, <span class="seriesInfo">DOI 10.17487/RFC9110</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9110">https://www.rfc-editor.org/info/rfc9110</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9111">[RFC9111]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"HTTP Caching"</span>, <span class="seriesInfo">STD 98</span>, <span class="seriesInfo">RFC 9111</span>, <span class="seriesInfo">DOI 10.17487/RFC9111</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9111">https://www.rfc-editor.org/info/rfc9111</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9162">[RFC9162]</dt>
      <dd>
<span class="refAuthor">Laurie, B.</span>, <span class="refAuthor">Messeri, E.</span>, and <span class="refAuthor">R. Stradling</span>, <span class="refTitle">"Certificate Transparency Version 2.0"</span>, <span class="seriesInfo">RFC 9162</span>, <span class="seriesInfo">DOI 10.17487/RFC9162</span>, <time datetime="2021-12" class="refDate">December 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9162">https://www.rfc-editor.org/info/rfc9162</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-9.2">
        <h3 id="name-informative-references">
<a href="#section-9.2" class="section-number selfRef">9.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="FETCH">[FETCH]</dt>
        <dd>
<span class="refAuthor">WHATWG</span>, <span class="refTitle">"Fetch - Living Standard"</span>, <span>&lt;<a href="https://fetch.spec.whatwg.org">https://fetch.spec.whatwg.org</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>
</dl>
</section>
</section>
<div id="authors-addresses">
<section id="appendix-A">
      <h2 id="name-authors-address">
<a href="#name-authors-address" class="section-name selfRef">Author's Address</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Emily Stark</span></div>
<div dir="auto" class="left"><span class="org">Google</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:estark@google.com" class="email">estark@google.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>