File: rfc9261.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 (2097 lines) | stat: -rw-r--r-- 91,968 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 9261: Exported Authenticators in TLS</title>
<meta content="Nick Sullivan" name="author">
<meta content="
       This document describes a mechanism that builds on Transport Layer Security (TLS) or
Datagram Transport Layer Security (DTLS) and enables peers to
provide proof of ownership of an identity, such as an X.509 certificate.  This proof can
be exported by one peer, transmitted out of band to the other peer, and verified by the
receiving peer. 
    " name="description">
<meta content="xml2rfc 3.12.10" name="generator">
<meta content="9261" 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="rfc9261.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/rfc9261" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-tls-exported-authenticator-15" 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 9261</td>
<td class="center">TLS Exported Authenticator</td>
<td class="right">July 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Sullivan</td>
<td class="center">Standards Track</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/rfc9261" class="eref">9261</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-07" class="published">July 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">N. Sullivan</div>
<div class="org">Cloudflare Inc.</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9261</h1>
<h1 id="title">Exported Authenticators in TLS</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">This document describes a mechanism that builds on Transport Layer Security (TLS) or
Datagram Transport Layer Security (DTLS) and enables peers to
provide proof of ownership of an identity, such as an X.509 certificate.  This proof can
be exported by one peer, transmitted out of band to the other peer, and verified by the
receiving peer.<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 is an Internet Standards Track document.<a href="#section-boilerplate.1-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.1-2">
            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).  Further
            information on Internet Standards is available in 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/rfc9261">https://www.rfc-editor.org/info/rfc9261</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>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-conventions-and-terminology" class="xref">Conventions and Terminology</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1" class="keepWithNext"><a href="#section-3" class="xref">3</a>.  <a href="#name-message-sequences" class="xref">Message Sequences</a></p>
</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-authenticator-request" class="xref">Authenticator Request</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-authenticator" class="xref">Authenticator</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-authenticator-keys" class="xref">Authenticator Keys</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-authenticator-construction" class="xref">Authenticator Construction</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.1">
                    <p id="section-toc.1-1.5.2.2.2.1.1"><a href="#section-5.2.1" class="xref">5.2.1</a>.  <a href="#name-certificate" class="xref">Certificate</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.2">
                    <p id="section-toc.1-1.5.2.2.2.2.1"><a href="#section-5.2.2" class="xref">5.2.2</a>.  <a href="#name-certificateverify" class="xref">CertificateVerify</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.3">
                    <p id="section-toc.1-1.5.2.2.2.3.1"><a href="#section-5.2.3" class="xref">5.2.3</a>.  <a href="#name-finished" class="xref">Finished</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2.2.4">
                    <p id="section-toc.1-1.5.2.2.2.4.1"><a href="#section-5.2.4" class="xref">5.2.4</a>.  <a href="#name-authenticator-creation" class="xref">Authenticator Creation</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-empty-authenticator" class="xref">Empty Authenticator</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-api-considerations" class="xref">API 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-the-request-api" class="xref">The "request" API</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-the-get-context-api" class="xref">The "get context" API</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-the-authenticate-api" class="xref">The "authenticate" API</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7.2.4">
                <p id="section-toc.1-1.7.2.4.1"><a href="#section-7.4" class="xref">7.4</a>.  <a href="#name-the-validate-api" class="xref">The "validate" API</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-update-of-the-tls-extension" class="xref">Update of the TLS ExtensionType 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-update-of-the-tls-exporter-" class="xref">Update of the TLS Exporter Labels Registry</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#section-8.3" class="xref">8.3</a>.  <a href="#name-update-of-the-tls-handshake" class="xref">Update of the TLS HandshakeType 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-security-considerations" class="xref">Security Considerations</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-10" class="xref">10</a>. <a href="#name-references" class="xref">References</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.1">
                <p id="section-toc.1-1.10.2.1.1"><a href="#section-10.1" class="xref">10.1</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10.2.2">
                <p id="section-toc.1-1.10.2.2.1"><a href="#section-10.2" class="xref">10.2</a>.  <a href="#name-informative-references" class="xref">Informative References</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-A" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-B" 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 provides a way to authenticate one party of a Transport Layer
Security (TLS) or Datagram Transport Layer Security (DTLS) connection to its peer
using authentication messages created after the session
has been established.  This allows both the client and server to prove ownership
of additional identities at any time after the handshake has completed.  This
proof of authentication can be exported and transmitted out of band from one
party to be validated by its peer.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">This mechanism provides two advantages over the authentication that TLS and DTLS natively
provide:<a href="#section-1-2" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-1-3">
        <dt id="section-1-3.1">multiple identities:</dt>
        <dd style="margin-left: 1.5em" id="section-1-3.2">
  Endpoints that are authoritative for multiple identities, but that do not have a
single certificate that includes all of the identities, can authenticate additional
 identities over a single connection.<a href="#section-1-3.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-1-3.3">spontaneous authentication:</dt>
        <dd style="margin-left: 1.5em" id="section-1-3.4">
After a connection is established, endpoints can authenticate in response to
events in a higher-layer protocol; they can also integrate more context (such as context from the application).<a href="#section-1-3.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-1-4">Versions of TLS prior to TLS 1.3 used renegotiation as a way to enable
post-handshake client authentication given an existing TLS connection.
The mechanism described in this document may be used to replace the
post-handshake authentication functionality provided by renegotiation.
Unlike renegotiation, Exported Authenticator-based post-handshake
      authentication does not require any changes at the TLS layer.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">Post-handshake authentication is defined in TLS 1.3 <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.6.2" class="relref">Section 4.6.2</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>, but it has the
disadvantage of requiring additional state to be stored as part of the TLS
state machine.  Furthermore, the authentication boundaries of TLS 1.3 post-handshake authentication align with TLS record boundaries,
which are often not aligned with the authentication boundaries of the
higher-layer protocol.  For example, multiplexed connection protocols
like HTTP/2 <span>[<a href="#RFC9113" class="xref">RFC9113</a>]</span> do not have a notion of which TLS record
a given message is a part of.<a href="#section-1-5" class="pilcrow">¶</a></p>
<p id="section-1-6">Exported Authenticators are meant to be used as a building block for
application protocols.  Mechanisms such as those required to advertise
support and handle authentication errors are not handled by TLS (or DTLS).<a href="#section-1-6" class="pilcrow">¶</a></p>
<p id="section-1-7">The minimum version of TLS and DTLS required to implement the mechanisms
      described in this document are TLS 1.2 <span>[<a href="#RFC5246" class="xref">RFC5246</a>]</span> and DTLS 1.2 <span>[<a href="#RFC6347" class="xref">RFC6347</a>]</span>. (These were obsoleted by TLS 1.3 <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> and 
   DTLS 1.3 <span>[<a href="#RFC9147" class="xref">RFC9147</a>]</span>.)<a href="#section-1-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="conventions-and-terminology">
<section id="section-2">
      <h2 id="name-conventions-and-terminology">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-conventions-and-terminology" class="section-name selfRef">Conventions and Terminology</a>
      </h2>
<p id="section-2-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-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">This document uses terminology such as client, server, connection,
handshake, endpoint, and peer that are defined in
<span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-1.1" class="relref">Section 1.1</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>.  The term "initial connection" refers to the (D)TLS
connection from which the Exported Authenticator messages are derived.<a href="#section-2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="message-sequences">
<section id="section-3">
      <h2 id="name-message-sequences">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-message-sequences" class="section-name selfRef">Message Sequences</a>
      </h2>
<p id="section-3-1">There are two types of messages defined in this document: authenticator requests and authenticators.  These can be combined in the following three sequences:<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">Client Authentication<a href="#section-3-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-3.1">Server generates authenticator request<a href="#section-3-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.2">Client generates Authenticator from Server's authenticator request<a href="#section-3-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-3.3">Server validates Client's authenticator<a href="#section-3-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-4">Server Authentication<a href="#section-3-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-5.1">Client generates authenticator request<a href="#section-3-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-5.2">Server generates authenticator from Client's authenticator request<a href="#section-3-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-5.3">Client validates Server's authenticator<a href="#section-3-5.3" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-3-6">Spontaneous Server Authentication<a href="#section-3-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3-7.1">Server generates authenticator<a href="#section-3-7.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-3-7.2">Client validates Server's authenticator<a href="#section-3-7.2" class="pilcrow">¶</a>
</li>
      </ul>
</section>
</div>
<div id="authenticator-request">
<section id="section-4">
      <h2 id="name-authenticator-request">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-authenticator-request" class="section-name selfRef">Authenticator Request</a>
      </h2>
<p id="section-4-1">The authenticator request is a structured message that can be created by either
party of a (D)TLS connection using data exported from that connection.  It can
be transmitted to the other party of the (D)TLS connection at the application
layer.  The application-layer protocol used to send the authenticator request
<span class="bcp14">SHOULD</span> use a secure transport channel with equivalent security to TLS, such as QUIC <span>[<a href="#RFC9001" class="xref">RFC9001</a>]</span>, as its
underlying transport to keep the request confidential.  The
application <span class="bcp14">MAY</span> use the existing (D)TLS connection to transport the authenticator.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">An authenticator request message can be constructed by either the client or the
server.  Server-generated authenticator requests use the CertificateRequest
message from <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.3.2" class="relref">Section 4.3.2</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>.  Client-generated
authenticator requests use a new message, called the "ClientCertificateRequest",
that uses the same structure as CertificateRequest.  (Note that the latter
is not a request for a client certificate, but rather a certificate request
generated by the client.)  These message
structures are used even if the connection protocol is TLS 1.2 or DTLS 1.2.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">The CertificateRequest and ClientCertificateRequest messages are used to define the
parameters in a request for an authenticator.  These are encoded as TLS handshake messages, including 
length and type fields. They do not include any TLS record-layer framing and are not encrypted with a handshake or application-data key.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">The structures are defined to be:<a href="#section-4-4" class="pilcrow">¶</a></p>
<div id="section-4-5">
<pre class="lang-tls-presentation sourcecode">
   struct {
      opaque certificate_request_context&lt;0..2^8-1&gt;;
      Extension extensions&lt;2..2^16-1&gt;;
   } ClientCertificateRequest;

   struct {
      opaque certificate_request_context&lt;0..2^8-1&gt;;
      Extension extensions&lt;2..2^16-1&gt;;
   } CertificateRequest;
</pre><a href="#section-4-5" class="pilcrow">¶</a>
</div>
<span class="break"></span><dl class="dlParallel" id="section-4-6">
        <dt id="section-4-6.1">certificate_request_context:</dt>
        <dd style="margin-left: 1.5em" id="section-4-6.2">
  An opaque string that identifies the authenticator request and that will
be echoed in the authenticator message.  A certificate_request_context value <span class="bcp14">MUST</span> be unique for
each authenticator request within the scope of a connection
(preventing replay and context confusion).  The
certificate_request_context <span class="bcp14">SHOULD</span> be chosen to be unpredictable
to the peer (e.g., by randomly generating it) in order to prevent
an attacker who has temporary access to the peer's private key
from precomputing valid authenticators.  For example, the application
may choose this value to correspond to a value used in an existing
data structure in the software to simplify implementation.<a href="#section-4-6.2" class="pilcrow">¶</a>
</dd>
        <dd class="break"></dd>
<dt id="section-4-6.3">extensions:</dt>
        <dd style="margin-left: 1.5em" id="section-4-6.4">
  The set of extensions allowed in the structures of CertificateRequest
 and ClientCertificateRequest is comprised of those
defined in the "TLS ExtensionType Values" IANA registry containing CR in the "TLS 1.3" column (see <span>[<a href="#IANA-TLS" class="xref">IANA-TLS</a>]</span> and <span>[<a href="#RFC8447" class="xref">RFC8447</a>]</span>).  In addition, the set of
extensions in the ClientCertificateRequest structure <span class="bcp14">MAY</span>
include the server_name extension <span>[<a href="#RFC6066" class="xref">RFC6066</a>]</span>.<a href="#section-4-6.4" class="pilcrow">¶</a>
</dd>
      <dd class="break"></dd>
</dl>
<p id="section-4-7">The uniqueness requirements of the certificate_request_context apply
across CertificateRequest and ClientCertificateRequest messages that
are used as part of authenticator requests. A certificate_request_context value used
in a ClientCertificateRequest cannot be used in an authenticator
CertificateRequest on the same connection, and vice versa.  There is no impact
if the value
of a certificate_request_context used in an authenticator
request matches the value of a certificate_request_context in the handshake or
in a post-handshake message.<a href="#section-4-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authenticator">
<section id="section-5">
      <h2 id="name-authenticator">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-authenticator" class="section-name selfRef">Authenticator</a>
      </h2>
<p id="section-5-1">The authenticator is a structured message that can be exported from either
party of a (D)TLS connection.  It can be transmitted to the other party of
the (D)TLS connection at the application layer.  The application-layer protocol used to send the authenticator
<span class="bcp14">SHOULD</span> use a secure transport channel with equivalent security to TLS, such as QUIC <span>[<a href="#RFC9001" class="xref">RFC9001</a>]</span>, as its
underlying transport to keep the authenticator confidential.
The application <span class="bcp14">MAY</span> use the existing (D)TLS connection to transport the authenticator.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">An authenticator message can be constructed by either the client or the
server given an established (D)TLS connection; an identity, such as an X.509 certificate;
and a corresponding private key.  Clients <span class="bcp14">MUST NOT</span> send an authenticator
without a preceding authenticator request; for servers, an
authenticator request is optional.  For authenticators that do not correspond
to authenticator requests, the certificate_request_context is chosen by
the server.<a href="#section-5-2" class="pilcrow">¶</a></p>
<div id="authenticator-keys">
<section id="section-5.1">
        <h3 id="name-authenticator-keys">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-authenticator-keys" class="section-name selfRef">Authenticator Keys</a>
        </h3>
<p id="section-5.1-1">Each authenticator is computed using a Handshake Context and Finished MAC (Message Authentication Code) Key
derived from the (D)TLS connection.  These values are derived using an exporter as
described in <span><a href="https://www.rfc-editor.org/rfc/rfc5705#section-4" class="relref">Section 4</a> of [<a href="#RFC5705" class="xref">RFC5705</a>]</span> (for (D)TLS 1.2) or <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-7.5" class="relref">Section 7.5</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span> (for
(D)TLS 1.3).  For (D)TLS 1.3, the exporter_master_secret <span class="bcp14">MUST</span> be used, not the
early_exporter_master_secret.  These values use different labels depending on the role of the
sender:<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.1-2.1">The Handshake Context is an exporter value that is derived using the label
"EXPORTER-client authenticator handshake context" or "EXPORTER-server
authenticator handshake context" for authenticators sent by the client or
server, respectively.<a href="#section-5.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.1-2.2">The Finished MAC Key is an exporter value derived using the label
"EXPORTER-client authenticator finished key" or "EXPORTER-server authenticator
finished key" for authenticators sent by the client or server, respectively.<a href="#section-5.1-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-5.1-3">The context_value used for the exporter is empty (zero length) for all four
values.  There is no need to include additional context
information at this stage because the application-supplied context
is included in the authenticator itself.  The length of the exported
value is equal to the length of the output of the hash function associated with the selected ciphersuite (for TLS 1.3) or the hash function used
for the pseudorandom function (PRF) (for (D)TLS 1.2).  Exported Authenticators cannot be
used with (D)TLS 1.2 ciphersuites that do not use the TLS PRF and with TLS 1.3 ciphersuites that do not have an associated
hash function.  This hash is referred to as the "authenticator hash".<a href="#section-5.1-3" class="pilcrow">¶</a></p>
<p id="section-5.1-4">To avoid key synchronization attacks, Exported Authenticators <span class="bcp14">MUST NOT</span> be generated or
accepted on (D)TLS 1.2 connections that did not negotiate
the extended master secret extension <span>[<a href="#RFC7627" class="xref">RFC7627</a>]</span>.<a href="#section-5.1-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authenticator-construction">
<section id="section-5.2">
        <h3 id="name-authenticator-construction">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-authenticator-construction" class="section-name selfRef">Authenticator Construction</a>
        </h3>
<p id="section-5.2-1">An authenticator is formed from the concatenation of TLS 1.3 
Certificate, CertificateVerify, and Finished messages <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>. These messages are
encoded as TLS handshake messages, including length and type fields.
They do not include any TLS record-layer framing and are not encrypted with a handshake or application-data key.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">If the peer populating the certificate_request_context field in an authenticator's Certificate message has already created or
correctly validated an authenticator with the same value, then no
authenticator should be constructed.  If there is no authenticator request,
the extensions are chosen from those presented in the (D)TLS handshake's ClientHello.
Only servers can provide an authenticator without a corresponding request.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">ClientHello extensions are used to determine permissible extensions
in the server's unsolicited Certificate message in order to follow the general model for
extensions in (D)TLS in which extensions can only be included
as part of a Certificate message if they were previously sent as
part of a CertificateRequest message or ClientHello message.  This ensures that the recipient
will be able to process such extensions.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<div id="certificate">
<section id="section-5.2.1">
          <h4 id="name-certificate">
<a href="#section-5.2.1" class="section-number selfRef">5.2.1. </a><a href="#name-certificate" class="section-name selfRef">Certificate</a>
          </h4>
<p id="section-5.2.1-1">The Certificate message contains the identity to be used for authentication, such as the
end-entity certificate and any supporting certificates in the chain. This structure is
defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.4.2" class="relref">Section 4.4.2</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>.<a href="#section-5.2.1-1" class="pilcrow">¶</a></p>
<p id="section-5.2.1-2">The Certificate message contains an opaque string called
"certificate_request_context", which is extracted from the authenticator request, if
present.  If no authenticator request is provided, the certificate_request_context
can be chosen arbitrarily; however, it <span class="bcp14">MUST</span> be unique within the scope of the connection
and be unpredictable to the peer.<a href="#section-5.2.1-2" class="pilcrow">¶</a></p>
<p id="section-5.2.1-3">Certificates chosen in the Certificate message <span class="bcp14">MUST</span> conform to the
requirements of a Certificate message in the negotiated version of (D)TLS.  In
particular, the entries of certificate_list <span class="bcp14">MUST</span> be valid for the signature algorithms
indicated by the peer in the "signature_algorithms" and "signature_algorithms_cert"
extensions, as described in <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.2.3" class="relref">Section 4.2.3</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span> for (D)TLS 1.3 or
in Sections <a href="https://www.rfc-editor.org/rfc/rfc5246#section-7.4.2" class="relref">7.4.2</a> and <a href="https://www.rfc-editor.org/rfc/rfc5246#section-7.4.6" class="relref">7.4.6</a> of <span>[<a href="#RFC5246" class="xref">RFC5246</a>]</span> for (D)TLS 1.2.<a href="#section-5.2.1-3" class="pilcrow">¶</a></p>
<p id="section-5.2.1-4">In addition to "signature_algorithms" and "signature_algorithms_cert",
the "server_name" <span>[<a href="#RFC6066" class="xref">RFC6066</a>]</span>, "certificate_authorities"
(<span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.2.4" class="relref">Section 4.2.4</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>), and "oid_filters"
(<span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.2.5" class="relref">Section 4.2.5</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>) extensions are used to guide certificate
selection.<a href="#section-5.2.1-4" class="pilcrow">¶</a></p>
<p id="section-5.2.1-5">Only the X.509 certificate type defined in <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span> is supported.
Alternative certificate formats such as Raw Public Keys as described in <span>[<a href="#RFC7250" class="xref">RFC7250</a>]</span> are
not supported in this version of the specification and their use in this context
has not yet been analyzed.<a href="#section-5.2.1-5" class="pilcrow">¶</a></p>
<p id="section-5.2.1-6">If an authenticator request was provided, the Certificate message <span class="bcp14">MUST</span> contain
only extensions present in the authenticator request.  Otherwise, the
Certificate message <span class="bcp14">MUST</span> contain only extensions present in the (D)TLS ClientHello.
Unrecognized extensions in the authenticator request <span class="bcp14">MUST</span> be ignored.<a href="#section-5.2.1-6" class="pilcrow">¶</a></p>
</section>
</div>
<div id="certificateverify">
<section id="section-5.2.2">
          <h4 id="name-certificateverify">
<a href="#section-5.2.2" class="section-number selfRef">5.2.2. </a><a href="#name-certificateverify" class="section-name selfRef">CertificateVerify</a>
          </h4>
<p id="section-5.2.2-1">This message is used to provide explicit proof that an endpoint possesses the
private key corresponding to its identity.  The format of this message is taken from TLS 1.3:<a href="#section-5.2.2-1" class="pilcrow">¶</a></p>
<div id="section-5.2.2-2">
<pre class="lang-tls-presentation sourcecode">
   struct {
      SignatureScheme algorithm;
      opaque signature&lt;0..2^16-1&gt;;
   } CertificateVerify;
</pre><a href="#section-5.2.2-2" class="pilcrow">¶</a>
</div>
<p id="section-5.2.2-3">The algorithm field specifies the signature algorithm used (see <span><a href="https://www.rfc-editor.org/rfc/rfc8446#section-4.2.3" class="relref">Section 4.2.3</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>
for the definition of this field).  The signature is a digital signature
using that algorithm.<a href="#section-5.2.2-3" class="pilcrow">¶</a></p>
<p id="section-5.2.2-4">The signature scheme <span class="bcp14">MUST</span> be a valid signature scheme for TLS 1.3. This
excludes all RSASSA-PKCS1-v1_5 algorithms and combinations of Elliptic Curve Digital Signature Algorithm (ECDSA) and hash
algorithms that are not supported in TLS 1.3.<a href="#section-5.2.2-4" class="pilcrow">¶</a></p>
<p id="section-5.2.2-5">If an authenticator request is present, the signature algorithm <span class="bcp14">MUST</span> be chosen
from one of the signature schemes present in the "signature_algorithms"
extension of the authenticator request.
Otherwise, with spontaneous server authentication, the signature algorithm used <span class="bcp14">MUST</span> be chosen
from the "signature_algorithms" sent by the peer in the ClientHello of the (D)TLS
handshake.  If there are no available signature algorithms, then no
authenticator should be constructed.<a href="#section-5.2.2-5" class="pilcrow">¶</a></p>
<p id="section-5.2.2-6">The signature is computed using the chosen signature scheme over the concatenation of:<a href="#section-5.2.2-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.2.2-7.1">a string that consists of octet 32 (0x20) repeated 64 times,<a href="#section-5.2.2-7.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.2.2-7.2">the context string "Exported Authenticator" (which is not NUL-terminated),<a href="#section-5.2.2-7.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.2.2-7.3">a single 0 octet that serves as the separator, and<a href="#section-5.2.2-7.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-5.2.2-7.4">the hashed authenticator transcript.<a href="#section-5.2.2-7.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-5.2.2-8">The authenticator transcript is the hash of the concatenated Handshake Context,
authenticator request (if present), and Certificate message:<a href="#section-5.2.2-8" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-5.2.2-9">
<pre>
Hash(Handshake Context || authenticator request || Certificate)
</pre><a href="#section-5.2.2-9" class="pilcrow">¶</a>
</div>
<p id="section-5.2.2-10">Where Hash is the authenticator hash defined in <a href="#authenticator-keys" class="xref">Section 5.1</a>.  If the authenticator request
is not present, it is omitted from this construction, i.e., it is zero-length.<a href="#section-5.2.2-10" class="pilcrow">¶</a></p>
<p id="section-5.2.2-11">If the party that generates the authenticator does so with a different
connection than the party that is validating it, then the Handshake Context will
not match, resulting in a CertificateVerify message that does not validate.
This includes situations in which the application data is sent via TLS-terminating
proxy.  Given a failed CertificateVerify validation, it may be helpful for
the application to confirm that both peers share the same connection
using a value derived from the connection secrets (such as the Handshake Context)
before taking a user-visible action.<a href="#section-5.2.2-11" class="pilcrow">¶</a></p>
</section>
</div>
<div id="finished">
<section id="section-5.2.3">
          <h4 id="name-finished">
<a href="#section-5.2.3" class="section-number selfRef">5.2.3. </a><a href="#name-finished" class="section-name selfRef">Finished</a>
          </h4>
<p id="section-5.2.3-1">An HMAC <span>[<a href="#RFC2104" class="xref">HMAC</a>]</span> over the hashed authenticator transcript is the
concatenation of the Handshake Context, authenticator request (if present),
Certificate, and CertificateVerify.  The HMAC is computed using the authenticator hash, using the Finished MAC Key as
a key.<a href="#section-5.2.3-1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-5.2.3-2">
<pre>
Finished = HMAC(Finished MAC Key, Hash(Handshake Context ||
     authenticator request || Certificate || CertificateVerify))
</pre><a href="#section-5.2.3-2" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="authenticator-creation">
<section id="section-5.2.4">
          <h4 id="name-authenticator-creation">
<a href="#section-5.2.4" class="section-number selfRef">5.2.4. </a><a href="#name-authenticator-creation" class="section-name selfRef">Authenticator Creation</a>
          </h4>
<p id="section-5.2.4-1">An endpoint constructs an authenticator by serializing the Certificate, CertificateVerify, and Finished as TLS handshake messages and concatenating the octets:<a href="#section-5.2.4-1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-5.2.4-2">
<pre>
Certificate || CertificateVerify || Finished
</pre><a href="#section-5.2.4-2" class="pilcrow">¶</a>
</div>
<p id="section-5.2.4-3">An authenticator is valid if the CertificateVerify message is correctly constructed given the authenticator request (if
used) and the Finished message matches the expected value.  When validating an authenticator, constant-time
comparisons <span class="bcp14">SHOULD</span> be used for signature and MAC validation.<a href="#section-5.2.4-3" class="pilcrow">¶</a></p>
</section>
</div>
</section>
</div>
</section>
</div>
<div id="empty-authenticator">
<section id="section-6">
      <h2 id="name-empty-authenticator">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-empty-authenticator" class="section-name selfRef">Empty Authenticator</a>
      </h2>
<p id="section-6-1">If, given an authenticator request, the endpoint does not have an appropriate
identity or does not want to return one, it constructs an authenticated
refusal called an "empty authenticator".  This is a Finished
message sent without a Certificate or CertificateVerify. This message is an
HMAC over the hashed authenticator transcript with a Certificate message
containing no CertificateEntries and the CertificateVerify message omitted.
The HMAC is computed using the authenticator hash, using the Finished MAC Key as a key.
This message is encoded as a TLS handshake message, including length and type field.
It does not include TLS record-layer framing and is not encrypted with a handshake or application-data key.<a href="#section-6-1" class="pilcrow">¶</a></p>
<div class="alignLeft art-text artwork" id="section-6-2">
<pre>
Finished = HMAC(Finished MAC Key, Hash(Handshake Context ||
     authenticator request || Certificate))
</pre><a href="#section-6-2" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="api-considerations">
<section id="section-7">
      <h2 id="name-api-considerations">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-api-considerations" class="section-name selfRef">API Considerations</a>
      </h2>
<p id="section-7-1">The creation and validation of both authenticator requests and authenticators
<span class="bcp14">SHOULD</span> be implemented inside the (D)TLS library even if it is possible to implement
it at the application layer.  (D)TLS implementations supporting the use of Exported
Authenticators <span class="bcp14">SHOULD</span> provide application programming interfaces by which clients
and servers may request and verify Exported Authenticator messages.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">Notwithstanding the success conditions described below, all APIs <span class="bcp14">MUST</span> fail if:<a href="#section-7-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7-3.1">the connection uses a (D)TLS version of 1.1 or earlier, or<a href="#section-7-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-7-3.2">the connection is (D)TLS 1.2 and the extended master secret extension <span>[<a href="#RFC7627" class="xref">RFC7627</a>]</span> was not
negotiated<a href="#section-7-3.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-7-4">The following sections describe APIs that are considered necessary to
implement Exported Authenticators.  These are informative only.<a href="#section-7-4" class="pilcrow">¶</a></p>
<div id="the-request-api">
<section id="section-7.1">
        <h3 id="name-the-request-api">
<a href="#section-7.1" class="section-number selfRef">7.1. </a><a href="#name-the-request-api" class="section-name selfRef">The "request" API</a>
        </h3>
<p id="section-7.1-1">The "request" API takes as input:<a href="#section-7.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.1-2.1">certificate_request_context (from 0 to 255 octets)<a href="#section-7.1-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.1-2.2">the set of extensions to include (this <span class="bcp14">MUST</span> include signature_algorithms) and the
contents thereof<a href="#section-7.1-2.2" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.1-3">It returns an authenticator request, which is a sequence of octets
that comprises a CertificateRequest or ClientCertificateRequest message.<a href="#section-7.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-get-context-api">
<section id="section-7.2">
        <h3 id="name-the-get-context-api">
<a href="#section-7.2" class="section-number selfRef">7.2. </a><a href="#name-the-get-context-api" class="section-name selfRef">The "get context" API</a>
        </h3>
<p id="section-7.2-1">The "get context" API takes as input:<a href="#section-7.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.2-2.1">authenticator or authenticator request<a href="#section-7.2-2.1" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.2-3">It returns the certificate_request_context.<a href="#section-7.2-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-authenticate-api">
<section id="section-7.3">
        <h3 id="name-the-authenticate-api">
<a href="#section-7.3" class="section-number selfRef">7.3. </a><a href="#name-the-authenticate-api" class="section-name selfRef">The "authenticate" API</a>
        </h3>
<p id="section-7.3-1">The "authenticate" API takes as input:<a href="#section-7.3-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.3-2.1">a reference to the initial connection<a href="#section-7.3-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-2.2">an identity, such as a set of certificate chains and associated extensions
(OCSP <span>[<a href="#RFC6960" class="xref">RFC6960</a>]</span>, SCT <span>[<a href="#RFC6962" class="xref">RFC6962</a>]</span> (obsoleted by <span>[<a href="#RFC9162" class="xref">RFC9162</a>]</span>), etc.)<a href="#section-7.3-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-2.3">a signer (either the private key associated with the identity or the interface to perform private key operations) for each chain<a href="#section-7.3-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.3-2.4">an authenticator request or certificate_request_context (from 0 to 255 octets)<a href="#section-7.3-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.3-3">It returns either the authenticator or an empty authenticator
as a sequence of octets.  It is <span class="bcp14">RECOMMENDED</span> that
the logic for selecting the certificates and extensions to include
in the exporter be implemented in the TLS library.  Implementing this
in the TLS library lets the implementer take advantage of existing
extension and certificate selection logic, and the implementer can more easily remember
which extensions were sent in the ClientHello.<a href="#section-7.3-3" class="pilcrow">¶</a></p>
<p id="section-7.3-4">It is also possible to implement this API outside of the TLS library using
TLS exporters.  This may be preferable in cases where the application
does not have access to a TLS library with these APIs or when TLS is
handled independently of the application-layer protocol.<a href="#section-7.3-4" class="pilcrow">¶</a></p>
</section>
</div>
<div id="the-validate-api">
<section id="section-7.4">
        <h3 id="name-the-validate-api">
<a href="#section-7.4" class="section-number selfRef">7.4. </a><a href="#name-the-validate-api" class="section-name selfRef">The "validate" API</a>
        </h3>
<p id="section-7.4-1">The "validate" API takes as input:<a href="#section-7.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-7.4-2.1">a reference to the initial connection<a href="#section-7.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.4-2.2">an optional authenticator request<a href="#section-7.4-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.4-2.3">an authenticator<a href="#section-7.4-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-7.4-2.4">a function for validating a certificate chain<a href="#section-7.4-2.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-7.4-3">It returns a status to indicate whether or not the authenticator is valid after
applying the function for validating the certificate chain to the chain
contained in the authenticator.  If validation is successful, it also returns
the identity, such as the certificate chain and its extensions.<a href="#section-7.4-3" class="pilcrow">¶</a></p>
<p id="section-7.4-4">The API should return a failure if the certificate_request_context of the
authenticator was used in a different authenticator that was previously validated.
Well-formed empty authenticators are returned as invalid.<a href="#section-7.4-4" class="pilcrow">¶</a></p>
<p id="section-7.4-5">When validating an authenticator, constant-time comparison should be used.<a href="#section-7.4-5" 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="update-of-the-tls-extensiontype-registry">
<section id="section-8.1">
        <h3 id="name-update-of-the-tls-extension">
<a href="#section-8.1" class="section-number selfRef">8.1. </a><a href="#name-update-of-the-tls-extension" class="section-name selfRef">Update of the TLS ExtensionType Registry</a>
        </h3>
<p id="section-8.1-1">IANA has updated the entry for server_name(0) in the "TLS ExtensionType Values" registry <span>[<a href="#IANA-TLS" class="xref">IANA-TLS</a>]</span> (defined in <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>) by replacing the value in the "TLS 1.3"
column with the value "CH, EE, CR" and listing this document in the "Reference" column.<a href="#section-8.1-1" class="pilcrow">¶</a></p>
<p id="section-8.1-2">IANA has also added the following note to the registry:<a href="#section-8.1-2" class="pilcrow">¶</a></p>
<blockquote id="section-8.1-3">
          <p id="section-8.1-3.1">The addition of the "CR" to the "TLS 1.3" column for the server_name(0) extension only marks the extension as valid in a ClientCertificateRequest created as part of client-generated authenticator requests.<a href="#section-8.1-3.1" class="pilcrow">¶</a></p>
</blockquote>
</section>
</div>
<div id="update-of-the-tls-exporter-labels-registry">
<section id="section-8.2">
        <h3 id="name-update-of-the-tls-exporter-">
<a href="#section-8.2" class="section-number selfRef">8.2. </a><a href="#name-update-of-the-tls-exporter-" class="section-name selfRef">Update of the TLS Exporter Labels Registry</a>
        </h3>
<p id="section-8.2-1">IANA has added the following entries to the "TLS Exporter Labels" registry <span>[<a href="#IANA-EXPORT" class="xref">IANA-EXPORT</a>]</span> (defined in <span>[<a href="#RFC5705" class="xref">RFC5705</a>]</span>): "EXPORTER-client authenticator handshake context",
"EXPORTER-server authenticator handshake context", 
"EXPORTER-client authenticator finished key" and 
"EXPORTER-server authenticator finished key" with "DTLS-OK" and "Recommended" set to "Y" and
this document listed as the reference.<a href="#section-8.2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="update-of-the-tls-handshaketype-registry">
<section id="section-8.3">
        <h3 id="name-update-of-the-tls-handshake">
<a href="#section-8.3" class="section-number selfRef">8.3. </a><a href="#name-update-of-the-tls-handshake" class="section-name selfRef">Update of the TLS HandshakeType Registry</a>
        </h3>
<p id="section-8.3-1">IANA has added the following entry to the "TLS HandshakeType" registry <span>[<a href="#IANA-HANDSHAKE" class="xref">IANA-HANDSHAKE</a>]</span> (defined in <span>[<a href="#RFC8446" class="xref">RFC8446</a>]</span>): "client_certificate_request" (17) 
with "DTLS-OK" set to "Y" and this document listed
as the reference.  In addition, the following appears in the "Comment" column:<a href="#section-8.3-1" class="pilcrow">¶</a></p>
<blockquote id="section-8.3-2">
          <p id="section-8.3-2.1">Used in TLS versions prior to 1.3.<a href="#section-8.3-2.1" class="pilcrow">¶</a></p>
</blockquote>
</section>
</div>
</section>
</div>
<div id="security">
<section id="section-9">
      <h2 id="name-security-considerations">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-9-1">The Certificate/Verify/Finished pattern intentionally looks like the
      TLS 1.3 pattern that now has been analyzed several times. For example,
<span>[<a href="#SIGMAC" class="xref">SIGMAC</a>]</span> presents a relevant framework for analysis, and  <span><a href="https://www.rfc-editor.org/rfc/rfc8446#appendix-E.1.6" class="relref">Appendix E.1.6</a> of [<a href="#RFC8446" class="xref">RFC8446</a>]</span>
contains a comprehensive set of references.<a href="#section-9-1" class="pilcrow">¶</a></p>
<p id="section-9-2">Authenticators are independent and unidirectional.  There is no explicit state change
inside TLS when an authenticator is either created or validated.  The application in
possession of a validated authenticator can rely on any semantics associated with data
in the certificate_request_context.<a href="#section-9-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-9-3.1">This property makes it difficult to formally prove that a server is jointly authoritative
over multiple identities, rather than individually authoritative over each.<a href="#section-9-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-9-3.2">There is no indication in (D)TLS about which point in time an authenticator was
computed.  Any feedback about the time of creation or validation of the authenticator
should be tracked as part of the application-layer semantics if required.<a href="#section-9-3.2" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-9-4">The signatures generated with this API cover the context string
"Exported Authenticator"; therefore, they cannot be transplanted into other
protocols.<a href="#section-9-4" class="pilcrow">¶</a></p>
<p id="section-9-5">In TLS 1.3, the client cannot explicitly learn from the TLS layer whether its
Finished message was accepted. Because the application traffic keys are not
dependent on the client's final flight, receiving messages from the server
does not prove that the server received the client's Finished message.
To avoid disagreement between the client and server
on the authentication status of Exported Authenticators, servers <span class="bcp14">MUST</span> verify the client Finished message
before sending an EA or processing a received Exported Authenticator.<a href="#section-9-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-10">
      <h2 id="name-references">
<a href="#section-10" class="section-number selfRef">10. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-10.1">
        <h3 id="name-normative-references">
<a href="#section-10.1" class="section-number selfRef">10.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2104">[HMAC]</dt>
        <dd>
<span class="refAuthor">Krawczyk, H.</span>, <span class="refAuthor">Bellare, M.</span>, and <span class="refAuthor">R. Canetti</span>, <span class="refTitle">"HMAC: Keyed-Hashing for Message Authentication"</span>, <span class="seriesInfo">RFC 2104</span>, <span class="seriesInfo">DOI 10.17487/RFC2104</span>, <time datetime="1997-02" class="refDate">February 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2104">https://www.rfc-editor.org/info/rfc2104</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5246">[RFC5246]</dt>
        <dd>
<span class="refAuthor">Dierks, T.</span> and <span class="refAuthor">E. Rescorla</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.2"</span>, <span class="seriesInfo">RFC 5246</span>, <span class="seriesInfo">DOI 10.17487/RFC5246</span>, <time datetime="2008-08" class="refDate">August 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5246">https://www.rfc-editor.org/info/rfc5246</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5705">[RFC5705]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"Keying Material Exporters for Transport Layer Security (TLS)"</span>, <span class="seriesInfo">RFC 5705</span>, <span class="seriesInfo">DOI 10.17487/RFC5705</span>, <time datetime="2010-03" class="refDate">March 2010</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5705">https://www.rfc-editor.org/info/rfc5705</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6066">[RFC6066]</dt>
        <dd>
<span class="refAuthor">Eastlake 3rd, D.</span>, <span class="refTitle">"Transport Layer Security (TLS) Extensions: Extension Definitions"</span>, <span class="seriesInfo">RFC 6066</span>, <span class="seriesInfo">DOI 10.17487/RFC6066</span>, <time datetime="2011-01" class="refDate">January 2011</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6066">https://www.rfc-editor.org/info/rfc6066</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6347">[RFC6347]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span> and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"Datagram Transport Layer Security Version 1.2"</span>, <span class="seriesInfo">RFC 6347</span>, <span class="seriesInfo">DOI 10.17487/RFC6347</span>, <time datetime="2012-01" class="refDate">January 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6347">https://www.rfc-editor.org/info/rfc6347</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7627">[RFC7627]</dt>
        <dd>
<span class="refAuthor">Bhargavan, K., Ed.</span>, <span class="refAuthor">Delignat-Lavaud, A.</span>, <span class="refAuthor">Pironti, A.</span>, <span class="refAuthor">Langley, A.</span>, and <span class="refAuthor">M. Ray</span>, <span class="refTitle">"Transport Layer Security (TLS) Session Hash and Extended Master Secret Extension"</span>, <span class="seriesInfo">RFC 7627</span>, <span class="seriesInfo">DOI 10.17487/RFC7627</span>, <time datetime="2015-09" class="refDate">September 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7627">https://www.rfc-editor.org/info/rfc7627</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="RFC8446">[RFC8446]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"The Transport Layer Security (TLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 8446</span>, <span class="seriesInfo">DOI 10.17487/RFC8446</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8446">https://www.rfc-editor.org/info/rfc8446</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8447">[RFC8447]</dt>
        <dd>
<span class="refAuthor">Salowey, J.</span> and <span class="refAuthor">S. Turner</span>, <span class="refTitle">"IANA Registry Updates for TLS and DTLS"</span>, <span class="seriesInfo">RFC 8447</span>, <span class="seriesInfo">DOI 10.17487/RFC8447</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8447">https://www.rfc-editor.org/info/rfc8447</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9147">[RFC9147]</dt>
      <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refAuthor">Tschofenig, H.</span>, and <span class="refAuthor">N. Modadugu</span>, <span class="refTitle">"The Datagram Transport Layer Security (DTLS) Protocol Version 1.3"</span>, <span class="seriesInfo">RFC 9147</span>, <span class="seriesInfo">DOI 10.17487/RFC9147</span>, <time datetime="2022-04" class="refDate">April 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9147">https://www.rfc-editor.org/info/rfc9147</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<section id="section-10.2">
        <h3 id="name-informative-references">
<a href="#section-10.2" class="section-number selfRef">10.2. </a><a href="#name-informative-references" class="section-name selfRef">Informative References</a>
        </h3>
<dl class="references">
<dt id="IANA-EXPORT">[IANA-EXPORT]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"TLS Exporter Labels"</span>, <span>&lt;<a href="https://www.iana.org/assignments/tls-parameters/">https://www.iana.org/assignments/tls-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA-HANDSHAKE">[IANA-HANDSHAKE]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"TLS HandshakeType"</span>, <span>&lt;<a href="https://www.iana.org/assignments/tls-parameters/">https://www.iana.org/assignments/tls-parameters/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="IANA-TLS">[IANA-TLS]</dt>
        <dd>
<span class="refAuthor">IANA</span>, <span class="refTitle">"TLS ExtensionType Values"</span>, <span>&lt;<a href="https://www.iana.org/assignments/tls-extensiontype-values/">https://www.iana.org/assignments/tls-extensiontype-values/</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6960">[RFC6960]</dt>
        <dd>
<span class="refAuthor">Santesson, S.</span>, <span class="refAuthor">Myers, M.</span>, <span class="refAuthor">Ankney, R.</span>, <span class="refAuthor">Malpani, A.</span>, <span class="refAuthor">Galperin, S.</span>, and <span class="refAuthor">C. Adams</span>, <span class="refTitle">"X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP"</span>, <span class="seriesInfo">RFC 6960</span>, <span class="seriesInfo">DOI 10.17487/RFC6960</span>, <time datetime="2013-06" class="refDate">June 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6960">https://www.rfc-editor.org/info/rfc6960</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="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="RFC7250">[RFC7250]</dt>
        <dd>
<span class="refAuthor">Wouters, P., Ed.</span>, <span class="refAuthor">Tschofenig, H., Ed.</span>, <span class="refAuthor">Gilmore, J.</span>, <span class="refAuthor">Weiler, S.</span>, and <span class="refAuthor">T. Kivinen</span>, <span class="refTitle">"Using Raw Public Keys in Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)"</span>, <span class="seriesInfo">RFC 7250</span>, <span class="seriesInfo">DOI 10.17487/RFC7250</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7250">https://www.rfc-editor.org/info/rfc7250</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9001">[RFC9001]</dt>
        <dd>
<span class="refAuthor">Thomson, M., Ed.</span> and <span class="refAuthor">S. Turner, Ed.</span>, <span class="refTitle">"Using TLS to Secure QUIC"</span>, <span class="seriesInfo">RFC 9001</span>, <span class="seriesInfo">DOI 10.17487/RFC9001</span>, <time datetime="2021-05" class="refDate">May 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9001">https://www.rfc-editor.org/info/rfc9001</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9113">[RFC9113]</dt>
        <dd>
<span class="refAuthor">Thomson, M., Ed.</span> and <span class="refAuthor">C. Benfield, Ed.</span>, <span class="refTitle">"HTTP/2"</span>, <span class="seriesInfo">RFC 9113</span>, <span class="seriesInfo">DOI 10.17487/RFC9113</span>, <time datetime="2022-06" class="refDate">June 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9113">https://www.rfc-editor.org/info/rfc9113</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>
<dt id="SIGMAC">[SIGMAC]</dt>
      <dd>
<span class="refAuthor">Krawczyk, H.</span>, <span class="refTitle">"A Unilateral-to-Mutual Authentication Compiler for Key Exchange (with Applications to Client Authentication in TLS 1.3)"</span>, <span class="refContent">Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security</span>, <span class="seriesInfo">DOI 10.1145/2976749.2978325</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://eprint.iacr.org/2016/711.pdf">https://eprint.iacr.org/2016/711.pdf</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="ack">
<section id="appendix-A">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="appendix-A-1">Comments on this proposal were provided by <span class="contact-name">Martin Thomson</span>.  Suggestions for
<a href="#security" class="xref">Section 9</a> were provided by <span class="contact-name">Karthikeyan Bhargavan</span>.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-B">
      <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">Nick Sullivan</span></div>
<div dir="auto" class="left"><span class="org">Cloudflare Inc.</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:nick@cloudflare.com" class="email">nick@cloudflare.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>