File: rfc8897.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 (1896 lines) | stat: -rw-r--r-- 84,767 bytes
parent folder | download | duplicates (2)
<!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 8897: Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties</title>
<meta content="Di Ma" name="author">
<meta content="Stephen Kent" name="author">
<meta content="
        This document provides a single reference point for requirements for
      Relying Party (RP) software for use in the Resource Public Key
      Infrastructure (RPKI). It cites requirements that appear in several RPKI
      RFCs, making it easier for implementers to become aware of these
      requirements. Over time, this RFC will be updated to reflect changes to
      the requirements and guidance specified in the RFCs discussed
      herein. 
    " name="description">
<meta content="xml2rfc 3.0.0" name="generator">
<meta content="dns" name="keyword">
<meta content="8897" name="rfc.number">
<link href="rfc8897.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

/* lists */
ol, ul {
  padding: 0;
  margin: 0 0 1em 2em;
}
ol ol, ul ul, ol ul, ul ol {
  margin-left: 1em;
}
li {
  margin: 0 0 0.25em 0;
}
.ulCompact li {
  margin: 0;
}
ul.empty, .ulEmpty {
  list-style-type: none;
}
ul.empty li, .ulEmpty li {
  margin-top: 0.5em;
}
ul.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;
}
#identifiers .authors .author {
  display: inline-block;
  margin-right: 1.5em;
}
#identifiers .authors .org {
  font-style: italic;
}

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: avoid-page;
  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;
}</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc8897" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-sidrops-rp-06" 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 8897</td>
<td class="center">RPKI RP Requirements</td>
<td class="right">September 2020</td>
</tr></thead>
<tfoot><tr>
<td class="left">Ma &amp; Kent</td>
<td class="center">Informational</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/rfc8897" class="eref">8897</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Informational</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2020-09" class="published">September 2020</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">D. Ma</div>
<div class="org">ZDNS</div>
</div>
<div class="author">
      <div class="author-name">S. Kent</div>
<div class="org">Independent</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 8897</h1>
<h1 id="title">Requirements for Resource Public Key Infrastructure (RPKI) Relying Parties</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1"> This document provides a single reference point for requirements for
      Relying Party (RP) software for use in the Resource Public Key
      Infrastructure (RPKI). It cites requirements that appear in several RPKI
      RFCs, making it easier for implementers to become aware of these
      requirements. Over time, this RFC will be updated to reflect changes to
      the requirements and guidance specified in the RFCs discussed
      herein.<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 informational purposes.<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).  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/rfc8897">https://www.rfc-editor.org/info/rfc8897</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) 2020 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 Simplified BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Simplified BSD License.<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="ulEmpty compact toc">
<li class="ulEmpty compact toc" 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><a href="#section-toc.1-1.1.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" 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-fetching-and-caching-rpki-r" class="xref">Fetching and Caching RPKI Repository Objects</a><a href="#section-toc.1-1.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.2.2.1">
                <p id="section-toc.1-1.2.2.1.1" class="keepWithNext"><a href="#section-2.1" class="xref">2.1</a>.  <a href="#name-tal-configuration-and-proce" class="xref">TAL Configuration and Processing</a><a href="#section-toc.1-1.2.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.2.2.2">
                <p id="section-toc.1-1.2.2.2.1" class="keepWithNext"><a href="#section-2.2" class="xref">2.2</a>.  <a href="#name-locating-rpki-objects-using" class="xref">Locating RPKI Objects Using Authority and Subject Information Extensions</a><a href="#section-toc.1-1.2.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" 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-dealing-with-key-rollover" class="xref">Dealing with Key Rollover</a><a href="#section-toc.1-1.2.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" 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-dealing-with-algorithm-tran" class="xref">Dealing with Algorithm Transition</a><a href="#section-toc.1-1.2.2.4.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.2.2.5">
                <p id="section-toc.1-1.2.2.5.1"><a href="#section-2.5" class="xref">2.5</a>.  <a href="#name-strategies-for-efficient-ca" class="xref">Strategies for Efficient Cache Maintenance</a><a href="#section-toc.1-1.2.2.5.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" 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-certificate-and-crl-process" class="xref">Certificate and CRL Processing</a><a href="#section-toc.1-1.3.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" 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-verifying-resource-certific" class="xref">Verifying Resource Certificate and Syntax</a><a href="#section-toc.1-1.3.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" 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-certificate-path-validation" class="xref">Certificate Path Validation</a><a href="#section-toc.1-1.3.2.2.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" 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-crl-processing" class="xref">CRL Processing</a><a href="#section-toc.1-1.3.2.3.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" 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-processing-rpki-repository-" class="xref">Processing RPKI Repository Signed Objects</a><a href="#section-toc.1-1.4.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-basic-signed-object-syntax-" class="xref">Basic Signed Object Syntax Checks</a><a href="#section-toc.1-1.4.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-syntax-and-validation-for-e" class="xref">Syntax and Validation for Each Type of Signed Object</a><a href="#section-toc.1-1.4.2.2.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" id="section-toc.1-1.4.2.2.2.1">
                    <p id="section-toc.1-1.4.2.2.2.1.1"><a href="#section-4.2.1" class="xref">4.2.1</a>.  <a href="#name-manifest" class="xref">Manifest</a><a href="#section-toc.1-1.4.2.2.2.1.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.2.2.2">
                    <p id="section-toc.1-1.4.2.2.2.2.1"><a href="#section-4.2.2" class="xref">4.2.2</a>.  <a href="#name-roa" class="xref">ROA</a><a href="#section-toc.1-1.4.2.2.2.2.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.2.2.3">
                    <p id="section-toc.1-1.4.2.2.2.3.1"><a href="#section-4.2.3" class="xref">4.2.3</a>.  <a href="#name-ghostbusters" class="xref">Ghostbusters</a><a href="#section-toc.1-1.4.2.2.2.3.1" class="pilcrow">¶</a></p>
</li>
                  <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.2.2.4">
                    <p id="section-toc.1-1.4.2.2.2.4.1"><a href="#section-4.2.4" class="xref">4.2.4</a>.  <a href="#name-verifying-bgpsec-router-cer" class="xref">Verifying BGPsec Router Certificate</a><a href="#section-toc.1-1.4.2.2.2.4.1" class="pilcrow">¶</a></p>
</li>
                </ul>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-how-to-make-use-of-manifest" class="xref">How to Make Use of Manifest Data</a><a href="#section-toc.1-1.4.2.3.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-what-to-do-with-ghostbuster" class="xref">What To Do with Ghostbusters Information</a><a href="#section-toc.1-1.4.2.4.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" 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-distributing-validated-cach" class="xref">Distributing Validated Cache</a><a href="#section-toc.1-1.5.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" 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-local-control" class="xref">Local Control</a><a href="#section-toc.1-1.6.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" 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><a href="#section-toc.1-1.7.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" 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><a href="#section-toc.1-1.8.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" 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><a href="#section-toc.1-1.9.1" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact toc">
<li class="ulEmpty compact toc" 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><a href="#section-toc.1-1.9.2.1.1" class="pilcrow">¶</a></p>
</li>
              <li class="ulEmpty compact toc" 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><a href="#section-toc.1-1.9.2.2.1" class="pilcrow">¶</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#section-appendix.a" class="xref"></a><a href="#name-acknowledgements" class="xref">Acknowledgements</a><a href="#section-toc.1-1.10.1" class="pilcrow">¶</a></p>
</li>
          <li class="ulEmpty compact toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#section-appendix.b" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a><a href="#section-toc.1-1.11.1" class="pilcrow">¶</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<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">RPKI Relying Party (RP) software is used by network operators and
   others to acquire and verify Internet Number Resource (INR) data
   stored in the RPKI repository system.  RPKI data, when verified,
   allows an RP to verify assertions about which Autonomous Systems
   (ASes) are authorized to originate routes for IP address prefixes.
   RPKI data also establishes a binding between public keys and BGP
   routers and indicates the AS numbers that each router is authorized
   to represent.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">The essential requirements imposed on RP software to support
      secure Internet routing <span>[<a href="#RFC6480" class="xref">RFC6480</a>]</span> are
      scattered throughout numerous protocol-specific RFCs and Best Current
      Practice RFCs. The following RFCs define these
      requirements:<a href="#section-1-2" class="pilcrow">¶</a></p>
<ul class="ulEmpty compact">
<li class="ulEmpty compact" id="section-1-3.1">
          <a href="#RFC6481" class="xref">RFC 6481</a> (Repository
       Structure)<a href="#section-1-3.1" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.2">
          <a href="#RFC6482" class="xref">RFC 6482</a> (ROA
       format)<a href="#section-1-3.2" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.3">
          <a href="#RFC6486" class="xref">RFC 6486</a>
       (Manifests)<a href="#section-1-3.3" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.4">
          <a href="#RFC6487" class="xref">RFC 6487</a> (Certificate and CRL profile)<a href="#section-1-3.4" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.5">
          <a href="#RFC6488" class="xref">RFC 6488</a> (RPKI Signed Objects)<a href="#section-1-3.5" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.6">
          <a href="#RFC6489" class="xref">RFC 6489</a> (Key Rollover)<a href="#section-1-3.6" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.7">
          <a href="#RFC6810" class="xref">RFC 6810</a> (RPKI to Router Protocol)<a href="#section-1-3.7" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.8">
          <a href="#RFC6916" class="xref">RFC 6916</a> (Algorithm Agility)<a href="#section-1-3.8" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.9">
          <a href="#RFC7935" class="xref">RFC 7935</a> (Algorithms)<a href="#section-1-3.9" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.10">
          <a href="#RFC8209" class="xref">RFC 8209</a> (Router Certificates)<a href="#section-1-3.10" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.11">
          <a href="#RFC8210" class="xref">RFC 8210</a> (RPKI to
       Router Protocol, Version 1)<a href="#section-1-3.11" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.12">
          <a href="#RFC8360" class="xref">RFC 8360</a> (Certificate Validation Procedure)<a href="#section-1-3.12" class="pilcrow">¶</a>
</li>
        <li class="ulEmpty compact" id="section-1-3.13">
          <a href="#RFC8630" class="xref">RFC 8630</a> (Trust Anchor Locator)<a href="#section-1-3.13" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-4">The distribution of RPKI RP requirements across these 13 documents
      makes it hard for an implementer to be confident that he/she has
      addressed all of these requirements. Additionally, good software
      engineering practice may call for segmenting the RP system into
      components with orthogonal functionalities so that those components may
      be distributed.  A taxonomy of the collected RP software requirements
      can help clarify the role of the RP.<a href="#section-1-4" class="pilcrow">¶</a></p>
<p id="section-1-5">To consolidate RP software requirements in one document, with
   pointers to all the relevant RFCs, this document outlines a set of
   baseline requirements imposed on RPs and provides a single reference
   point for requirements for RP software for use in the RPKI. The requirements
   are organized into four groups:<a href="#section-1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-1-6.1">Fetching and Caching RPKI Repository Objects<a href="#section-1-6.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-6.2">Processing Certificates and Certificate Revocation Lists (CRLs)<a href="#section-1-6.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-6.3">Processing RPKI Repository Signed Objects<a href="#section-1-6.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="section-1-6.4">Distributing Validated Cache of the RPKI Data<a href="#section-1-6.4" class="pilcrow">¶</a>
</li>
      </ul>
<p id="section-1-7">This document will be updated to reflect new or changed requirements
   as these RFCs are updated or additional RFCs are written.<a href="#section-1-7" class="pilcrow">¶</a></p>
</section>
<section id="section-2">
      <h2 id="name-fetching-and-caching-rpki-r">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-fetching-and-caching-rpki-r" class="section-name selfRef">Fetching and Caching RPKI Repository Objects</a>
      </h2>
<p id="section-2-1">RP software uses synchronization mechanisms supported by targeted
   repositories (e.g., <span>[<a href="#rsync" class="xref">rsync</a>]</span> or RRDP  <span>[<a href="#RFC8182" class="xref">RFC8182</a>]</span>) 
   to download RPKI signed objects from the repository system in order to
   update a local cache. These mechanisms download only those objects that
   have been added or replaced with new versions since the time when the
   RP most recently checked the repository.
   RP software validates the RPKI data and uses it to
   generate authenticated data identifying which ASes are authorized to
   originate routes for address prefixes and which routers are
   authorized to sign BGP updates on behalf of specified ASes.<a href="#section-2-1" class="pilcrow">¶</a></p>
<section id="section-2.1">
        <h3 id="name-tal-configuration-and-proce">
<a href="#section-2.1" class="section-number selfRef">2.1. </a><a href="#name-tal-configuration-and-proce" class="section-name selfRef">TAL Configuration and Processing</a>
        </h3>
<p id="section-2.1-1">In the RPKI, each RP chooses a set of trust anchors
 (TAs). Consistent with the extant INR allocation hierarchy, the IANA
 and/or the five Regional Internet Registries (RIRs) are obvious
 candidates to be default TAs for the RP.<a href="#section-2.1-1" class="pilcrow">¶</a></p>
<p id="section-2.1-2">An RP does not retrieve TAs directly.  A set of Trust Anchor
 Locators (TALs) is used by RP software to retrieve and verify the
 authenticity of each TA.<a href="#section-2.1-2" class="pilcrow">¶</a></p>
<p id="section-2.1-3">TAL configuration and processing are specified in <span><a href="https://www.rfc-editor.org/rfc/rfc8630#section-3" class="relref">Section 3</a> of [<a href="#RFC8630" class="xref">RFC8630</a>]</span>.<a href="#section-2.1-3" class="pilcrow">¶</a></p>
</section>
<section id="section-2.2">
        <h3 id="name-locating-rpki-objects-using">
<a href="#section-2.2" class="section-number selfRef">2.2. </a><a href="#name-locating-rpki-objects-using" class="section-name selfRef">Locating RPKI Objects Using Authority and Subject Information Extensions</a>
        </h3>
<p id="section-2.2-1">The RPKI repository system is a distributed one, consisting of
   multiple repository instances.  Each repository instance contains one
   or more repository publication points.  RP software discovers publication
   points using the Subject Information Access (SIA) and the Authority
   Information Access (AIA) extensions from (validated) certificates.<a href="#section-2.2-1" class="pilcrow">¶</a></p>
<p id="section-2.2-2"><span><a href="https://www.rfc-editor.org/rfc/rfc6481#section-5" class="relref">Section 5</a> of [<a href="#RFC6481" class="xref">RFC6481</a>]</span>  specifies how RP software
        locates all RPKI objects by using the SIA and AIA extensions.
        Detailed specifications of SIA and AIA extensions in a resource
        certificate are described in Sections <a href="https://www.rfc-editor.org/rfc/rfc6487#section-4.8.8" class="relref">4.8.8</a> and <a href="https://www.rfc-editor.org/rfc/rfc6487#section-4.8.7" class="relref">4.8.7</a> of <span>[<a href="#RFC6487" class="xref">RFC6487</a>]</span>, respectively.<a href="#section-2.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-2.3">
        <h3 id="name-dealing-with-key-rollover">
<a href="#section-2.3" class="section-number selfRef">2.3. </a><a href="#name-dealing-with-key-rollover" class="section-name selfRef">Dealing with Key Rollover</a>
        </h3>
<p id="section-2.3-1">RP software takes the key rollover period into account with regard to its
   frequency of synchronization with the RPKI repository system.<a href="#section-2.3-1" class="pilcrow">¶</a></p>
<p id="section-2.3-2">RP software requirements for dealing with key rollover are
 described in <span><a href="https://www.rfc-editor.org/rfc/rfc6489#section-3" class="relref">Section 3</a> of [<a href="#RFC6489" class="xref">RFC6489</a>]</span>
 and <span><a href="https://www.rfc-editor.org/rfc/rfc8634#section-3" class="relref">Section 3</a> of [<a href="#RFC8634" class="xref">RFC8634</a>]</span>.<a href="#section-2.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-2.4">
        <h3 id="name-dealing-with-algorithm-tran">
<a href="#section-2.4" class="section-number selfRef">2.4. </a><a href="#name-dealing-with-algorithm-tran" class="section-name selfRef">Dealing with Algorithm Transition</a>
        </h3>
<p id="section-2.4-1">The set of cryptographic algorithms used with the RPKI is expected to
   change over time.  Each RP is expected to be aware of the milestones
   established for the algorithm transition and what actions are
   required at every juncture.<a href="#section-2.4-1" class="pilcrow">¶</a></p>
<p id="section-2.4-2">RP software requirements for dealing with algorithm transition are
   specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6916#section-4" class="relref">Section 4</a> of [<a href="#RFC6916" class="xref">RFC6916</a>]</span>.<a href="#section-2.4-2" class="pilcrow">¶</a></p>
</section>
<section id="section-2.5">
        <h3 id="name-strategies-for-efficient-ca">
<a href="#section-2.5" class="section-number selfRef">2.5. </a><a href="#name-strategies-for-efficient-ca" class="section-name selfRef">Strategies for Efficient Cache Maintenance</a>
        </h3>
<p id="section-2.5-1">Each RP is expected to maintain a local cache of RPKI objects.  
The cache needs to be brought up to date and made consistent with the
repository publication point data as frequently as allowed by 
repository publication points and by locally selected RP processing
constraints.<a href="#section-2.5-1" class="pilcrow">¶</a></p>
<p id="section-2.5-2">The last paragraph of <span><a href="https://www.rfc-editor.org/rfc/rfc6481#section-5" class="relref">Section 5</a> of [<a href="#RFC6481" class="xref">RFC6481</a>]</span> provides
    guidance for maintenance of a local cache.<a href="#section-2.5-2" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-3">
      <h2 id="name-certificate-and-crl-process">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-certificate-and-crl-process" class="section-name selfRef">Certificate and CRL Processing</a>
      </h2>
<p id="section-3-1">The RPKI makes use of X.509 certificates and CRLs, but it profiles
      the standard formats described in <span>[<a href="#RFC6487" class="xref">RFC6487</a>]</span>.  The
      major change to the profile established in <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span> is the mandatory use of a new extension in RPKI
      certificates, defined in <span>[<a href="#RFC3779" class="xref">RFC3779</a>]</span>.<a href="#section-3-1" class="pilcrow">¶</a></p>
<section id="section-3.1">
        <h3 id="name-verifying-resource-certific">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-verifying-resource-certific" class="section-name selfRef">Verifying Resource Certificate and Syntax</a>
        </h3>
<p id="section-3.1-1">Certificates in the RPKI are called resource certificates, and they
 are required to conform to the profile described in <span>[<a href="#RFC6487" class="xref">RFC6487</a>]</span>.  An RP is required to verify that a resource
 certificate adheres to the profile established by <span><a href="https://www.rfc-editor.org/rfc/rfc6487#section-4" class="relref">Section 4</a> of [<a href="#RFC6487" class="xref">RFC6487</a>]</span>.  This means that
 all extensions mandated by <span><a href="https://www.rfc-editor.org/rfc/rfc6487#section-4.8" class="relref">Section 4.8</a> of [<a href="#RFC6487" class="xref">RFC6487</a>]</span> must be present and the value of each extension
 must be within the range specified by <span>[<a href="#RFC6487" class="xref">RFC6487</a>]</span>.  Moreover, any extension excluded by
 <span><a href="https://www.rfc-editor.org/rfc/rfc6487#section-4.8" class="relref">Section 4.8</a> of [<a href="#RFC6487" class="xref">RFC6487</a>]</span> must be omitted.<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.1-2"><span><a href="https://www.rfc-editor.org/rfc/rfc6487#section-7.1" class="relref">Section 7.1</a> of [<a href="#RFC6487" class="xref">RFC6487</a>]</span> specifies
 the procedure that RP software follows when verifying extensions
 described in <span>[<a href="#RFC3779" class="xref">RFC3779</a>]</span>.<a href="#section-3.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-3.2">
        <h3 id="name-certificate-path-validation">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-certificate-path-validation" class="section-name selfRef">Certificate Path Validation</a>
        </h3>
<p id="section-3.2-1">Initially, the INRs in the issuer's certificate are required to
 encompass the INRs in the subject's certificate.  This is one of the
 necessary principles of certificate path validation in addition to
 cryptographic verification (i.e., verification of the signature on
 each certificate using the public key of the parent certificate).<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.2-2"><span><a href="https://www.rfc-editor.org/rfc/rfc6487#section-7.2" class="relref">Section 7.2</a> of [<a href="#RFC6487" class="xref">RFC6487</a>]</span> specifies
 the procedure that RP software should follow to perform certificate
 path validation.<a href="#section-3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.2-3">Certification Authorities (CAs) that want to reduce aspects of
 operational fragility will migrate to the new OIDs <span>[<a href="#RFC8360" class="xref">RFC8360</a>]</span>, informing RP software to use an
 alternative RPKI validation algorithm.  An RP is expected to support
 the amended procedure to handle accidental overclaiming, which is
 described in <span><a href="https://www.rfc-editor.org/rfc/rfc8360#section-4" class="relref">Section 4</a> of [<a href="#RFC8360" class="xref">RFC8360</a>]</span>.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-3.3">
        <h3 id="name-crl-processing">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-crl-processing" class="section-name selfRef">CRL Processing</a>
        </h3>
<p id="section-3.3-1">The CRL processing requirements imposed on CAs and RPs are described
 in <span><a href="https://www.rfc-editor.org/rfc/rfc6487#section-5" class="relref">Section 5</a> of [<a href="#RFC6487" class="xref">RFC6487</a>]</span>.  CRLs in
 the RPKI are tightly constrained; only the AuthorityKeyIdentifier
 (<span><a href="https://www.rfc-editor.org/rfc/rfc6487#section-4.8.3" class="relref">Section 4.8.3</a> of [<a href="#RFC6487" class="xref">RFC6487</a>]</span>) and
 CRLNumber (<span><a href="https://www.rfc-editor.org/rfc/rfc5280#section-5.2.3" class="relref">Section 5.2.3</a> of [<a href="#RFC5280" class="xref">RFC5280</a>]</span>)
 extensions are allowed, and they are required to be present.  No other
 CRL extensions are allowed, and no CRLEntry extensions are permitted.
 RP software is required to verify that these constraints have been
 met.  Each CRL in the RPKI must be verified using the public key from
 the certificate of the CA that issued the CRL.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3-2">In the RPKI, RPs are expected to pay extra attention when dealing
 with a CRL that is not consistent with the manifest associated with
 the publication point associated with the CRL.<a href="#section-3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3-3">Processing of a CRL that is not consistent with a manifest is a
 matter of local policy, as described in the fifth paragraph of <span><a href="https://www.rfc-editor.org/rfc/rfc6486#section-6.6" class="relref">Section 6.6</a> of [<a href="#RFC6486" class="xref">RFC6486</a>]</span>.<a href="#section-3.3-3" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-4">
      <h2 id="name-processing-rpki-repository-">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-processing-rpki-repository-" class="section-name selfRef">Processing RPKI Repository Signed Objects</a>
      </h2>
<section id="section-4.1">
        <h3 id="name-basic-signed-object-syntax-">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-basic-signed-object-syntax-" class="section-name selfRef">Basic Signed Object Syntax Checks</a>
        </h3>
<p id="section-4.1-1">Before an RP can use a signed object from the RPKI repository, RP software
   is required to check the signed-object syntax.<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.1-2"><span><a href="https://www.rfc-editor.org/rfc/rfc6488#section-3" class="relref">Section 3</a> of [<a href="#RFC6488" class="xref">RFC6488</a>]</span> lists all
 the steps that RP software is required to execute in order to validate
 the top-level syntax of a repository signed object.<a href="#section-4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.1-3">Note that these checks are necessary but not sufficient.
 Additional validation checks must be performed based on the specific
 type of signed object, as described in <a href="#syntax" class="xref">Section 4.2</a>.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
</section>
<div id="syntax">
<section id="section-4.2">
        <h3 id="name-syntax-and-validation-for-e">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-syntax-and-validation-for-e" class="section-name selfRef">Syntax and Validation for Each Type of Signed Object</a>
        </h3>
<section id="section-4.2.1">
          <h4 id="name-manifest">
<a href="#section-4.2.1" class="section-number selfRef">4.2.1. </a><a href="#name-manifest" class="section-name selfRef">Manifest</a>
          </h4>
<p id="section-4.2.1-1">To determine whether a manifest is valid, RP software is required
   to perform manifest-specific checks in addition to the generic
   signed-object checks specified in <span>[<a href="#RFC6488" class="xref">RFC6488</a>]</span>.<a href="#section-4.2.1-1" class="pilcrow">¶</a></p>
<p id="section-4.2.1-2">Specific checks for a manifest are described in <span><a href="https://www.rfc-editor.org/rfc/rfc6486#section-4" class="relref">Section 4</a> of [<a href="#RFC6486" class="xref">RFC6486</a>]</span>.  If any of these
   checks fail, indicating that the manifest is invalid, then the
   manifest will be discarded, and RP software will act as though no
   manifest were present.<a href="#section-4.2.1-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.2.2">
          <h4 id="name-roa">
<a href="#section-4.2.2" class="section-number selfRef">4.2.2. </a><a href="#name-roa" class="section-name selfRef">ROA</a>
          </h4>
<p id="section-4.2.2-1">To validate a Route Origin Authorization (ROA), RP software is
   required to perform all the checks specified in <span>[<a href="#RFC6488" class="xref">RFC6488</a>]</span> as well as additional,
   ROA-specific validation steps.  The IP Address Delegation extension
   <span>[<a href="#RFC3779" class="xref">RFC3779</a>]</span> present in the end-entity
   (EE) certificate (contained within the ROA) must encompass each of
   the IP address prefix(es) in the ROA.<a href="#section-4.2.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2.2-2">More details for ROA validation are specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6482#section-4" class="relref">Section 4</a> of [<a href="#RFC6482" class="xref">RFC6482</a>]</span>.<a href="#section-4.2.2-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.2.3">
          <h4 id="name-ghostbusters">
<a href="#section-4.2.3" class="section-number selfRef">4.2.3. </a><a href="#name-ghostbusters" class="section-name selfRef">Ghostbusters</a>
          </h4>
<p id="section-4.2.3-1">The Ghostbusters Record is optional; a publication point in the RPKI
   can have zero or more associated Ghostbusters Records.  If a CA has at
   least one Ghostbusters Record, RP software is required to verify that this
   Ghostbusters Record conforms to the syntax of signed objects defined
   in <span>[<a href="#RFC6488" class="xref">RFC6488</a>]</span>.<a href="#section-4.2.3-1" class="pilcrow">¶</a></p>
<p id="section-4.2.3-2">The payload of this signed object is a (severely) profiled
   vCard. RP software is required to verify that the payload of
   Ghostbusters conforms to format as profiled in <span>[<a href="#RFC6493" class="xref">RFC6493</a>]</span>.<a href="#section-4.2.3-2" class="pilcrow">¶</a></p>
</section>
<section id="section-4.2.4">
          <h4 id="name-verifying-bgpsec-router-cer">
<a href="#section-4.2.4" class="section-number selfRef">4.2.4. </a><a href="#name-verifying-bgpsec-router-cer" class="section-name selfRef">Verifying BGPsec Router Certificate</a>
          </h4>
<p id="section-4.2.4-1">A BGPsec Router Certificate is a resource certificate, so it is
   required to comply with <span>[<a href="#RFC6487" class="xref">RFC6487</a>]</span>.
   Additionally, the certificate must contain an AS Identifier
   Delegation extension (<span><a href="https://www.rfc-editor.org/rfc/rfc6487#section-4.8.11" class="relref">Section 4.8.11</a> of [<a href="#RFC6487" class="xref">RFC6487</a>]</span>) and must not contain an IP Address Delegation
   extension (<span><a href="https://www.rfc-editor.org/rfc/rfc6487#section-4.8.10" class="relref">Section 4.8.10</a> of [<a href="#RFC6487" class="xref">RFC6487</a>]</span>).  The validation procedure used for BGPsec
   Router Certificates is analogous to the validation procedure
   described in <span><a href="https://www.rfc-editor.org/rfc/rfc6487#section-7" class="relref">Section 7</a> of [<a href="#RFC6487" class="xref">RFC6487</a>]</span>, but it uses the constraints defined in <span><a href="https://www.rfc-editor.org/rfc/rfc8209#section-3" class="relref">Section 3</a> of [<a href="#RFC8209" class="xref">RFC8209</a>]</span>.<a href="#section-4.2.4-1" class="pilcrow">¶</a></p>
<p id="section-4.2.4-2">Note that the cryptographic algorithms used by BGPsec routers are
   found in <span>[<a href="#RFC8608" class="xref">RFC8608</a>]</span>.  Currently, the
   algorithms specified in <span>[<a href="#RFC8608" class="xref">RFC8608</a>]</span>
   and <span>[<a href="#RFC7935" class="xref">RFC7935</a>]</span> are different.  BGPsec
   RP software will need to support algorithms that are used to
   validate BGPsec signatures as well as the algorithms that are needed
   to validate signatures on BGPsec certificates, RPKI CA certificates,
   and RPKI CRLs.<a href="#section-4.2.4-2" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<section id="section-4.3">
        <h3 id="name-how-to-make-use-of-manifest">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-how-to-make-use-of-manifest" class="section-name selfRef">How to Make Use of Manifest Data</a>
        </h3>
<p id="section-4.3-1">For a given publication point, RP software ought to perform tests,
 as specified in <span><a href="https://www.rfc-editor.org/rfc/rfc6486#section-6.1" class="relref">Section 6.1</a> of [<a href="#RFC6486" class="xref">RFC6486</a>]</span>, to determine the state of the manifest at the
 publication point.  A manifest can be classified as either valid or
 invalid, and a valid manifest is either current or stale.  An RP
 decides how to make use of a manifest based on its state, according to
 local (RP) policy.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3-2">If there are valid objects in a publication point that are not
 present on a manifest, <span>[<a href="#RFC6486" class="xref">RFC6486</a>]</span> does
 not mandate specific RP behavior with respect to such objects.<a href="#section-4.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3-3">In the absence of a manifest, an RP is expected to accept all valid
 signed objects present in the publication point (see <span><a href="https://www.rfc-editor.org/rfc/rfc6486#section-6.2" class="relref">Section 6.2</a> of [<a href="#RFC6486" class="xref">RFC6486</a>]</span>). If a manifest is
 stale or invalid and an RP has no way to acquire a more recent valid
 manifest, the RP is expected to contact the repository manager via
 Ghostbusters Records and thereafter make decisions according to local
 (RP) policy (see Sections <a href="https://www.rfc-editor.org/rfc/rfc6486#section-6.3" class="relref">6.3</a> and <a href="https://www.rfc-editor.org/rfc/rfc6486#section-6.4" class="relref">6.4</a> of <span>[<a href="#RFC6486" class="xref">RFC6486</a>]</span>).<a href="#section-4.3-3" class="pilcrow">¶</a></p>
</section>
<section id="section-4.4">
        <h3 id="name-what-to-do-with-ghostbuster">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-what-to-do-with-ghostbuster" class="section-name selfRef">What To Do with Ghostbusters Information</a>
        </h3>
<p id="section-4.4-1">RP software may encounter a stale manifest or CRL, or an expired CA
 certificate or ROA at a publication point. An RP is expected to use
 the information from the Ghostbusters Records to contact the maintainer
 of the publication point where any stale/expired objects were
 encountered.  The intent here is to encourage the relevant CA and/or
 repository manager to update the stale or expired objects.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
</section>
</section>
<section id="section-5">
      <h2 id="name-distributing-validated-cach">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-distributing-validated-cach" class="section-name selfRef">Distributing Validated Cache</a>
      </h2>
<p id="section-5-1">On a periodic basis, BGP speakers within an AS request updated
   validated origin AS data and router/ASN data from the (local) validated cache of RPKI data.
   The RP may either transfer the validated data to the BGP speakers directly,
   or it may transfer the validated data to a cache server that is responsible
   for provisioning such data to BGP speakers.  The specifications of the
   protocol designed to deliver validated cache data to a BGP Speaker are provided
   in <span>[<a href="#RFC6810" class="xref">RFC6810</a>]</span> and <span>[<a href="#RFC8210" class="xref">RFC8210</a>]</span>.<a href="#section-5-1" class="pilcrow">¶</a></p>
</section>
<section id="section-6">
      <h2 id="name-local-control">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-local-control" class="section-name selfRef">Local Control</a>
      </h2>
<p id="section-6-1">ISPs may want to establish a local view of exceptions to the RPKI
   data in the form of local filters and additions.  For instance, a
   network operator might wish to make use of a local override
   capability to protect routes from adverse actions <span>[<a href="#RFC8211" class="xref">RFC8211</a>]</span>. The
   mechanisms developed to provide this capability to network operators
   are called Simplified Local Internet Number Resource Management with the
   RPKI (SLURM).  If an ISP wants to implement SLURM, its RP system
   can follow the instruction specified in <span>[<a href="#RFC8416" class="xref">RFC8416</a>]</span>.<a href="#section-6-1" class="pilcrow">¶</a></p>
</section>
<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>
<p id="section-7-1">This document does not introduce any new security considerations; it
   is a resource for implementers.  The RP links the RPKI provisioning
   side and the routing system, establishing a verified, local view of global
   RPKI data to BGP speakers.  The security of the RP is critical for exchanging BGP
   messages.  Each RP implementation is expected to offer
   cache backup management to facilitate recovery from outages.
   RP software should also support secure transport (e.g., IPsec <span>[<a href="#RFC4301" class="xref">RFC4301</a>]</span>) that can protect validated cache
   delivery in an unsafe environment. This document highlights
   many validation actions applied to RPKI signed objects, an essential
   element of secure operation of RPKI security.<a href="#section-7-1" class="pilcrow">¶</a></p>
</section>
<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>
<p id="section-8-1">This document has no IANA actions.<a href="#section-8-1" class="pilcrow">¶</a></p>
</section>
<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="RFC3779">[RFC3779]</dt>
        <dd>
<span class="refAuthor">Lynn, C.</span><span class="refAuthor">, Kent, S.</span><span class="refAuthor">, and K. Seo</span>, <span class="refTitle">"X.509 Extensions for IP Addresses and AS Identifiers"</span>, <span class="seriesInfo">RFC 3779</span>, <span class="seriesInfo">DOI 10.17487/RFC3779</span>, <time datetime="2004-06" class="refDate">June 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3779">https://www.rfc-editor.org/info/rfc3779</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><span class="refAuthor">, and 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="RFC6481">[RFC6481]</dt>
        <dd>
<span class="refAuthor">Huston, G.</span><span class="refAuthor">, Loomans, R.</span><span class="refAuthor">, and G. Michaelson</span>, <span class="refTitle">"A Profile for Resource Certificate Repository Structure"</span>, <span class="seriesInfo">RFC 6481</span>, <span class="seriesInfo">DOI 10.17487/RFC6481</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6481">https://www.rfc-editor.org/info/rfc6481</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6482">[RFC6482]</dt>
        <dd>
<span class="refAuthor">Lepinski, M.</span><span class="refAuthor">, Kent, S.</span><span class="refAuthor">, and D. Kong</span>, <span class="refTitle">"A Profile for Route Origin Authorizations (ROAs)"</span>, <span class="seriesInfo">RFC 6482</span>, <span class="seriesInfo">DOI 10.17487/RFC6482</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6482">https://www.rfc-editor.org/info/rfc6482</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6486">[RFC6486]</dt>
        <dd>
<span class="refAuthor">Austein, R.</span><span class="refAuthor">, Huston, G.</span><span class="refAuthor">, Kent, S.</span><span class="refAuthor">, and M. Lepinski</span>, <span class="refTitle">"Manifests for the Resource Public Key Infrastructure (RPKI)"</span>, <span class="seriesInfo">RFC 6486</span>, <span class="seriesInfo">DOI 10.17487/RFC6486</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6486">https://www.rfc-editor.org/info/rfc6486</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6487">[RFC6487]</dt>
        <dd>
<span class="refAuthor">Huston, G.</span><span class="refAuthor">, Michaelson, G.</span><span class="refAuthor">, and R. Loomans</span>, <span class="refTitle">"A Profile for X.509 PKIX Resource Certificates"</span>, <span class="seriesInfo">RFC 6487</span>, <span class="seriesInfo">DOI 10.17487/RFC6487</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6487">https://www.rfc-editor.org/info/rfc6487</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6488">[RFC6488]</dt>
        <dd>
<span class="refAuthor">Lepinski, M.</span><span class="refAuthor">, Chi, A.</span><span class="refAuthor">, and S. Kent</span>, <span class="refTitle">"Signed Object Template for the Resource Public Key Infrastructure (RPKI)"</span>, <span class="seriesInfo">RFC 6488</span>, <span class="seriesInfo">DOI 10.17487/RFC6488</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6488">https://www.rfc-editor.org/info/rfc6488</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6489">[RFC6489]</dt>
        <dd>
<span class="refAuthor">Huston, G.</span><span class="refAuthor">, Michaelson, G.</span><span class="refAuthor">, and S. Kent</span>, <span class="refTitle">"Certification Authority (CA) Key Rollover in the Resource Public Key Infrastructure (RPKI)"</span>, <span class="seriesInfo">BCP 174</span>, <span class="seriesInfo">RFC 6489</span>, <span class="seriesInfo">DOI 10.17487/RFC6489</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6489">https://www.rfc-editor.org/info/rfc6489</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6493">[RFC6493]</dt>
        <dd>
<span class="refAuthor">Bush, R.</span>, <span class="refTitle">"The Resource Public Key Infrastructure (RPKI) Ghostbusters Record"</span>, <span class="seriesInfo">RFC 6493</span>, <span class="seriesInfo">DOI 10.17487/RFC6493</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6493">https://www.rfc-editor.org/info/rfc6493</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6810">[RFC6810]</dt>
        <dd>
<span class="refAuthor">Bush, R.</span><span class="refAuthor"> and R. Austein</span>, <span class="refTitle">"The Resource Public Key Infrastructure (RPKI) to Router Protocol"</span>, <span class="seriesInfo">RFC 6810</span>, <span class="seriesInfo">DOI 10.17487/RFC6810</span>, <time datetime="2013-01" class="refDate">January 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6810">https://www.rfc-editor.org/info/rfc6810</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6916">[RFC6916]</dt>
        <dd>
<span class="refAuthor">Gagliano, R.</span><span class="refAuthor">, Kent, S.</span><span class="refAuthor">, and S. Turner</span>, <span class="refTitle">"Algorithm Agility Procedure for the Resource Public Key Infrastructure (RPKI)"</span>, <span class="seriesInfo">BCP 182</span>, <span class="seriesInfo">RFC 6916</span>, <span class="seriesInfo">DOI 10.17487/RFC6916</span>, <time datetime="2013-04" class="refDate">April 2013</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6916">https://www.rfc-editor.org/info/rfc6916</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7935">[RFC7935]</dt>
        <dd>
<span class="refAuthor">Huston, G.</span><span class="refAuthor"> and G. Michaelson, Ed.</span>, <span class="refTitle">"The Profile for Algorithms and Key Sizes for Use in the Resource Public Key Infrastructure"</span>, <span class="seriesInfo">RFC 7935</span>, <span class="seriesInfo">DOI 10.17487/RFC7935</span>, <time datetime="2016-08" class="refDate">August 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7935">https://www.rfc-editor.org/info/rfc7935</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8209">[RFC8209]</dt>
        <dd>
<span class="refAuthor">Reynolds, M.</span><span class="refAuthor">, Turner, S.</span><span class="refAuthor">, and S. Kent</span>, <span class="refTitle">"A Profile for BGPsec Router Certificates, Certificate Revocation Lists, and Certification Requests"</span>, <span class="seriesInfo">RFC 8209</span>, <span class="seriesInfo">DOI 10.17487/RFC8209</span>, <time datetime="2017-09" class="refDate">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8209">https://www.rfc-editor.org/info/rfc8209</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8210">[RFC8210]</dt>
        <dd>
<span class="refAuthor">Bush, R.</span><span class="refAuthor"> and R. Austein</span>, <span class="refTitle">"The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1"</span>, <span class="seriesInfo">RFC 8210</span>, <span class="seriesInfo">DOI 10.17487/RFC8210</span>, <time datetime="2017-09" class="refDate">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8210">https://www.rfc-editor.org/info/rfc8210</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8360">[RFC8360]</dt>
        <dd>
<span class="refAuthor">Huston, G.</span><span class="refAuthor">, Michaelson, G.</span><span class="refAuthor">, Martinez, C.</span><span class="refAuthor">, Bruijnzeels, T.</span><span class="refAuthor">, Newton, A.</span><span class="refAuthor">, and D. Shaw</span>, <span class="refTitle">"Resource Public Key Infrastructure (RPKI) Validation Reconsidered"</span>, <span class="seriesInfo">RFC 8360</span>, <span class="seriesInfo">DOI 10.17487/RFC8360</span>, <time datetime="2018-04" class="refDate">April 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8360">https://www.rfc-editor.org/info/rfc8360</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8608">[RFC8608]</dt>
        <dd>
<span class="refAuthor">Turner, S.</span><span class="refAuthor"> and O. Borchert</span>, <span class="refTitle">"BGPsec Algorithms, Key Formats, and Signature Formats"</span>, <span class="seriesInfo">RFC 8608</span>, <span class="seriesInfo">DOI 10.17487/RFC8608</span>, <time datetime="2019-06" class="refDate">June 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8608">https://www.rfc-editor.org/info/rfc8608</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8630">[RFC8630]</dt>
        <dd>
<span class="refAuthor">Huston, G.</span><span class="refAuthor">, Weiler, S.</span><span class="refAuthor">, Michaelson, G.</span><span class="refAuthor">, Kent, S.</span><span class="refAuthor">, and T. Bruijnzeels</span>, <span class="refTitle">"Resource Public Key Infrastructure (RPKI) Trust Anchor Locator"</span>, <span class="seriesInfo">RFC 8630</span>, <span class="seriesInfo">DOI 10.17487/RFC8630</span>, <time datetime="2019-08" class="refDate">August 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8630">https://www.rfc-editor.org/info/rfc8630</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8634">[RFC8634]</dt>
      <dd>
<span class="refAuthor">Weis, B.</span><span class="refAuthor">, Gagliano, R.</span><span class="refAuthor">, and K. Patel</span>, <span class="refTitle">"BGPsec Router Certificate Rollover"</span>, <span class="seriesInfo">BCP 224</span>, <span class="seriesInfo">RFC 8634</span>, <span class="seriesInfo">DOI 10.17487/RFC8634</span>, <time datetime="2019-08" class="refDate">August 2019</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8634">https://www.rfc-editor.org/info/rfc8634</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="RFC4301">[RFC4301]</dt>
        <dd>
<span class="refAuthor">Kent, S.</span><span class="refAuthor"> and K. Seo</span>, <span class="refTitle">"Security Architecture for the Internet Protocol"</span>, <span class="seriesInfo">RFC 4301</span>, <span class="seriesInfo">DOI 10.17487/RFC4301</span>, <time datetime="2005-12" class="refDate">December 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4301">https://www.rfc-editor.org/info/rfc4301</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6480">[RFC6480]</dt>
        <dd>
<span class="refAuthor">Lepinski, M.</span><span class="refAuthor"> and S. Kent</span>, <span class="refTitle">"An Infrastructure to Support Secure Internet Routing"</span>, <span class="seriesInfo">RFC 6480</span>, <span class="seriesInfo">DOI 10.17487/RFC6480</span>, <time datetime="2012-02" class="refDate">February 2012</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc6480">https://www.rfc-editor.org/info/rfc6480</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8182">[RFC8182]</dt>
        <dd>
<span class="refAuthor">Bruijnzeels, T.</span><span class="refAuthor">, Muravskiy, O.</span><span class="refAuthor">, Weber, B.</span><span class="refAuthor">, and R. Austein</span>, <span class="refTitle">"The RPKI Repository Delta Protocol (RRDP)"</span>, <span class="seriesInfo">RFC 8182</span>, <span class="seriesInfo">DOI 10.17487/RFC8182</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8182">https://www.rfc-editor.org/info/rfc8182</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8211">[RFC8211]</dt>
        <dd>
<span class="refAuthor">Kent, S.</span><span class="refAuthor"> and D. Ma</span>, <span class="refTitle">"Adverse Actions by a Certification Authority (CA) or Repository Manager in the Resource Public Key Infrastructure (RPKI)"</span>, <span class="seriesInfo">RFC 8211</span>, <span class="seriesInfo">DOI 10.17487/RFC8211</span>, <time datetime="2017-09" class="refDate">September 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8211">https://www.rfc-editor.org/info/rfc8211</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8416">[RFC8416]</dt>
        <dd>
<span class="refAuthor">Ma, D.</span><span class="refAuthor">, Mandelberg, D.</span><span class="refAuthor">, and T. Bruijnzeels</span>, <span class="refTitle">"Simplified Local Internet Number Resource Management with the RPKI (SLURM)"</span>, <span class="seriesInfo">RFC 8416</span>, <span class="seriesInfo">DOI 10.17487/RFC8416</span>, <time datetime="2018-08" class="refDate">August 2018</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8416">https://www.rfc-editor.org/info/rfc8416</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="rsync">[rsync]</dt>
      <dd>
<span class="refTitle">"rsync"</span>, <span>&lt;<a href="http://rsync.samba.org/">http://rsync.samba.org/</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<section id="section-appendix.a">
      <h2 id="name-acknowledgements">
<a href="#name-acknowledgements" class="section-name selfRef">Acknowledgements</a>
      </h2>
<p id="section-appendix.a-1">The authors thank <span class="contact-name">David Mandelberg</span>, <span class="contact-name">Wei Wang</span>, <span class="contact-name">Tim Bruijnzeels</span>, <span class="contact-name">George Michaelson</span>, and <span class="contact-name">Oleg Muravskiy</span>
      for their review, feedback, and editorial assistance in preparing this
      document.<a href="#section-appendix.a-1" class="pilcrow">¶</a></p>
</section>
<div id="authors-addresses">
<section id="section-appendix.b">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Di Ma</span></div>
<div dir="auto" class="left"><span class="org">ZDNS</span></div>
<div dir="auto" class="left"><span class="street-address">4 South 4th St. Zhongguancun</span></div>
<div dir="auto" class="left"><span class="locality">Haidian</span></div>
<div dir="auto" class="left">
<span class="region">Beijing</span>, <span class="postal-code">100190</span>
</div>
<div dir="auto" class="left"><span class="country-name">China</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:madi@zdns.cn" class="email">madi@zdns.cn</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Stephen Kent</span></div>
<div dir="auto" class="left"><span class="org">Independent</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:kent@alum.mit.edu" class="email">kent@alum.mit.edu</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>