File: rfc9092.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 (2449 lines) | stat: -rw-r--r-- 108,316 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 9092: Finding and Using Geofeed Data</title>
<meta content="Randy Bush" name="author">
<meta content="Massimo Candela" name="author">
<meta content="Warren Kumari" name="author">
<meta content="Russ Housley" name="author">
<meta content="
       
        This document specifies how to augment the Routing Policy
        Specification Language inetnum: class to refer specifically to geofeed
        data comma-separated values (CSV) files and describes an optional scheme
        that uses the Routing Public Key Infrastructure to authenticate the
        geofeed data CSV files.
       
    " name="description">
<meta content="xml2rfc 3.9.1" name="generator">
<meta content="geolocation" name="keyword">
<meta content="geo-location" name="keyword">
<meta content="RPSL" name="keyword">
<meta content="9092" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.9.1
    Python 3.6.10
    appdirs 1.4.4
    ConfigArgParse 1.2.3
    google-i18n-address 2.3.5
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.2
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.19.0
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.3.1
    requests 2.22.0
    setuptools 40.6.2
    six 1.14.0
    WeasyPrint 51
-->
<link href="rfc9092.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

/* info block */
#identifiers {
  margin: 0;
  font-size: 0.9em;
}
#identifiers dt {
  width: 3em;
  clear: left;
}
#identifiers dd {
  float: left;
  margin-bottom: 0;
}
#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;
}
/* 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/rfc9092" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-opsawg-finding-geofeeds-17" 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 9092</td>
<td class="center">Finding Geofeeds</td>
<td class="right">July 2021</td>
</tr></thead>
<tfoot><tr>
<td class="left">Bush, et al.</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/rfc9092" class="eref">9092</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="2021-07" class="published">July 2021</time>
    </dd>
<dt class="label-issn">ISSN:</dt>
<dd class="issn">2070-1721</dd>
<dt class="label-authors">Authors:</dt>
<dd class="authors">
<div class="author">
      <div class="author-name">R. Bush</div>
<div class="org">IIJ &amp; Arrcus</div>
</div>
<div class="author">
      <div class="author-name">M. Candela</div>
<div class="org">NTT</div>
</div>
<div class="author">
      <div class="author-name">W. Kumari</div>
<div class="org">Google</div>
</div>
<div class="author">
      <div class="author-name">R. Housley</div>
<div class="org">Vigil Security</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9092</h1>
<h1 id="title">Finding and Using Geofeed Data</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
        This document specifies how to augment the Routing Policy
        Specification Language inetnum: class to refer specifically to geofeed
        data comma-separated values (CSV) files and describes an optional scheme
        that uses the Routing Public Key Infrastructure to authenticate the
        geofeed data CSV files.<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/rfc9092">https://www.rfc-editor.org/info/rfc9092</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2021 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include 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 ulBare compact toc">
<li class="ulEmpty ulBare 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></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare toc" id="section-toc.1-1.1.2.1">
                <p id="section-toc.1-1.1.2.1.1" class="keepWithNext"><a href="#section-1.1" class="xref">1.1</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare compact toc" 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-geofeed-files" class="xref">Geofeed Files</a></p>
</li>
          <li class="ulEmpty ulBare 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-inetnum-class" class="xref">inetnum: Class</a></p>
</li>
          <li class="ulEmpty ulBare 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-authenticating-geofeed-data" class="xref">Authenticating Geofeed Data</a></p>
</li>
          <li class="ulEmpty ulBare 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-operational-considerations" class="xref">Operational Considerations</a></p>
</li>
          <li class="ulEmpty ulBare 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-privacy-considerations" class="xref">Privacy Considerations</a></p>
</li>
          <li class="ulEmpty ulBare 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></p>
</li>
          <li class="ulEmpty ulBare 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></p>
</li>
          <li class="ulEmpty ulBare 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></p>
<ul class="compact ulEmpty ulBare toc">
<li class="compact ulEmpty ulBare 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></p>
</li>
              <li class="compact ulEmpty ulBare 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></p>
</li>
            </ul>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-example" class="xref">Example</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-B" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="ulEmpty ulBare compact toc" id="section-toc.1-1.12">
            <p id="section-toc.1-1.12.1"><a href="#appendix-C" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="intro">
<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">
        Providers of Internet content and other services may wish to
        customize those services based on the geographic location of the
        user of the service.  This is often done using the source IP
        address used to contact the service.  Also, infrastructure and
        other services might wish to publish the locale of their
        services.  <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span> defines geofeed, a syntax to
        associate geographic locales with IP addresses, but it does not
        specify how to find the relevant geofeed data given an IP
        address.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
        This document specifies how to augment the Routing Policy
        Specification Language (RPSL) <span>[<a href="#RFC2725" class="xref">RFC2725</a>]</span> inetnum:
        class to refer specifically to geofeed data CSV files and how
        to prudently use them.  In all places inetnum: is used,
        inet6num: should also be assumed <span>[<a href="#RFC4012" class="xref">RFC4012</a>]</span>.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
        The reader may find <span>[<a href="#INETNUM" class="xref">INETNUM</a>]</span> and <span>[<a href="#INET6NUM" class="xref">INET6NUM</a>]</span> informative, and certainly more verbose,
        descriptions of the inetnum: database classes.<a href="#section-1-3" class="pilcrow">¶</a></p>
<p id="section-1-4">
        An optional utterly awesome but slightly complex means for
        authenticating geofeed data is also defined.<a href="#section-1-4" class="pilcrow">¶</a></p>
<section id="section-1.1">
        <h3 id="name-requirements-language">
<a href="#section-1.1" class="section-number selfRef">1.1. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
        </h3>
<p id="section-1.1-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>",
    "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>",
    "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are
    to be interpreted as described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span>
          <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> when, and only when, they appear in all capitals,
    as shown here.<a href="#section-1.1-1" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<div id="gf">
<section id="section-2">
      <h2 id="name-geofeed-files">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-geofeed-files" class="section-name selfRef">Geofeed Files</a>
      </h2>
<p id="section-2-1">
        Geofeed files are described in <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span>.  They
        provide a facility for an IP address resource "owner" to
        associate those IP addresses to geographic locales.<a href="#section-2-1" class="pilcrow">¶</a></p>
<p id="section-2-2">
        Content providers and other parties who wish to locate an IP address
        to a geographic locale need to find the relevant geofeed data.  In
        <a href="#inetnum" class="xref">Section 3</a>, this document specifies how
        to find the relevant geofeed <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span>
        file given an IP address.<a href="#section-2-2" class="pilcrow">¶</a></p>
<p id="section-2-3">
        Geofeed data for large providers with significant horizontal
        scale and high granularity can be quite large.  The size of a
        file can be even larger if an unsigned geofeed file combines
        data for many prefixes, if dual IPv4/IPv6 spaces are represented,
        etc.<a href="#section-2-3" class="pilcrow">¶</a></p>
<p id="section-2-4">
        Geofeed data do have privacy considerations (see <a href="#privacy" class="xref">Section 6</a>); this process makes bulk access
        to those data easier.<a href="#section-2-4" class="pilcrow">¶</a></p>
<p id="section-2-5">
        This document also suggests an optional signature to strongly
        authenticate the data in the geofeed files.<a href="#section-2-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="inetnum">
<section id="section-3">
      <h2 id="name-inetnum-class">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-inetnum-class" class="section-name selfRef">inetnum: Class</a>
      </h2>
<p id="section-3-1">
        The original RPSL specifications starting with <span>[<a href="#RIPE81" class="xref">RIPE81</a>]</span>, <span>[<a href="#RIPE181" class="xref">RIPE181</a>]</span>, and a trail of
        subsequent documents were written by the RIPE community.  The IETF
        standardized RPSL in <span>[<a href="#RFC2622" class="xref">RFC2622</a>]</span> and <span>[<a href="#RFC4012" class="xref">RFC4012</a>]</span>.  Since then, it has been modified and
        extensively enhanced in the Regional Internet Registry (RIR)
        community, mostly by RIPE <span>[<a href="#RIPE-DB" class="xref">RIPE-DB</a>]</span>.  Currently,
        change control effectively lies in the operator community.<a href="#section-3-1" class="pilcrow">¶</a></p>
<p id="section-3-2">
        The RPSL, and <span>[<a href="#RFC2725" class="xref">RFC2725</a>]</span> and <span>[<a href="#RFC4012" class="xref">RFC4012</a>]</span> used by the
        Regional Internet Registries (RIRs), specify the inetnum:
        database class.  Each of these objects describes an IP address
        range and its attributes.  The inetnum: objects form a hierarchy
        ordered on the address space.<a href="#section-3-2" class="pilcrow">¶</a></p>
<p id="section-3-3">
        Ideally, RPSL would be augmented to define a new RPSL geofeed:
        attribute in the inetnum: class.  Until such time, this document
        defines the syntax of a Geofeed remarks: attribute, which contains an
        HTTPS URL of a geofeed file.  The format of the inetnum: geofeed
        remarks: attribute <span class="bcp14">MUST</span> be as in this example,
        "remarks: Geofeed ", where the token "Geofeed " <span class="bcp14">MUST</span> be
        case sensitive, followed by a URL that will vary, but it
        <span class="bcp14">MUST</span> refer only to a single geofeed <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span> file.<a href="#section-3-3" class="pilcrow">¶</a></p>
<div id="section-3-4">
<pre class="sourcecode lang-rpsl">
    inetnum: 192.0.2.0/24 # example
    remarks: Geofeed https://example.com/geofeed.csv
</pre><a href="#section-3-4" class="pilcrow">¶</a>
</div>
<p id="section-3-5">
        While we leave global agreement of RPSL modification to the relevant
        parties, we specify that a proper geofeed: attribute in the inetnum:
        class <span class="bcp14">MUST</span> be "geofeed:" and <span class="bcp14">MUST</span> be
        followed by a single URL that will vary, but it <span class="bcp14">MUST</span>
        refer only to a single geofeed <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span> file.<a href="#section-3-5" class="pilcrow">¶</a></p>
<div id="section-3-6">
<pre class="sourcecode lang-rpsl">
    inetnum: 192.0.2.0/24 # example
    geofeed: https://example.com/geofeed.csv
</pre><a href="#section-3-6" class="pilcrow">¶</a>
</div>
<p id="section-3-7">
        Registries <span class="bcp14">MAY</span>, for the interim, provide a mix of the remarks:
        attribute form and the geofeed: attribute form.<a href="#section-3-7" class="pilcrow">¶</a></p>
<p id="section-3-8">
 The URL uses HTTPS, so the WebPKI provides authentication, integrity,
 and confidentiality for the fetched geofeed file.  However, the WebPKI
 can not provide authentication of IP address space assignment.  In
 contrast, the RPKI (see <span>[<a href="#RFC6481" class="xref">RFC6481</a>]</span>) can
 be used to authenticate IP space assignment; see optional
 authentication in <a href="#auth" class="xref">Section 4</a>.<a href="#section-3-8" class="pilcrow">¶</a></p>
<p id="section-3-9">
        Until all producers of inetnum: objects, i.e., the RIRs, state that they
        have migrated to supporting a geofeed: attribute, consumers
        looking at inetnum: objects to find geofeed URLs <span class="bcp14">MUST</span> be able to
        consume both the remarks: and geofeed: forms.  


 The migration not only implies that the RIRs support the geofeed:
 attribute, but that all registrants have migrated any inetnum: objects
 from remarks: to geofeed: attributes.<a href="#section-3-9" class="pilcrow">¶</a></p>
<p id="section-3-10">
        Any particular inetnum: object <span class="bcp14">MUST</span> have, at most, one geofeed
        reference, whether a remarks: or a proper geofeed: attribute
        when it is implemented.  If there is more than one, all are
        ignored.<a href="#section-3-10" class="pilcrow">¶</a></p>
<p id="section-3-11">
        If a geofeed CSV file describes multiple disjoint ranges of IP
        address space, there are likely to be geofeed references from
        multiple inetnum: objects.  Files with geofeed references from
        multiple inetnum: objects are not compatible with the signing
        procedure in <a href="#auth" class="xref">Section 4</a>.<a href="#section-3-11" class="pilcrow">¶</a></p>
<p id="section-3-12">
        When geofeed references are provided by multiple inetnum:
        objects that have identical address ranges, then the geofeed
        reference on the inetnum: with the most recent last-modified:
        attribute <span class="bcp14">SHOULD</span> be preferred.<a href="#section-3-12" class="pilcrow">¶</a></p>
<p id="section-3-13">
        As inetnum: objects form a hierarchy, geofeed references <span class="bcp14">SHOULD</span>
        be at the lowest applicable inetnum: object covering the
        relevant address ranges in the referenced geofeed file.  When
        fetching, the most specific inetnum: object with a geofeed
        reference <span class="bcp14">MUST</span> be used.<a href="#section-3-13" class="pilcrow">¶</a></p>
<p id="section-3-14">
        It is significant that geofeed data may have finer granularity
        than the inetnum: that refers to them.  For example, an INETNUM
        object for an address range P could refer to a geofeed file in
        which P has been subdivided into one or more longer prefixes.<a href="#section-3-14" class="pilcrow">¶</a></p>
<p id="section-3-15">
        Currently, the registry data published by ARIN are not the same RPSL as
        that of the other registries (see <span>[<a href="#RFC7485" class="xref">RFC7485</a>]</span> for a survey of the WHOIS Tower of Babel);
        therefore, when fetching from ARIN via FTP <span>[<a href="#RFC0959" class="xref">RFC0959</a>]</span>, WHOIS <span>[<a href="#RFC3912" class="xref">RFC3912</a>]</span>,
        the Registration Data Access Protocol (RDAP) <span>[<a href="#RFC9082" class="xref">RFC9082</a>]</span>, etc., the "NetRange" attribute/key
        <span class="bcp14">MUST</span> be treated as "inetnum", and the "Comment"
        attribute <span class="bcp14">MUST</span> be treated as "remarks".<a href="#section-3-15" class="pilcrow">¶</a></p>
</section>
</div>
<div id="auth">
<section id="section-4">
      <h2 id="name-authenticating-geofeed-data">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-authenticating-geofeed-data" class="section-name selfRef">Authenticating Geofeed Data</a>
      </h2>
<p id="section-4-1">
        The question arises whether a particular geofeed <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span> data set is valid, i.e., is
        authorized by the "owner" of the IP address space and is authoritative
        in some sense.  The inetnum: that points to the geofeed <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span> file provides some assurance.
        Unfortunately, the RPSL in many repositories is weakly authenticated
        at best.  An approach where RPSL was signed per <span>[<a href="#RFC7909" class="xref">RFC7909</a>]</span> would be good, except it would have to be deployed
        by all RPSL registries, and there is a fair number of them.<a href="#section-4-1" class="pilcrow">¶</a></p>
<p id="section-4-2">
        A single optional authenticator <span class="bcp14">MAY</span> be appended to a
        geofeed <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span> file.  It is a
        digest of the main body of the file signed by the private key of the
        relevant RPKI certificate for a covering address range.  One needs a
        format that bundles the relevant RPKI certificate with the signature
        of the geofeed text.<a href="#section-4-2" class="pilcrow">¶</a></p>
<p id="section-4-3">
        The canonicalization procedure converts the data from their internal
        character representation to the UTF-8 <span>[<a href="#RFC3629" class="xref">RFC3629</a>]</span> character encoding, and the &lt;CRLF&gt; sequence
        <span class="bcp14">MUST</span> be used to denote the end of a line of text.  A
        blank line is represented solely by the &lt;CRLF&gt; sequence.  For
        robustness, any non-printable characters <span class="bcp14">MUST NOT</span> be
        changed by canonicalization.  Trailing blank lines <span class="bcp14">MUST NOT</span> appear at the end of the file.  That is, the file must not
        end with multiple consecutive &lt;CRLF&gt; sequences.  Any end-of-file
        marker used by an operating system is not considered to be part of the
        file content.  When present, such end-of-file markers <span class="bcp14">MUST NOT</span> be processed by the digital signature algorithm.<a href="#section-4-3" class="pilcrow">¶</a></p>
<p id="section-4-4">
        Should the authenticator be syntactically incorrect per the
        above, the authenticator is invalid.<a href="#section-4-4" class="pilcrow">¶</a></p>
<p id="section-4-5">
        Borrowing detached signatures from <span>[<a href="#RFC5485" class="xref">RFC5485</a>]</span>, after file canonicalization, the Cryptographic
        Message Syntax (CMS) <span>[<a href="#RFC5652" class="xref">RFC5652</a>]</span> would
        be used to create a detached DER-encoded signature that is then padded
        BASE64 encoded (as per <span><a href="https://www.rfc-editor.org/rfc/rfc4648#section-4" class="relref">Section 4</a> of [<a href="#RFC4648" class="xref">RFC4648</a>]</span>) and line wrapped to 72 or fewer
        characters.  The same digest algorithm <span class="bcp14">MUST</span> be used for
        calculating the message digest on content being signed, which is the
        geofeed file, and for calculating the message digest on the SignerInfo
        SignedAttributes <span>[<a href="#RFC8933" class="xref">RFC8933</a>]</span>.  The
        message digest algorithm identifier <span class="bcp14">MUST</span> appear in both
        the SignedData DigestAlgorithmIdentifiers and the SignerInfo
        DigestAlgorithmIdentifier <span>[<a href="#RFC5652" class="xref">RFC5652</a>]</span>.<a href="#section-4-5" class="pilcrow">¶</a></p>
<p id="section-4-6">
        The address range of the signing certificate <span class="bcp14">MUST</span> cover all
        prefixes in the geofeed file it signs.<a href="#section-4-6" class="pilcrow">¶</a></p>
<p id="section-4-7">
        An address range A "covers" address range B if the range of B is
        identical to or a subset of A. "Address range" is used here because
        inetnum: objects and RPKI certificates need not align on Classless
        Inter-Domain Routing (CIDR) <span>[<a href="#RFC4632" class="xref">RFC4632</a>]</span> prefix
        boundaries, while those of the CSV lines in a geofeed file do.<a href="#section-4-7" class="pilcrow">¶</a></p>
<p id="section-4-8">
        As the signer specifies the covered RPKI resources relevant to the
        signature, the RPKI certificate covering the inetnum: object's address
        range is included in the <span>[<a href="#RFC5652" class="xref">RFC5652</a>]</span> CMS
        SignedData certificates field.<a href="#section-4-8" class="pilcrow">¶</a></p>
<p id="section-4-9">
        Identifying the private key associated with the certificate and
        getting the department that controls the private key (which might be
        trapped in a Hardware Security Module (HSM)) to sign the CMS blob is
        left as an exercise for the implementor.  On the other hand, verifying
        the signature requires no complexity; the certificate, which can be
        validated in the public RPKI, has the needed public key.

        The trust anchors for the RIRs are expected to already be
        available to the party performing signature validation.
        Validation of the CMS signature on the geofeed file
        involves:<a href="#section-4-9" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4-10">
<li id="section-4-10.1">
          <p id="section-4-10.1.1"> Obtaining the signer's certificate from the CMS SignedData
    CertificateSet <span>[<a href="#RFC5652" class="xref">RFC5652</a>]</span>.  The certificate
    SubjectKeyIdentifier extension <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span>
            <span class="bcp14">MUST</span> match the SubjectKeyIdentifier in the CMS SignerInfo
    SignerIdentifier <span>[<a href="#RFC5652" class="xref">RFC5652</a>]</span>.  If the key
    identifiers do not match, then validation <span class="bcp14">MUST</span> fail.<a href="#section-4-10.1.1" class="pilcrow">¶</a></p>
<p id="section-4-10.1.2">
          Validation of the signer's certificate <span class="bcp14">MUST</span> ensure
          that it is part of the current <span>[<a href="#RFC6486" class="xref">RFC6486</a>]</span> manifest and that the resources are covered by
          the RPKI certificate.<a href="#section-4-10.1.2" class="pilcrow">¶</a></p>
</li>
        <li id="section-4-10.2">
          Constructing the certification path for the signer's certificate.
          All of the needed certificates are expected to be readily
          available in the RPKI repository.  The certification path <span class="bcp14">MUST</span>
          be valid according to the validation algorithm in <span>[<a href="#RFC5280" class="xref">RFC5280</a>]</span> and the additional checks specified in
          <span>[<a href="#RFC3779" class="xref">RFC3779</a>]</span> associated with the IP Address
          Delegation certificate extension and the Autonomous System
          Identifier Delegation certificate extension.  If certification
          path validation is unsuccessful, then validation <span class="bcp14">MUST</span> fail.<a href="#section-4-10.2" class="pilcrow">¶</a>
</li>
        <li id="section-4-10.3">
          Validating the CMS SignedData as specified in <span>[<a href="#RFC5652" class="xref">RFC5652</a>]</span> using the public key from the validated
          signer's certificate.  If the signature validation is
          unsuccessful, then validation <span class="bcp14">MUST</span> fail.<a href="#section-4-10.3" class="pilcrow">¶</a>
</li>
        <li id="section-4-10.4">
          Verifying that the IP Address Delegation certificate extension
          <span>[<a href="#RFC3779" class="xref">RFC3779</a>]</span> covers all of the address ranges of
          the geofeed file.  If all of the address ranges are not
          covered, then validation <span class="bcp14">MUST</span> fail.<a href="#section-4-10.4" class="pilcrow">¶</a>
</li>
      </ol>
<p id="section-4-11">
        All of these steps <span class="bcp14">MUST</span> be successful to consider the geofeed
        file signature as valid.<a href="#section-4-11" class="pilcrow">¶</a></p>
<p id="section-4-12">
        As the signer specifies the covered RPKI resources relevant to the
        signature, the RPKI certificate covering the inetnum: object's address
        range is included in the CMS SignedData certificates field <span>[<a href="#RFC5652" class="xref">RFC5652</a>]</span>.<a href="#section-4-12" class="pilcrow">¶</a></p>
<p id="section-4-13">
        Identifying the private key associated with the certificate and
        getting the department with the Hardware Security Module (HSM) to sign
        the CMS blob is left as an exercise for the implementor.  On the other
        hand, verifying the signature requires no complexity; the certificate,
        which can be validated in the public RPKI, has the needed public key.<a href="#section-4-13" class="pilcrow">¶</a></p>
<p id="section-4-14">
        The appendix <span class="bcp14">MUST</span> be hidden as a series of "#" comments at the
        end of the geofeed file.  The following is a cryptographically
        incorrect, albeit simple, example.  A correct and full example is
        in <a href="#example" class="xref">Appendix A</a>.<a href="#section-4-14" class="pilcrow">¶</a></p>
<div id="section-4-15">
<pre class="sourcecode">
    # RPKI Signature: 192.0.2.0 - 192.0.2.255
    # MIIGlwYJKoZIhvcNAQcCoIIGiDCCBoQCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
    # IhvcNAQkQAS+gggSxMIIErTCCA5WgAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
    ...
    # imwYkXpiMxw44EZqDjl36MiWsRDLdgoijBBcGbibwyAfGeR46k5raZCGvxG+4xa
    # O8PDTxTfIYwAnBjRBKAqAZ7yX5xHfm58jUXsZJ7Ileq1S7G6Kk=
    # End Signature: 192.0.2.0 - 192.0.2.255
</pre><a href="#section-4-15" class="pilcrow">¶</a>
</div>
<p id="section-4-16">
        The signature does not cover the signature lines.<a href="#section-4-16" class="pilcrow">¶</a></p>
<p id="section-4-17">
        The bracketing "# RPKI Signature:" and "# End Signature:" <span class="bcp14">MUST</span>
        be present following the model as shown.  Their IP address range
        <span class="bcp14">MUST</span> match that of the inetnum: URL followed to the file.<a href="#section-4-17" class="pilcrow">¶</a></p>
<p id="section-4-18">
        <span>[<a href="#I-D.ietf-sidrops-rpki-rsc" class="xref">RPKI-RSC</a>]</span> describes
        and provides code for a CMS profile for
        a general purpose listing of checksums (a "checklist") for use with
        the Resource Public Key Infrastructure (RPKI).  It provides usable,
        albeit complex, code to sign geofeed files.<a href="#section-4-18" class="pilcrow">¶</a></p>
<p id="section-4-19">
        <span>[<a href="#I-D.ietf-sidrops-rpki-rta" class="xref">RPKI-RTA</a>]</span> describes
        a CMS profile for a general purpose Resource Tagged Attestation (RTA)
        based on the RPKI.  While this is expected to become applicable in the
        long run, for the purposes of this document, a self-signed root trust
        anchor is used.<a href="#section-4-19" class="pilcrow">¶</a></p>
</section>
</div>
<div id="ops">
<section id="section-5">
      <h2 id="name-operational-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-operational-considerations" class="section-name selfRef">Operational Considerations</a>
      </h2>
<p id="section-5-1">
        To create the needed inetnum: objects, an operator wishing to register
        the location of their geofeed file needs to coordinate with their
        Regional Internet Registry (RIR) or National Internet Registry (NIR)
        and/or any provider Local Internet Registry (LIR) that has assigned
        address ranges to them.  RIRs/NIRs provide means for assignees to
        create and maintain inetnum: objects.  They also provide means of
        assigning or sub-assigning IP address resources and allowing the
        assignee to create WHOIS data, including inetnum: objects, thereby
        referring to geofeed files.<a href="#section-5-1" class="pilcrow">¶</a></p>
<p id="section-5-2">
        The geofeed files <span class="bcp14">MUST</span> be published via and fetched using
        HTTPS <span>[<a href="#RFC2818" class="xref">RFC2818</a>]</span>.<a href="#section-5-2" class="pilcrow">¶</a></p>
<p id="section-5-3">
        When using data from a geofeed file, one <span class="bcp14">MUST</span> ignore data
        outside the referring inetnum: object's inetnum: attribute
        address range.<a href="#section-5-3" class="pilcrow">¶</a></p>
<p id="section-5-4">
        If and only if the geofeed file is not signed per <a href="#auth" class="xref">Section 4</a>, then multiple inetnum: objects <span class="bcp14">MAY</span>
        refer to the same geofeed file, and the consumer <span class="bcp14">MUST</span>
        use only lines in the geofeed file where the prefix is covered by the
        address range of the inetnum: object's URL it has followed.<a href="#section-5-4" class="pilcrow">¶</a></p>
<p id="section-5-5">
        If the geofeed file is signed, and the signer's certificate
        changes, the signature in the geofeed file <span class="bcp14">MUST</span> be updated.<a href="#section-5-5" class="pilcrow">¶</a></p>
<p id="section-5-6">
        It is good key hygiene to use a given key for only one purpose.
        To dedicate a signing private key for signing a geofeed file, an
        RPKI Certification Authority (CA) may issue a subordinate certificate exclusively for
        the purpose shown in <a href="#example" class="xref">Appendix A</a>.<a href="#section-5-6" class="pilcrow">¶</a></p>
<p id="section-5-7">
        To minimize the load on RIR WHOIS <span>[<a href="#RFC3912" class="xref">RFC3912</a>]</span> services, use of the RIR's FTP <span>[<a href="#RFC0959" class="xref">RFC0959</a>]</span> services <span class="bcp14">SHOULD</span> be
        used for large-scale access to gather geofeed URLs.  This also
        provides bulk access instead of fetching by brute-force search
        through the IP space.<a href="#section-5-7" class="pilcrow">¶</a></p>
<p id="section-5-8">
        Currently, geolocation providers have bulk WHOIS data access at
        all the RIRs. An anonymized version of such data is openly
        available for all RIRs except ARIN, which requires an
        authorization.  However, for users without such authorization,
        the same result can be achieved with extra RDAP effort. There is
        open-source code to pass over such data across all RIRs, collect
        all geofeed references, and process them <span>[<a href="#GEOFEED-FINDER" class="xref">GEOFEED-FINDER</a>]</span>.<a href="#section-5-8" class="pilcrow">¶</a></p>
<p id="section-5-9">
        To prevent undue load on RPSL and geofeed servers, entity-fetching
        geofeed data using these mechanisms <span class="bcp14">MUST NOT</span> do
        frequent real-time lookups.  <span><a href="https://www.rfc-editor.org/rfc/rfc8805#section-3.4" class="relref">Section 3.4</a> of [<a href="#RFC8805" class="xref">RFC8805</a>]</span> suggests use of the HTTP Expires
        header <span>[<a href="#RFC7234" class="xref">RFC7234</a>]</span> to signal when
        geofeed data should be refetched. As the data change very
        infrequently, in the absence of such an HTTP Header signal, collectors
        <span class="bcp14">SHOULD NOT</span> fetch more frequently than weekly.  It would
        be polite not to fetch at magic times such as midnight UTC, the first
        of the month, etc., because too many others are likely to do the same.<a href="#section-5-9" class="pilcrow">¶</a></p>
</section>
</div>
<div id="privacy">
<section id="section-6">
      <h2 id="name-privacy-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-privacy-considerations" class="section-name selfRef">Privacy Considerations</a>
      </h2>
<p id="section-6-1">
        <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span> geofeed data may reveal the
        approximate location of an IP address, which might in turn reveal the
        approximate location of an individual user.  Unfortunately, <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span> provides no privacy guidance on
        avoiding or ameliorating possible damage due to this exposure of the
        user.  In publishing pointers to geofeed files as described in this
        document, the operator should be aware of this exposure in geofeed
        data and be cautious.  All the privacy considerations of <span><a href="https://www.rfc-editor.org/rfc/rfc8805#section-4" class="relref">Section 4</a> of [<a href="#RFC8805" class="xref">RFC8805</a>]</span>
        apply to this document.<a href="#section-6-1" class="pilcrow">¶</a></p>
<p id="section-6-2">
        Where <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span> provided the ability
        to publish location data, this document makes bulk access to those data
        readily available.  This is a goal, not an accident.<a href="#section-6-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="seccons">
<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">
        It is generally prudent for a consumer of geofeed data to also
        use other sources to cross validate the data.  All the security
        considerations of <span>[<a href="#RFC8805" class="xref">RFC8805</a>]</span> apply here as well.<a href="#section-7-1" class="pilcrow">¶</a></p>
<p id="section-7-2">
        As mentioned in <a href="#auth" class="xref">Section 4</a>, many RPSL
        repositories have weak, if any, authentication.  This allows spoofing
        of inetnum: objects pointing to malicious geofeed files.  <a href="#auth" class="xref">Section 4</a> suggests an unfortunately complex
        method for stronger authentication based on the RPKI.<a href="#section-7-2" class="pilcrow">¶</a></p>
<p id="section-7-3">
        For example, if an inetnum: for a wide address range (e.g., a
        /16) points to an RPKI-signed geofeed file, a customer or
        attacker could publish an unsigned equal or narrower (e.g., a
        /24) inetnum: in a WHOIS registry that has weak authorization,
        abusing the rule that the most-specific inetnum: object with a
        geofeed reference <span class="bcp14">MUST</span> be used.<a href="#section-7-3" class="pilcrow">¶</a></p>
<p id="section-7-4">
        If signatures were mandatory, the above attack would be stymied, but
        of course that is not happening anytime soon.<a href="#section-7-4" class="pilcrow">¶</a></p>
<p id="section-7-5">
        The RPSL providers have had to throttle fetching from their
        servers due to too-frequent queries.  Usually, they throttle by
        the querying IP address or block.  Similar defenses will likely
        need to be deployed by geofeed file servers.<a href="#section-7-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="iana">
<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">
        IANA has registered object identifiers for one content
        type in the "SMI Security for S/MIME CMS Content Type
        (1.2.840.113549.1.9.16.1)" registry as follows:<a href="#section-8-1" class="pilcrow">¶</a></p>
<div id="iana_table">
<table class="center" id="table-1">
        <caption><a href="#table-1" class="selfRef">Table 1</a></caption>
<thead>
          <tr>
            <th class="text-left" rowspan="1" colspan="1">Decimal</th>
            <th class="text-left" rowspan="1" colspan="1">Description</th>
            <th class="text-left" rowspan="1" colspan="1">References</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td class="text-left" rowspan="1" colspan="1">47</td>
            <td class="text-left" rowspan="1" colspan="1">id-ct-geofeedCSVwithCRLF</td>
            <td class="text-left" rowspan="1" colspan="1">RFC 9092</td>
          </tr>
        </tbody>
      </table>
</div>
</section>
</div>
<section id="section-9">
      <h2 id="name-references">
<a href="#section-9" class="section-number selfRef">9. </a><a href="#name-references" class="section-name selfRef">References</a>
      </h2>
<section id="section-9.1">
        <h3 id="name-normative-references">
<a href="#section-9.1" class="section-number selfRef">9.1. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
        </h3>
<dl class="references">
<dt id="RFC2119">[RFC2119]</dt>
        <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2622">[RFC2622]</dt>
        <dd>
<span class="refAuthor">Alaettinoglu, C.</span>, <span class="refAuthor">Villamizar, C.</span>, <span class="refAuthor">Gerich, E.</span>, <span class="refAuthor">Kessens, D.</span>, <span class="refAuthor">Meyer, D.</span>, <span class="refAuthor">Bates, T.</span>, <span class="refAuthor">Karrenberg, D.</span>, and <span class="refAuthor">M. Terpstra</span>, <span class="refTitle">"Routing Policy Specification Language (RPSL)"</span>, <span class="seriesInfo">RFC 2622</span>, <span class="seriesInfo">DOI 10.17487/RFC2622</span>, <time datetime="1999-06" class="refDate">June 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2622">https://www.rfc-editor.org/info/rfc2622</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2725">[RFC2725]</dt>
        <dd>
<span class="refAuthor">Villamizar, C.</span>, <span class="refAuthor">Alaettinoglu, C.</span>, <span class="refAuthor">Meyer, D.</span>, and <span class="refAuthor">S. Murphy</span>, <span class="refTitle">"Routing Policy System Security"</span>, <span class="seriesInfo">RFC 2725</span>, <span class="seriesInfo">DOI 10.17487/RFC2725</span>, <time datetime="1999-12" class="refDate">December 1999</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2725">https://www.rfc-editor.org/info/rfc2725</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2818">[RFC2818]</dt>
        <dd>
<span class="refAuthor">Rescorla, E.</span>, <span class="refTitle">"HTTP Over TLS"</span>, <span class="seriesInfo">RFC 2818</span>, <span class="seriesInfo">DOI 10.17487/RFC2818</span>, <time datetime="2000-05" class="refDate">May 2000</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2818">https://www.rfc-editor.org/info/rfc2818</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3629">[RFC3629]</dt>
        <dd>
<span class="refAuthor">Yergeau, F.</span>, <span class="refTitle">"UTF-8, a transformation format of ISO 10646"</span>, <span class="seriesInfo">STD 63</span>, <span class="seriesInfo">RFC 3629</span>, <span class="seriesInfo">DOI 10.17487/RFC3629</span>, <time datetime="2003-11" class="refDate">November 2003</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3629">https://www.rfc-editor.org/info/rfc3629</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3779">[RFC3779]</dt>
        <dd>
<span class="refAuthor">Lynn, C.</span>, <span class="refAuthor">Kent, S.</span>, and <span class="refAuthor">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="RFC4012">[RFC4012]</dt>
        <dd>
<span class="refAuthor">Blunk, L.</span>, <span class="refAuthor">Damas, J.</span>, <span class="refAuthor">Parent, F.</span>, and <span class="refAuthor">A. Robachevsky</span>, <span class="refTitle">"Routing Policy Specification Language next generation (RPSLng)"</span>, <span class="seriesInfo">RFC 4012</span>, <span class="seriesInfo">DOI 10.17487/RFC4012</span>, <time datetime="2005-03" class="refDate">March 2005</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4012">https://www.rfc-editor.org/info/rfc4012</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4648">[RFC4648]</dt>
        <dd>
<span class="refAuthor">Josefsson, S.</span>, <span class="refTitle">"The Base16, Base32, and Base64 Data Encodings"</span>, <span class="seriesInfo">RFC 4648</span>, <span class="seriesInfo">DOI 10.17487/RFC4648</span>, <time datetime="2006-10" class="refDate">October 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4648">https://www.rfc-editor.org/info/rfc4648</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5280">[RFC5280]</dt>
        <dd>
<span class="refAuthor">Cooper, D.</span>, <span class="refAuthor">Santesson, S.</span>, <span class="refAuthor">Farrell, S.</span>, <span class="refAuthor">Boeyen, S.</span>, <span class="refAuthor">Housley, R.</span>, and <span class="refAuthor">W. Polk</span>, <span class="refTitle">"Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile"</span>, <span class="seriesInfo">RFC 5280</span>, <span class="seriesInfo">DOI 10.17487/RFC5280</span>, <time datetime="2008-05" class="refDate">May 2008</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5280">https://www.rfc-editor.org/info/rfc5280</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5652">[RFC5652]</dt>
        <dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"Cryptographic Message Syntax (CMS)"</span>, <span class="seriesInfo">STD 70</span>, <span class="seriesInfo">RFC 5652</span>, <span class="seriesInfo">DOI 10.17487/RFC5652</span>, <time datetime="2009-09" class="refDate">September 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5652">https://www.rfc-editor.org/info/rfc5652</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC6481">[RFC6481]</dt>
        <dd>
<span class="refAuthor">Huston, G.</span>, <span class="refAuthor">Loomans, R.</span>, and <span class="refAuthor">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="RFC6486">[RFC6486]</dt>
        <dd>
<span class="refAuthor">Austein, R.</span>, <span class="refAuthor">Huston, G.</span>, <span class="refAuthor">Kent, S.</span>, and <span class="refAuthor">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="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="RFC8805">[RFC8805]</dt>
        <dd>
<span class="refAuthor">Kline, E.</span>, <span class="refAuthor">Duleba, K.</span>, <span class="refAuthor">Szamonek, Z.</span>, <span class="refAuthor">Moser, S.</span>, and <span class="refAuthor">W. Kumari</span>, <span class="refTitle">"A Format for Self-Published IP Geolocation Feeds"</span>, <span class="seriesInfo">RFC 8805</span>, <span class="seriesInfo">DOI 10.17487/RFC8805</span>, <time datetime="2020-08" class="refDate">August 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8805">https://www.rfc-editor.org/info/rfc8805</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8933">[RFC8933]</dt>
      <dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier Protection"</span>, <span class="seriesInfo">RFC 8933</span>, <span class="seriesInfo">DOI 10.17487/RFC8933</span>, <time datetime="2020-10" class="refDate">October 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8933">https://www.rfc-editor.org/info/rfc8933</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="GEOFEED-FINDER">[GEOFEED-FINDER]</dt>
        <dd>
<span class="refTitle">"geofeed-finder"</span>, <span class="refContent">commit 5f557a4</span>, <time datetime="2021-06" class="refDate">June 2021</time>, <span>&lt;<a href="https://github.com/massimocandela/geofeed-finder">https://github.com/massimocandela/geofeed-finder</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="INET6NUM">[INET6NUM]</dt>
        <dd>
<span class="refAuthor">RIPE NCC</span>, <span class="refTitle">"Description of the INET6NUM Object"</span>, <time datetime="2019-10" class="refDate">October 2019</time>, <span>&lt;<a href="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-3-description-of-the-inet6num-object">https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-3-description-of-the-inet6num-object</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="INETNUM">[INETNUM]</dt>
        <dd>
<span class="refAuthor">RIPE NCC</span>, <span class="refTitle">"Description of the INETNUM Object"</span>, <time datetime="2020-06" class="refDate">June 2020</time>, <span>&lt;<a href="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object">https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation/rpsl-object-types/4-2-descriptions-of-primary-objects/4-2-4-description-of-the-inetnum-object</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC0959">[RFC0959]</dt>
        <dd>
<span class="refAuthor">Postel, J.</span> and <span class="refAuthor">J. Reynolds</span>, <span class="refTitle">"File Transfer Protocol"</span>, <span class="seriesInfo">STD 9</span>, <span class="seriesInfo">RFC 959</span>, <span class="seriesInfo">DOI 10.17487/RFC0959</span>, <time datetime="1985-10" class="refDate">October 1985</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc959">https://www.rfc-editor.org/info/rfc959</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3912">[RFC3912]</dt>
        <dd>
<span class="refAuthor">Daigle, L.</span>, <span class="refTitle">"WHOIS Protocol Specification"</span>, <span class="seriesInfo">RFC 3912</span>, <span class="seriesInfo">DOI 10.17487/RFC3912</span>, <time datetime="2004-09" class="refDate">September 2004</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3912">https://www.rfc-editor.org/info/rfc3912</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC4632">[RFC4632]</dt>
        <dd>
<span class="refAuthor">Fuller, V.</span> and <span class="refAuthor">T. Li</span>, <span class="refTitle">"Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan"</span>, <span class="seriesInfo">BCP 122</span>, <span class="seriesInfo">RFC 4632</span>, <span class="seriesInfo">DOI 10.17487/RFC4632</span>, <time datetime="2006-08" class="refDate">August 2006</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc4632">https://www.rfc-editor.org/info/rfc4632</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC5485">[RFC5485]</dt>
        <dd>
<span class="refAuthor">Housley, R.</span>, <span class="refTitle">"Digital Signatures on Internet-Draft Documents"</span>, <span class="seriesInfo">RFC 5485</span>, <span class="seriesInfo">DOI 10.17487/RFC5485</span>, <time datetime="2009-03" class="refDate">March 2009</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc5485">https://www.rfc-editor.org/info/rfc5485</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7234">[RFC7234]</dt>
        <dd>
<span class="refAuthor">Fielding, R., Ed.</span>, <span class="refAuthor">Nottingham, M., Ed.</span>, and <span class="refAuthor">J. Reschke, Ed.</span>, <span class="refTitle">"Hypertext Transfer Protocol (HTTP/1.1): Caching"</span>, <span class="seriesInfo">RFC 7234</span>, <span class="seriesInfo">DOI 10.17487/RFC7234</span>, <time datetime="2014-06" class="refDate">June 2014</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7234">https://www.rfc-editor.org/info/rfc7234</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7485">[RFC7485]</dt>
        <dd>
<span class="refAuthor">Zhou, L.</span>, <span class="refAuthor">Kong, N.</span>, <span class="refAuthor">Shen, S.</span>, <span class="refAuthor">Sheng, S.</span>, and <span class="refAuthor">A. Servin</span>, <span class="refTitle">"Inventory and Analysis of WHOIS Registration Objects"</span>, <span class="seriesInfo">RFC 7485</span>, <span class="seriesInfo">DOI 10.17487/RFC7485</span>, <time datetime="2015-03" class="refDate">March 2015</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7485">https://www.rfc-editor.org/info/rfc7485</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC7909">[RFC7909]</dt>
        <dd>
<span class="refAuthor">Kisteleki, R.</span> and <span class="refAuthor">B. Haberman</span>, <span class="refTitle">"Securing Routing Policy Specification Language (RPSL) Objects with Resource Public Key Infrastructure (RPKI) Signatures"</span>, <span class="seriesInfo">RFC 7909</span>, <span class="seriesInfo">DOI 10.17487/RFC7909</span>, <time datetime="2016-06" class="refDate">June 2016</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc7909">https://www.rfc-editor.org/info/rfc7909</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9082">[RFC9082]</dt>
        <dd>
<span class="refAuthor">Hollenbeck, S.</span> and <span class="refAuthor">A. Newton</span>, <span class="refTitle">"Registration Data Access Protocol (RDAP) Query Format"</span>, <span class="seriesInfo">STD 95</span>, <span class="seriesInfo">RFC 9082</span>, <span class="seriesInfo">DOI 10.17487/RFC9082</span>, <time datetime="2021-06" class="refDate">June 2021</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc9082">https://www.rfc-editor.org/info/rfc9082</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RIPE-DB">[RIPE-DB]</dt>
        <dd>
<span class="refAuthor">RIPE NCC</span>, <span class="refTitle">"RIPE Database Documentation"</span>, <span>&lt;<a href="https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation">https://www.ripe.net/manage-ips-and-asns/db/support/documentation/ripe-database-documentation</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RIPE181">[RIPE181]</dt>
        <dd>
<span class="refAuthor">RIPE NCC</span>, <span class="refTitle">"Representation Of IP Routing Policies In A Routing Registry"</span>, <time datetime="1994-10" class="refDate">October 1994</time>, <span>&lt;<a href="https://www.ripe.net/publications/docs/ripe-181">https://www.ripe.net/publications/docs/ripe-181</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RIPE81">[RIPE81]</dt>
        <dd>
<span class="refAuthor">RIPE NCC</span>, <span class="refTitle">"Representation Of IP Routing Policies In The RIPE Database"</span>, <time datetime="1993-02" class="refDate">February 1993</time>, <span>&lt;<a href="https://www.ripe.net/publications/docs/ripe-081">https://www.ripe.net/publications/docs/ripe-081</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-sidrops-rpki-rsc">[RPKI-RSC]</dt>
        <dd>
<span class="refAuthor">Snijders, J.</span>, <span class="refAuthor">Harrison, T.</span>, and <span class="refAuthor">B. Maddison</span>, <span class="refTitle">"Resource Public Key Infrastructure (RPKI) object profile for Signed Checklist (RSC)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-sidrops-rpki-rsc-04</span>, <time datetime="2021-05-31" class="refDate">31 May 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-04">https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rsc-04</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="I-D.ietf-sidrops-rpki-rta">[RPKI-RTA]</dt>
      <dd>
<span class="refAuthor">Michaelson, G. G.</span>, <span class="refAuthor">Huston, G.</span>, <span class="refAuthor">Harrison, T.</span>, <span class="refAuthor">Bruijnzeels, T.</span>, and <span class="refAuthor">M. Hoffmann</span>, <span class="refTitle">"A profile for Resource Tagged Attestations (RTAs)"</span>, <span class="refContent">Work in Progress</span>, <span class="seriesInfo">Internet-Draft, draft-ietf-sidrops-rpki-rta-00</span>, <time datetime="2021-01-21" class="refDate">21 January 2021</time>, <span>&lt;<a href="https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00">https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-rpki-rta-00</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
</section>
<div id="example">
<section id="appendix-A">
      <h2 id="name-example">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-example" class="section-name selfRef">Example</a>
      </h2>
<p id="appendix-A-1">
      This appendix provides an example that includes a trust anchor, a CA
      certificate subordinate to the trust anchor, an end-entity
      certificate subordinate to the CA for signing the geofeed, and a
      detached signature.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">
      The trust anchor is represented by a self-signed certificate.  As
      usual in the RPKI, the trust anchor has authority over all IPv4
      address blocks, all IPv6 address blocks, and all Autonomous System (AS) numbers.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<div id="appendix-A-3">
<pre class="sourcecode">
    -----BEGIN CERTIFICATE-----
    MIIEPjCCAyagAwIBAgIUPsUFJ4e/7pKZ6E14aBdkbYzms1gwDQYJKoZIhvcNAQEL
    BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMDA5MDMxODU0NTRaFw0zMDA5
    MDExODU0NTRaMBUxEzARBgNVBAMTCmV4YW1wbGUtdGEwggEiMA0GCSqGSIb3DQEB
    AQUAA4IBDwAwggEKAoIBAQCelMmMDCGBhqn/a3VrNAoKMr1HVLKxGoG7VF/13HZJ
    0twObUZlh3Jz+XeD+kNAURhELWTrsgdTkQQfqinqOuRemxTl55+x7nLpe5nmwaBH
    XqqDOHubmkbAGanGcm6T/rD9KNk1Z46Uc2p7UYu0fwNO0mo0aqFL2FSyvzZwziNe
    g7ELYZ4a3LvGn81JfP/JvM6pgtoMNuee5RV6TWaz7LV304ICj8Bhphy/HFpOA1rb
    O9gs8CUMgqz+RroAIa8cV8gbF/fPCz9Ofl7Gdmib679JxxFrW4wRJ0nMJgJmsZXq
    jaVc0g7ORc+eIAcHw7Uroc6h7Y7lGjOkDZF75j0mLQa3AgMBAAGjggGEMIIBgDAd
    BgNVHQ4EFgQU3hNEuwvUGNCHY1TBatcUR03pNdYwHwYDVR0jBBgwFoAU3hNEuwvU
    GNCHY1TBatcUR03pNdYwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYw
    GAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjCBuQYIKwYBBQUHAQsEgawwgakwPgYI
    KwYBBQUHMAqGMnJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4
    YW1wbGUtdGEubWZ0MDUGCCsGAQUFBzANhilodHRwczovL3JyZHAuZXhhbXBsZS5u
    ZXQvbm90aWZpY2F0aW9uLnhtbDAwBggrBgEFBQcwBYYkcnN5bmM6Ly9ycGtpLmV4
    YW1wbGUubmV0L3JlcG9zaXRvcnkvMCcGCCsGAQUFBwEHAQH/BBgwFjAJBAIAATAD
    AwEAMAkEAgACMAMDAQAwHgYIKwYBBQUHAQgEEjAQoA4wDDAKAgEAAgUA/////zAN
    BgkqhkiG9w0BAQsFAAOCAQEAgZFQ0Sf3CI5Hwev61AUWHYOFniy69PuDTq+WnhDe
    xX5rpjSDRrs5L756KSKJcaOJ36lzO45lfOPSY9fH6x30pnipaqRA7t5rApky24jH
    cSUA9iRednzxhVyGjWKnfAKyNo2MYfaOAT0db1GjyLKbOADI9FowtHBUu+60ykcM
    Quz66XrzxtmxlrRcAnbv/HtV17qOd4my6q5yjTPR1dmYN9oR/2ChlXtGE6uQVguA
    rvNZ5CwiJ1TgGGTB7T8ORHwWU6dGTc0jk2rESAaikmLi1roZSNC21fckhapEit1a
    x8CyiVxjcVc5e0AmS1rJfL6LIfwmtive/N/eBtIM92HkBA==
    -----END CERTIFICATE-----
</pre><a href="#appendix-A-3" class="pilcrow">¶</a>
</div>
<p id="appendix-A-4">
   The CA certificate is issued by the trust anchor.  This
   certificate grants authority over one IPv4 address block
   (192.0.2.0/24) and two AS numbers (64496 and 64497).<a href="#appendix-A-4" class="pilcrow">¶</a></p>
<div id="appendix-A-5">
<pre class="sourcecode">
    -----BEGIN CERTIFICATE-----
    MIIFBzCCA++gAwIBAgIUcyCzS10hdfG65kbRq7toQAvRDKowDQYJKoZIhvcNAQEL
    BQAwFTETMBEGA1UEAxMKZXhhbXBsZS10YTAeFw0yMDA5MDMxOTAyMTlaFw0yMTA5
    MDMxOTAyMTlaMDMxMTAvBgNVBAMTKDNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVG
    QzFFMjk3QjM3Nzg2NDIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDc
    zz1qwTxC2ocw5rqp8ktm2XyYkl8riBVuqlXwfefTxsR2YFpgz9vkYUd5Az9EVEG7
    6wGIyZbtmhK63eEeaqbKz2GHub467498BXeVrYysO+YuIGgCEYKznNDZ4j5aaDbo
    j5+4/z0Qvv6HEsxQd0f8br6lKJwgeRM6+fm7796HNPB0aqD7Zj9NRCLXjbB0DCgJ
    liH6rXMKR86ofgll9V2mRjesvhdKYgkGbOif9rvxVpLJ/6zdru5CE9yeuJZ59l+n
    YH/r6PzdJ4Q7yKrJX8qD6A60j4+biaU4MQ72KpsjhQNTTqF/HRwi0N54GDaknEwE
    TnJQHgLJDYqww9yKWtjjAgMBAAGjggIvMIICKzAdBgNVHQ4EFgQUOs4s70+yG30R
    4+GE78Hil7N3hkIwHwYDVR0jBBgwFoAU3hNEuwvUGNCHY1TBatcUR03pNdYwDwYD
    VR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwGAYDVR0gAQH/BA4wDDAKBggr
    BgEFBQcOAjBhBgNVHR8EWjBYMFagVKBShlByc3luYzovL3Jwa2kuZXhhbXBsZS5u
    ZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0Iz
    Nzc4NjQyLmNybDBOBggrBgEFBQcBAQRCMEAwPgYIKwYBBQUHMAKGMnJzeW5jOi8v
    cnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5L2V4YW1wbGUtdGEuY2VyMIG5Bggr
    BgEFBQcBCwSBrDCBqTA+BggrBgEFBQcwCoYycnN5bmM6Ly9ycGtpLmV4YW1wbGUu
    bmV0L3JlcG9zaXRvcnkvZXhhbXBsZS1jYS5tZnQwNQYIKwYBBQUHMA2GKWh0dHBz
    Oi8vcnJkcC5leGFtcGxlLm5ldC9ub3RpZmljYXRpb24ueG1sMDAGCCsGAQUFBzAF
    hiRyc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8wHwYIKwYBBQUH
    AQcBAf8EEDAOMAwEAgABMAYDBADAAAIwHgYIKwYBBQUHAQgEEjAQoA4wDDAKAgMA
    +/ACAwD78TANBgkqhkiG9w0BAQsFAAOCAQEAnLu+d1ZsUTiX3YWGueTHIalW4ad0
    Kupi7pYMV2nXbxNGmdJMol9BkzVz9tj55ReMghUU4YLm/ICYe4fz5e0T8o9s/vIm
    cGS29+WoGuiznMitpvbS/379gaMezk6KpqjH6Brw6meMqy09phmcmvm3x3WTmx09
    mLlQneMptwk8qSYcnMUmGLJs+cVqmkOa3sWRdw8WrGu6QqYtQz3HFZQojF06YzEq
    V/dBdCFdEOwTfVl2n2XqhoJl/oEBdC4uu2G0qRk3+WVs+uwVHP0Ttsbt7TzFgZfY
    yxqvOg6QoldxZVZmHHncKmETu/BqCDGJot9may31ukrx34Bu+XFMVihm0w==
    -----END CERTIFICATE-----
</pre><a href="#appendix-A-5" class="pilcrow">¶</a>
</div>
<p id="appendix-A-6">
   The end-entity certificate is issued by the CA.  This
   certificate grants signature authority for one IPv4 address block
   (192.0.2.0/24).  Signature authority for AS numbers is not needed for
   geofeed data signatures, so no AS numbers are included in the
   certificate.<a href="#appendix-A-6" class="pilcrow">¶</a></p>
<div id="appendix-A-7">
<pre class="sourcecode">
    -----BEGIN CERTIFICATE-----
    MIIEpTCCA42gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZuQwDQYJKoZIhvcNAQEL
    BQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExRTNFMTg0RUZDMUUyOTdC
    Mzc3ODY0MjAeFw0yMTA1MjAxNjA1NDVaFw0yMjAzMTYxNjA1NDVaMDMxMTAvBgNV
    BAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM0NUFCRjA1M0ExODcwggEi
    MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycTQrOb/qB2W3i3Ki8PhA/DEW
    yii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQgtPCVwr62hTQZCIowBN0BL0c
    K0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZmr5xphXRvE+mzuJVLgu2V1upm
    BXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXhaFLe08y4DPfr/S/tXJOBm7QzQp
    tmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKGzqTFCcc3EW9l5UFE1MFLlnoEog
    qtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQft5w6g6cmxG+aYDdIEB34zrAgMB
    AAGjggGvMIIBqzAdBgNVHQ4EFgQUkUZSo71RwUQmAZiIn1xFq/BToYcwHwYDVR0j
    BBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkIwDAYDVR0TAQH/BAIwADAOBgNVHQ8B
    Af8EBAMCB4AwGAYDVR0gAQH/BA4wDDAKBggrBgEFBQcOAjBhBgNVHR8EWjBYMFag
    VKBShlByc3luYzovL3Jwa2kuZXhhbXBsZS5uZXQvcmVwb3NpdG9yeS8zQUNFMkNF
    RjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5N0IzNzc4NjQyLmNybDBsBggrBgEFBQcB
    AQRgMF4wXAYIKwYBBQUHMAKGUHJzeW5jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBv
    c2l0b3J5LzNBQ0UyQ0VGNEZCMjFCN0QxMUUzRTE4NEVGQzFFMjk3QjM3Nzg2NDIu
    Y2VyMBkGCCsGAQUFBwEHAQH/BAowCDAGBAIAAQUAMEUGCCsGAQUFBwELBDkwNzA1
    BggrBgEFBQcwDYYpaHR0cHM6Ly9ycmRwLmV4YW1wbGUubmV0L25vdGlmaWNhdGlv
    bi54bWwwDQYJKoZIhvcNAQELBQADggEBAEjC98gVp0Mb7uiKaHylP0453mtJ+AkN
    07fsK/qGw/e90DJv7cp1hvjj4uy3sgf7PJQ7cKNGrgybq/lE0jce+ARgVjbi2Brz
    ZsWAnB846Snwsktw6cenaif6Aww6q00NspAepMBd2Vg/9sKFvOwJFVOgNcqiQiXP
    5rGJPWBcOMv52a/7adjfXwpnOijiTOgMloQGmC2TPZpydZKjlxEATdFEQssa33xD
    nlpp+/r9xuNVYRtRcC36oWraVA3jzN6F6rDE8r8xs3ylISVz6JeCQ4YRYwbMsjjc
    /tiJLM7ZYxIe5IrYz1ZtN6n/SEssJAswRIgps2EhCt/HS2xAmGCOhgU=
    -----END CERTIFICATE-----
</pre><a href="#appendix-A-7" class="pilcrow">¶</a>
</div>
<p id="appendix-A-8">
      The end-entity certificate is displayed below in detail.  For
      brevity, the other two certificates are not.<a href="#appendix-A-8" class="pilcrow">¶</a></p>
<div id="appendix-A-9">
<pre class="sourcecode">
    0 1189: SEQUENCE {
    4  909:  SEQUENCE {
    8    3:   [0] {
   10    1:    INTEGER 2
          :     }
   13   20:   INTEGER 27AD394083D7F2B5B99B8670C775B2B96EE166E4
   35   13:   SEQUENCE {
   37    9:    OBJECT IDENTIFIER
          :     sha256WithRSAEncryption (1 2 840 113549 1 1 11)
   48    0:    NULL
          :     }
   50   51:   SEQUENCE {
   52   49:    SET {
   54   47:     SEQUENCE {
   56    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
   61   40:      PrintableString
          :       '3ACE2CEF4FB21B7D11E3E184EFC1E297B3778642'
          :       }
          :      }
          :     }
  103   30:   SEQUENCE {
  105   13:    UTCTime 20/05/2021 16:05:45 GMT
  120   13:    UTCTime 16/03/2022 16:05:45 GMT
          :     }
  135   51:   SEQUENCE {
  137   49:    SET {
  139   47:     SEQUENCE {
  141    3:      OBJECT IDENTIFIER commonName (2 5 4 3)
  146   40:      PrintableString
          :       '914652A3BD51C144260198889F5C45ABF053A187'
          :       }
          :      }
          :     }
  188  290:   SEQUENCE {
  192   13:    SEQUENCE {
  194    9:     OBJECT IDENTIFIER rsaEncryption
          :      (1 2 840 113549 1 1 1)
  205    0:     NULL
          :      }
  207  271:    BIT STRING, encapsulates {
  212  266:     SEQUENCE {
  216  257:      INTEGER
          :       00 B2 71 34 2B 39 BF EA 07 65 B7 8B 72 A2 F0 F8
          :       40 FC 31 16 CA 28 B6 4E 01 A8 F6 98 02 C0 EF 65
          :       B0 84 48 E9 96 FF 93 E6 92 89 65 8F F6 44 9C CE
          :       57 10 82 D3 C2 57 0A FA DA 14 D0 64 22 28 C0 13
          :       74 04 BD 1C 2B 4F F9 93 58 A6 25 D8 B9 A9 D3 37
          :       9E F2 AC C0 CF 02 9E 84 75 D6 F0 7C A5 01 70 AE
          :       E6 66 AF 9C 69 85 74 6F 13 E9 B3 B8 95 4B 82 ED
          :       95 D6 EA 66 05 7B 96 96 87 B2 9A E7 61 E9 65 89
          :       F8 60 E3 C0 F5 CE DD 18 97 05 E8 C1 AC E1 4D 5E
          :       16 85 2D ED 3C CB 80 CF 7E BF D2 FE D5 C9 38 19
          :       BB 43 34 29 B6 66 CF 2D 8B 46 7E 9A D8 BB 8E 65
          :       88 51 6A A8 FF 78 51 E2 E9 21 27 D7 77 7E 80 28
          :       6C EA 4C 50 9C 73 71 16 F6 5E 54 14 4D 4C 14 B9
          :       67 A0 4A 20 AA DA 0B A0 A0 01 B7 42 24 38 51 8A
          :       78 2F C4 81 E6 81 75 62 DE E3 AF 5D 74 2F 6B 41
          :       FB 79 C3 A8 3A 72 6C 46 F9 A6 03 74 81 01 DF 8C
          :       EB
  477    3:      INTEGER 65537
          :       }
          :      }
          :     }
  482  431:   [3] {
  486  427:    SEQUENCE {
  490   29:     SEQUENCE {
  492    3:      OBJECT IDENTIFIER subjectKeyIdentifier (2 5 29 14)
  497   22:      OCTET STRING, encapsulates {
  499   20:       OCTET STRING
          :        91 46 52 A3 BD 51 C1 44 26 01 98 88 9F 5C 45 AB
          :        F0 53 A1 87
          :        }
          :       }
  521   31:     SEQUENCE {
  523    3:      OBJECT IDENTIFIER authorityKeyIdentifier (2 5 29 35)
  528   24:      OCTET STRING, encapsulates {
  530   22:       SEQUENCE {
  532   20:        [0]
          :         3A CE 2C EF 4F B2 1B 7D 11 E3 E1 84 EF C1 E2 97
          :         B3 77 86 42
          :         }
          :        }
          :       }
  554   12:     SEQUENCE {
  556    3:      OBJECT IDENTIFIER basicConstraints (2 5 29 19)
  561    1:      BOOLEAN TRUE
  564    2:      OCTET STRING, encapsulates {
  566    0:       SEQUENCE {}
          :        }
          :       }
  568   14:     SEQUENCE {
  570    3:      OBJECT IDENTIFIER keyUsage (2 5 29 15)
  575    1:      BOOLEAN TRUE
  578    4:      OCTET STRING, encapsulates {
  580    2:       BIT STRING 7 unused bits
          :        '1'B (bit 0)
          :        }
          :       }
  584   24:     SEQUENCE {
  586    3:      OBJECT IDENTIFIER certificatePolicies (2 5 29 32)
  591    1:      BOOLEAN TRUE
  594   14:      OCTET STRING, encapsulates {
  596   12:       SEQUENCE {
  598   10:        SEQUENCE {
  600    8:         OBJECT IDENTIFIER
          :          resourceCertificatePolicy (1 3 6 1 5 5 7 14 2)
          :          }
          :         }
          :        }
          :       }
  610   97:     SEQUENCE {
  612    3:      OBJECT IDENTIFIER cRLDistributionPoints (2 5 29 31)
  617   90:      OCTET STRING, encapsulates {
  619   88:       SEQUENCE {
  621   86:        SEQUENCE {
  623   84:         [0] {
  625   82:          [0] {
  627   80:           [6]
          :          'rsync://rpki.example.net/repository/3ACE2CEF4F'
          :          'B21B7D11E3E184EFC1E297B3778642.crl'
          :            }
          :           }
          :          }
          :         }
          :        }
          :       }
  709  108:     SEQUENCE {
  711    8:      OBJECT IDENTIFIER authorityInfoAccess
          :       (1 3 6 1 5 5 7 1 1)
  721   96:      OCTET STRING, encapsulates {
  723   94:       SEQUENCE {
  725   92:        SEQUENCE {
  727    8:         OBJECT IDENTIFIER caIssuers (1 3 6 1 5 5 7 48 2)
  737   80:         [6]
          :          'rsync://rpki.example.net/repository/3ACE2CEF4F'
          :          'B21B7D11E3E184EFC1E297B3778642.cer'
          :          }
          :         }
          :        }
          :       }
  819   25:     SEQUENCE {
  821    8:      OBJECT IDENTIFIER ipAddrBlocks (1 3 6 1 5 5 7 1 7)
  831    1:      BOOLEAN TRUE
  834   10:      OCTET STRING, encapsulates {
  836    8:       SEQUENCE {
  838    6:        SEQUENCE {
  840    2:         OCTET STRING 00 01
  844    0:         NULL
          :          }
          :         }
          :        }
          :       }
  846   69:     SEQUENCE {
  848    8:      OBJECT IDENTIFIER subjectInfoAccess
          :       (1 3 6 1 5 5 7 1 11)
  858   57:      OCTET STRING, encapsulates {
  860   55:       SEQUENCE {
  862   53:        SEQUENCE {
  864    8:         OBJECT IDENTIFIER '1 3 6 1 5 5 7 48 13'
  874   41:         [6]
          :          'https://rrdp.example.net/notification.xml'
          :          }
          :         }
          :        }
          :       }
          :      }
          :     }
          :    }
  917   13:  SEQUENCE {
  919    9:   OBJECT IDENTIFIER sha256WithRSAEncryption
          :    (1 2 840 113549 1 1 11)
  930    0:   NULL
          :    }
  932  257:  BIT STRING
          :   48 C2 F7 C8 15 A7 43 1B EE E8 8A 68 7C A5 3F 4E
          :   39 DE 6B 49 F8 09 0D D3 B7 EC 2B FA 86 C3 F7 BD
          :   D0 32 6F ED CA 75 86 F8 E3 E2 EC B7 B2 07 FB 3C
          :   94 3B 70 A3 46 AE 0C 9B AB F9 44 D2 37 1E F8 04
          :   60 56 36 E2 D8 1A F3 66 C5 80 9C 1F 38 E9 29 F0
          :   B2 4B 70 E9 C7 A7 6A 27 FA 03 0C 3A AB 4D 0D B2
          :   90 1E A4 C0 5D D9 58 3F F6 C2 85 BC EC 09 15 53
          :   A0 35 CA A2 42 25 CF E6 B1 89 3D 60 5C 38 CB F9
          :   D9 AF FB 69 D8 DF 5F 0A 67 3A 28 E2 4C E8 0C 96
          :   84 06 98 2D 93 3D 9A 72 75 92 A3 97 11 00 4D D1
          :   44 42 CB 1A DF 7C 43 9E 5A 69 FB FA FD C6 E3 55
          :   61 1B 51 70 2D FA A1 6A DA 54 0D E3 CC DE 85 EA
          :   B0 C4 F2 BF 31 B3 7C A5 21 25 73 E8 97 82 43 86
          :   11 63 06 CC B2 38 DC FE D8 89 2C CE D9 63 12 1E
          :   E4 8A D8 CF 56 6D 37 A9 FF 48 4B 2C 24 0B 30 44
          :   88 29 B3 61 21 0A DF C7 4B 6C 40 98 60 8E 86 05
          :   }
</pre><a href="#appendix-A-9" class="pilcrow">¶</a>
</div>
<p id="appendix-A-10">
To allow reproduction of the signature results, the end-entity
private key is provided.  For brevity, the other two private
keys are not.<a href="#appendix-A-10" class="pilcrow">¶</a></p>
<div id="appendix-A-11">
<pre class="sourcecode">
 -----BEGIN RSA PRIVATE KEY-----
 MIIEpQIBAAKCAQEAsnE0Kzm/6gdlt4tyovD4QPwxFsootk4BqPaYAsDvZbCESOmW
 /5Pmkollj/ZEnM5XEILTwlcK+toU0GQiKMATdAS9HCtP+ZNYpiXYuanTN57yrMDP
 Ap6EddbwfKUBcK7mZq+caYV0bxPps7iVS4LtldbqZgV7lpaHsprnYellifhg48D1
 zt0YlwXowazhTV4WhS3tPMuAz36/0v7VyTgZu0M0KbZmzy2LRn6a2LuOZYhRaqj/
 eFHi6SEn13d+gChs6kxQnHNxFvZeVBRNTBS5Z6BKIKraC6CgAbdCJDhRingvxIHm
 gXVi3uOvXXQva0H7ecOoOnJsRvmmA3SBAd+M6wIDAQABAoIBAQCyB0FeMuKm8bRo
 18aKjFGSPEoZi53srIz5bvUgIi92TBLez7ZnzL6Iym26oJ+5th+lCHGO/dqlhXio
 pI50C5Yc9TFbblb/ECOsuCuuqKFjZ8CD3GVsHozXKJeMM+/o5YZXQrORj6UnwT0z
 ol/JE5pIGUCIgsXX6tz9s5BP3lUAvVQHsv6+vEVKLxQ3wj/1vIL8O/CN036EV0GJ
 mpkwmygPjfECT9wbWo0yn3jxJb36+M/QjjUP28oNIVn/IKoPZRXnqchEbuuCJ651
 IsaFSqtiThm4WZtvCH/IDq+6/dcMucmTjIRcYwW7fdHfjplllVPve9c/OmpWEQvF
 t3ArWUt5AoGBANs4764yHxo4mctLIE7G7l/tf9bP4KKUiYw4R4ByEocuqMC4yhmt
 MPCfOFLOQet71OWCkjP2L/7EKUe9yx7G5KmxAHY6jOjvcRkvGsl6lWFOsQ8p126M
 Y9hmGzMOjtsdhAiMmOWKzjvm4WqfMgghQe+PnjjSVkgTt+7BxpIuGBAvAoGBANBg
 26FF5cDLpixOd3Za1YXsOgguwCaw3Plvi7vUZRpa/zBMELEtyOebfakkIRWNm07l
 nE+lAZwxm+29PTD0nqCFE91teyzjnQaLO5kkAdJiFuVV3icLOGo399FrnJbKensm
 FGSli+3KxQhCNIJJfgWzq4bE0ioAMjdGbYXzIYQFAoGBAM6tuDJ36KDU+hIS6wu6
 O2TPSfZhF/zPo3pCWQ78/QDb+Zdw4IEiqoBA7F4NPVLg9Y/H8UTx9r/veqe7hPOo
 Ok7NpIzSmKTHkc5XfZ60Zn9OLFoKbaQ40a1kXoJdWEu2YROaUlAe9F6/Rog6PHYz
 vLE5qscRbu0XQhLkN+z7bg5bAoGBAKDsbDEb/dbqbyaAYpmwhH2sdRSkphg7Niwc
 DNm9qWa1J6Zw1+M87I6Q8naRREuU1IAVqqWHVLr/ROBQ6NTJ1Uc5/qFeT2XXUgkf
 taMKv61tuyjZK3sTmznMh0HfzUpWjEhWnCEuB+ZYVdmO52ZGw2A75RdrILL2+9Dc
 PvDXVubRAoGAdqXeSWoLxuzZXzl8rsaKrQsTYaXnOWaZieU1SL5vVe8nK257UDqZ
 E3ng2j5XPTUWli+aNGFEJGRoNtcQvO60O/sFZUhu52sqq9mWVYZNh1TB5aP8X+pV
 iFcZOLUvQEcN6PA+YQK5FU11rAI1M0Gm5RDnVnUl0L2xfCYxb7FzV6Y=
 -----END RSA PRIVATE KEY-----
</pre><a href="#appendix-A-11" class="pilcrow">¶</a>
</div>
<p id="appendix-A-12">
Signing of "192.0.2.0/24,US,WA,Seattle," (terminated by CR and LF) yields the
following detached CMS signature.<a href="#appendix-A-12" class="pilcrow">¶</a></p>
<div id="appendix-A-13">
<pre class="sourcecode">
 # RPKI Signature: 192.0.2.0 - 192.0.2.255
 # MIIGjwYJKoZIhvcNAQcCoIIGgDCCBnwCAQMxDTALBglghkgBZQMEAgEwDQYLKoZ
 # IhvcNAQkQAS+gggSpMIIEpTCCA42gAwIBAgIUJ605QIPX8rW5m4Zwx3WyuW7hZu
 # QwDQYJKoZIhvcNAQELBQAwMzExMC8GA1UEAxMoM0FDRTJDRUY0RkIyMUI3RDExR
 # TNFMTg0RUZDMUUyOTdCMzc3ODY0MjAeFw0yMTA1MjAxNjA1NDVaFw0yMjAzMTYx
 # NjA1NDVaMDMxMTAvBgNVBAMTKDkxNDY1MkEzQkQ1MUMxNDQyNjAxOTg4ODlGNUM
 # 0NUFCRjA1M0ExODcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCycT
 # QrOb/qB2W3i3Ki8PhA/DEWyii2TgGo9pgCwO9lsIRI6Zb/k+aSiWWP9kSczlcQg
 # tPCVwr62hTQZCIowBN0BL0cK0/5k1imJdi5qdM3nvKswM8CnoR11vB8pQFwruZm
 # r5xphXRvE+mzuJVLgu2V1upmBXuWloeymudh6WWJ+GDjwPXO3RiXBejBrOFNXha
 # FLe08y4DPfr/S/tXJOBm7QzQptmbPLYtGfprYu45liFFqqP94UeLpISfXd36AKG
 # zqTFCcc3EW9l5UFE1MFLlnoEogqtoLoKABt0IkOFGKeC/EgeaBdWLe469ddC9rQ
 # ft5w6g6cmxG+aYDdIEB34zrAgMBAAGjggGvMIIBqzAdBgNVHQ4EFgQUkUZSo71R
 # wUQmAZiIn1xFq/BToYcwHwYDVR0jBBgwFoAUOs4s70+yG30R4+GE78Hil7N3hkI
 # wDAYDVR0TAQH/BAIwADAOBgNVHQ8BAf8EBAMCB4AwGAYDVR0gAQH/BA4wDDAKBg
 # grBgEFBQcOAjBhBgNVHR8EWjBYMFagVKBShlByc3luYzovL3Jwa2kuZXhhbXBsZ
 # S5uZXQvcmVwb3NpdG9yeS8zQUNFMkNFRjRGQjIxQjdEMTFFM0UxODRFRkMxRTI5
 # N0IzNzc4NjQyLmNybDBsBggrBgEFBQcBAQRgMF4wXAYIKwYBBQUHMAKGUHJzeW5
 # jOi8vcnBraS5leGFtcGxlLm5ldC9yZXBvc2l0b3J5LzNBQ0UyQ0VGNEZCMjFCN0
 # QxMUUzRTE4NEVGQzFFMjk3QjM3Nzg2NDIuY2VyMBkGCCsGAQUFBwEHAQH/BAowC
 # DAGBAIAAQUAMEUGCCsGAQUFBwELBDkwNzA1BggrBgEFBQcwDYYpaHR0cHM6Ly9y
 # cmRwLmV4YW1wbGUubmV0L25vdGlmaWNhdGlvbi54bWwwDQYJKoZIhvcNAQELBQA
 # DggEBAEjC98gVp0Mb7uiKaHylP0453mtJ+AkN07fsK/qGw/e90DJv7cp1hvjj4u
 # y3sgf7PJQ7cKNGrgybq/lE0jce+ARgVjbi2BrzZsWAnB846Snwsktw6cenaif6A
 # ww6q00NspAepMBd2Vg/9sKFvOwJFVOgNcqiQiXP5rGJPWBcOMv52a/7adjfXwpn
 # OijiTOgMloQGmC2TPZpydZKjlxEATdFEQssa33xDnlpp+/r9xuNVYRtRcC36oWr
 # aVA3jzN6F6rDE8r8xs3ylISVz6JeCQ4YRYwbMsjjc/tiJLM7ZYxIe5IrYz1ZtN6
 # n/SEssJAswRIgps2EhCt/HS2xAmGCOhgUxggGqMIIBpgIBA4AUkUZSo71RwUQmA
 # ZiIn1xFq/BToYcwCwYJYIZIAWUDBAIBoGswGgYJKoZIhvcNAQkDMQ0GCyqGSIb3
 # DQEJEAEvMBwGCSqGSIb3DQEJBTEPFw0yMTA1MjAxNjI4MzlaMC8GCSqGSIb3DQE
 # JBDEiBCAr4vKeUvHJINsE0YQwUMxoo48qrOU+iPuFbQR8qX3BFjANBgkqhkiG9w
 # 0BAQEFAASCAQB85HsCBrU3EcVOcf4nC6Z3jrOjT+fVlyTDAObF6GTNWgrxe7jSA
 # Inyf51UzuIGqhVY3sQiiXbdWcVYtPb4118KvyeXh8A/HLp4eeAJntl9D3igt38M
 # o84q5pf9pTQXx3hbsm51ilpOip/TKVMqzE42s6OPox3M0+6eKH3/vBKnw1s1ayM
 # 0MUnPDTBfZL3JJEGPWfIZHEcrypevbqR7Jjsz5vp0qyF2D9v+w+nyhZOPmuePm7
 # YqLyOw/E99PVBs9uI+hmBiCz/BK2Z3VRjrrlrUU+49eldSTkZ2sJyhCbbV2Ufgi
 # S2FOquAgJzjilyN3BDQLV8Rp9cGh0PpVslKH2na
 # End Signature: 192.0.2.0 - 192.0.2.255
</pre><a href="#appendix-A-13" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="ack">
<section id="appendix-B">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-B-1">
        Thanks to <span class="contact-name">Rob Austein</span> for CMS and detached
        signature clue, <span class="contact-name">George Michaelson</span> for the first
        and substantial external review, and <span class="contact-name">Erik Kline</span>
        who was too shy to agree to coauthorship.  Additionally, we express
        our gratitude to early implementors, including <span class="contact-name">Menno         Schepers</span>; <span class="contact-name">Flavio Luciani</span>; <span class="contact-name">Eric Dugas</span>; <span class="contact-name">Job Snijders</span>, who
        provided running code; and <span class="contact-name">Kevin Pack</span>.  Also,
        thanks to the following geolocation providers who are consuming geofeeds with this
        described solution: <span class="contact-name">Jonathan Kosgei</span> (ipdata.co),
        <span class="contact-name">Ben Dowling</span> (ipinfo.io), and <span class="contact-name">Pol Nisenblat</span> (bigdatacloud.com).  For an amazing number
        of helpful reviews, we thank <span class="contact-name">Adrian Farrel</span>,
        <span class="contact-name">Antonio Prado</span>, <span class="contact-name">Francesca         Palombini</span>, <span class="contact-name">Jean-Michel Combes</span> (INTDIR),
        <span class="contact-name">John Scudder</span>, <span class="contact-name">Kyle Rose</span>
        (SECDIR), <span class="contact-name">Martin Duke</span>, <span class="contact-name">Murray         Kucherawy</span>, <span class="contact-name">Paul Kyzivat</span> (GENART), <span class="contact-name">Rob Wilton</span>, and <span class="contact-name">Roman Danyliw</span>.  The
        authors also thank <span class="contact-name">George Michaelson</span>, the
        awesome document shepherd.<a href="#appendix-B-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-C">
      <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">Randy Bush</span></div>
<div dir="auto" class="left"><span class="org">IIJ &amp; Arrcus</span></div>
<div dir="auto" class="left"><span class="street-address">5147 Crystal Springs</span></div>
<div dir="auto" class="left">
<span class="locality">Bainbridge Island</span>, <span class="region">Washington</span> <span class="postal-code">98110</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:randy@psg.com" class="email">randy@psg.com</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Massimo Candela</span></div>
<div dir="auto" class="left"><span class="org">NTT</span></div>
<div dir="auto" class="left"><span class="street-address">Siriusdreef 70-72</span></div>
<div dir="auto" class="left">
<span class="postal-code">2132 WT</span> <span class="locality">Hoofddorp</span>
</div>
<div dir="auto" class="left"><span class="country-name">Netherlands</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:massimo@ntt.net" class="email">massimo@ntt.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Warren Kumari</span></div>
<div dir="auto" class="left"><span class="org">Google</span></div>
<div dir="auto" class="left"><span class="street-address">1600 Amphitheatre Parkway</span></div>
<div dir="auto" class="left">
<span class="locality">Mountain View</span>, <span class="region">CA</span> <span class="postal-code">94043</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:warren@kumari.net" class="email">warren@kumari.net</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Russ Housley</span></div>
<div dir="auto" class="left"><span class="org">Vigil Security, LLC</span></div>
<div dir="auto" class="left"><span class="street-address">516 Dranesville Road</span></div>
<div dir="auto" class="left">
<span class="locality">Herndon</span>, <span class="region">VA</span> <span class="postal-code">20170</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="email">
<span>Email:</span>
<a href="mailto:housley@vigilsec.com" class="email">housley@vigilsec.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>