File: rfc9173.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 (5119 lines) | stat: -rw-r--r-- 261,604 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 9173: Default Security Contexts for Bundle Protocol Security (BPSec)</title>
<meta content="Edward J. Birrane, III" name="author">
<meta content="Alex White" name="author">
<meta content="Sarah Heiner" name="author">
<meta content="
       
         This document defines default integrity and confidentiality security
         contexts that can be used with Bundle Protocol Security
         (BPSec) implementations.  These security contexts are intended to be 
         used both for testing the interoperability of BPSec implementations and for providing 
         basic security operations when no other security contexts are defined 
         or otherwise required for a network.
       
    " name="description">
<meta content="xml2rfc 3.12.0" name="generator">
<meta content="security" name="keyword">
<meta content="bundle" name="keyword">
<meta content="integrity" name="keyword">
<meta content="confidentiality" name="keyword">
<meta content="9173" name="rfc.number">
<!-- Generator version information:
  xml2rfc 3.12.0
    Python 3.6.15
    appdirs 1.4.4
    ConfigArgParse 1.4.1
    google-i18n-address 2.4.0
    html5lib 1.0.1
    intervaltree 3.0.2
    Jinja2 2.11.3
    kitchen 1.2.6
    lxml 4.4.2
    pycairo 1.15.1
    pycountry 19.8.18
    pyflakes 2.1.1
    PyYAML 5.4.1
    requests 2.24.0
    setuptools 40.5.0
    six 1.14.0
    WeasyPrint 52.5
-->
<link href="rfc9173.xml" rel="alternate" type="application/rfc+xml">
<link href="#copyright" rel="license">
<style type="text/css">/*

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

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

*/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

.refInstance {
  margin-bottom: 1.25em;
}

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

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

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

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

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

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

/* pagination */
@media print {
  body {

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

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

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

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

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

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

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

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

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

}

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


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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

}
/* Tweak the bcp14 keyword presentation */
.bcp14 {
  font-variant: small-caps;
  font-weight: bold;
  font-size: 0.9em;
}
/* Tweak the invisible space above H* in order not to overlay links in text above */
 h2 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 31px;
 }
 h3 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
 h4 {
  margin-top: -18px;  /* provide offset for in-page anchors */
  padding-top: 24px;
 }
/* Float artwork pilcrow to the right */
@media screen {
  .artwork a.pilcrow {
    display: block;
    line-height: 0.7;
    margin-top: 0.15em;
  }
}
/* Make pilcrows on dd visible */
@media screen {
  dd:hover > a.pilcrow {
    visibility: visible;
  }
}
/* Make the placement of figcaption match that of a table's caption
   by removing the figure's added bottom margin */
.alignLeft.art-text,
.alignCenter.art-text,
.alignRight.art-text {
   margin-bottom: 0;
}
.alignLeft,
.alignCenter,
.alignRight {
  margin: 1em 0 0 0;
}
/* In print, the pilcrow won't show on hover, so prevent it from taking up space,
   possibly even requiring a new line */
@media print {
  a.pilcrow {
    display: none;
  }
}
/* Styling for the external metadata */
div#external-metadata {
  background-color: #eee;
  padding: 0.5em;
  margin-bottom: 0.5em;
  display: none;
}
div#internal-metadata {
  padding: 0.5em;                       /* to match the external-metadata padding */
}
/* Styling for title RFC Number */
h1#rfcnum {
  clear: both;
  margin: 0 0 -1em;
  padding: 1em 0 0 0;
}
/* Make .olPercent look the same as <ol><li> */
dl.olPercent > dd {
  margin-bottom: 0.25em;
  min-height: initial;
}
/* Give aside some styling to set it apart */
aside {
  border-left: 1px solid #ddd;
  margin: 1em 0 1em 2em;
  padding: 0.2em 2em;
}
aside > dl,
aside > ol,
aside > ul,
aside > table,
aside > p {
  margin-bottom: 0.5em;
}
/* Additional page break settings */
@media print {
  figcaption, table caption {
    page-break-before: avoid;
  }
}
/* Font size adjustments for print */
@media print {
  body  { font-size: 10pt;      line-height: normal; max-width: 96%; }
  h1    { font-size: 1.72em;    padding-top: 1.5em; } /* 1*1.2*1.2*1.2 */
  h2    { font-size: 1.44em;    padding-top: 1.5em; } /* 1*1.2*1.2 */
  h3    { font-size: 1.2em;     padding-top: 1.5em; } /* 1*1.2 */
  h4    { font-size: 1em;       padding-top: 1.5em; }
  h5, h6 { font-size: 1em;      margin: initial; padding: 0.5em 0 0.3em; }
}
/* Sourcecode margin in print, when there's no pilcrow */
@media print {
  .artwork,
  .sourcecode {
    margin-bottom: 1em;
  }
}
/* Avoid narrow tables forcing too narrow table captions, which may render badly */
table {
  min-width: 20em;
}
/* ol type a */
ol.type-a { list-style-type: lower-alpha; }
ol.type-A { list-style-type: upper-alpha; }
ol.type-i { list-style-type: lower-roman; }
ol.type-I { list-style-type: lower-roman; }
/* Apply the print table and row borders in general, on request from the RPC,
and increase the contrast between border and odd row background sligthtly */
table {
  border: 1px solid #ddd;
}
td {
  border-top: 1px solid #ddd;
}
tr:nth-child(2n+1) > td {
  background-color: #f8f8f8;
}
/* Use style rules to govern display of the TOC. */
@media screen and (max-width: 1023px) {
  #toc nav { display: none; }
  #toc.active nav { display: block; }
}
/* Add support for keepWithNext */
.keepWithNext {
  break-after: avoid-page;
  break-after: avoid-page;
}
/* Add support for keepWithPrevious */
.keepWithPrevious {
  break-before: avoid-page;
}
/* Change the approach to avoiding breaks inside artwork etc. */
figure, pre, table, .artwork, .sourcecode  {
  break-before: auto;
  break-after: auto;
}
/* Avoid breaks between <dt> and <dd> */
dl {
  break-before: auto;
  break-inside: auto;
}
dt {
  break-before: auto;
  break-after: avoid-page;
}
dd {
  break-before: avoid-page;
  break-after: auto;
  orphans: 3;
  widows: 3
}
span.break, dd.break {
  margin-bottom: 0;
  min-height: 0;
  break-before: auto;
  break-inside: auto;
  break-after: auto;
}
/* Undo break-before ToC */
@media print {
  #toc {
    break-before: auto;
  }
}
/* Text in compact lists should not get extra bottim margin space,
   since that would makes the list not compact */
ul.compact p, .ulCompact p,
ol.compact p, .olCompact p {
 margin: 0;
}
/* But the list as a whole needs the extra space at the end */
section ul.compact,
section .ulCompact,
section ol.compact,
section .olCompact {
  margin-bottom: 1em;                    /* same as p not within ul.compact etc. */
}
/* The tt and code background above interferes with for instance table cell
   backgrounds.  Changed to something a bit more selective. */
tt, code {
  background-color: transparent;
}
p tt, p code, li tt, li code {
  background-color: #f8f8f8;
}
/* Tweak the pre margin -- 0px doesn't come out well */
pre {
   margin-top: 0.5px;
}
/* Tweak the comact list text */
ul.compact, .ulCompact,
ol.compact, .olCompact,
dl.compact, .dlCompact {
  line-height: normal;
}
/* Don't add top margin for nested lists */
li > ul, li > ol, li > dl,
dd > ul, dd > ol, dd > dl,
dl > dd > dl {
  margin-top: initial;
}
/* Elements that should not be rendered on the same line as a <dt> */
/* This should match the element list in writer.text.TextWriter.render_dl() */
dd > div.artwork:first-child,
dd > aside:first-child,
dd > figure:first-child,
dd > ol:first-child,
dd > div:first-child > pre.sourcecode,
dd > table:first-child,
dd > ul:first-child {
  clear: left;
}
/* fix for weird browser behaviour when <dd/> is empty */
dt+dd:empty::before{
  content: "\00a0";
}
/* Make paragraph spacing inside <li> smaller than in body text, to fit better within the list */
li > p {
  margin-bottom: 0.5em
}
/* Don't let p margin spill out from inside list items */
li > p:last-of-type {
  margin-bottom: 0;
}
</style>
<link href="rfc-local.css" rel="stylesheet" type="text/css">
<link href="https://dx.doi.org/10.17487/rfc9173" rel="alternate">
  <link href="urn:issn:2070-1721" rel="alternate">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-dtn-bpsec-default-sc-11" 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 9173</td>
<td class="center">BPSec Default Security Contexts</td>
<td class="right">January 2022</td>
</tr></thead>
<tfoot><tr>
<td class="left">Birrane, III, 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/rfc9173" class="eref">9173</a></dd>
<dt class="label-category">Category:</dt>
<dd class="category">Standards Track</dd>
<dt class="label-published">Published:</dt>
<dd class="published">
<time datetime="2022-01" class="published">January 2022</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">E. Birrane, III</div>
<div class="org">JHU/APL</div>
</div>
<div class="author">
      <div class="author-name">A. White</div>
<div class="org">JHU/APL</div>
</div>
<div class="author">
      <div class="author-name">S. Heiner</div>
<div class="org">JHU/APL</div>
</div>
</dd>
</dl>
</div>
<h1 id="rfcnum">RFC 9173</h1>
<h1 id="title">Default Security Contexts for Bundle Protocol Security (BPSec)</h1>
<section id="section-abstract">
      <h2 id="abstract"><a href="#abstract" class="selfRef">Abstract</a></h2>
<p id="section-abstract-1">
         This document defines default integrity and confidentiality security
         contexts that can be used with Bundle Protocol Security
         (BPSec) implementations.  These security contexts are intended to be 
         used both for testing the interoperability of BPSec implementations and for providing 
         basic security operations when no other security contexts are defined 
         or otherwise required for a network.<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/rfc9173">https://www.rfc-editor.org/info/rfc9173</a></span>.<a href="#section-boilerplate.1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="copyright">
<section id="section-boilerplate.2">
        <h2 id="name-copyright-notice">
<a href="#name-copyright-notice" class="section-name selfRef">Copyright Notice</a>
        </h2>
<p id="section-boilerplate.2-1">
            Copyright (c) 2022 IETF Trust and the persons identified as the
            document authors. All rights reserved.<a href="#section-boilerplate.2-1" class="pilcrow">¶</a></p>
<p id="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<span><a href="https://trustee.ietf.org/license-info">https://trustee.ietf.org/license-info</a></span>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.<a href="#section-boilerplate.2-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="toc">
<section id="section-toc.1">
        <a href="#" onclick="scroll(0,0)" class="toplink">▲</a><h2 id="name-table-of-contents">
<a href="#name-table-of-contents" class="section-name selfRef">Table of Contents</a>
        </h2>
<nav class="toc"><ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.1">
            <p id="section-toc.1-1.1.1" class="keepWithNext"><a href="#section-1" class="xref">1</a>.  <a href="#name-introduction" class="xref">Introduction</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.2">
            <p id="section-toc.1-1.2.1" class="keepWithNext"><a href="#section-2" class="xref">2</a>.  <a href="#name-requirements-language" class="xref">Requirements Language</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3">
            <p id="section-toc.1-1.3.1"><a href="#section-3" class="xref">3</a>.  <a href="#name-integrity-security-context-" class="xref">Integrity Security Context BIB-HMAC-SHA2</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.1">
                <p id="section-toc.1-1.3.2.1.1" class="keepWithNext"><a href="#section-3.1" class="xref">3.1</a>.  <a href="#name-overview" class="xref">Overview</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.2">
                <p id="section-toc.1-1.3.2.2.1"><a href="#section-3.2" class="xref">3.2</a>.  <a href="#name-scope" class="xref">Scope</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3">
                <p id="section-toc.1-1.3.2.3.1"><a href="#section-3.3" class="xref">3.3</a>.  <a href="#name-parameters" class="xref">Parameters</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3.2.1">
                    <p id="section-toc.1-1.3.2.3.2.1.1"><a href="#section-3.3.1" class="xref">3.3.1</a>.  <a href="#name-sha-variant" class="xref">SHA Variant</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3.2.2">
                    <p id="section-toc.1-1.3.2.3.2.2.1"><a href="#section-3.3.2" class="xref">3.3.2</a>.  <a href="#name-wrapped-key" class="xref">Wrapped Key</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3.2.3">
                    <p id="section-toc.1-1.3.2.3.2.3.1"><a href="#section-3.3.3" class="xref">3.3.3</a>.  <a href="#name-integrity-scope-flags" class="xref">Integrity Scope Flags</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.3.2.4">
                    <p id="section-toc.1-1.3.2.3.2.4.1"><a href="#section-3.3.4" class="xref">3.3.4</a>.  <a href="#name-enumerations" class="xref">Enumerations</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.4">
                <p id="section-toc.1-1.3.2.4.1"><a href="#section-3.4" class="xref">3.4</a>.  <a href="#name-results" class="xref">Results</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.5">
                <p id="section-toc.1-1.3.2.5.1"><a href="#section-3.5" class="xref">3.5</a>.  <a href="#name-key-considerations" class="xref">Key Considerations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.6">
                <p id="section-toc.1-1.3.2.6.1"><a href="#section-3.6" class="xref">3.6</a>.  <a href="#name-security-processing-conside" class="xref">Security Processing Considerations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.7">
                <p id="section-toc.1-1.3.2.7.1"><a href="#section-3.7" class="xref">3.7</a>.  <a href="#name-canonicalization-algorithms" class="xref">Canonicalization Algorithms</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.8">
                <p id="section-toc.1-1.3.2.8.1"><a href="#section-3.8" class="xref">3.8</a>.  <a href="#name-processing" class="xref">Processing</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.8.2.1">
                    <p id="section-toc.1-1.3.2.8.2.1.1"><a href="#section-3.8.1" class="xref">3.8.1</a>.  <a href="#name-keyed-hash-generation" class="xref">Keyed Hash Generation</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.3.2.8.2.2">
                    <p id="section-toc.1-1.3.2.8.2.2.1"><a href="#section-3.8.2" class="xref">3.8.2</a>.  <a href="#name-keyed-hash-verification" class="xref">Keyed Hash Verification</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4">
            <p id="section-toc.1-1.4.1"><a href="#section-4" class="xref">4</a>.  <a href="#name-security-context-bcb-aes-gc" class="xref">Security Context BCB-AES-GCM</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.1">
                <p id="section-toc.1-1.4.2.1.1"><a href="#section-4.1" class="xref">4.1</a>.  <a href="#name-overview-2" class="xref">Overview</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.2">
                <p id="section-toc.1-1.4.2.2.1"><a href="#section-4.2" class="xref">4.2</a>.  <a href="#name-scope-2" class="xref">Scope</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3">
                <p id="section-toc.1-1.4.2.3.1"><a href="#section-4.3" class="xref">4.3</a>.  <a href="#name-parameters-2" class="xref">Parameters</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3.2.1">
                    <p id="section-toc.1-1.4.2.3.2.1.1"><a href="#section-4.3.1" class="xref">4.3.1</a>.  <a href="#name-initialization-vector-iv" class="xref">Initialization Vector (IV)</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3.2.2">
                    <p id="section-toc.1-1.4.2.3.2.2.1"><a href="#section-4.3.2" class="xref">4.3.2</a>.  <a href="#name-aes-variant" class="xref">AES Variant</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3.2.3">
                    <p id="section-toc.1-1.4.2.3.2.3.1"><a href="#section-4.3.3" class="xref">4.3.3</a>.  <a href="#name-wrapped-key-2" class="xref">Wrapped Key</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3.2.4">
                    <p id="section-toc.1-1.4.2.3.2.4.1"><a href="#section-4.3.4" class="xref">4.3.4</a>.  <a href="#name-aad-scope-flags" class="xref">AAD Scope Flags</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.3.2.5">
                    <p id="section-toc.1-1.4.2.3.2.5.1"><a href="#section-4.3.5" class="xref">4.3.5</a>.  <a href="#name-enumerations-2" class="xref">Enumerations</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4">
                <p id="section-toc.1-1.4.2.4.1"><a href="#section-4.4" class="xref">4.4</a>.  <a href="#name-results-2" class="xref">Results</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.1">
                    <p id="section-toc.1-1.4.2.4.2.1.1"><a href="#section-4.4.1" class="xref">4.4.1</a>.  <a href="#name-authentication-tag" class="xref">Authentication Tag</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.4.2.2">
                    <p id="section-toc.1-1.4.2.4.2.2.1"><a href="#section-4.4.2" class="xref">4.4.2</a>.  <a href="#name-enumerations-3" class="xref">Enumerations</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.5">
                <p id="section-toc.1-1.4.2.5.1"><a href="#section-4.5" class="xref">4.5</a>.  <a href="#name-key-considerations-2" class="xref">Key Considerations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.6">
                <p id="section-toc.1-1.4.2.6.1"><a href="#section-4.6" class="xref">4.6</a>.  <a href="#name-gcm-considerations" class="xref">GCM Considerations</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.7">
                <p id="section-toc.1-1.4.2.7.1"><a href="#section-4.7" class="xref">4.7</a>.  <a href="#name-canonicalization-algorithms-2" class="xref">Canonicalization Algorithms</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.7.2.1">
                    <p id="section-toc.1-1.4.2.7.2.1.1"><a href="#section-4.7.1" class="xref">4.7.1</a>.  <a href="#name-calculations-related-to-cip" class="xref">Calculations Related to Ciphertext</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.7.2.2">
                    <p id="section-toc.1-1.4.2.7.2.2.1"><a href="#section-4.7.2" class="xref">4.7.2</a>.  <a href="#name-additional-authenticated-da" class="xref">Additional Authenticated Data</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.8">
                <p id="section-toc.1-1.4.2.8.1"><a href="#section-4.8" class="xref">4.8</a>.  <a href="#name-processing-2" class="xref">Processing</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.8.2.1">
                    <p id="section-toc.1-1.4.2.8.2.1.1"><a href="#section-4.8.1" class="xref">4.8.1</a>.  <a href="#name-encryption" class="xref">Encryption</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.4.2.8.2.2">
                    <p id="section-toc.1-1.4.2.8.2.2.1"><a href="#section-4.8.2" class="xref">4.8.2</a>.  <a href="#name-decryption" class="xref">Decryption</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5">
            <p id="section-toc.1-1.5.1"><a href="#section-5" class="xref">5</a>.  <a href="#name-iana-considerations" class="xref">IANA Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.1">
                <p id="section-toc.1-1.5.2.1.1"><a href="#section-5.1" class="xref">5.1</a>.  <a href="#name-security-context-identifier" class="xref">Security Context Identifiers</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.2">
                <p id="section-toc.1-1.5.2.2.1"><a href="#section-5.2" class="xref">5.2</a>.  <a href="#name-integrity-scope-flags-2" class="xref">Integrity Scope Flags</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.3">
                <p id="section-toc.1-1.5.2.3.1"><a href="#section-5.3" class="xref">5.3</a>.  <a href="#name-aad-scope-flags-2" class="xref">AAD Scope Flags</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.5.2.4">
                <p id="section-toc.1-1.5.2.4.1"><a href="#section-5.4" class="xref">5.4</a>.  <a href="#name-guidance-for-designated-exp" class="xref">Guidance for Designated Experts</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6">
            <p id="section-toc.1-1.6.1"><a href="#section-6" class="xref">6</a>.  <a href="#name-security-considerations" class="xref">Security Considerations</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.1">
                <p id="section-toc.1-1.6.2.1.1"><a href="#section-6.1" class="xref">6.1</a>.  <a href="#name-key-management" class="xref">Key Management</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.2">
                <p id="section-toc.1-1.6.2.2.1"><a href="#section-6.2" class="xref">6.2</a>.  <a href="#name-key-handling" class="xref">Key Handling</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.3">
                <p id="section-toc.1-1.6.2.3.1"><a href="#section-6.3" class="xref">6.3</a>.  <a href="#name-aes-gcm" class="xref">AES GCM</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.4">
                <p id="section-toc.1-1.6.2.4.1"><a href="#section-6.4" class="xref">6.4</a>.  <a href="#name-aes-key-wrap" class="xref">AES Key Wrap</a></p>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.6.2.5">
                <p id="section-toc.1-1.6.2.5.1"><a href="#section-6.5" class="xref">6.5</a>.  <a href="#name-bundle-fragmentation" class="xref">Bundle Fragmentation</a></p>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.7">
            <p id="section-toc.1-1.7.1"><a href="#section-7" class="xref">7</a>.  <a href="#name-normative-references" class="xref">Normative References</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8">
            <p id="section-toc.1-1.8.1"><a href="#appendix-A" class="xref">Appendix A</a>.  <a href="#name-examples" class="xref">Examples</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1">
                <p id="section-toc.1-1.8.2.1.1"><a href="#appendix-A.1" class="xref">A.1</a>.  <a href="#name-example-1-simple-integrity" class="xref">Example 1 - Simple Integrity</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1.2.1">
                    <p id="section-toc.1-1.8.2.1.2.1.1"><a href="#appendix-A.1.1" class="xref">A.1.1</a>.  <a href="#name-original-bundle" class="xref">Original Bundle</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1.2.2">
                    <p id="section-toc.1-1.8.2.1.2.2.1"><a href="#appendix-A.1.2" class="xref">A.1.2</a>.  <a href="#name-security-operation-overview" class="xref">Security Operation Overview</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1.2.3">
                    <p id="section-toc.1-1.8.2.1.2.3.1"><a href="#appendix-A.1.3" class="xref">A.1.3</a>.  <a href="#name-block-integrity-block" class="xref">Block Integrity Block</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.1.2.4">
                    <p id="section-toc.1-1.8.2.1.2.4.1"><a href="#appendix-A.1.4" class="xref">A.1.4</a>.  <a href="#name-final-bundle" class="xref">Final Bundle</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2">
                <p id="section-toc.1-1.8.2.2.1"><a href="#appendix-A.2" class="xref">A.2</a>.  <a href="#name-example-2-simple-confidenti" class="xref">Example 2 - Simple Confidentiality with Key Wrap</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2.2.1">
                    <p id="section-toc.1-1.8.2.2.2.1.1"><a href="#appendix-A.2.1" class="xref">A.2.1</a>.  <a href="#name-original-bundle-2" class="xref">Original Bundle</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2.2.2">
                    <p id="section-toc.1-1.8.2.2.2.2.1"><a href="#appendix-A.2.2" class="xref">A.2.2</a>.  <a href="#name-security-operation-overview-2" class="xref">Security Operation Overview</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2.2.3">
                    <p id="section-toc.1-1.8.2.2.2.3.1"><a href="#appendix-A.2.3" class="xref">A.2.3</a>.  <a href="#name-block-confidentiality-block" class="xref">Block Confidentiality Block</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.2.2.4">
                    <p id="section-toc.1-1.8.2.2.2.4.1"><a href="#appendix-A.2.4" class="xref">A.2.4</a>.  <a href="#name-final-bundle-2" class="xref">Final Bundle</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3">
                <p id="section-toc.1-1.8.2.3.1"><a href="#appendix-A.3" class="xref">A.3</a>.  <a href="#name-example-3-security-blocks-f" class="xref">Example 3 - Security Blocks from Multiple Sources</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3.2.1">
                    <p id="section-toc.1-1.8.2.3.2.1.1"><a href="#appendix-A.3.1" class="xref">A.3.1</a>.  <a href="#name-original-bundle-3" class="xref">Original Bundle</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3.2.2">
                    <p id="section-toc.1-1.8.2.3.2.2.1"><a href="#appendix-A.3.2" class="xref">A.3.2</a>.  <a href="#name-security-operation-overview-3" class="xref">Security Operation Overview</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3.2.3">
                    <p id="section-toc.1-1.8.2.3.2.3.1"><a href="#appendix-A.3.3" class="xref">A.3.3</a>.  <a href="#name-block-integrity-block-2" class="xref">Block Integrity Block</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3.2.4">
                    <p id="section-toc.1-1.8.2.3.2.4.1"><a href="#appendix-A.3.4" class="xref">A.3.4</a>.  <a href="#name-block-confidentiality-block-2" class="xref">Block Confidentiality Block</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.3.2.5">
                    <p id="section-toc.1-1.8.2.3.2.5.1"><a href="#appendix-A.3.5" class="xref">A.3.5</a>.  <a href="#name-final-bundle-3" class="xref">Final Bundle</a></p>
</li>
                </ul>
</li>
              <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4">
                <p id="section-toc.1-1.8.2.4.1"><a href="#appendix-A.4" class="xref">A.4</a>.  <a href="#name-example-4-security-blocks-w" class="xref">Example 4 - Security Blocks with Full Scope</a></p>
<ul class="compact toc ulBare ulEmpty">
<li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4.2.1">
                    <p id="section-toc.1-1.8.2.4.2.1.1"><a href="#appendix-A.4.1" class="xref">A.4.1</a>.  <a href="#name-original-bundle-4" class="xref">Original Bundle</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4.2.2">
                    <p id="section-toc.1-1.8.2.4.2.2.1"><a href="#appendix-A.4.2" class="xref">A.4.2</a>.  <a href="#name-security-operation-overview-4" class="xref">Security Operation Overview</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4.2.3">
                    <p id="section-toc.1-1.8.2.4.2.3.1"><a href="#appendix-A.4.3" class="xref">A.4.3</a>.  <a href="#name-block-integrity-block-3" class="xref">Block Integrity Block</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4.2.4">
                    <p id="section-toc.1-1.8.2.4.2.4.1"><a href="#appendix-A.4.4" class="xref">A.4.4</a>.  <a href="#name-block-confidentiality-block-3" class="xref">Block Confidentiality Block</a></p>
</li>
                  <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.8.2.4.2.5">
                    <p id="section-toc.1-1.8.2.4.2.5.1"><a href="#appendix-A.4.5" class="xref">A.4.5</a>.  <a href="#name-final-bundle-4" class="xref">Final Bundle</a></p>
</li>
                </ul>
</li>
            </ul>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.9">
            <p id="section-toc.1-1.9.1"><a href="#appendix-B" class="xref">Appendix B</a>.  <a href="#name-cddl-expression" class="xref">CDDL Expression</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.10">
            <p id="section-toc.1-1.10.1"><a href="#appendix-C" class="xref"></a><a href="#name-acknowledgments" class="xref">Acknowledgments</a></p>
</li>
          <li class="compact toc ulBare ulEmpty" id="section-toc.1-1.11">
            <p id="section-toc.1-1.11.1"><a href="#appendix-D" class="xref"></a><a href="#name-authors-addresses" class="xref">Authors' Addresses</a></p>
</li>
        </ul>
</nav>
</section>
</div>
<div id="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">
         The Bundle Protocol Security (BPSec) specification
         <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span> provides inter-bundle 
         integrity and confidentiality operations for networks deploying the 
         Bundle Protocol (BP) <span>[<a href="#RFC9171" class="xref">RFC9171</a>]</span>. BPSec defines 
         BP extension blocks to carry security information produced under the
         auspices of some security context.<a href="#section-1-1" class="pilcrow">¶</a></p>
<p id="section-1-2">
         This document defines two security contexts (one for an integrity
         service and one for a confidentiality service) for populating 
         BPSec Block Integrity Blocks (BIBs) and Block Confidentiality Blocks 
         (BCBs). This document assumes familiarity with the concepts and 
         terminology associated with BP and BPSec, as these security 
         contexts are used with BPSec security blocks and other BP blocks 
         carried within BP bundles.<a href="#section-1-2" class="pilcrow">¶</a></p>
<p id="section-1-3">
         These contexts generate information that <span class="bcp14">MUST</span> be encoded using
         the Concise Binary Object Representation (CBOR) specification documented in <span>[<a href="#RFC8949" class="xref">RFC8949</a>]</span>.<a href="#section-1-3" class="pilcrow">¶</a></p>
</section>
</div>
<div id="term">
<section id="section-2">
      <h2 id="name-requirements-language">
<a href="#section-2" class="section-number selfRef">2. </a><a href="#name-requirements-language" class="section-name selfRef">Requirements Language</a>
      </h2>
<p id="section-2-1">
    The key words "<span class="bcp14">MUST</span>", "<span class="bcp14">MUST NOT</span>", "<span class="bcp14">REQUIRED</span>", "<span class="bcp14">SHALL</span>", "<span class="bcp14">SHALL NOT</span>", "<span class="bcp14">SHOULD</span>", "<span class="bcp14">SHOULD NOT</span>", "<span class="bcp14">RECOMMENDED</span>", "<span class="bcp14">NOT RECOMMENDED</span>",
    "<span class="bcp14">MAY</span>", and "<span class="bcp14">OPTIONAL</span>" in this document are to be interpreted as
    described in BCP 14 <span>[<a href="#RFC2119" class="xref">RFC2119</a>]</span> <span>[<a href="#RFC8174" class="xref">RFC8174</a>]</span> 
    when, and only when, they appear in all capitals, as shown here.<a href="#section-2-1" class="pilcrow">¶</a></p>
</section>
</div>
<div id="first-context">
<section id="section-3">
      <h2 id="name-integrity-security-context-">
<a href="#section-3" class="section-number selfRef">3. </a><a href="#name-integrity-security-context-" class="section-name selfRef">Integrity Security Context BIB-HMAC-SHA2</a>
      </h2>
<section id="section-3.1">
        <h3 id="name-overview">
<a href="#section-3.1" class="section-number selfRef">3.1. </a><a href="#name-overview" class="section-name selfRef">Overview</a>
        </h3>
<p id="section-3.1-1">
            The BIB-HMAC-SHA2 security context provides a keyed-hash 
            Message Authentication Code (MAC) over a 
            set of plaintext information. This context uses the Secure 
            Hash Algorithm 2 (SHA-2) discussed in <span>[<a href="#SHS" class="xref">SHS</a>]</span> combined 
            with the Hashed Message Authentication Code (HMAC) keyed hash discussed in <span>[<a href="#RFC2104" class="xref">RFC2104</a>]</span>. The combination 
            of HMAC and SHA-2 as the integrity mechanism for this security
            context was selected for two reasons:<a href="#section-3.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.1-2">
<li id="section-3.1-2.1"> The use of symmetric keys allows this security context to
                be used in places where an asymmetric-key infrastructure (such as a 
                public key infrastructure) might be impractical.<a href="#section-3.1-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-3.1-2.2">
                The combination HMAC-SHA2 represents a well-supported and well-understood
                integrity mechanism with multiple implementations available.<a href="#section-3.1-2.2" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-3.1-3">
            BIB-HMAC-SHA2 supports three variants of HMAC-SHA, based on 
            the supported length of the SHA-2 hash value.  These variants 
            correspond to HMAC 256/256, HMAC 384/384, and HMAC 512/512 as 
            defined in Table 7 ("HMAC Algorithm Values") of <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>. 
            The selection of which variant is used by this context is 
            provided as a security context parameter.<a href="#section-3.1-3" class="pilcrow">¶</a></p>
<p id="section-3.1-4">
            The output of the HMAC <span class="bcp14">MUST</span> be equal to the size of the SHA2 
            hashing function: 256 bits for SHA-256, 384 bits for SHA-384, and 
            512 bits for SHA-512.<a href="#section-3.1-4" class="pilcrow">¶</a></p>
<p id="section-3.1-5">
            The BIB-HMAC-SHA2 security context <span class="bcp14">MUST</span> have the security context 
            identifier specified in <a href="#sc_ids" class="xref">Section 5.1</a>.<a href="#section-3.1-5" class="pilcrow">¶</a></p>
</section>
<section id="section-3.2">
        <h3 id="name-scope">
<a href="#section-3.2" class="section-number selfRef">3.2. </a><a href="#name-scope" class="section-name selfRef">Scope</a>
        </h3>
<p id="section-3.2-1">
          The scope of BIB-HMAC-SHA2 is the set of information used
          to produce the plaintext over which a keyed hash is calculated. This
          plaintext is termed the "Integrity-Protected Plaintext (IPPT)". The
          content of the IPPT is constructed as the concatenation of information
          whose integrity is being preserved from the BIB-HMAC-SHA2 security 
          source to its security acceptor. There are five types of information 
          that can be used in the generation of the IPPT, based on 
          how broadly the concept of integrity is being applied. These
          five types of information, whether they are required, and why
          they are important for integrity are discussed as follows.<a href="#section-3.2-1" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-3.2-2">
          <dt id="section-3.2-2.1">Security target contents</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.2"> 
              The contents of the block-type-specific data field of the security 
              target <span class="bcp14">MUST</span> be included in the IPPT. Including this information protects
              the security target data and is considered the minimal, required
              set of information for an integrity service on the security
              target.<a href="#section-3.2-2.2" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.3">IPPT scope</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.4"> 
              The determination of which optional types of information were
              used when constructing the IPPT <span class="bcp14">MUST</span> always be included
              in the IPPT. Including this information ensures that the scope 
              of the IPPT construction at a security source matches the scope of
              the IPPT construction at security verifiers and security acceptors.<a href="#section-3.2-2.4" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.5">Primary block</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.6">
            <p id="section-3.2-2.6.1"> 
              The primary block identifies a bundle, and once 
              created, the contents of this block are immutable. Changes to 
              the primary block associated with the security target indicate
              that the security target (and BIB) might no longer be in the
              correct bundle.<a href="#section-3.2-2.6.1" class="pilcrow">¶</a></p>
<p id="section-3.2-2.6.2"> 
              For example, if a security target and associated BIB are copied
              from one bundle to another bundle, the BIB might still contain a
              verifiable signature for the security target unless information
              associated with the bundle primary block is included in the
              keyed hash carried by the BIB.<a href="#section-3.2-2.6.2" class="pilcrow">¶</a></p>
<p id="section-3.2-2.6.3"> 
              Including this information in the IPPT protects the integrity 
              of the association of the security target with a specific bundle.<a href="#section-3.2-2.6.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.7">Other fields of the security target</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.8">
            <p id="section-3.2-2.8.1"> 
              The other fields of the security target include block 
              identification and processing information. Changing this 
              information changes how the security target is treated by nodes 
              in the network even when the
              "user data" of the security target are otherwise unchanged.<a href="#section-3.2-2.8.1" class="pilcrow">¶</a></p>
<p id="section-3.2-2.8.2"> 
              For example, if the block processing control flags of a security 
              target are different at a security verifier than they were 
              originally set at the security source, then the policy for
              handling the security target has been modified.<a href="#section-3.2-2.8.2" class="pilcrow">¶</a></p>
<p id="section-3.2-2.8.3"> 
              Including this information in the IPPT protects the integrity
              of the policy and identification of the security target data.<a href="#section-3.2-2.8.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-3.2-2.9">Other fields of the BIB</dt>
          <dd style="margin-left: 1.5em" id="section-3.2-2.10">
            <p id="section-3.2-2.10.1"> 
              The other fields of the BIB include block identification 
              and processing information. 
              Changing this information changes how the BIB
              is treated by nodes in the network, even when other aspects of the
              BIB are unchanged.<a href="#section-3.2-2.10.1" class="pilcrow">¶</a></p>
<p id="section-3.2-2.10.2"> 
              For example, if the block processing control flags of the BIB are 
              different at a security verifier than they were 
              originally set at the security source, then the policy for
              handling the BIB has been modified.<a href="#section-3.2-2.10.2" class="pilcrow">¶</a></p>
<p id="section-3.2-2.10.3"> 
              Including this information in the IPPT protects the integrity
              of the policy and identification of the security service in the bundle.<a href="#section-3.2-2.10.3" class="pilcrow">¶</a></p>
<aside id="section-3.2-2.10.4">
              <p id="section-3.2-2.10.4.1"> 
              NOTE: The security context identifier and security context
              parameters of the security block are not included in the IPPT
              because these parameters, by definition, are required to verify or 
              accept the security service. Successful verification at security
              verifiers and security acceptors implies that these parameters
              were unchanged since being specified at the security source.
              This is the case because keys cannot be reused across security
              contexts and because the integrity scope flags used to define
              the IPPT are included in the IPPT itself.<a href="#section-3.2-2.10.4.1" class="pilcrow">¶</a></p>
</aside>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-3.2-3">
          The scope of the BIB-HMAC-SHA2 security context is configured using
          an optional security context parameter.<a href="#section-3.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-3.3">
        <h3 id="name-parameters">
<a href="#section-3.3" class="section-number selfRef">3.3. </a><a href="#name-parameters" class="section-name selfRef">Parameters</a>
        </h3>
<p id="section-3.3-1">
          BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants, 
          communicate key information, and define the scope of the IPPT.<a href="#section-3.3-1" class="pilcrow">¶</a></p>
<section id="section-3.3.1">
          <h4 id="name-sha-variant">
<a href="#section-3.3.1" class="section-number selfRef">3.3.1. </a><a href="#name-sha-variant" class="section-name selfRef">SHA Variant</a>
          </h4>
<p id="section-3.3.1-1">
            This optional parameter identifies which variant of the SHA-2 
            algorithm is to be used in the generation of the authentication code.<a href="#section-3.3.1-1" class="pilcrow">¶</a></p>
<p id="section-3.3.1-2">
            This value <span class="bcp14">MUST</span> be encoded as a CBOR unsigned integer.<a href="#section-3.3.1-2" class="pilcrow">¶</a></p>
<p id="section-3.3.1-3">
            Valid values for this parameter are as follows.<a href="#section-3.3.1-3" class="pilcrow">¶</a></p>
<span id="name-sha-variant-parameter-value"></span><div id="sha_var">
<table class="center" id="table-1">
            <caption>
<a href="#table-1" class="selfRef">Table 1</a>:
<a href="#name-sha-variant-parameter-value" class="selfRef">SHA Variant Parameter Values</a>
            </caption>
<thead>
              <tr>
                <th class="text-center" rowspan="1" colspan="1">Value</th>
                <th class="text-center" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">5</td>
                <td class="text-left" rowspan="1" colspan="1">HMAC 256/256 as defined in Table 7 ("HMAC Algorithm Values") of <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">6</td>
                <td class="text-left" rowspan="1" colspan="1">HMAC 384/384 as defined in Table 7 ("HMAC Algorithm Values") of <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">7</td>
                <td class="text-left" rowspan="1" colspan="1">HMAC 512/512 as defined in Table 7 ("HMAC Algorithm Values") of <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>
</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-3.3.1-5">
            When not provided, implementations <span class="bcp14">SHOULD</span> assume a value of 6
            (indicating use of HMAC 384/384), unless an alternate default is 
            established by local security policy at the security source, verifiers,
            or acceptor of this integrity service.<a href="#section-3.3.1-5" class="pilcrow">¶</a></p>
</section>
<section id="section-3.3.2">
          <h4 id="name-wrapped-key">
<a href="#section-3.3.2" class="section-number selfRef">3.3.2. </a><a href="#name-wrapped-key" class="section-name selfRef">Wrapped Key</a>
          </h4>
<p id="section-3.3.2-1">        
     This optional parameter contains the output of the AES key wrap function as defined in <span>[<a href="#RFC3394" class="xref">RFC3394</a>]</span>.  Specifically, this parameter holds the ciphertext produced when running this key wrap algorithm with the
     input string being the symmetric HMAC 
            key used to generate the security results present in the security block. 
            The value of this parameter is used as input to the AES key wrap authenticated
            decryption function at security verifiers and security acceptors to determine 
            the symmetric HMAC key needed for the proper validation of the security results 
            in the security block.<a href="#section-3.3.2-1" class="pilcrow">¶</a></p>
<p id="section-3.3.2-2">
            This value <span class="bcp14">MUST</span> be encoded as a CBOR byte string.<a href="#section-3.3.2-2" class="pilcrow">¶</a></p>
<p id="section-3.3.2-3">
            If this parameter is not present, then security verifiers 
            and acceptors <span class="bcp14">MUST</span> determine the proper key as a function of their local BPSec policy 
            and configuration.<a href="#section-3.3.2-3" class="pilcrow">¶</a></p>
</section>
<section id="section-3.3.3">
          <h4 id="name-integrity-scope-flags">
<a href="#section-3.3.3" class="section-number selfRef">3.3.3. </a><a href="#name-integrity-scope-flags" class="section-name selfRef">Integrity Scope Flags</a>
          </h4>
<p id="section-3.3.3-1">
            This optional parameter contains a series of flags that describe
            what information is to be included with the block-type-specific data 
            when constructing the IPPT value.<a href="#section-3.3.3-1" class="pilcrow">¶</a></p>
<p id="section-3.3.3-2">
            This value <span class="bcp14">MUST</span> be represented as a CBOR unsigned
            integer, the value of which <span class="bcp14">MUST</span> be processed as a 16-bit field.                           
            The maximum value of this field, as a CBOR unsigned integer, <span class="bcp14">MUST</span> be
            65535.<a href="#section-3.3.3-2" class="pilcrow">¶</a></p>
<p id="section-3.3.3-3">When not provided, implementations <span class="bcp14">SHOULD</span> assume a value of 7 (indicating all assigned fields), unless an alternate default is established by local security policy at the security source,  verifier, or acceptor of this integrity service.<a href="#section-3.3.3-3" class="pilcrow">¶</a></p>
<p id="section-3.3.3-4">
            Implementations <span class="bcp14">MUST</span> set reserved and unassigned bits in this 
            field to 0 when constructing these flags at a security source. 
            Once set, the value of this field <span class="bcp14">MUST NOT</span> be altered until the
            security service is completed at the security acceptor in the
            network and removed from the bundle.<a href="#section-3.3.3-4" class="pilcrow">¶</a></p>
<p id="section-3.3.3-5">
            Bits in this field represent additional information to be included
            when generating an integrity signature over the security target.
            These bits are defined as follows.<a href="#section-3.3.3-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-3.3.3-6">
            <dt id="section-3.3.3-6.1">Bit 0 (the low-order bit, 0x0001):</dt>
            <dd style="margin-left: 1.5em" id="section-3.3.3-6.2">Include primary block flag<a href="#section-3.3.3-6.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.3.3-6.3">Bit 1 (0x0002):</dt>
            <dd style="margin-left: 1.5em" id="section-3.3.3-6.4">Include target header flag<a href="#section-3.3.3-6.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.3.3-6.5">Bit 2 (0x0004):</dt>
            <dd style="margin-left: 1.5em" id="section-3.3.3-6.6">Include security header flag<a href="#section-3.3.3-6.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.3.3-6.7">Bits 3-7:</dt>
            <dd style="margin-left: 1.5em" id="section-3.3.3-6.8">Reserved<a href="#section-3.3.3-6.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-3.3.3-6.9">Bits 8-15:</dt>
            <dd style="margin-left: 1.5em" id="section-3.3.3-6.10">Unassigned<a href="#section-3.3.3-6.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
<section id="section-3.3.4">
          <h4 id="name-enumerations">
<a href="#section-3.3.4" class="section-number selfRef">3.3.4. </a><a href="#name-enumerations" class="section-name selfRef">Enumerations</a>
          </h4>
<p id="section-3.3.4-1">
            The BIB-HMAC-SHA2 security context parameters are listed in 
            <a href="#bib_parm_table" class="xref">Table 2</a>. In this table, the "Parm Id" column 
            refers to the expected parameter identifier described in Section
             <span><a href="https://www.rfc-editor.org/rfc/rfc9172#section-3.10" class="relref">3.10</a> (<a href="https://www.rfc-editor.org/rfc/rfc9172#section-3.10" class="relref">"Parameter 
             and Result Identification"</a>)</span> of <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>.<a href="#section-3.3.4-1" class="pilcrow">¶</a></p>
<p id="section-3.3.4-2">
            An empty "Default Value" column  indicates that the
            security context parameter does not have a default value.<a href="#section-3.3.4-2" class="pilcrow">¶</a></p>
<span id="name-bib-hmac-sha2-security-cont"></span><div id="bib_parm_table">
<table class="center" id="table-2">
            <caption>
<a href="#table-2" class="selfRef">Table 2</a>:
<a href="#name-bib-hmac-sha2-security-cont" class="selfRef">BIB-HMAC-SHA2 Security Context Parameters</a>
            </caption>
<thead>
              <tr>
                <th class="text-center" rowspan="1" colspan="1">Parm Id</th>
                <th class="text-left" rowspan="1" colspan="1">Parm Name</th>
                <th class="text-left" rowspan="1" colspan="1">CBOR Encoding Type</th>
                <th class="text-left" rowspan="1" colspan="1">Default Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">SHA Variant</td>
                <td class="text-left" rowspan="1" colspan="1">unsigned integer</td>
                <td class="text-center" rowspan="1" colspan="1">6</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">2</td>
                <td class="text-left" rowspan="1" colspan="1">Wrapped Key</td>
                <td class="text-left" rowspan="1" colspan="1">byte string</td>
                <td class="text-center" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">3</td>
                <td class="text-left" rowspan="1" colspan="1">Integrity Scope Flags</td>
                <td class="text-left" rowspan="1" colspan="1">unsigned integer</td>
                <td class="text-center" rowspan="1" colspan="1">7</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</section>
<div id="bib_results">
<section id="section-3.4">
        <h3 id="name-results">
<a href="#section-3.4" class="section-number selfRef">3.4. </a><a href="#name-results" class="section-name selfRef">Results</a>
        </h3>
<p id="section-3.4-1">            
            The BIB-HMAC-SHA2 security context results are listed in 
            <a href="#bib_res_table" class="xref">Table 3</a>. In this table, the "Result Id" column 
            refers to the expected result identifier described in Section
             <span><a href="https://www.rfc-editor.org/rfc/rfc9172#section-3.10" class="relref">3.10</a> (<a href="https://www.rfc-editor.org/rfc/rfc9172#section-3.10" class="relref">"Parameter 
             and Result Identification"</a>)</span> of <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>.<a href="#section-3.4-1" class="pilcrow">¶</a></p>
<span id="name-bib-hmac-sha2-security-resu"></span><div id="bib_res_table">
<table class="center" id="table-3">
          <caption>
<a href="#table-3" class="selfRef">Table 3</a>:
<a href="#name-bib-hmac-sha2-security-resu" class="selfRef">BIB-HMAC-SHA2 Security Results</a>
          </caption>
<thead>
            <tr>
              <th class="text-center" rowspan="1" colspan="1">Result Id</th>
              <th class="text-center" rowspan="1" colspan="1">Result Name</th>
              <th class="text-center" rowspan="1" colspan="1">CBOR Encoding Type</th>
              <th class="text-center" rowspan="1" colspan="1">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1</td>
              <td class="text-center" rowspan="1" colspan="1">Expected HMAC</td>
              <td class="text-center" rowspan="1" colspan="1">byte string</td>
              <td class="text-left" rowspan="1" colspan="1">The output of the HMAC calculation at the security source.</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<div id="bib_key_mgmt">
<section id="section-3.5">
        <h3 id="name-key-considerations">
<a href="#section-3.5" class="section-number selfRef">3.5. </a><a href="#name-key-considerations" class="section-name selfRef">Key Considerations</a>
        </h3>
<p id="section-3.5-1">
          HMAC keys used with this context <span class="bcp14">MUST</span> be symmetric and <span class="bcp14">MUST</span> have 
          a key length equal to the output of the HMAC. For this reason, HMAC 
          key lengths will be integers divisible by 8 bytes, and special padding-aware 
          AES key wrap algorithms are not needed.<a href="#section-3.5-1" class="pilcrow">¶</a></p>
<p id="section-3.5-2">
          It is assumed that any security verifier or security acceptor
          performing an integrity verification can determine the proper HMAC
          key to be used. Potential sources of the HMAC key include (but are
          not limited to) the following:<a href="#section-3.5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.5-3.1"> Pre-placed keys selected based on local policy.<a href="#section-3.5-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-3.2"> Keys extracted from material carried in the BIB.<a href="#section-3.5-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-3.5-3.3"> Session keys negotiated via a mechanism external to the BIB.<a href="#section-3.5-3.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-3.5-4">
          When an AES Key Wrap (AES-KW) <span>[<a href="#RFC3394" class="xref">RFC3394</a>]</span> wrapped key is present in a security block, it is
          assumed that security verifiers and security acceptors can
          independently determine the key encryption key (KEK) used in the
          wrapping of the symmetric HMAC key.<a href="#section-3.5-4" class="pilcrow">¶</a></p>
<p id="section-3.5-5">
          As discussed in <a href="#SecCons" class="xref">Section 6</a> and emphasized here, it is
          strongly recommended that keys be protected once generated, both
          when they are stored and when they are transmitted.<a href="#section-3.5-5" class="pilcrow">¶</a></p>
</section>
</div>
<section id="section-3.6">
        <h3 id="name-security-processing-conside">
<a href="#section-3.6" class="section-number selfRef">3.6. </a><a href="#name-security-processing-conside" class="section-name selfRef">Security Processing Considerations</a>
        </h3>
<p id="section-3.6-1">
          An HMAC calculated over the same IPPT with the same key will always
          have the same value.  This regularity can lead to practical
          side-channel attacks whereby an attacker could produce known
          plaintext, guess at an HMAC tag, and observe the behavior of a
          verifier.  With a modest number of trials, a side-channel attack
          could produce an HMAC tag for attacker-provided plaintext without
          the attacker ever knowing the HMAC key.<a href="#section-3.6-1" class="pilcrow">¶</a></p>
<p id="section-3.6-2">
          A common method of observing the behavior of a verifier is precise
          analysis of the timing associated with comparisons. Therefore, one
          way to prevent behavior analysis of this type is to ensure that 
          any comparisons of the supplied and expected authentication tag occur
          in constant time.<a href="#section-3.6-2" class="pilcrow">¶</a></p>
<p id="section-3.6-3">
          A constant-time comparison function <span class="bcp14">SHOULD</span> be used for the comparison
          of authentication tags by any implementation of this security context.
          In cases where such a function is difficult or impossible to use,
          the impact of side-channel attacks (in general) and timing attacks (specifically)
          need to be considered as part of the implementation.<a href="#section-3.6-3" class="pilcrow">¶</a></p>
</section>
<div id="bib_canon">
<section id="section-3.7">
        <h3 id="name-canonicalization-algorithms">
<a href="#section-3.7" class="section-number selfRef">3.7. </a><a href="#name-canonicalization-algorithms" class="section-name selfRef">Canonicalization Algorithms</a>
        </h3>
<p id="section-3.7-1">
          This section defines the canonicalization algorithm used to prepare
          the IPPT input to the BIB-HMAC-SHA2 integrity mechanism. The
          construction of the IPPT depends on the settings of the
          integrity scope flags that can be provided as part of customizing
          the behavior of this security context.<a href="#section-3.7-1" class="pilcrow">¶</a></p>
<p id="section-3.7-2">
          In all cases, the canonical form of any portion of an extension block
          <span class="bcp14">MUST</span> be created as described in <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>.
          The canonicalization algorithms defined in <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>  
          adhere to the canonical forms for extension blocks defined in 
          <span>[<a href="#RFC9171" class="xref">RFC9171</a>]</span> but resolve ambiguities related to
          how values are represented in CBOR.<a href="#section-3.7-2" class="pilcrow">¶</a></p>
<p id="section-3.7-3">
          The IPPT is constructed using the following process. While integrity 
          scope flags might not be included in the BIB representing the 
          security operation, they <span class="bcp14">MUST</span> be included in the IPPT value itself.<a href="#section-3.7-3" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-3.7-4">
<li id="section-3.7-4.1">
              The canonical form of the IPPT starts as the CBOR encoding of the 
              integrity scope flags in which all unset flags, reserved bits, 
              and unassigned bits have been set to 0.  For example, if the
              primary block flag, target header flag, and security header flag are 
              each set, then the initial value of the canonical form of the
              IPPT will be 0x07.<a href="#section-3.7-4.1" class="pilcrow">¶</a>
</li>
          <li id="section-3.7-4.2">
If the primary block flag of the integrity scope flags is set to 1 and the
security target is not the bundle's primary block, then a canonical form of
the bundle's primary block <span class="bcp14">MUST</span> be calculated and the result
appended to the IPPT.<a href="#section-3.7-4.2" class="pilcrow">¶</a>
</li>
          <li id="section-3.7-4.3">
If the target header flag of the integrity scope flags is set to 1 and the
security target is not the bundle's primary block, then the canonical form of
the block type code, block number, and block processing control flags
associated with the security target <span class="bcp14">MUST</span> be calculated and, in
that order, appended to the IPPT.<a href="#section-3.7-4.3" class="pilcrow">¶</a>
</li>
          <li id="section-3.7-4.4">
              If the security header flag of the integrity scope flags is set
              to 1, then the canonical form of the block type code, 
              block number, and block processing control flags associated with 
              the BIB <span class="bcp14">MUST</span> be calculated and, in that order, appended to the IPPT.<a href="#section-3.7-4.4" class="pilcrow">¶</a>
</li>
          <li id="section-3.7-4.5">
The canonical form of the security target <span class="bcp14">MUST</span> be calculated
and appended to the IPPT. If the security target is the primary block, this is
the canonical form of the primary block. Otherwise, this is the canonical form
of the block-type-specific data of the security target.<a href="#section-3.7-4.5" class="pilcrow">¶</a>
</li>
        </ol>
<aside id="section-3.7-5">
          <p id="section-3.7-5.1">NOTE: When the security target is the bundle's primary block, the
   canonicalization steps associated with the primary block flag and
   the target header flag are skipped. Skipping primary block flag
   processing, in this case, avoids adding the bundle's primary block
   twice in the IPPT calculation. Skipping target header flag
   processing, in this case, is necessary because the primary block of
   a bundle does not have the expected elements of a block header such
   as block number and block processing control flags.<a href="#section-3.7-5.1" class="pilcrow">¶</a></p>
</aside>
</section>
</div>
<section id="section-3.8">
        <h3 id="name-processing">
<a href="#section-3.8" class="section-number selfRef">3.8. </a><a href="#name-processing" class="section-name selfRef">Processing</a>
        </h3>
<section id="section-3.8.1">
          <h4 id="name-keyed-hash-generation">
<a href="#section-3.8.1" class="section-number selfRef">3.8.1. </a><a href="#name-keyed-hash-generation" class="section-name selfRef">Keyed Hash Generation</a>
          </h4>
<p id="section-3.8.1-1">
            During keyed hash generation, two inputs are prepared for
            the appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT.
            These data items <span class="bcp14">MUST</span> be generated as follows.<a href="#section-3.8.1-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.8.1-2.1">
                The HMAC key <span class="bcp14">MUST</span> have the appropriate length
                as required by local security policy.  The key can be
                generated specifically for this integrity service, given as
                part of local security policy, or obtained through some other
                key management mechanism as discussed in <a href="#bib_key_mgmt" class="xref">Section 3.5</a>.<a href="#section-3.8.1-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.8.1-2.2">
                Prior to the generation of the IPPT, if a Cyclic Redundancy Check (CRC) value is present
                for the target block of the BIB, then that CRC value <span class="bcp14">MUST</span> be
                removed from the target block. This involves both removing the
                CRC value from the target block and setting the CRC type field
                of the target block to "no CRC is present."<a href="#section-3.8.1-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.8.1-2.3">
                Once CRC information is removed, the IPPT <span class="bcp14">MUST</span> be generated as 
                discussed in <a href="#bib_canon" class="xref">Section 3.7</a>.<a href="#section-3.8.1-2.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.8.1-3">
            Upon successful hash generation, the following action <span class="bcp14">MUST</span> occur.<a href="#section-3.8.1-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.8.1-4.1">
                The keyed hash produced by the HMAC/SHA2 variant <span class="bcp14">MUST</span> be added 
                as a security result for the BIB representing the security
                operation on this security target, as discussed
                in <a href="#bib_results" class="xref">Section 3.4</a>.<a href="#section-3.8.1-4.1" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.8.1-5">
            Finally, the BIB containing information about this security operation
            <span class="bcp14">MUST</span> be updated as follows. These operations can occur in any order.<a href="#section-3.8.1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.8.1-6.1">
                The security context identifier for the BIB <span class="bcp14">MUST</span> be set to the context
                identifier for BIB-HMAC-SHA2.<a href="#section-3.8.1-6.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.8.1-6.2">
                Any local flags used to generate the IPPT <span class="bcp14">MUST</span> be placed in
                the integrity scope flags security context parameter for the BIB unless
                these flags are expected to be correctly configured at security
                verifiers and acceptors in the network.<a href="#section-3.8.1-6.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.8.1-6.3">
                The HMAC key <span class="bcp14">MAY</span> be included as a security context parameter, in which case
                it <span class="bcp14">MUST</span> be wrapped using the AES key wrap function as defined in <span>[<a href="#RFC3394" class="xref">RFC3394</a>]</span> and
                the results of the wrapping added as the wrapped key 
                security context parameter for the BIB.<a href="#section-3.8.1-6.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.8.1-6.4">
                The SHA variant used by this security context <span class="bcp14">SHOULD</span> be added as
                the SHA variant security context parameter for the BIB if it differs from 
                the default key length. Otherwise, this parameter <span class="bcp14">MAY</span> be
                omitted if doing so provides a useful reduction in message sizes.<a href="#section-3.8.1-6.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.8.1-7">
            Problems encountered in the keyed hash generation <span class="bcp14">MUST</span> be 
            processed in accordance with local BPSec security policy.<a href="#section-3.8.1-7" class="pilcrow">¶</a></p>
</section>
<section id="section-3.8.2">
          <h4 id="name-keyed-hash-verification">
<a href="#section-3.8.2" class="section-number selfRef">3.8.2. </a><a href="#name-keyed-hash-verification" class="section-name selfRef">Keyed Hash Verification</a>
          </h4>
<p id="section-3.8.2-1">
            During keyed hash verification, the input of the security target 
            and an HMAC key are provided to the appropriate HMAC/SHA2 algorithm.<a href="#section-3.8.2-1" class="pilcrow">¶</a></p>
<p id="section-3.8.2-2">
            During keyed hash verification, two inputs are prepared for 
            the appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT.
            These data items <span class="bcp14">MUST</span> be generated as follows.<a href="#section-3.8.2-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-3.8.2-3.1">
                The HMAC key <span class="bcp14">MUST</span> be derived using the wrapped key 
                security context parameter if such a parameter is included in the
                security context parameters of the BIB. Otherwise, this key
                <span class="bcp14">MUST</span> be derived in accordance with security policy at the
                verifying node as discussed in <a href="#bib_key_mgmt" class="xref">Section 3.5</a>.<a href="#section-3.8.2-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-3.8.2-3.2">
                The IPPT <span class="bcp14">MUST</span> be generated as discussed in <a href="#bib_canon" class="xref">Section 3.7</a> 
                with the value of integrity scope flags being taken from the 
                integrity scope flags security context parameter. If the 
                integrity scope flags parameter is not included in the 
                security context parameters, then these flags <span class="bcp14">MAY</span> be derived 
                from local security policy.<a href="#section-3.8.2-3.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-3.8.2-4"> 
            The calculated HMAC output <span class="bcp14">MUST</span> be compared to the expected HMAC
            output encoded in the security results of the BIB for the security
            target. If the calculated HMAC and expected HMAC are
            identical, the verification <span class="bcp14">MUST</span> be considered a success. Otherwise,
            the verification <span class="bcp14">MUST</span> be considered a failure.<a href="#section-3.8.2-4" class="pilcrow">¶</a></p>
<p id="section-3.8.2-5">
            If the verification fails or otherwise experiences an error or if any 
            needed parameters are missing, then
            the verification <span class="bcp14">MUST</span> be treated as failed and processed in accordance 
            with local security policy.<a href="#section-3.8.2-5" class="pilcrow">¶</a></p>
<p id="section-3.8.2-6">
            This security service is removed from the bundle at the
            security acceptor as required by the BPSec specification <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>. If the
            security acceptor is not the bundle destination and if no other
            integrity service is being applied to the target block, then a
            CRC <span class="bcp14">MUST</span> be included for the target block. The CRC type, as determined
            by policy, is set in the target block's CRC type field, and the 
            corresponding CRC value is added as the CRC field for that block.<a href="#section-3.8.2-6" class="pilcrow">¶</a></p>
</section>
</section>
</section>
</div>
<div id="second-context">
<section id="section-4">
      <h2 id="name-security-context-bcb-aes-gc">
<a href="#section-4" class="section-number selfRef">4. </a><a href="#name-security-context-bcb-aes-gc" class="section-name selfRef">Security Context BCB-AES-GCM</a>
      </h2>
<section id="section-4.1">
        <h3 id="name-overview-2">
<a href="#section-4.1" class="section-number selfRef">4.1. </a><a href="#name-overview-2" class="section-name selfRef">Overview</a>
        </h3>
<p id="section-4.1-1">
          The BCB-AES-GCM security context replaces the block-type-specific data 
          field of its security target with ciphertext generated using the 
          Advanced Encryption Standard (AES) cipher operating in Galois/Counter Mode
          (GCM) <span>[<a href="#AES-GCM" class="xref">AES-GCM</a>]</span>. The use of AES-GCM was selected
          as the cipher suite for this confidentiality mechanism for several reasons:<a href="#section-4.1-1" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4.1-2">
<li id="section-4.1-2.1"> The selection of a symmetric-key cipher suite allows for relatively smaller
              keys than asymmetric-key cipher suites.<a href="#section-4.1-2.1" class="pilcrow">¶</a>
</li>
          <li id="section-4.1-2.2"> The selection of a symmetric-key cipher suite allows this security context to
              be used in places where an asymmetric-key infrastructure (such as a public key
              infrastructure) might be impractical.<a href="#section-4.1-2.2" class="pilcrow">¶</a>
</li>
          <li id="section-4.1-2.3">
              The use of the Galois/Counter Mode produces ciphertext with the same size as
              the plaintext making the replacement of target block information easier as 
              length fields do not need to be changed.<a href="#section-4.1-2.3" class="pilcrow">¶</a>
</li>
          <li id="section-4.1-2.4">
              The AES-GCM cipher suite provides authenticated encryption, as required by the
              BPSec protocol.<a href="#section-4.1-2.4" class="pilcrow">¶</a>
</li>
        </ol>
<p id="section-4.1-3">
          Additionally, the BCB-AES-GCM security context generates an
          authentication tag based on the plaintext value of the block-type-specific
          data and other additional authenticated data (AAD) that might be specified
          via parameters to this security context.<a href="#section-4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.1-4">
          This security context supports two variants of AES-GCM, based on 
          the supported length of the symmetric key.  These variants 
          correspond to A128GCM and A256GCM as
          defined in Table 9 ("Algorithm Value for AES-GCM") of <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>.<a href="#section-4.1-4" class="pilcrow">¶</a></p>
<p id="section-4.1-5">
          The BCB-AES-GCM security context <span class="bcp14">MUST</span> have the security context identifier 
          specified in <a href="#sc_ids" class="xref">Section 5.1</a>.<a href="#section-4.1-5" class="pilcrow">¶</a></p>
</section>
<section id="section-4.2">
        <h3 id="name-scope-2">
<a href="#section-4.2" class="section-number selfRef">4.2. </a><a href="#name-scope-2" class="section-name selfRef">Scope</a>
        </h3>
<p id="section-4.2-1">
          There are two scopes associated with BCB-AES-GCM: the scope of the 
          confidentiality service and the scope of the authentication
          service. The first defines the set of information provided to the 
          AES-GCM cipher for the purpose of producing ciphertext. The second
          defines the set of information used to generate an authentication tag.<a href="#section-4.2-1" class="pilcrow">¶</a></p>
<p id="section-4.2-2">
          The scope of the confidentiality service defines the set of information
          provided to the AES-GCM cipher for the purpose of producing ciphertext.
          This <span class="bcp14">MUST</span> be the full set of plaintext contained in the 
          block-type-specific data field of the security target.<a href="#section-4.2-2" class="pilcrow">¶</a></p>
<p id="section-4.2-3">
          The scope of the authentication service defines the set of information
          used to generate an authentication tag carried with the security
          block. This information contains all data protected by the
          confidentiality service and the scope flags used to identify other
          optional information; it <span class="bcp14">MAY</span> include other information 
          (additional authenticated data), as follows.<a href="#section-4.2-3" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlNewline" id="section-4.2-4">
          <dt id="section-4.2-4.1">Primary block</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-4.2">
            <p id="section-4.2-4.2.1"> 
              The primary block identifies a bundle, and once 
              created, the contents of this block are immutable. Changes to 
              the primary block associated with the security target indicate
              that the security target (and BCB) might no longer be in the
              correct bundle.<a href="#section-4.2-4.2.1" class="pilcrow">¶</a></p>
<p id="section-4.2-4.2.2"> 
              For example, if a security target and associated BCB are copied
              from one bundle to another bundle, the BCB might still be able to
              decrypt the security target even though these blocks were never
              intended to exist in the copied-to bundle.<a href="#section-4.2-4.2.2" class="pilcrow">¶</a></p>
<p id="section-4.2-4.2.3"> 
              Including this information as part of additional authenticated data
              ensures that the security target (and security block) appear in the
              same bundle at the time of decryption as at the time of encryption.<a href="#section-4.2-4.2.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-4.3">Other fields of the security target</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-4.4">
            <p id="section-4.2-4.4.1"> 
              The other fields of the security target include block 
              identification and processing information. Changing this 
              information changes how the security target is treated by nodes 
              in the network even when the "user data" of the security target 
              are otherwise unchanged.<a href="#section-4.2-4.4.1" class="pilcrow">¶</a></p>
<p id="section-4.2-4.4.2"> 
              For example, if the block processing control flags of a security 
              target are different at a security verifier than they were 
              originally set at the security source, then the policy for
              handling the security target has been modified.<a href="#section-4.2-4.4.2" class="pilcrow">¶</a></p>
<p id="section-4.2-4.4.3"> 
              Including this information as part of additional authenticated data
              ensures that the ciphertext in the security target will not be used
              with a different set of block policy than originally set at the
              time of encryption.<a href="#section-4.2-4.4.3" class="pilcrow">¶</a></p>
</dd>
          <dd class="break"></dd>
<dt id="section-4.2-4.5">Other fields of the BCB</dt>
          <dd style="margin-left: 1.5em" id="section-4.2-4.6">
            <p id="section-4.2-4.6.1"> 
              The other fields of the BCB include block identification and 
              processing information. Changing this information changes how the BCB
              is treated by nodes in the network, even when other aspects of the
              BCB are unchanged.<a href="#section-4.2-4.6.1" class="pilcrow">¶</a></p>
<p id="section-4.2-4.6.2"> 
              For example, if the block processing control flags of the BCB are 
              different at a security acceptor than they were 
              originally set at the security source, then the policy for
              handling the BCB has been modified.<a href="#section-4.2-4.6.2" class="pilcrow">¶</a></p>
<p id="section-4.2-4.6.3"> 
              Including this information as part of additional authenticated data
              ensures that the policy and identification of the security service 
              in the bundle has not changed.<a href="#section-4.2-4.6.3" class="pilcrow">¶</a></p>
<aside id="section-4.2-4.6.4">
              <p id="section-4.2-4.6.4.1"> 
              NOTE: The security context identifier and security context
              parameters of the security block are not included as additional
              authenticated data because these parameters, by definition, are
              those needed to verify or accept the security service. Therefore,
              it is expected that changes to these values would result in failures
              at security verifiers and security acceptors. This is the case 
              because keys cannot be reused across security
              contexts and because the AAD scope flags used to identify
              the AAD are included in the AAD.<a href="#section-4.2-4.6.4.1" class="pilcrow">¶</a></p>
</aside>
</dd>
        <dd class="break"></dd>
</dl>
<p id="section-4.2-5">
          The scope of the BCB-AES-GCM security context is configured using
          an optional security context parameter.<a href="#section-4.2-5" class="pilcrow">¶</a></p>
</section>
<section id="section-4.3">
        <h3 id="name-parameters-2">
<a href="#section-4.3" class="section-number selfRef">4.3. </a><a href="#name-parameters-2" class="section-name selfRef">Parameters</a>
        </h3>
<p id="section-4.3-1">
          BCB-AES-GCM can be parameterized to specify the AES variant, 
          initialization vector, key information, and identify additional
          authenticated data.<a href="#section-4.3-1" class="pilcrow">¶</a></p>
<section id="section-4.3.1">
          <h4 id="name-initialization-vector-iv">
<a href="#section-4.3.1" class="section-number selfRef">4.3.1. </a><a href="#name-initialization-vector-iv" class="section-name selfRef">Initialization Vector (IV)</a>
          </h4>
<p id="section-4.3.1-1">
            This optional parameter identifies the initialization vector (IV) 
            used to initialize the AES-GCM cipher.<a href="#section-4.3.1-1" class="pilcrow">¶</a></p>
<p id="section-4.3.1-2">
            The length of the initialization vector, prior to any CBOR encoding,
            <span class="bcp14">MUST</span> be between 8-16 bytes. A value of 12 bytes <span class="bcp14">SHOULD</span> be used
            unless local security policy requires a different length.<a href="#section-4.3.1-2" class="pilcrow">¶</a></p>
<p id="section-4.3.1-3">
            This value <span class="bcp14">MUST</span> be encoded as a CBOR byte string.<a href="#section-4.3.1-3" class="pilcrow">¶</a></p>
<p id="section-4.3.1-4">
            The initialization vector can have any value, with the caveat that a 
            value <span class="bcp14">MUST NOT</span> be reused for multiple encryptions using the same 
            encryption key. This value <span class="bcp14">MAY</span> be reused when encrypting with different 
            keys. For example, if each encryption operation using BCB-AES-GCM
            uses a newly generated key, then the same IV can be reused.<a href="#section-4.3.1-4" class="pilcrow">¶</a></p>
</section>
<section id="section-4.3.2">
          <h4 id="name-aes-variant">
<a href="#section-4.3.2" class="section-number selfRef">4.3.2. </a><a href="#name-aes-variant" class="section-name selfRef">AES Variant</a>
          </h4>
<p id="section-4.3.2-1">
            This optional parameter identifies the AES variant being used for
            the AES-GCM encryption, where the variant is identified by the length
            of key used.<a href="#section-4.3.2-1" class="pilcrow">¶</a></p>
<p id="section-4.3.2-2">
            This value <span class="bcp14">MUST</span> be encoded as a CBOR unsigned integer.<a href="#section-4.3.2-2" class="pilcrow">¶</a></p>
<p id="section-4.3.2-3">
            Valid values for this parameter are as follows.<a href="#section-4.3.2-3" class="pilcrow">¶</a></p>
<span id="name-aes-variant-parameter-value"></span><table class="center" id="table-4">
            <caption>
<a href="#table-4" class="selfRef">Table 4</a>:
<a href="#name-aes-variant-parameter-value" class="selfRef">AES Variant Parameter Values</a>
            </caption>
<thead>
              <tr>
                <th class="text-center" rowspan="1" colspan="1">Value</th>
                <th class="text-center" rowspan="1" colspan="1">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">1</td>
                <td class="text-left" rowspan="1" colspan="1">A128GCM as defined in Table 9 ("Algorithm Value for AES-GCM") of <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>
</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">3</td>
                <td class="text-left" rowspan="1" colspan="1">A256GCM as defined in Table 9 ("Algorithm Value for AES-GCM") of <span>[<a href="#RFC8152" class="xref">RFC8152</a>]</span>
</td>
              </tr>
            </tbody>
          </table>
<p id="section-4.3.2-5">
            When not provided, implementations <span class="bcp14">SHOULD</span> assume a value of 3
            (indicating use of A256GCM), unless an alternate default is 
            established by local security policy at the security source, verifier,
            or acceptor of this integrity service.<a href="#section-4.3.2-5" class="pilcrow">¶</a></p>
<p id="section-4.3.2-6">
            Regardless of the variant, the generated authentication tag <span class="bcp14">MUST</span>
            always be 128 bits.<a href="#section-4.3.2-6" class="pilcrow">¶</a></p>
</section>
<section id="section-4.3.3">
          <h4 id="name-wrapped-key-2">
<a href="#section-4.3.3" class="section-number selfRef">4.3.3. </a><a href="#name-wrapped-key-2" class="section-name selfRef">Wrapped Key</a>
          </h4>
<p id="section-4.3.3-1">        
     This optional parameter contains the output of the AES key wrap function as defined in <span>[<a href="#RFC3394" class="xref">RFC3394</a>]</span>.  Specifically, this parameter holds the ciphertext produced when running this key wrap algorithm with 
     the input string being the symmetric AES key used to generate the security results 
            present in the security block. 
            The value of this parameter is used as input to the AES key wrap authenticated
            decryption function at security verifiers and security acceptors to determine 
            the symmetric AES key needed for the proper decryption of the security results 
            in the security block.<a href="#section-4.3.3-1" class="pilcrow">¶</a></p>
<p id="section-4.3.3-2">
            This value <span class="bcp14">MUST</span> be encoded as a CBOR byte string.<a href="#section-4.3.3-2" class="pilcrow">¶</a></p>
<p id="section-4.3.3-3">
            If this parameter is not present, then security verifiers 
            and acceptors <span class="bcp14">MUST</span> determine the proper key as a function of their local BPSec policy 
            and configuration.<a href="#section-4.3.3-3" class="pilcrow">¶</a></p>
</section>
<section id="section-4.3.4">
          <h4 id="name-aad-scope-flags">
<a href="#section-4.3.4" class="section-number selfRef">4.3.4. </a><a href="#name-aad-scope-flags" class="section-name selfRef">AAD Scope Flags</a>
          </h4>
<p id="section-4.3.4-1">
            This optional parameter contains a series of flags that describe
            what information is to be included with the 
            block-type-specific data of the security target as part of
            additional authenticated data (AAD).<a href="#section-4.3.4-1" class="pilcrow">¶</a></p>
<p id="section-4.3.4-2">
            This value <span class="bcp14">MUST</span> be represented as a CBOR unsigned
            integer, the value of which <span class="bcp14">MUST</span> be processed as a 16-bit field.
            The maximum value of this field, as a CBOR unsigned integer, <span class="bcp14">MUST</span> be
            65535.<a href="#section-4.3.4-2" class="pilcrow">¶</a></p>
<p id="section-4.3.4-3">When not provided, implementations <span class="bcp14">SHOULD</span> assume a value of 7
   (indicating all assigned fields), unless an alternate default is
   established by local security policy at the security source,
   verifier, or acceptor of this integrity service.<a href="#section-4.3.4-3" class="pilcrow">¶</a></p>
<p id="section-4.3.4-4">
            Implementations <span class="bcp14">MUST</span> set reserved and unassigned bits in this 
            field to 0 when constructing these flags at a security source. 
            Once set, the value of this field <span class="bcp14">MUST NOT</span> be altered until the
            security service is completed at the security acceptor in the
            network and removed from the bundle.<a href="#section-4.3.4-4" class="pilcrow">¶</a></p>
<p id="section-4.3.4-5">
            Bits in this field represent additional information to be included
            when generating an integrity signature over the security target.
            These bits are defined as follows.<a href="#section-4.3.4-5" class="pilcrow">¶</a></p>
<span class="break"></span><dl class="dlParallel" id="section-4.3.4-6">
            <dt id="section-4.3.4-6.1">Bit 0 (the low-order bit, 0x0001):</dt>
            <dd style="margin-left: 1.5em" id="section-4.3.4-6.2">Include primary block flag<a href="#section-4.3.4-6.2" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.3.4-6.3">Bit 1 (0x0002):</dt>
            <dd style="margin-left: 1.5em" id="section-4.3.4-6.4">Include target header flag<a href="#section-4.3.4-6.4" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.3.4-6.5">Bit 2 (0x0004):</dt>
            <dd style="margin-left: 1.5em" id="section-4.3.4-6.6">Include security header flag<a href="#section-4.3.4-6.6" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.3.4-6.7">Bits 3-7:</dt>
            <dd style="margin-left: 1.5em" id="section-4.3.4-6.8">Reserved<a href="#section-4.3.4-6.8" class="pilcrow">¶</a>
</dd>
            <dd class="break"></dd>
<dt id="section-4.3.4-6.9">Bits 8-15:</dt>
            <dd style="margin-left: 1.5em" id="section-4.3.4-6.10">Unassigned<a href="#section-4.3.4-6.10" class="pilcrow">¶</a>
</dd>
          <dd class="break"></dd>
</dl>
</section>
<section id="section-4.3.5">
          <h4 id="name-enumerations-2">
<a href="#section-4.3.5" class="section-number selfRef">4.3.5. </a><a href="#name-enumerations-2" class="section-name selfRef">Enumerations</a>
          </h4>
<p id="section-4.3.5-1">            
            The BCB-AES-GCM security context parameters are listed in 
            <a href="#bcb_parm_table" class="xref">Table 5</a>. In this table, the "Parm Id" column 
            refers to the expected parameter identifier described in Section
<span><a href="https://www.rfc-editor.org/rfc/rfc9172#section-3.10" class="relref">3.10</a> (<a href="https://www.rfc-editor.org/rfc/rfc9172#section-3.10" class="relref">"Parameter 
             and Result Identification"</a>)</span> of <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>.<a href="#section-4.3.5-1" class="pilcrow">¶</a></p>
<p id="section-4.3.5-2">
            An empty "Default Value" column indicates that the
            security context parameter does not have a default value.<a href="#section-4.3.5-2" class="pilcrow">¶</a></p>
<span id="name-bcb-aes-gcm-security-contex"></span><div id="bcb_parm_table">
<table class="center" id="table-5">
            <caption>
<a href="#table-5" class="selfRef">Table 5</a>:
<a href="#name-bcb-aes-gcm-security-contex" class="selfRef">BCB-AES-GCM Security Context Parameters</a>
            </caption>
<thead>
              <tr>
                <th class="text-center" rowspan="1" colspan="1">Parm Id</th>
                <th class="text-center" rowspan="1" colspan="1">Parm Name</th>
                <th class="text-center" rowspan="1" colspan="1">CBOR Encoding Type</th>
                <th class="text-center" rowspan="1" colspan="1">Default Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">1</td>
                <td class="text-center" rowspan="1" colspan="1">Initialization Vector</td>
                <td class="text-center" rowspan="1" colspan="1">byte string</td>
                <td class="text-center" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">2</td>
                <td class="text-center" rowspan="1" colspan="1">AES Variant</td>
                <td class="text-center" rowspan="1" colspan="1">unsigned integer</td>
                <td class="text-center" rowspan="1" colspan="1">3</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">3</td>
                <td class="text-center" rowspan="1" colspan="1">Wrapped Key</td>
                <td class="text-center" rowspan="1" colspan="1">byte string</td>
                <td class="text-center" rowspan="1" colspan="1"></td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">4</td>
                <td class="text-center" rowspan="1" colspan="1">AAD Scope Flags</td>
                <td class="text-center" rowspan="1" colspan="1">unsigned integer</td>
                <td class="text-center" rowspan="1" colspan="1">7</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</section>
<div id="bcb_results">
<section id="section-4.4">
        <h3 id="name-results-2">
<a href="#section-4.4" class="section-number selfRef">4.4. </a><a href="#name-results-2" class="section-name selfRef">Results</a>
        </h3>
<p id="section-4.4-1">
        The BCB-AES-GCM security context produces a single security result
        carried in the security block: the authentication tag.<a href="#section-4.4-1" class="pilcrow">¶</a></p>
<p id="section-4.4-2">
        NOTES:<a href="#section-4.4-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.4-3.1">
            The ciphertext generated by the cipher suite is not considered a 
            security result as it is stored in the block-type-specific data field
            of the security target block. When operating in GCM mode, AES produces 
            ciphertext of the same size as its plaintext; therefore, 
            no additional logic is required to handle padding or overflow caused
            by the encryption in most cases.<a href="#section-4.4-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.4-3.2">
            If the authentication tag can be separated from the ciphertext, then
            the tag <span class="bcp14">MAY</span> be separated and stored in the authentication tag 
            security result field. Otherwise, the security target block <span class="bcp14">MUST</span> be 
            resized to accommodate the additional 128 bits of authentication 
            tag included with the generated ciphertext replacing the 
            block-type-specific data field of the security target block.<a href="#section-4.4-3.2" class="pilcrow">¶</a>
</li>
        </ul>
<section id="section-4.4.1">
          <h4 id="name-authentication-tag">
<a href="#section-4.4.1" class="section-number selfRef">4.4.1. </a><a href="#name-authentication-tag" class="section-name selfRef">Authentication Tag</a>
          </h4>
<p id="section-4.4.1-1">
          The authentication tag is generated by the cipher suite over the 
          security target plaintext input to the cipher suite as combined with 
          any optional additional authenticated data. This tag is used to ensure
          that the plaintext (and important information associated with the
          plaintext) is authenticated prior to decryption.<a href="#section-4.4.1-1" class="pilcrow">¶</a></p>
<p id="section-4.4.1-2">
          If the authentication tag is included in the ciphertext placed
          in the security target block-type-specific data field, then this
          security result <span class="bcp14">MUST NOT</span> be included in the BCB for that security
          target.<a href="#section-4.4.1-2" class="pilcrow">¶</a></p>
<p id="section-4.4.1-3">
          The length of the authentication tag, prior to any CBOR encoding,
          <span class="bcp14">MUST</span> be 128 bits.<a href="#section-4.4.1-3" class="pilcrow">¶</a></p>
<p id="section-4.4.1-4">
          This value <span class="bcp14">MUST</span> be encoded as a CBOR byte string.<a href="#section-4.4.1-4" class="pilcrow">¶</a></p>
</section>
<section id="section-4.4.2">
          <h4 id="name-enumerations-3">
<a href="#section-4.4.2" class="section-number selfRef">4.4.2. </a><a href="#name-enumerations-3" class="section-name selfRef">Enumerations</a>
          </h4>
<p id="section-4.4.2-1">          
          The BCB-AES-GCM security context results are listed in 
            <a href="#bcb_res_table" class="xref">Table 6</a>. In this table, the "Result Id" column 
            refers to the expected result identifier described in Section
             <span><a href="https://www.rfc-editor.org/rfc/rfc9172#section-3.10" class="relref">3.10</a> (<a href="https://www.rfc-editor.org/rfc/rfc9172#section-3.10" class="relref">"Parameter 
             and Result Identification"</a>)</span> of <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>.<a href="#section-4.4.2-1" class="pilcrow">¶</a></p>
<span id="name-bcb-aes-gcm-security-result"></span><div id="bcb_res_table">
<table class="center" id="table-6">
            <caption>
<a href="#table-6" class="selfRef">Table 6</a>:
<a href="#name-bcb-aes-gcm-security-result" class="selfRef">BCB-AES-GCM Security Results</a>
            </caption>
<thead>
              <tr>
                <th class="text-center" rowspan="1" colspan="1">Result Id</th>
                <th class="text-center" rowspan="1" colspan="1">Result Name</th>
                <th class="text-center" rowspan="1" colspan="1">CBOR Encoding Type</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">1</td>
                <td class="text-center" rowspan="1" colspan="1">Authentication Tag</td>
                <td class="text-center" rowspan="1" colspan="1">byte string</td>
              </tr>
            </tbody>
          </table>
</div>
</section>
</section>
</div>
<div id="bcb_key_mgmt">
<section id="section-4.5">
        <h3 id="name-key-considerations-2">
<a href="#section-4.5" class="section-number selfRef">4.5. </a><a href="#name-key-considerations-2" class="section-name selfRef">Key Considerations</a>
        </h3>
<p id="section-4.5-1">
        Keys used with this context <span class="bcp14">MUST</span> be symmetric and <span class="bcp14">MUST</span> have 
        a key length equal to the key length defined in the security
        context parameters or as defined by local security policy at
        security verifiers and acceptors. For this reason, content-encrypting 
        key lengths will be integers divisible by 8 bytes, and special padding-aware AES
        key wrap algorithms are not needed.<a href="#section-4.5-1" class="pilcrow">¶</a></p>
<p id="section-4.5-2">
        It is assumed that any security verifier or security acceptor
        can determine the proper key to be used. Potential sources of the key 
        include (but are not limited to) the following.<a href="#section-4.5-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.5-3.1">Pre-placed keys selected based on local policy.<a href="#section-4.5-3.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-3.2">Keys extracted from material carried in the BCB.<a href="#section-4.5-3.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.5-3.3">Session keys negotiated via a mechanism external to the BCB.<a href="#section-4.5-3.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-4.5-4">
        When an AES-KW wrapped key is present in a security block, it is assumed that
        security verifiers and security acceptors can independently determine the
        KEK used in the wrapping of the symmetric AES content-encrypting key.<a href="#section-4.5-4" class="pilcrow">¶</a></p>
<p id="section-4.5-5">
        The security provided by block ciphers is reduced as more data is 
        processed with the same key. The total number of AES blocks processed with
        a single key for AES-GCM is recommended to be less than 2<sup>64</sup>, as
        described in Appendix B of <span>[<a href="#AES-GCM" class="xref">AES-GCM</a>]</span>.<a href="#section-4.5-5" class="pilcrow">¶</a></p>
<p id="section-4.5-6">
        Additionally, there exist limits on the number of encryptions that
        can be performed with the same key.  The total number of invocations
        of the authenticated encryption function with a single key for
        AES-GCM is required to not exceed 2<sup>32</sup>, as described in Section
        8.3 of <span>[<a href="#AES-GCM" class="xref">AES-GCM</a>]</span>.<a href="#section-4.5-6" class="pilcrow">¶</a></p>
<p id="section-4.5-7">
        As discussed in <a href="#SecCons" class="xref">Section 6</a> and emphasized here, it is
        strongly recommended that keys be protected once generated, both
        when they are stored and when they are transmitted.<a href="#section-4.5-7" class="pilcrow">¶</a></p>
</section>
</div>
<div id="GcmCons">
<section id="section-4.6">
        <h3 id="name-gcm-considerations">
<a href="#section-4.6" class="section-number selfRef">4.6. </a><a href="#name-gcm-considerations" class="section-name selfRef">GCM Considerations</a>
        </h3>
<p id="section-4.6-1">
        The GCM cryptographic mode of AES has specific requirements that
        <span class="bcp14">MUST</span> be followed by implementers for the secure function of the
        BCB-AES-GCM security context. While these requirements are well
        documented in <span>[<a href="#AES-GCM" class="xref">AES-GCM</a>]</span>, some of them are
        repeated here for emphasis.<a href="#section-4.6-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.6-2.1">
            <p id="section-4.6-2.1.1">
            With the exception of the AES-KW function, the IVs 
            used by the BCB-AES-GCM security context are considered to
            be per-invocation IVs. 
            The pairing of a per-invocation IV and a security key
            <span class="bcp14">MUST</span> be unique. A per-invocation IV <span class="bcp14">MUST NOT</span> be used with a security
            key more than one time. If a per-invocation IV and key pair are repeated, then the GCM implementation
            is vulnerable to forgery attacks. Because the loss of integrity protection
            occurs with even a single reuse, this situation is often considered to have
            catastrophic security consequences. More information regarding 
            the importance of the uniqueness of the IV value can be found in 
            Appendix A of <span>[<a href="#AES-GCM" class="xref">AES-GCM</a>]</span>.<a href="#section-4.6-2.1.1" class="pilcrow">¶</a></p>
<p id="section-4.6-2.1.2">
            Methods of generating unique IV values are provided in Section 8
            of <span>[<a href="#AES-GCM" class="xref">AES-GCM</a>]</span>. For example, one method decomposes the
            IV value into a fixed field and an invocation field. The fixed field
            is a constant value associated with a device, and the invocation 
            field changes on each invocation (such as by incrementing an
            integer counter). Implementers <span class="bcp14">SHOULD</span> carefully read
            all relevant sections of <span>[<a href="#AES-GCM" class="xref">AES-GCM</a>]</span> when generating
            any mechanism to create unique IVs.<a href="#section-4.6-2.1.2" class="pilcrow">¶</a></p>
</li>
          <li class="normal" id="section-4.6-2.2">
            The AES-KW function used to wrap keys for the security contexts in this document uses 
            a single, globally constant IV input to the AES cipher 
            operation and thus is distinct from the aforementioned 
            requirement related to per-invocation IVs.<a href="#section-4.6-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.6-2.3">
            While any tag-based authentication mechanism has some likelihood
            of being forged, this probability is increased when using AES-GCM.
            In particular, short tag lengths combined with very long messages
            <span class="bcp14">SHOULD</span> be avoided when using this mode. The BCB-AES-GCM security 
            context requires the use of 128-bit authentication tags at all
            times. Concerns relating to the size of authentication tags is 
            discussed in Appendices B and C of <span>[<a href="#AES-GCM" class="xref">AES-GCM</a>]</span>.<a href="#section-4.6-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.6-2.4">
            As discussed in Appendix B of <span>[<a href="#AES-GCM" class="xref">AES-GCM</a>]</span>, 
            implementations <span class="bcp14">SHOULD</span> limit the number of unsuccessful
            verification attempts for each key to reduce the likelihood 
            of guessing tag values. This type of check has potential 
            state-keeping issues when AES-KW is used, since an attacker
            could cause a large number of keys to be used at least
            once.<a href="#section-4.6-2.4" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-4.6-2.5">
            As discussed in Section
            <span><a href="https://www.rfc-editor.org/rfc/rfc9172#section-8" class="relref">8</a> (<a href="https://www.rfc-editor.org/rfc/rfc9172#section-8" class="relref">"Security Considerations"</a>)</span> of <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>, delay-tolerant networks have a higher 
            occurrence of replay attacks due to the store-and-forward nature
            of the network. Because GCM has no inherent replay attack 
            protection, implementors <span class="bcp14">SHOULD</span> attempt to detect replay attacks 
            by using mechanisms such as those described in Appendix D of 
            <span>[<a href="#AES-GCM" class="xref">AES-GCM</a>]</span>.<a href="#section-4.6-2.5" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</div>
<section id="section-4.7">
        <h3 id="name-canonicalization-algorithms-2">
<a href="#section-4.7" class="section-number selfRef">4.7. </a><a href="#name-canonicalization-algorithms-2" class="section-name selfRef">Canonicalization Algorithms</a>
        </h3>
<p id="section-4.7-1">
        This section defines the canonicalization algorithms used to prepare
        the inputs used to generate both the ciphertext and the
        authentication tag.<a href="#section-4.7-1" class="pilcrow">¶</a></p>
<p id="section-4.7-2">
        In all cases, the canonical form of any portion of an extension block
        <span class="bcp14">MUST</span> be created as described in <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>.
        The canonicalization algorithms defined in <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>  
        adhere to the canonical forms for extension blocks defined in 
        <span>[<a href="#RFC9171" class="xref">RFC9171</a>]</span> but resolve ambiguities related to
        how values are represented in CBOR.<a href="#section-4.7-2" class="pilcrow">¶</a></p>
<div id="bcb_canon_cipher">
<section id="section-4.7.1">
          <h4 id="name-calculations-related-to-cip">
<a href="#section-4.7.1" class="section-number selfRef">4.7.1. </a><a href="#name-calculations-related-to-cip" class="section-name selfRef">Calculations Related to Ciphertext</a>
          </h4>
<p id="section-4.7.1-1">
          The BCB operates over the block-type-specific data of 
          a block, but the BP always encodes these data within a 
          single, definite-length CBOR byte string. Therefore, the plaintext 
          used during encryption <span class="bcp14">MUST</span> be calculated as the value of the 
          block-type-specific data field of the security target 
          excluding the BP CBOR encoding.<a href="#section-4.7.1-1" class="pilcrow">¶</a></p>
<p id="section-4.7.1-2">
          <a href="#enc_ex" class="xref">Table 7</a> shows two CBOR-encoded examples and the 
          plaintext that would be extracted from them. The first example
          is an unsigned integer, while the second is a byte string.<a href="#section-4.7.1-2" class="pilcrow">¶</a></p>
<span id="name-cbor-plaintext-extraction-e"></span><div id="enc_ex">
<table class="center" id="table-7">
            <caption>
<a href="#table-7" class="selfRef">Table 7</a>:
<a href="#name-cbor-plaintext-extraction-e" class="selfRef">CBOR Plaintext Extraction Examples</a>
            </caption>
<thead>
              <tr>
                <th class="text-center" rowspan="1" colspan="1">CBOR Encoding (Hex)</th>
                <th class="text-center" rowspan="1" colspan="1">CBOR Part (Hex)</th>
                <th class="text-center" rowspan="1" colspan="1">Plaintext Part (Hex)</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">18ED</td>
                <td class="text-center" rowspan="1" colspan="1">18</td>
                <td class="text-center" rowspan="1" colspan="1">ED</td>
              </tr>
              <tr>
                <td class="text-center" rowspan="1" colspan="1">C24CDEADBEEFDEADBEEFDEADBEEF</td>
                <td class="text-center" rowspan="1" colspan="1">C24C</td>
                <td class="text-center" rowspan="1" colspan="1">DEADBEEFDEADBEEFDEADBEEF</td>
              </tr>
            </tbody>
          </table>
</div>
<p id="section-4.7.1-4"> 
          The ciphertext used during decryption <span class="bcp14">MUST</span> be calculated 
          as the single, definite-length CBOR byte string representing the 
          block-type-specific data field excluding the CBOR byte string 
          identifying byte and optional CBOR byte string length field.<a href="#section-4.7.1-4" class="pilcrow">¶</a></p>
<p id="section-4.7.1-5">
          All other fields of the security target (such as the block type code, 
          block number, block processing control flags, or any CRC information)
          <span class="bcp14">MUST NOT</span> be considered as part of encryption or decryption.<a href="#section-4.7.1-5" class="pilcrow">¶</a></p>
</section>
</div>
<div id="bcb_canon_aad">
<section id="section-4.7.2">
          <h4 id="name-additional-authenticated-da">
<a href="#section-4.7.2" class="section-number selfRef">4.7.2. </a><a href="#name-additional-authenticated-da" class="section-name selfRef">Additional Authenticated Data</a>
          </h4>
<p id="section-4.7.2-1">
          The construction of additional authenticated data depends on the
          AAD scope flags that can be provided as part of customizing the
          behavior of this security context.<a href="#section-4.7.2-1" class="pilcrow">¶</a></p>
<p id="section-4.7.2-2">
          The canonical form of the AAD input to the BCB-AES-GCM mechanism is
          constructed using the following process. While the AAD scope flags
          might not be included in the BCB representing the security operation,
          they <span class="bcp14">MUST</span> be included in the AAD value itself. This process <span class="bcp14">MUST</span> be
          followed when generating AAD for either encryption or decryption.<a href="#section-4.7.2-2" class="pilcrow">¶</a></p>
<ol start="1" type="1" class="normal type-1" id="section-4.7.2-3">
<li id="section-4.7.2-3.1">
              The canonical form of the AAD starts as the CBOR encoding
              of the AAD scope flags in which all unset flags, reserved bits,
              and unassigned bits have been set to 0. For example, if the
              primary block flag, target header flag, and security header flag are 
              each set, then the initial value of the canonical form of the
              AAD will be 0x07.<a href="#section-4.7.2-3.1" class="pilcrow">¶</a>
</li>
            <li id="section-4.7.2-3.2">
              If the primary block flag of the AAD scope flags is set to 
              1, then a canonical form of the bundle's primary 
              block <span class="bcp14">MUST</span> be calculated and the result appended to the AAD.<a href="#section-4.7.2-3.2" class="pilcrow">¶</a>
</li>
            <li id="section-4.7.2-3.3">
              If the target header flag of the AAD scope flags is set to 
              1, then the canonical form of the block type code, 
              block number, and block processing control flags associated with the
              security target <span class="bcp14">MUST</span> be calculated and, in that order, appended 
              to the AAD.<a href="#section-4.7.2-3.3" class="pilcrow">¶</a>
</li>
            <li id="section-4.7.2-3.4">
              If the security header flag of the AAD scope flags is set to 1, 
              then the canonical form of the block type code, 
              block number, and block processing control flags associated with 
              the BIB <span class="bcp14">MUST</span> be calculated and, in that order, appended to the AAD.<a href="#section-4.7.2-3.4" class="pilcrow">¶</a>
</li>
          </ol>
</section>
</div>
</section>
<section id="section-4.8">
        <h3 id="name-processing-2">
<a href="#section-4.8" class="section-number selfRef">4.8. </a><a href="#name-processing-2" class="section-name selfRef">Processing</a>
        </h3>
<section id="section-4.8.1">
          <h4 id="name-encryption">
<a href="#section-4.8.1" class="section-number selfRef">4.8.1. </a><a href="#name-encryption" class="section-name selfRef">Encryption</a>
          </h4>
<p id="section-4.8.1-1">
          During encryption, four data elements are prepared for input to the
          AES-GCM cipher: the encryption key, the IV, 
          the security target plaintext to be encrypted, and any 
          additional authenticated data. These data items <span class="bcp14">MUST</span> be generated
          as follows.<a href="#section-4.8.1-1" class="pilcrow">¶</a></p>
<p id="section-4.8.1-2">
          Prior to encryption, if a CRC value is present for the target block, 
          then that CRC value <span class="bcp14">MUST</span> be removed. This requires removing the CRC 
          field from the target block and setting the CRC type field of the 
          target block to "no CRC is present."<a href="#section-4.8.1-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.8.1-3.1">
              The encryption key <span class="bcp14">MUST</span> have the appropriate
              length as required by local security policy.  The key might be
              generated specifically for this encryption, given as part of
              local security policy, or obtained through some other key
              management mechanism as discussed in <a href="#bcb_key_mgmt" class="xref">Section 4.5</a>.<a href="#section-4.8.1-3.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.1-3.2">
              The IV selected <span class="bcp14">MUST</span> be of the appropriate
              length. Because replaying an IV in counter mode voids the 
              confidentiality of all messages encrypted with said IV, this 
              context also requires a unique IV for every encryption performed 
              with the same key. This means the same key and IV combination <span class="bcp14">MUST NOT</span> be used more than once.<a href="#section-4.8.1-3.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.1-3.3">
              The security target plaintext for encryption <span class="bcp14">MUST</span> be generated as
              discussed in <a href="#bcb_canon_cipher" class="xref">Section 4.7.1</a>.<a href="#section-4.8.1-3.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.1-3.4">
              Additional authenticated data <span class="bcp14">MUST</span> be generated as
              discussed in <a href="#bcb_canon_aad" class="xref">Section 4.7.2</a>, with the value of 
              AAD scope flags being taken from local security policy.<a href="#section-4.8.1-3.4" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.8.1-4">
          Upon successful encryption, the following actions <span class="bcp14">MUST</span> occur.<a href="#section-4.8.1-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.8.1-5.1">
              The ciphertext produced by AES-GCM <span class="bcp14">MUST</span> replace the bytes used 
              to define the plaintext in the security target block's 
              block-type-specific data field. The block length of the security
              target <span class="bcp14">MUST</span> be updated if the generated ciphertext is larger
              than the plaintext (which can occur when the authentication
              tag is included in the ciphertext calculation, as discussed
              in <a href="#bcb_results" class="xref">Section 4.4</a>).<a href="#section-4.8.1-5.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.1-5.2">              
              The authentication tag calculated by the AES-GCM cipher <span class="bcp14">MAY</span> be
              added as a security result for the security target in the BCB
              holding results for this security operation, in which case it 
              <span class="bcp14">MUST</span> be processed as described in <a href="#bcb_results" class="xref">Section 4.4</a>.<a href="#section-4.8.1-5.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.1-5.3">
              The authentication tag <span class="bcp14">MUST</span> be included either as a security
              result in the BCB representing the security operation or
              (with the ciphertext) in the security target block-type-specific 
              data field.<a href="#section-4.8.1-5.3" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.8.1-6">
          Finally, the BCB containing information about this security operation
          <span class="bcp14">MUST</span> be updated as follows. These operations can occur in any order.<a href="#section-4.8.1-6" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.8.1-7.1">
              The security context identifier for the BCB <span class="bcp14">MUST</span> be set to the context
              identifier for BCB-AES-GCM.<a href="#section-4.8.1-7.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.1-7.2">
              The IV input to the cipher <span class="bcp14">MUST</span> be added as the
              IV security context parameter for the BCB.<a href="#section-4.8.1-7.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.1-7.3">
              Any local flags used to generate AAD for this cipher <span class="bcp14">MUST</span> be
              placed in the AAD scope flags security context parameter for the BCB
              unless these flags are expected to be correctly configured at
              security verifiers and security acceptors in the network.<a href="#section-4.8.1-7.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.1-7.4">
              The encryption key <span class="bcp14">MAY</span> be included as a security
              context parameter, in which case it <span class="bcp14">MUST</span> be
              wrapped using the AES key wrap function as defined in <span>[<a href="#RFC3394" class="xref">RFC3394</a>]</span> and the results of the
              wrapping added as the wrapped key security context parameter for
              the BCB.<a href="#section-4.8.1-7.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.1-7.5">
              The AES variant used by this security context <span class="bcp14">SHOULD</span> be added as
              the AES variant security context parameter for the BCB if it differs from 
              the default key length. Otherwise, this parameter <span class="bcp14">MAY</span> be
              omitted if doing so provides a useful reduction in message sizes.<a href="#section-4.8.1-7.5" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.8.1-8">
           Problems encountered in the encryption <span class="bcp14">MUST</span> be processed in accordance 
           with local security policy. This <span class="bcp14">MAY</span> include restoring a CRC value
           removed from the target block prior to encryption, if the target block
           is allowed to be transmitted after an encryption error.<a href="#section-4.8.1-8" class="pilcrow">¶</a></p>
</section>
<section id="section-4.8.2">
          <h4 id="name-decryption">
<a href="#section-4.8.2" class="section-number selfRef">4.8.2. </a><a href="#name-decryption" class="section-name selfRef">Decryption</a>
          </h4>
<p id="section-4.8.2-1">
          During decryption, five data elements are prepared for input to the
          AES-GCM cipher: the decryption key, the IV, 
          the security target ciphertext to be decrypted, any additional 
          authenticated data, and the authentication tag generated from the
          original encryption. These data items <span class="bcp14">MUST</span> be generated as follows.<a href="#section-4.8.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.8.2-2.1">
              The decryption key <span class="bcp14">MUST</span> be derived using the wrapped key
              security context parameter if such a parameter is included in the
              security context parameters of the BCB. Otherwise, this key
              <span class="bcp14">MUST</span> be derived in accordance with local security policy at the
              decrypting node as discussed in <a href="#bcb_key_mgmt" class="xref">Section 4.5</a>.<a href="#section-4.8.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.2-2.2">
              The IV <span class="bcp14">MUST</span> be set to the value of the
              IV security context parameter included in the BCB. If the IV parameter
              is not included as a security context parameter, an IV <span class="bcp14">MAY</span> be derived
              as a function of local security policy and other BCB contents, or
              a lack of an IV security context parameter in the BCB <span class="bcp14">MAY</span> be treated
              as an error by the decrypting node.<a href="#section-4.8.2-2.2" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.2-2.3">
              The security target ciphertext for decryption <span class="bcp14">MUST</span> be generated as
              discussed in <a href="#bcb_canon_cipher" class="xref">Section 4.7.1</a>.<a href="#section-4.8.2-2.3" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.2-2.4">
              Additional authenticated data <span class="bcp14">MUST</span> be generated as
              discussed in <a href="#bcb_canon_aad" class="xref">Section 4.7.2</a> with the value of 
              AAD scope flags being taken from the AAD scope flags
              security context parameter. If the AAD scope flags parameter is
              not included in the security context parameters, then these flags
              <span class="bcp14">MAY</span> be derived from local security policy in cases where the
              set of such flags is determinable in the network.<a href="#section-4.8.2-2.4" class="pilcrow">¶</a>
</li>
            <li class="normal" id="section-4.8.2-2.5">
              The authentication tag <span class="bcp14">MUST</span> be present either as a security
              result in the BCB representing the security operation or
              (with the ciphertext) in the security target block-type-specific 
              data field.<a href="#section-4.8.2-2.5" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.8.2-3">
          Upon successful decryption, the following action <span class="bcp14">MUST</span> occur.<a href="#section-4.8.2-3" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-4.8.2-4.1">
              The plaintext produced by AES-GCM <span class="bcp14">MUST</span> replace
              the bytes used to define the ciphertext in the security target
              block's block-type-specific data field. Any changes to the
              security target block length field <span class="bcp14">MUST</span> be
              corrected in cases where the plaintext has a different length
              than the replaced ciphertext.<a href="#section-4.8.2-4.1" class="pilcrow">¶</a>
</li>
          </ul>
<p id="section-4.8.2-5">
          If the security acceptor is not the bundle destination and if no other
          integrity or confidentiality service is being applied to the target block, 
          then a CRC <span class="bcp14">MUST</span> be included for the target block. The CRC type, as determined
          by policy, is set in the target block's CRC type field and the 
          corresponding CRC value is added as the CRC field for that block.<a href="#section-4.8.2-5" class="pilcrow">¶</a></p>
<p id="section-4.8.2-6">
          If the ciphertext fails to authenticate, if any needed parameters 
          are missing, or if there are other problems in the decryption, then 
          the decryption <span class="bcp14">MUST</span> be treated as failed and processed in accordance 
          with local security policy.<a href="#section-4.8.2-6" class="pilcrow">¶</a></p>
</section>
</section>
</section>
</div>
<div id="IANA">
<section id="section-5">
      <h2 id="name-iana-considerations">
<a href="#section-5" class="section-number selfRef">5. </a><a href="#name-iana-considerations" class="section-name selfRef">IANA Considerations</a>
      </h2>
<div id="sc_ids">
<section id="section-5.1">
        <h3 id="name-security-context-identifier">
<a href="#section-5.1" class="section-number selfRef">5.1. </a><a href="#name-security-context-identifier" class="section-name selfRef">Security Context Identifiers</a>
        </h3>
<p id="section-5.1-1">
        This specification allocates two security context identifiers from the 
        "BPSec Security Context Identifiers" registry defined in 
        <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>.<a href="#section-5.1-1" class="pilcrow">¶</a></p>
<span id="name-additional-entries-for-the-"></span><div id="iana_table">
<table class="center" id="table-8">
          <caption>
<a href="#table-8" class="selfRef">Table 8</a>:
<a href="#name-additional-entries-for-the-" class="selfRef">Additional Entries for the BPSec Security Context Identifiers Registry</a>
          </caption>
<thead>
            <tr>
              <th class="text-center" rowspan="1" colspan="1">Value</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">BIB-HMAC-SHA2</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9173</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">BCB-AES-GCM</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9173</td>
            </tr>
          </tbody>
        </table>
</div>
</section>
</div>
<section id="section-5.2">
        <h3 id="name-integrity-scope-flags-2">
<a href="#section-5.2" class="section-number selfRef">5.2. </a><a href="#name-integrity-scope-flags-2" class="section-name selfRef">Integrity Scope Flags</a>
        </h3>
<p id="section-5.2-1">
          The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field for 
          which IANA has created and now maintains a new registry named
          "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the "Bundle Protocol" registry page. 
          <a href="#bib_flags" class="xref">Table 9</a> shows the initial values for this registry.<a href="#section-5.2-1" class="pilcrow">¶</a></p>
<p id="section-5.2-2">
          The registration policy for this registry is Specification Required <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>.<a href="#section-5.2-2" class="pilcrow">¶</a></p>
<p id="section-5.2-3">
          The value range is unsigned 16-bit integer.<a href="#section-5.2-3" class="pilcrow">¶</a></p>
<span id="name-bpsec-bib-hmac-sha2-integri"></span><div id="bib_flags">
<table class="center" id="table-9">
          <caption>
<a href="#table-9" class="selfRef">Table 9</a>:
<a href="#name-bpsec-bib-hmac-sha2-integri" class="selfRef">BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry</a>
          </caption>
<thead>
            <tr>
              <th class="text-center" rowspan="1" colspan="1">Bit Position (right to left)</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Include primary block flag</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9173</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">Include target header flag</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9173</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">Include security header flag</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9173</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">3-7</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9173</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">8-15</td>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
          </tbody>
        </table>
</div>
</section>
<section id="section-5.3">
        <h3 id="name-aad-scope-flags-2">
<a href="#section-5.3" class="section-number selfRef">5.3. </a><a href="#name-aad-scope-flags-2" class="section-name selfRef">AAD Scope Flags</a>
        </h3>
<p id="section-5.3-1">
          The BCB-AES-GCM security context has an AAD Scope Flags field for 
          which IANA has created and now maintains a new registry named
          "BPSec BCB-AES-GCM AAD Scope Flags" on the "Bundle Protocol" registry page.
          <a href="#bcb_flags" class="xref">Table 10</a> shows the initial values for this registry.<a href="#section-5.3-1" class="pilcrow">¶</a></p>
<p id="section-5.3-2">
          The registration policy for this registry is Specification Required.<a href="#section-5.3-2" class="pilcrow">¶</a></p>
<p id="section-5.3-3">
          The value range is unsigned 16-bit integer.<a href="#section-5.3-3" class="pilcrow">¶</a></p>
<span id="name-bpsec-bcb-aes-gcm-aad-scope"></span><div id="bcb_flags">
<table class="center" id="table-10">
          <caption>
<a href="#table-10" class="selfRef">Table 10</a>:
<a href="#name-bpsec-bcb-aes-gcm-aad-scope" class="selfRef">BPSec BCB-AES-GCM AAD Scope Flags Registry</a>
          </caption>
<thead>
            <tr>
              <th class="text-center" rowspan="1" colspan="1">Bit Position (right to left)</th>
              <th class="text-left" rowspan="1" colspan="1">Description</th>
              <th class="text-left" rowspan="1" colspan="1">Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">0</td>
              <td class="text-left" rowspan="1" colspan="1">Include primary block flag</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9173</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">1</td>
              <td class="text-left" rowspan="1" colspan="1">Include target header flag</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9173</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">2</td>
              <td class="text-left" rowspan="1" colspan="1">Include security header flag</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9173</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">3-7</td>
              <td class="text-left" rowspan="1" colspan="1">Reserved</td>
              <td class="text-left" rowspan="1" colspan="1">RFC 9173</td>
            </tr>
            <tr>
              <td class="text-center" rowspan="1" colspan="1">8-15</td>
              <td class="text-left" rowspan="1" colspan="1">Unassigned</td>
              <td class="text-left" rowspan="1" colspan="1"></td>
            </tr>
          </tbody>
        </table>
</div>
</section>
<section id="section-5.4">
        <h3 id="name-guidance-for-designated-exp">
<a href="#section-5.4" class="section-number selfRef">5.4. </a><a href="#name-guidance-for-designated-exp" class="section-name selfRef">Guidance for Designated Experts</a>
        </h3>
<p id="section-5.4-1">
            New assignments within the "BPSec BIB-HMAC-SHA2 
            Integrity Scope Flags" and 
            "BPSec BCB-AES-GCM AAD Scope Flags" registries require
            review by a Designated Expert (DE). This section
            provides guidance to the DE when performing their
            reviews. Specifically, a DE is expected to perform
            the following activities.<a href="#section-5.4-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-5.4-2.1">
                Ascertain the existence of suitable documentation
                (a specification) as described in <span>[<a href="#RFC8126" class="xref">RFC8126</a>]</span>
                and verify that the document is permanently and
                publicly available.<a href="#section-5.4-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.4-2.2">
                Ensure that any changes to the "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" registry
                clearly state how new assignments interact with existing
                flags and how the inclusion of new assignments affects
                the construction of the IPPT value.<a href="#section-5.4-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.4-2.3">
                Ensure that any changes to the "BPSec BCB-AES-GCM AAD Scope Flags" registry clearly 
                state how new assignments interact with existing
                flags and how the inclusion of new assignments affects
                the construction of the AAD input to the BCB-AES-GCM mechanism.<a href="#section-5.4-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-5.4-2.4">
                Ensure that any processing changes proposed with new assignments
                do not alter any required behavior in this specification.<a href="#section-5.4-2.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
</section>
</div>
<div id="SecCons">
<section id="section-6">
      <h2 id="name-security-considerations">
<a href="#section-6" class="section-number selfRef">6. </a><a href="#name-security-considerations" class="section-name selfRef">Security Considerations</a>
      </h2>
<p id="section-6-1">
      Security considerations specific to a single security context are 
      provided in the description of that context (see Sections <a href="#first-context" class="xref">3</a> and <a href="#second-context" class="xref">4</a>). This section discusses 
      security considerations that should be evaluated by implementers of any 
      security context described in this document. Considerations can also be 
      found in documents listed as normative references and should also be 
      reviewed by security context implementors.<a href="#section-6-1" class="pilcrow">¶</a></p>
<section id="section-6.1">
        <h3 id="name-key-management">
<a href="#section-6.1" class="section-number selfRef">6.1. </a><a href="#name-key-management" class="section-name selfRef">Key Management</a>
        </h3>
<p id="section-6.1-1">
        The delayed and disrupted nature of Delay-Tolerant
   Networking (DTN) complicates the process of key management
        because there might not be reliable, timely, round-trip exchange between security
        sources, security verifiers, and security acceptors in the network. This is true when
        there is a substantial signal propagation delay between nodes, when nodes are in a highly
        challenged communications environment, and when nodes do not support bidirectional 
        communication.<a href="#section-6.1-1" class="pilcrow">¶</a></p>
<p id="section-6.1-2">
        In these environments, key establishment protocols that rely on round-trip information
        exchange might not converge on a shared secret in a timely manner (or at all). Also,
        key revocation or key verification mechanisms that rely on access to a centralized
        authority (such as a certificate authority) might similarly fail in the stressing 
        conditions of DTN.<a href="#section-6.1-2" class="pilcrow">¶</a></p>
<p id="section-6.1-3">
        For these reasons, the default security contexts described in this document rely
        on symmetric-key cryptographic mechanisms because asymmetric-key infrastructure (such
        as a public key infrastructure) might be impractical in this environment.<a href="#section-6.1-3" class="pilcrow">¶</a></p>
<p id="section-6.1-4">
        BPSec assumes that "key management is handled as a separate part of network management" 
        <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>. This assumption is also made
        by the security contexts defined in this document, which do not define new protocols for
        key derivation, exchange of KEKs, revocation of existing keys, 
        or the security configuration or policy used to select certain keys for certain 
        security operations.<a href="#section-6.1-4" class="pilcrow">¶</a></p>
<p id="section-6.1-5">
        Nodes using these security contexts need to perform the following kinds of
        activities, independent of the construction, transmission, and processing of
        BPSec security blocks.<a href="#section-6.1-5" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.1-6.1">
            Establish shared KEKs with other nodes in the network using
            an out-of-band mechanism. This might include pre-sharing of KEKs
            or the use of older key establishment mechanisms prior to the 
            exchange of BPSec security blocks.<a href="#section-6.1-6.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-6.2">
            Determine when a key is considered exhausted and no longer to be used in 
            the generation, verification, or acceptance of a security block.<a href="#section-6.1-6.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-6.3">
            Determine when a key is considered invalid and no longer to be used in the
            generation, verification, or acceptance of a security block. Such revocations
            can be based on a variety of mechanisms, including local security policy, 
            time relative to the generation or use of the key, or other mechanisms
            specified through network management.<a href="#section-6.1-6.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.1-6.4">
            Determine, through an out-of-band mechanism such as local security policy,
            what keys are to be used for what security blocks. This includes the selection
            of which key should be used in the evaluation of a security block received by
            a security verifier or a security acceptor.<a href="#section-6.1-6.4" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.1-7">
        The failure to provide effective key management techniques appropriate 
        for the operational networking environment can result in the compromise of 
        those unmanaged keys and the loss of security services in the network.<a href="#section-6.1-7" class="pilcrow">¶</a></p>
</section>
<section id="section-6.2">
        <h3 id="name-key-handling">
<a href="#section-6.2" class="section-number selfRef">6.2. </a><a href="#name-key-handling" class="section-name selfRef">Key Handling</a>
        </h3>
<p id="section-6.2-1">
        Once generated, keys should be handled as follows.<a href="#section-6.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.2-2.1">
            It is strongly <span class="bcp14">RECOMMENDED</span> that implementations protect keys both  
            when they are stored and when they are transmitted.<a href="#section-6.2-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.2">
            In the event that a key is compromised, any security operations using 
            a security context associated with that key <span class="bcp14">SHOULD</span> also be
            considered compromised. This means that the BIB-HMAC-SHA2 security context
            <span class="bcp14">SHOULD NOT</span> be treated as providing integrity when used with a compromised key, and 
            BCB-AES-GCM <span class="bcp14">SHOULD NOT</span> be treated as providing confidentiality when used with a compromised key.<a href="#section-6.2-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.3"> 
            The same key, whether a KEK or a wrapped key, <span class="bcp14">MUST NOT</span> 
            be used for different algorithms as doing so might leak information 
            about the key.<a href="#section-6.2-2.3" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.2-2.4">
            A KEK <span class="bcp14">MUST NOT</span> be used to encrypt keys for different security
            contexts. Any KEK used by a security context defined in this document <span class="bcp14">MUST</span>
            only be used to wrap keys associated with security operations using
            that security context. This means that a compliant security source
            would not use the same KEK to wrap keys for both the BIB-HMAC-SHA2 and
            BCB-AES-GCM security contexts. Similarly, any compliant security verifier
            or security acceptor would not use the same KEK to unwrap keys
            for different security contexts.<a href="#section-6.2-2.4" class="pilcrow">¶</a>
</li>
        </ul>
</section>
<section id="section-6.3">
        <h3 id="name-aes-gcm">
<a href="#section-6.3" class="section-number selfRef">6.3. </a><a href="#name-aes-gcm" class="section-name selfRef">AES GCM</a>
        </h3>
<p id="section-6.3-1">
        There are a significant number of considerations related to the use of the
        GCM mode of AES to provide a confidentiality service. These considerations
        are provided in <a href="#GcmCons" class="xref">Section 4.6</a> as part of the documentation
        of the BCB-AES-GCM security context.<a href="#section-6.3-1" class="pilcrow">¶</a></p>
<p id="section-6.3-2">
        The length of the ciphertext produced by the 
        GCM mode of AES will be equal to the length of the plaintext input 
        to the cipher suite. The authentication tag also produced by this 
        cipher suite is separate from the ciphertext. However, it should be 
        noted that implementations of the AES-GCM cipher suite might not separate 
        the concept of ciphertext and authentication tag in their Application 
        Programming Interface (API).<a href="#section-6.3-2" class="pilcrow">¶</a></p>
<p id="section-6.3-3">
        Implementations of the BCB-AES-GCM security context can either keep the length
        of the target block unchanged by holding the authentication tag in a BCB
        security result or alter the length of the target block by including the
        authentication tag with the ciphertext replacing the block-type-specific data
        field of the target block. Implementations <span class="bcp14">MAY</span> use the authentication tag
        security result in cases where keeping target block length unchanged is an
        important processing concern. In all cases, the ciphertext and authentication
        tag <span class="bcp14">MUST</span> be processed in accordance with the API of the AES-GCM cipher suites
        at the security source and security acceptor.<a href="#section-6.3-3" class="pilcrow">¶</a></p>
</section>
<section id="section-6.4">
        <h3 id="name-aes-key-wrap">
<a href="#section-6.4" class="section-number selfRef">6.4. </a><a href="#name-aes-key-wrap" class="section-name selfRef">AES Key Wrap</a>
        </h3>
<p id="section-6.4-1">
        The AES-KW algorithm used by the security contexts in this document 
        does not use a per-invocation initialization vector and does not require any key padding. Key padding is
        not needed because wrapped keys used by these security contexts will always be multiples of 8
        bytes. The length of the wrapped key can be determined by inspecting the security 
        context parameters. Therefore, a key can be unwrapped using only the information present 
        in the security block and the KEK provided by local security policy at the security verifier 
        or security acceptor.<a href="#section-6.4-1" class="pilcrow">¶</a></p>
</section>
<section id="section-6.5">
        <h3 id="name-bundle-fragmentation">
<a href="#section-6.5" class="section-number selfRef">6.5. </a><a href="#name-bundle-fragmentation" class="section-name selfRef">Bundle Fragmentation</a>
        </h3>
<p id="section-6.5-1">
        Bundle fragmentation might prevent security services in a bundle from being 
        verified after a bundle is fragmented and before the bundle is 
        re-assembled. Examples of potential issues include the following.<a href="#section-6.5-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="section-6.5-2.1">
            If a security block and its security target do not exist in the
            same fragment, then the security block cannot be processed until the
            bundle is re-assembled. If a fragment includes an encrypted 
            target block, but not its BCB, then a receiving Bundle Protocol
            Agent (BPA) will not know that the target block has been encrypted.<a href="#section-6.5-2.1" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.5-2.2">
            A security block can be cryptographically bound to a bundle by setting the
            integrity scope flags (for BIB-HMAC-SHA2) or the AAD scope flags (for
            BCB-AES-GCM) to include the bundle primary block. When a security
            block is cryptographically bound to a bundle, it cannot be processed 
            even if the security block and target both coexist in the fragment. This 
            is because fragments have different primary blocks than the original bundle.<a href="#section-6.5-2.2" class="pilcrow">¶</a>
</li>
          <li class="normal" id="section-6.5-2.3">
            If security blocks and their target blocks are repeated in 
            multiple fragments, policy needs to determine how to deal with issues
            where a security operation verifies in one fragment but fails
            in another fragment. This might happen, for example, if a BIB block 
            becomes corrupted in one fragment but not in another fragment.<a href="#section-6.5-2.3" class="pilcrow">¶</a>
</li>
        </ul>
<p id="section-6.5-3">
        Implementors should consider how security blocks are processed when
        a BPA fragments a received bundle. For example, security blocks and their targets 
        could be placed in the same fragment if the security block is not 
        otherwise cryptographically bound to the bundle being fragmented.
        Alternatively, if security blocks are cryptographically bound to a 
        bundle, then a fragmenting BPA should consider encapsulating the bundle 
        first and then fragmenting the encapsulating bundle.<a href="#section-6.5-3" class="pilcrow">¶</a></p>
</section>
</section>
</div>
<section id="section-7">
      <h2 id="name-normative-references">
<a href="#section-7" class="section-number selfRef">7. </a><a href="#name-normative-references" class="section-name selfRef">Normative References</a>
      </h2>
<dl class="references">
<dt id="AES-GCM">[AES-GCM]</dt>
      <dd>
<span class="refAuthor">Dworkin, M.</span>, <span class="refTitle">"Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC"</span>, <span class="seriesInfo">NIST Special Publication 800-38D</span>, <span class="seriesInfo">DOI 10.6028/NIST.SP.800-38D</span>, <time datetime="2007-11" class="refDate">November 2007</time>, <span>&lt;<a href="https://doi.org/10.6028/NIST.SP.800-38D">https://doi.org/10.6028/NIST.SP.800-38D</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2104">[RFC2104]</dt>
      <dd>
<span class="refAuthor">Krawczyk, H.</span>, <span class="refAuthor">Bellare, M.</span>, and <span class="refAuthor">R. Canetti</span>, <span class="refTitle">"HMAC: Keyed-Hashing for Message Authentication"</span>, <span class="seriesInfo">RFC 2104</span>, <span class="seriesInfo">DOI 10.17487/RFC2104</span>, <time datetime="1997-02" class="refDate">February 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2104">https://www.rfc-editor.org/info/rfc2104</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC2119">[RFC2119]</dt>
      <dd>
<span class="refAuthor">Bradner, S.</span>, <span class="refTitle">"Key words for use in RFCs to Indicate Requirement Levels"</span>, <span class="seriesInfo">BCP 14</span>, <span class="seriesInfo">RFC 2119</span>, <span class="seriesInfo">DOI 10.17487/RFC2119</span>, <time datetime="1997-03" class="refDate">March 1997</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc2119">https://www.rfc-editor.org/info/rfc2119</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC3394">[RFC3394]</dt>
      <dd>
<span class="refAuthor">Schaad, J.</span> and <span class="refAuthor">R. Housley</span>, <span class="refTitle">"Advanced Encryption Standard (AES) Key Wrap Algorithm"</span>, <span class="seriesInfo">RFC 3394</span>, <span class="seriesInfo">DOI 10.17487/RFC3394</span>, <time datetime="2002-09" class="refDate">September 2002</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc3394">https://www.rfc-editor.org/info/rfc3394</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8126">[RFC8126]</dt>
      <dd>
<span class="refAuthor">Cotton, M.</span>, <span class="refAuthor">Leiba, B.</span>, and <span class="refAuthor">T. Narten</span>, <span class="refTitle">"Guidelines for Writing an IANA Considerations Section in RFCs"</span>, <span class="seriesInfo">BCP 26</span>, <span class="seriesInfo">RFC 8126</span>, <span class="seriesInfo">DOI 10.17487/RFC8126</span>, <time datetime="2017-06" class="refDate">June 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8126">https://www.rfc-editor.org/info/rfc8126</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8152">[RFC8152]</dt>
      <dd>
<span class="refAuthor">Schaad, J.</span>, <span class="refTitle">"CBOR Object Signing and Encryption (COSE)"</span>, <span class="seriesInfo">RFC 8152</span>, <span class="seriesInfo">DOI 10.17487/RFC8152</span>, <time datetime="2017-07" class="refDate">July 2017</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8152">https://www.rfc-editor.org/info/rfc8152</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="RFC8742">[RFC8742]</dt>
      <dd>
<span class="refAuthor">Bormann, C.</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR) Sequences"</span>, <span class="seriesInfo">RFC 8742</span>, <span class="seriesInfo">DOI 10.17487/RFC8742</span>, <time datetime="2020-02" class="refDate">February 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8742">https://www.rfc-editor.org/info/rfc8742</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC8949">[RFC8949]</dt>
      <dd>
<span class="refAuthor">Bormann, C.</span> and <span class="refAuthor">P. Hoffman</span>, <span class="refTitle">"Concise Binary Object Representation (CBOR)"</span>, <span class="seriesInfo">STD 94</span>, <span class="seriesInfo">RFC 8949</span>, <span class="seriesInfo">DOI 10.17487/RFC8949</span>, <time datetime="2020-12" class="refDate">December 2020</time>, <span>&lt;<a href="https://www.rfc-editor.org/info/rfc8949">https://www.rfc-editor.org/info/rfc8949</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9171">[RFC9171]</dt>
      <dd>
<span class="refAuthor">Burleigh, S.</span>, <span class="refAuthor">Fall, K.</span>, and <span class="refAuthor">E. Birrane, III</span>, <span class="refTitle">"Bundle Protocol Version 7"</span>, <span class="seriesInfo">RFC 9171</span>, <span class="seriesInfo">DOI 10.17487/RFC9171</span>, <time datetime="2022-01" class="refDate">January 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9171">https://www.rfc-editor.org/rfc/rfc9171</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="RFC9172">[RFC9172]</dt>
      <dd>
<span class="refAuthor">Birrane, III, E.</span> and <span class="refAuthor">K. McKeever</span>, <span class="refTitle">"Bundle Protocol Security (BPSec)"</span>, <span class="seriesInfo">RFC 9172</span>, <span class="seriesInfo">DOI 10.17487/RFC9172</span>, <time datetime="2022-01" class="refDate">January 2022</time>, <span>&lt;<a href="https://www.rfc-editor.org/rfc/rfc9172">https://www.rfc-editor.org/rfc/rfc9172</a>&gt;</span>. </dd>
<dd class="break"></dd>
<dt id="SHS">[SHS]</dt>
    <dd>
<span class="refAuthor">National Institute of Standards and Technology</span>, <span class="refTitle">"Secure Hash Standard (SHS)"</span>, <span class="seriesInfo">FIPS PUB 180-4</span>, <span class="seriesInfo">DOI 10.6028/NIST.FIPS.180-4</span>, <time datetime="2015-08" class="refDate">August 2015</time>, <span>&lt;<a href="https://csrc.nist.gov/publications/detail/fips/180/4/final">https://csrc.nist.gov/publications/detail/fips/180/4/final</a>&gt;</span>. </dd>
<dd class="break"></dd>
</dl>
</section>
<div id="vectors">
<section id="appendix-A">
      <h2 id="name-examples">
<a href="#appendix-A" class="section-number selfRef">Appendix A. </a><a href="#name-examples" class="section-name selfRef">Examples</a>
      </h2>
<p id="appendix-A-1"> This appendix is informative.<a href="#appendix-A-1" class="pilcrow">¶</a></p>
<p id="appendix-A-2">
      This appendix presents a series of examples of constructing BPSec 
      security blocks (using the security contexts defined in this document)
      and adding those blocks to a sample bundle.<a href="#appendix-A-2" class="pilcrow">¶</a></p>
<p id="appendix-A-3"> 
      The examples presented in this appendix represent valid constructions of 
      bundles, security blocks, and the encoding of security context parameters 
      and results. For this reason, they can inform unit test suites 
      for individual implementations as well as interoperability test suites 
      amongst implementations. However, these examples do not cover every 
      permutation of security context parameters, security results, or use of security 
      blocks in a bundle.<a href="#appendix-A-3" class="pilcrow">¶</a></p>
<p id="appendix-A-4">
      NOTES:<a href="#appendix-A-4" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-A-5.1">The bundle diagrams in this appendix are patterned after the bundle
      diagrams used in Section <span><a href="https://www.rfc-editor.org/rfc/rfc9172#section-3.11" class="relref">3.11</a> (<a href="https://www.rfc-editor.org/rfc/rfc9172#section-3.11" class="relref">"BPSec Block Examples"</a>)</span> of <span>[<a href="#RFC9172" class="xref">RFC9172</a>]</span>.<a href="#appendix-A-5.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-A-5.2">
Figures in this appendix identified as "(CBOR Diagnostic Notation)" 
      are represented using the CBOR diagnostic notation defined in <span>[<a href="#RFC8949" class="xref">RFC8949</a>]</span>. 
      This notation is used to express CBOR data structures in a manner that enables 
      visual inspection. The bundles, security blocks, and security context contents
      in these figures are represented using CBOR structures. In cases where BP blocks 
      (to include BPSec security blocks) are comprised of a sequence of
      CBOR objects, these objects are represented as a CBOR sequence as defined in 
      <span>[<a href="#RFC8742" class="xref">RFC8742</a>]</span>.<a href="#appendix-A-5.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-A-5.3">
      Examples in this appendix use the "ipn" URI scheme for endpoint ID
      naming, as defined in <span>[<a href="#RFC9171" class="xref">RFC9171</a>]</span>.<a href="#appendix-A-5.3" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-A-5.4">
      The bundle source is presumed to be the security source for all
      security blocks in this appendix, unless otherwise noted.<a href="#appendix-A-5.4" class="pilcrow">¶</a>
</li>
      </ul>
<section id="appendix-A.1">
        <h3 id="name-example-1-simple-integrity">
<a href="#appendix-A.1" class="section-number selfRef">A.1. </a><a href="#name-example-1-simple-integrity" class="section-name selfRef">Example 1 - Simple Integrity</a>
        </h3>
<p id="appendix-A.1-1">
        This example shows the addition of a BIB to a sample bundle
        to provide integrity for the payload block.<a href="#appendix-A.1-1" class="pilcrow">¶</a></p>
<section id="appendix-A.1.1">
          <h4 id="name-original-bundle">
<a href="#appendix-A.1.1" class="section-number selfRef">A.1.1. </a><a href="#name-original-bundle" class="section-name selfRef">Original Bundle</a>
          </h4>
<p id="appendix-A.1.1-1">
          The following diagram shows the original bundle before the
          BIB has been added.<a href="#appendix-A.1.1-1" class="pilcrow">¶</a></p>
<span id="name-example-1-original-bundle"></span><figure id="figure-1">
            <div class="alignCenter art-text artwork" id="appendix-A.1.1-2.1">
<pre>
                  Block                    Block   Block
                in Bundle                  Type    Number
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
+----------------------------------------+-------+--------+
|  Payload Block                         |   1   |    1   |
+----------------------------------------+-------+--------+
</pre>
</div>
<figcaption><a href="#figure-1" class="selfRef">Figure 1</a>:
<a href="#name-example-1-original-bundle" class="selfRef">Example 1 - Original Bundle</a>
            </figcaption></figure>
<div id="ex_primary_block">
<section id="appendix-A.1.1.1">
            <h5 id="name-primary-block">
<a href="#appendix-A.1.1.1" class="section-number selfRef">A.1.1.1. </a><a href="#name-primary-block" class="section-name selfRef">Primary Block</a>
            </h5>
<p id="appendix-A.1.1.1-1">
            The Bundle Protocol version 7 (BPv7) bundle has no special block
            and bundle processing control flags, and no CRC is provided
            because the primary block is expected to be protected by an
            integrity service BIB using the BIB-HMAC-SHA2 security context.<a href="#appendix-A.1.1.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.1.1.1-2">
            The bundle is sourced at the source node ipn:2.1 and destined for
            the destination node ipn:1.2. 
The bundle creation time is set to 0, indicating lack of an accurate clock,
     with a 
            sequence number of 40. The lifetime of the bundle is given as
            1,000,000 milliseconds since the bundle creation time.<a href="#appendix-A.1.1.1-2" class="pilcrow">¶</a></p>
<p id="appendix-A.1.1.1-3">
            The primary block is provided as follows.<a href="#appendix-A.1.1.1-3" class="pilcrow">¶</a></p>
<span id="name-primary-block-cbor-diagnost"></span><div id="ex_bdl_prim">
<figure id="figure-2">
              <div id="appendix-A.1.1.1-4.1">
<pre class="lang-cbor-diag sourcecode">
[
  7,           / BP version            /
  0,           / flags                 /
  0,           / CRC type              /
  [2, [1,2]],  / destination (ipn:1.2) /
  [2, [2,1]],  / source      (ipn:2.1) /
  [2, [2,1]],  / report-to   (ipn:2.1) /
  [0, 40],     / timestamp             /
  1000000      / lifetime              /
]
</pre>
</div>
<figcaption><a href="#figure-2" class="selfRef">Figure 2</a>:
<a href="#name-primary-block-cbor-diagnost" class="selfRef">Primary Block (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.1.1.1-5">
            The CBOR encoding of the primary block is:<a href="#appendix-A.1.1.1-5" class="pilcrow">¶</a></p>
<div id="appendix-A.1.1.1-6">
<pre class="sourcecode">
0x88070000820282010282028202018202820201820018281a000f4240
</pre><a href="#appendix-A.1.1.1-6" class="pilcrow">¶</a>
</div>
</section>
</div>
<div id="ex_payload_block">
<section id="appendix-A.1.1.2">
            <h5 id="name-payload-block">
<a href="#appendix-A.1.1.2" class="section-number selfRef">A.1.1.2. </a><a href="#name-payload-block" class="section-name selfRef">Payload Block</a>
            </h5>
<p id="appendix-A.1.1.2-1">
            Other than its use as a source of plaintext for security blocks,
            the payload has no required distinguishing characteristic for the
            purpose of this example. The sample payload is a 35-byte string.<a href="#appendix-A.1.1.2-1" class="pilcrow">¶</a></p>
<p id="appendix-A.1.1.2-2">
            The payload is represented in the payload block as a byte string
            of the raw payload string. It is NOT represented as a CBOR text
            string wrapped within a CBOR binary string. The hex value of the
            payload is:<a href="#appendix-A.1.1.2-2" class="pilcrow">¶</a></p>
<div id="appendix-A.1.1.2-3">
<pre class="sourcecode">
0x526561647920746f2067656e657261746520612033322d62797465207061796c6f
6164
</pre><a href="#appendix-A.1.1.2-3" class="pilcrow">¶</a>
</div>
<p id="appendix-A.1.1.2-4">
            The payload block is provided as follows.<a href="#appendix-A.1.1.2-4" class="pilcrow">¶</a></p>
<span id="name-payload-block-cbor-diagnost"></span><figure id="figure-3">
              <div id="appendix-A.1.1.2-5.1">
<pre class="lang-cbor-diag sourcecode">
[
  1,                       / type code: Payload block       /
  1,                       / block number                   /
  0,                       / block processing control flags /
  0,                       / CRC type                       /
  h'526561647920746f206765 / type-specific-data: payload    /
  6e657261746520612033322d
  62797465207061796c6f6164'
]
</pre>
</div>
<figcaption><a href="#figure-3" class="selfRef">Figure 3</a>:
<a href="#name-payload-block-cbor-diagnost" class="selfRef">Payload Block (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
<p id="appendix-A.1.1.2-6">
            The CBOR encoding of the payload block is:<a href="#appendix-A.1.1.2-6" class="pilcrow">¶</a></p>
<div id="appendix-A.1.1.2-7">
<pre class="sourcecode">
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</pre><a href="#appendix-A.1.1.2-7" class="pilcrow">¶</a>
</div>
</section>
</div>
<section id="appendix-A.1.1.3">
            <h5 id="name-bundle-cbor-representation">
<a href="#appendix-A.1.1.3" class="section-number selfRef">A.1.1.3. </a><a href="#name-bundle-cbor-representation" class="section-name selfRef">Bundle CBOR Representation</a>
            </h5>
<p id="appendix-A.1.1.3-1">
            A BPv7 bundle is represented as an indefinite-length array consisting
            of the blocks comprising the bundle, with a terminator character at
            the end.<a href="#appendix-A.1.1.3-1" class="pilcrow">¶</a></p>
<p id="appendix-A.1.1.3-2">
            The CBOR encoding of the original bundle is:<a href="#appendix-A.1.1.3-2" class="pilcrow">¶</a></p>
<div id="appendix-A.1.1.3-3">
<pre class="sourcecode">
0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
</pre><a href="#appendix-A.1.1.3-3" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.1.2">
          <h4 id="name-security-operation-overview">
<a href="#appendix-A.1.2" class="section-number selfRef">A.1.2. </a><a href="#name-security-operation-overview" class="section-name selfRef">Security Operation Overview</a>
          </h4>
<p id="appendix-A.1.2-1">
          This example adds a BIB to the bundle using the BIB-HMAC-SHA2 security 
          context to provide an integrity mechanism over the payload block.<a href="#appendix-A.1.2-1" class="pilcrow">¶</a></p>
<p id="appendix-A.1.2-2">
          The following diagram shows the resulting bundle after the 
          BIB is added.<a href="#appendix-A.1.2-2" class="pilcrow">¶</a></p>
<span id="name-example-1-resulting-bundle"></span><figure id="figure-4">
            <div class="alignCenter art-text artwork" id="appendix-A.1.2-3.1">
<pre>
                  Block                    Block   Block
                in Bundle                  Type    Number
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
+----------------------------------------+-------+--------+
|  Block Integrity Block                 |   11  |    2   |
|  OP(bib-integrity, target=1)           |       |        |
+----------------------------------------+-------+--------+
|  Payload Block                         |   1   |    1   |
+----------------------------------------+-------+--------+
</pre>
</div>
<figcaption><a href="#figure-4" class="selfRef">Figure 4</a>:
<a href="#name-example-1-resulting-bundle" class="selfRef">Example 1 - Resulting Bundle</a>
            </figcaption></figure>
</section>
<section id="appendix-A.1.3">
          <h4 id="name-block-integrity-block">
<a href="#appendix-A.1.3" class="section-number selfRef">A.1.3. </a><a href="#name-block-integrity-block" class="section-name selfRef">Block Integrity Block</a>
          </h4>
<p id="appendix-A.1.3-1">
          In this example, a BIB is used to carry an integrity signature over
          the payload block.<a href="#appendix-A.1.3-1" class="pilcrow">¶</a></p>
<section id="appendix-A.1.3.1">
            <h5 id="name-configuration-parameters-an">
<a href="#appendix-A.1.3.1" class="section-number selfRef">A.1.3.1. </a><a href="#name-configuration-parameters-an" class="section-name selfRef">Configuration, Parameters, and Results</a>
            </h5>
<p id="appendix-A.1.3.1-1">
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.<a href="#appendix-A.1.3.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.1.3.1-2">
            This BIB has a single target and includes a single security
            result: the calculated signature over the payload block.<a href="#appendix-A.1.3.1-2" class="pilcrow">¶</a></p>
<span id="name-example-1-configuration-par"></span><div id="ex1_cpr">
<figure id="figure-5">
              <div class="alignCenter art-text artwork" id="appendix-A.1.3.1-3.1">
<pre>
 Key         : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
 SHA Variant : HMAC 512/512
 Scope Flags : 0x00
 Payload Data: h'526561647920746f2067656e65726174
                 6520612033322d62797465207061796c
                 6f6164'
 IPPT        : h'005823526561647920746f2067656e65
                 7261746520612033322d627974652070
                 61796c6f6164'
 Signature   : h'3bdc69b3a34a2b5d3a8554368bd1e808
                 f606219d2a10a846eae3886ae4ecc83c
                 4ee550fdfb1cc636b904e2f1a73e303d
                 cd4b6ccece003e95e8164dcc89a156e1'
</pre>
</div>
<figcaption><a href="#figure-5" class="selfRef">Figure 5</a>:
<a href="#name-example-1-configuration-par" class="selfRef">Example 1 - Configuration, Parameters, and Results</a>
              </figcaption></figure>
</div>
</section>
<section id="appendix-A.1.3.2">
            <h5 id="name-abstract-security-block">
<a href="#appendix-A.1.3.2" class="section-number selfRef">A.1.3.2. </a><a href="#name-abstract-security-block" class="section-name selfRef">Abstract Security Block</a>
            </h5>
<p id="appendix-A.1.3.2-1">
            The abstract security block structure of the BIB's
            block-type-specific data field for this application is as follows.<a href="#appendix-A.1.3.2-1" class="pilcrow">¶</a></p>
<span id="name-example-1-bib-abstract-secu"></span><div id="ex1_bib_asb">
<figure id="figure-6">
              <div id="appendix-A.1.3.2-2.1">
<pre class="lang-cbor-diag sourcecode">
[1],           / Security Target        - Payload block       /
1,             / Security Context ID    - BIB-HMAC-SHA2       /
1,             / Security Context Flags - Parameters Present  /
[2,[2, 1]],    / Security Source        - ipn:2.1             /
[              / Security Parameters    - 2 Parameters        /
   [1, 7],     / SHA Variant            - HMAC 512/512        /
   [3, 0x00]   / Scope Flags            - No Additional Scope /
],
[              / Security Results: 1 Result                   /
  [            / Target 1 Results                             /
    [1, h'3bdc69b3a34a2b5d3a8554368bd1e808         / MAC      /
          f606219d2a10a846eae3886ae4ecc83c
          4ee550fdfb1cc636b904e2f1a73e303d
          cd4b6ccece003e95e8164dcc89a156e1']
  ]
]
</pre>
</div>
<figcaption><a href="#figure-6" class="selfRef">Figure 6</a>:
<a href="#name-example-1-bib-abstract-secu" class="selfRef">Example 1 - BIB Abstract Security Block (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.1.3.2-3">
            The CBOR encoding of the BIB block-type-specific data field (the abstract security block) is:<a href="#appendix-A.1.3.2-3" class="pilcrow">¶</a></p>
<div id="appendix-A.1.3.2-4">
<pre class="sourcecode">
0x810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a8554
368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2f1a7
3e303dcd4b6ccece003e95e8164dcc89a156e1
</pre><a href="#appendix-A.1.3.2-4" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.1.3.3">
            <h5 id="name-representations">
<a href="#appendix-A.1.3.3" class="section-number selfRef">A.1.3.3. </a><a href="#name-representations" class="section-name selfRef">Representations</a>
            </h5>
<p id="appendix-A.1.3.3-1">
            The complete BIB is as follows.<a href="#appendix-A.1.3.3-1" class="pilcrow">¶</a></p>
<span id="name-example-1-bib-cbor-diagnost"></span><div id="ex1_bib">
<figure id="figure-7">
              <div id="appendix-A.1.3.3-2.1">
<pre class="lang-cbor-diag sourcecode">
[
  11, / type code    /
  2,  / block number /
  0,  / flags        /
  0,  / CRC type     /
  h'810101018202820201828201078203008181820158403bdc69b3a34a
  2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550
  fdfb1cc636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1'
]
</pre>
</div>
<figcaption><a href="#figure-7" class="selfRef">Figure 7</a>:
<a href="#name-example-1-bib-cbor-diagnost" class="selfRef">Example 1 - BIB (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.1.3.3-3">
            The CBOR encoding of the BIB block is:<a href="#appendix-A.1.3.3-3" class="pilcrow">¶</a></p>
<div id="appendix-A.1.3.3-4">
<pre class="sourcecode">
0x850b0200005856810101018202820201828201078203008181820158403bdc69b3
a34a2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1c
c636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1
</pre><a href="#appendix-A.1.3.3-4" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.1.4">
          <h4 id="name-final-bundle">
<a href="#appendix-A.1.4" class="section-number selfRef">A.1.4. </a><a href="#name-final-bundle" class="section-name selfRef">Final Bundle</a>
          </h4>
<p id="appendix-A.1.4-1">
          The CBOR encoding of the full output bundle, with the BIB:<a href="#appendix-A.1.4-1" class="pilcrow">¶</a></p>
<div id="appendix-A.1.4-2">
<pre class="sourcecode">
0x9f88070000820282010282028202018202820201820018281a000f4240850b0200
005856810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a
8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2
f1a73e303dcd4b6ccece003e95e8164dcc89a156e185010100005823526561647920
746f2067656e657261746520612033322d62797465207061796c6f6164ff
</pre><a href="#appendix-A.1.4-2" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.2">
        <h3 id="name-example-2-simple-confidenti">
<a href="#appendix-A.2" class="section-number selfRef">A.2. </a><a href="#name-example-2-simple-confidenti" class="section-name selfRef">Example 2 - Simple Confidentiality with Key Wrap</a>
        </h3>
<p id="appendix-A.2-1">
        This example shows the addition of a BCB to a sample bundle
        to provide confidentiality for the payload block. AES key wrap 
        is used to transmit the symmetric key used to generate the
        security results for this service.<a href="#appendix-A.2-1" class="pilcrow">¶</a></p>
<section id="appendix-A.2.1">
          <h4 id="name-original-bundle-2">
<a href="#appendix-A.2.1" class="section-number selfRef">A.2.1. </a><a href="#name-original-bundle-2" class="section-name selfRef">Original Bundle</a>
          </h4>
<p id="appendix-A.2.1-1">
          The following diagram shows the original bundle before the
          BCB has been added.<a href="#appendix-A.2.1-1" class="pilcrow">¶</a></p>
<span id="name-example-2-original-bundle"></span><figure id="figure-8">
            <div class="alignCenter art-text artwork" id="appendix-A.2.1-2.1">
<pre>
                  Block                    Block   Block
                in Bundle                  Type    Number
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
+----------------------------------------+-------+--------+
|  Payload Block                         |   1   |    1   |
+----------------------------------------+-------+--------+
</pre>
</div>
<figcaption><a href="#figure-8" class="selfRef">Figure 8</a>:
<a href="#name-example-2-original-bundle" class="selfRef">Example 2 - Original Bundle</a>
            </figcaption></figure>
<section id="appendix-A.2.1.1">
            <h5 id="name-primary-block-2">
<a href="#appendix-A.2.1.1" class="section-number selfRef">A.2.1.1. </a><a href="#name-primary-block-2" class="section-name selfRef">Primary Block</a>
            </h5>
<p id="appendix-A.2.1.1-1">
           The primary block used in this example is identical to the primary block
           presented for Example 1 in <a href="#ex_primary_block" class="xref">Appendix A.1.1.1</a>.<a href="#appendix-A.2.1.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.2.1.1-2"> 
            In summary, the CBOR encoding of the primary block is:<a href="#appendix-A.2.1.1-2" class="pilcrow">¶</a></p>
<div id="appendix-A.2.1.1-3">
<pre class="sourcecode">
0x88070000820282010282028202018202820201820018281a000f4240
</pre><a href="#appendix-A.2.1.1-3" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.2.1.2">
            <h5 id="name-payload-block-2">
<a href="#appendix-A.2.1.2" class="section-number selfRef">A.2.1.2. </a><a href="#name-payload-block-2" class="section-name selfRef">Payload Block</a>
            </h5>
<p id="appendix-A.2.1.2-1">
           The payload block used in this example is identical to the payload block
           presented for Example 1 in <a href="#ex_payload_block" class="xref">Appendix A.1.1.2</a>.<a href="#appendix-A.2.1.2-1" class="pilcrow">¶</a></p>
<p id="appendix-A.2.1.2-2"> 
            In summary, the CBOR encoding of the payload block is:<a href="#appendix-A.2.1.2-2" class="pilcrow">¶</a></p>
<div id="appendix-A.2.1.2-3">
<pre class="sourcecode">
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</pre><a href="#appendix-A.2.1.2-3" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.2.1.3">
            <h5 id="name-bundle-cbor-representation-2">
<a href="#appendix-A.2.1.3" class="section-number selfRef">A.2.1.3. </a><a href="#name-bundle-cbor-representation-2" class="section-name selfRef">Bundle CBOR Representation</a>
            </h5>
<p id="appendix-A.2.1.3-1">
            A BPv7 bundle is represented as an indefinite-length array consisting
            of the blocks comprising the bundle, with a terminator character at
            the end.<a href="#appendix-A.2.1.3-1" class="pilcrow">¶</a></p>
<p id="appendix-A.2.1.3-2">
            The CBOR encoding of the original bundle is:<a href="#appendix-A.2.1.3-2" class="pilcrow">¶</a></p>
<div id="appendix-A.2.1.3-3">
<pre class="sourcecode">
0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
</pre><a href="#appendix-A.2.1.3-3" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.2.2">
          <h4 id="name-security-operation-overview-2">
<a href="#appendix-A.2.2" class="section-number selfRef">A.2.2. </a><a href="#name-security-operation-overview-2" class="section-name selfRef">Security Operation Overview</a>
          </h4>
<p id="appendix-A.2.2-1">
          This example adds a BCB using the BCB-AES-GCM security context 
          using AES key wrap to provide a confidentiality mechanism over 
          the payload block and transmit the symmetric key.<a href="#appendix-A.2.2-1" class="pilcrow">¶</a></p>
<p id="appendix-A.2.2-2">
          The following diagram shows the resulting bundle after the 
          BCB is added.<a href="#appendix-A.2.2-2" class="pilcrow">¶</a></p>
<span id="name-example-2-resulting-bundle"></span><figure id="figure-9">
            <div class="alignCenter art-text artwork" id="appendix-A.2.2-3.1">
<pre>
                  Block                    Block   Block
                in Bundle                  Type    Number
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
+----------------------------------------+-------+--------+
|  Block Confidentiality Block           |   12  |    2   |
|  OP(bcb-confidentiality, target=1)     |       |        |
+----------------------------------------+-------+--------+
|  Payload Block (Encrypted)             |   1   |    1   |
+----------------------------------------+-------+--------+
</pre>
</div>
<figcaption><a href="#figure-9" class="selfRef">Figure 9</a>:
<a href="#name-example-2-resulting-bundle" class="selfRef">Example 2 - Resulting Bundle</a>
            </figcaption></figure>
</section>
<section id="appendix-A.2.3">
          <h4 id="name-block-confidentiality-block">
<a href="#appendix-A.2.3" class="section-number selfRef">A.2.3. </a><a href="#name-block-confidentiality-block" class="section-name selfRef">Block Confidentiality Block</a>
          </h4>
<p id="appendix-A.2.3-1">
  In this example, a BCB is used to encrypt the payload block, and AES key
  wrap is used to encode the symmetric key prior to its inclusion in the BCB.<a href="#appendix-A.2.3-1" class="pilcrow">¶</a></p>
<section id="appendix-A.2.3.1">
            <h5 id="name-configuration-parameters-and">
<a href="#appendix-A.2.3.1" class="section-number selfRef">A.2.3.1. </a><a href="#name-configuration-parameters-and" class="section-name selfRef">Configuration, Parameters, and Results</a>
            </h5>
<p id="appendix-A.2.3.1-1">
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.<a href="#appendix-A.2.3.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.2.3.1-2">
            This BCB has a single target -- the payload block. Three
            security results are generated: ciphertext that
            replaces the plaintext block-type-specific data to
            encrypt the payload block, an authentication tag, and
            the AES wrapped key.<a href="#appendix-A.2.3.1-2" class="pilcrow">¶</a></p>
<span id="name-example-2-configuration-par"></span><div id="ex2_cpr">
<figure id="figure-10">
              <div class="alignCenter art-text artwork" id="appendix-A.2.3.1-3.1">
<pre>
 Content Encryption
                Key: h'71776572747975696f70617364666768'
 Key Encryption Key: h'6162636465666768696a6b6c6d6e6f70'
                 IV: h'5477656c7665313231323132'
        AES Variant: A128GCM
    AES Wrapped Key: h'69c411276fecddc4780df42c8a2af892
                       96fabf34d7fae700'
        Scope Flags: 0x00
       Payload Data: h'526561647920746f2067656e65726174
                       6520612033322d62797465207061796c
                       6f6164'
                AAD: h'00'
 Authentication Tag: h'efa4b5ac0108e3816c5606479801bc04'
 Payload Ciphertext: h'3a09c1e63fe23a7f66a59c7303837241
                       e070b02619fc59c5214a22f08cd70795
                       e73e9a'
</pre>
</div>
<figcaption><a href="#figure-10" class="selfRef">Figure 10</a>:
<a href="#name-example-2-configuration-par" class="selfRef">Example 2 - Configuration, Parameters, and Results</a>
              </figcaption></figure>
</div>
</section>
<section id="appendix-A.2.3.2">
            <h5 id="name-abstract-security-block-2">
<a href="#appendix-A.2.3.2" class="section-number selfRef">A.2.3.2. </a><a href="#name-abstract-security-block-2" class="section-name selfRef">Abstract Security Block</a>
            </h5>
<p id="appendix-A.2.3.2-1">
            The abstract security block structure of the BCB's
            block-type-specific data field for this application is as follows.<a href="#appendix-A.2.3.2-1" class="pilcrow">¶</a></p>
<span id="name-example-2-bcb-abstract-secu"></span><div id="ex2_bcb_asb">
<figure id="figure-11">
              <div id="appendix-A.2.3.2-2.1">
<pre class="lang-cbor-diag sourcecode">
[1],               / Security Target        - Payload block       /
2,                 / Security Context ID    - BCB-AES-GCM         /
1,                 / Security Context Flags - Parameters Present  /
[2,[2, 1]],        / Security Source        - ipn:2.1             /
[                  / Security Parameters    - 4 Parameters        /
  [1, h'5477656c7665313231323132'], / Initialization Vector       /
  [2, 1],                           / AES Variant - A128GCM       /
  [3, h'69c411276fecddc4780df42c8a  / AES wrapped key             /
        2af89296fabf34d7fae700'],
  [4, 0x00]                         / Scope Flags - No extra scope/
],
[                                   /  Security Results: 1 Result /
  [                                 /  Target 1 Results           /
    [1, h'efa4b5ac0108e3816c5606479801bc04']  / Payload Auth. Tag /
  ]
]
</pre>
</div>
<figcaption><a href="#figure-11" class="selfRef">Figure 11</a>:
<a href="#name-example-2-bcb-abstract-secu" class="selfRef">Example 2 - BCB Abstract Security Block (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.2.3.2-3">
            The CBOR encoding of the BCB block-type-specific data field 
            (the abstract security block) is:<a href="#appendix-A.2.3.2-3" class="pilcrow">¶</a></p>
<div id="appendix-A.2.3.2-4">
<pre class="sourcecode">
0x8101020182028202018482014c5477656c76653132313231328202018203581869
c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150efa4b5
ac0108e3816c5606479801bc04
</pre><a href="#appendix-A.2.3.2-4" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.2.3.3">
            <h5 id="name-representations-2">
<a href="#appendix-A.2.3.3" class="section-number selfRef">A.2.3.3. </a><a href="#name-representations-2" class="section-name selfRef">Representations</a>
            </h5>
<p id="appendix-A.2.3.3-1">
            The complete BCB is as follows.<a href="#appendix-A.2.3.3-1" class="pilcrow">¶</a></p>
<span id="name-example-2-bcb-cbor-diagnost"></span><div id="ex2_bcb">
<figure id="figure-12">
              <div id="appendix-A.2.3.3-2.1">
<pre class="lang-cbor-diag sourcecode">
[
  12, / type code                                          /
  2,  / block number                                       /
  1,  / flags - block must be replicated in every fragment /
  0,  / CRC type                                           /
  h'8101020182028202018482014c5477656c766531323132313282020182035818
    69c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150
    efa4b5ac0108e3816c5606479801bc04'
]
</pre>
</div>
<figcaption><a href="#figure-12" class="selfRef">Figure 12</a>:
<a href="#name-example-2-bcb-cbor-diagnost" class="selfRef">Example 2 - BCB (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.2.3.3-3">
            The CBOR encoding of the BCB block is:<a href="#appendix-A.2.3.3-3" class="pilcrow">¶</a></p>
<div id="appendix-A.2.3.3-4">
<pre class="sourcecode">
0x850c02010058508101020182028202018482014c5477656c766531323132313282
02018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081
81820150efa4b5ac0108e3816c5606479801bc04
</pre><a href="#appendix-A.2.3.3-4" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.2.4">
          <h4 id="name-final-bundle-2">
<a href="#appendix-A.2.4" class="section-number selfRef">A.2.4. </a><a href="#name-final-bundle-2" class="section-name selfRef">Final Bundle</a>
          </h4>
<p id="appendix-A.2.4-1">
          The CBOR encoding of the full output bundle, with the BCB:<a href="#appendix-A.2.4-1" class="pilcrow">¶</a></p>
<div id="appendix-A.2.4-2">
<pre class="sourcecode">
0x9f88070000820282010282028202018202820201820018281a000f4240850c0201
0058508101020182028202018482014c5477656c7665313231323132820201820358
1869c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150ef
a4b5ac0108e3816c5606479801bc04850101000058233a09c1e63fe23a7f66a59c73
03837241e070b02619fc59c5214a22f08cd70795e73e9aff
</pre><a href="#appendix-A.2.4-2" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.3">
        <h3 id="name-example-3-security-blocks-f">
<a href="#appendix-A.3" class="section-number selfRef">A.3. </a><a href="#name-example-3-security-blocks-f" class="section-name selfRef">Example 3 - Security Blocks from Multiple Sources</a>
        </h3>
<p id="appendix-A.3-1">
        This example shows the addition of a BIB and BCB to 
        a sample bundle. These two security blocks are added 
        by two different nodes. The BCB is added by the source 
        endpoint, and the BIB is added by a forwarding node.<a href="#appendix-A.3-1" class="pilcrow">¶</a></p>
<p id="appendix-A.3-2">
        The resulting bundle contains a BCB to encrypt the 
        Payload Block and a BIB to provide integrity to the 
        primary block and Bundle Age Block.<a href="#appendix-A.3-2" class="pilcrow">¶</a></p>
<section id="appendix-A.3.1">
          <h4 id="name-original-bundle-3">
<a href="#appendix-A.3.1" class="section-number selfRef">A.3.1. </a><a href="#name-original-bundle-3" class="section-name selfRef">Original Bundle</a>
          </h4>
<p id="appendix-A.3.1-1">
          The following diagram shows the original bundle before the
          security blocks have been added.<a href="#appendix-A.3.1-1" class="pilcrow">¶</a></p>
<span id="name-example-3-original-bundle"></span><figure id="figure-13">
            <div class="alignCenter art-text artwork" id="appendix-A.3.1-2.1">
<pre>
                  Block                    Block   Block
                in Bundle                  Type    Number
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
+----------------------------------------+-------+--------+
|  Extension Block: Bundle Age Block     |   7   |    2   |
+----------------------------------------+-------+--------+
|  Payload Block                         |   1   |    1   |
+----------------------------------------+-------+--------+
</pre>
</div>
<figcaption><a href="#figure-13" class="selfRef">Figure 13</a>:
<a href="#name-example-3-original-bundle" class="selfRef">Example 3 - Original Bundle</a>
            </figcaption></figure>
<section id="appendix-A.3.1.1">
            <h5 id="name-primary-block-3">
<a href="#appendix-A.3.1.1" class="section-number selfRef">A.3.1.1. </a><a href="#name-primary-block-3" class="section-name selfRef">Primary Block</a>
            </h5>
<p id="appendix-A.3.1.1-1">
           The primary block used in this example is identical to the primary block
           presented for Example 1 in <a href="#ex_primary_block" class="xref">Appendix A.1.1.1</a>.<a href="#appendix-A.3.1.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.3.1.1-2"> 
            In summary, the CBOR encoding of the primary block is:<a href="#appendix-A.3.1.1-2" class="pilcrow">¶</a></p>
<div id="appendix-A.3.1.1-3">
<pre class="sourcecode">
0x88070000820282010282028202018202820201820018281a000f4240
</pre><a href="#appendix-A.3.1.1-3" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.3.1.2">
            <h5 id="name-bundle-age-block">
<a href="#appendix-A.3.1.2" class="section-number selfRef">A.3.1.2. </a><a href="#name-bundle-age-block" class="section-name selfRef">Bundle Age Block</a>
            </h5>
<p id="appendix-A.3.1.2-1">
          A Bundle Age Block is added to the bundle to help other nodes in the
          network determine the age of the bundle. The use of this block is
          recommended because the bundle source does not have an accurate
          clock (as indicated by the DTN time of 0).<a href="#appendix-A.3.1.2-1" class="pilcrow">¶</a></p>
<p id="appendix-A.3.1.2-2">
          Because this block is specified at the time the bundle is being
          forwarded, the bundle age represents the time that has elapsed 
          from the time the bundle was created to the time it is being prepared
          for forwarding.  In this case, the value is given as 300 milliseconds.<a href="#appendix-A.3.1.2-2" class="pilcrow">¶</a></p>
<p id="appendix-A.3.1.2-3">
          The Bundle Age extension block is provided as follows.<a href="#appendix-A.3.1.2-3" class="pilcrow">¶</a></p>
<span id="name-bundle-age-block-cbor-diagn"></span><div id="ex_bdl_age">
<figure id="figure-14">
              <div id="appendix-A.3.1.2-4.1">
<pre class="lang-cbor-diag sourcecode">
[
  7,      / type code: Bundle Age Block    /
  2,      / block number                   /
  0,      / block processing control flags /
  0,      / CRC type                       /
  &lt;&lt;300&gt;&gt; / type-specific-data: age        /
]
</pre>
</div>
<figcaption><a href="#figure-14" class="selfRef">Figure 14</a>:
<a href="#name-bundle-age-block-cbor-diagn" class="selfRef">Bundle Age Block (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.3.1.2-5">
            The CBOR encoding of the Bundle Age Block is:<a href="#appendix-A.3.1.2-5" class="pilcrow">¶</a></p>
<div id="appendix-A.3.1.2-6">
<pre class="sourcecode">
0x85070200004319012c
</pre><a href="#appendix-A.3.1.2-6" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.3.1.3">
            <h5 id="name-payload-block-3">
<a href="#appendix-A.3.1.3" class="section-number selfRef">A.3.1.3. </a><a href="#name-payload-block-3" class="section-name selfRef">Payload Block</a>
            </h5>
<p id="appendix-A.3.1.3-1">
           The payload block used in this example is identical to the payload block
           presented for Example 1 in <a href="#ex_payload_block" class="xref">Appendix A.1.1.2</a>.<a href="#appendix-A.3.1.3-1" class="pilcrow">¶</a></p>
<p id="appendix-A.3.1.3-2"> 
            In summary, the CBOR encoding of the payload block is:<a href="#appendix-A.3.1.3-2" class="pilcrow">¶</a></p>
<div id="appendix-A.3.1.3-3">
<pre class="sourcecode">
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</pre><a href="#appendix-A.3.1.3-3" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.3.1.4">
            <h5 id="name-bundle-cbor-representation-3">
<a href="#appendix-A.3.1.4" class="section-number selfRef">A.3.1.4. </a><a href="#name-bundle-cbor-representation-3" class="section-name selfRef">Bundle CBOR Representation</a>
            </h5>
<p id="appendix-A.3.1.4-1">
            A BPv7 bundle is represented as an indefinite-length array consisting
            of the blocks comprising the bundle, with a terminator character at
            the end.<a href="#appendix-A.3.1.4-1" class="pilcrow">¶</a></p>
<p id="appendix-A.3.1.4-2">
            The CBOR encoding of the original bundle is:<a href="#appendix-A.3.1.4-2" class="pilcrow">¶</a></p>
<div id="appendix-A.3.1.4-3">
<pre class="sourcecode">
0x9f88070000820282010282028202018202820201820018281a000f424085070200
004319012c85010100005823526561647920746f2067656e65726174652061203332
2d62797465207061796c6f6164ff
</pre><a href="#appendix-A.3.1.4-3" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.3.2">
          <h4 id="name-security-operation-overview-3">
<a href="#appendix-A.3.2" class="section-number selfRef">A.3.2. </a><a href="#name-security-operation-overview-3" class="section-name selfRef">Security Operation Overview</a>
          </h4>
<p id="appendix-A.3.2-1">
          This example provides:<a href="#appendix-A.3.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-A.3.2-2.1"> 
              a BIB with the BIB-HMAC-SHA2 security context to provide an 
              integrity mechanism over the primary block and Bundle Age 
              Block.<a href="#appendix-A.3.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-A.3.2-2.2">
              a BCB with the BCB-AES-GCM security context to provide a
              confidentiality mechanism over the payload block.<a href="#appendix-A.3.2-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="appendix-A.3.2-3">
          The following diagram shows the resulting bundle after the 
          security blocks are added.<a href="#appendix-A.3.2-3" class="pilcrow">¶</a></p>
<span id="name-example-3-resulting-bundle"></span><figure id="figure-15">
            <div class="alignCenter art-text artwork" id="appendix-A.3.2-4.1">
<pre>
                  Block                    Block   Block
                in Bundle                  Type    Number
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
+----------------------------------------+-------+--------+
|  Block Integrity Block                 |   11  |    3   |
|  OP(bib-integrity, targets=0, 2)       |       |        |
+----------------------------------------+-------+--------+
|  Block Confidentiality Block           |   12  |    4   |
|  OP(bcb-confidentiality, target=1)     |       |        |
+----------------------------------------+-------+--------+
|  Extension Block: Bundle Age Block     |   7   |    2   |
+----------------------------------------+-------+--------+
|  Payload Block (Encrypted)             |   1   |    1   |
+----------------------------------------+-------+--------+
</pre>
</div>
<figcaption><a href="#figure-15" class="selfRef">Figure 15</a>:
<a href="#name-example-3-resulting-bundle" class="selfRef">Example 3 - Resulting Bundle</a>
            </figcaption></figure>
</section>
<section id="appendix-A.3.3">
          <h4 id="name-block-integrity-block-2">
<a href="#appendix-A.3.3" class="section-number selfRef">A.3.3. </a><a href="#name-block-integrity-block-2" class="section-name selfRef">Block Integrity Block</a>
          </h4>
<p id="appendix-A.3.3-1">
          In this example, a BIB is used to carry an integrity signature over
          the Bundle Age Block and an additional signature over the 
          payload block. The BIB is added by a waypoint node -- ipn:3.0.<a href="#appendix-A.3.3-1" class="pilcrow">¶</a></p>
<section id="appendix-A.3.3.1">
            <h5 id="name-configuration-parameters-and-">
<a href="#appendix-A.3.3.1" class="section-number selfRef">A.3.3.1. </a><a href="#name-configuration-parameters-and-" class="section-name selfRef">Configuration, Parameters, and Results</a>
            </h5>
<p id="appendix-A.3.3.1-1">
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.<a href="#appendix-A.3.3.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.3.3.1-2">
            This BIB has two security targets and includes two
            security results, holding the calculated signatures over
            the Bundle Age Block and primary block.<a href="#appendix-A.3.3.1-2" class="pilcrow">¶</a></p>
<span id="name-example-3-configuration-par"></span><div id="ex3_bib_cpr">
<figure id="figure-16">
              <div class="alignCenter art-text artwork" id="appendix-A.3.3.1-3.1">
<pre>
                Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
        SHA Variant: HMAC 256/256
        Scope Flags: 0x00
 Primary Block Data: h'88070000820282010282028202018202
                       820201820018281a000f4240'
 Bundle Age Block
               Data: h'4319012c'
 Primary Block IPPT: h'00581c88070000820282010282028202
                       018202820201820018281a000f4240'
Bundle Age Block
               IPPT: h'004319012c'
 Primary Block
          Signature: h'cac6ce8e4c5dae57988b757e49a6dd14
                       31dc04763541b2845098265bc817241b'
 Bundle Age Block
          Signature: h'3ed614c0d97f49b3633627779aa18a33
                       8d212bf3c92b97759d9739cd50725596'
</pre>
</div>
<figcaption><a href="#figure-16" class="selfRef">Figure 16</a>:
<a href="#name-example-3-configuration-par" class="selfRef">Example 3 - Configuration, Parameters, and Results for the BIB</a>
              </figcaption></figure>
</div>
</section>
<section id="appendix-A.3.3.2">
            <h5 id="name-abstract-security-block-3">
<a href="#appendix-A.3.3.2" class="section-number selfRef">A.3.3.2. </a><a href="#name-abstract-security-block-3" class="section-name selfRef">Abstract Security Block</a>
            </h5>
<p id="appendix-A.3.3.2-1">
            The abstract security block structure of the BIB's
            block-type-specific data field for this application is as follows.<a href="#appendix-A.3.3.2-1" class="pilcrow">¶</a></p>
<span id="name-example-3-bib-abstract-secu"></span><div id="ex3_bib_asb">
<figure id="figure-17">
              <div id="appendix-A.3.3.2-2.1">
<pre class="lang-cbor-diag sourcecode">
[0, 2],         / Security Targets                             /
1,              / Security Context ID    - BIB-HMAC-SHA2       /
1,              / Security Context Flags - Parameters Present  /
[2,[3, 0]],     / Security Source        - ipn:3.0             /
[               / Security Parameters    - 2 Parameters        /
   [1, 5],      / SHA Variant            - HMAC 256            /
   [3, 0]       / Scope Flags            - No Additional Scope /
],
[               / Security Results: 2 Results                  /
   [            / Primary Block Results                        /
       [1, h'cac6ce8e4c5dae57988b757e49a6dd14
             31dc04763541b2845098265bc817241b']       / MAC    /
    ],
    [           / Bundle Age Block Results                     /
       [1, h'3ed614c0d97f49b3633627779aa18a33
             8d212bf3c92b97759d9739cd50725596']       / MAC    /
    ]
]
</pre>
</div>
<figcaption><a href="#figure-17" class="selfRef">Figure 17</a>:
<a href="#name-example-3-bib-abstract-secu" class="selfRef">Example 3 - BIB Abstract Security Block (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.3.3.2-3">
            The CBOR encoding of the BIB block-type-specific data field (the abstract security block) is:<a href="#appendix-A.3.3.2-3" class="pilcrow">¶</a></p>
<div id="appendix-A.3.3.2-4">
<pre class="sourcecode">
0x8200020101820282030082820105820300828182015820cac6ce8e4c5dae57988b
757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d97f49
b3633627779aa18a338d212bf3c92b97759d9739cd50725596
</pre><a href="#appendix-A.3.3.2-4" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.3.3.3">
            <h5 id="name-representations-3">
<a href="#appendix-A.3.3.3" class="section-number selfRef">A.3.3.3. </a><a href="#name-representations-3" class="section-name selfRef">Representations</a>
            </h5>
<p id="appendix-A.3.3.3-1">
            The complete BIB is as follows.<a href="#appendix-A.3.3.3-1" class="pilcrow">¶</a></p>
<span id="name-example-3-bib-cbor-diagnost"></span><div id="ex3_bib">
<figure id="figure-18">
              <div id="appendix-A.3.3.3-2.1">
<pre class="lang-cbor-diag sourcecode">
[
  11, / type code    /
  3,  / block number /
  0,  / flags        /
  0,  / CRC type     /
  h'8200020101820282030082820105820300828182015820cac6ce8e4c5dae5798
  8b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9
  7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596'
]
</pre>
</div>
<figcaption><a href="#figure-18" class="selfRef">Figure 18</a>:
<a href="#name-example-3-bib-cbor-diagnost" class="selfRef">Example 3 - BIB (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.3.3.3-3">
            The CBOR encoding of the BIB block is:<a href="#appendix-A.3.3.3-3" class="pilcrow">¶</a></p>
<div id="appendix-A.3.3.3-4">
<pre class="sourcecode">
0x850b030000585c8200020101820282030082820105820300828182015820cac6ce
8e4c5dae57988b757e49a6dd1431dc04763541b2845098265bc817241b8182015820
3ed614c0d97f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596
</pre><a href="#appendix-A.3.3.3-4" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.3.4">
          <h4 id="name-block-confidentiality-block-2">
<a href="#appendix-A.3.4" class="section-number selfRef">A.3.4. </a><a href="#name-block-confidentiality-block-2" class="section-name selfRef">Block Confidentiality Block</a>
          </h4>
<p id="appendix-A.3.4-1">
          In this example, a BCB is used encrypt the payload
          block. The BCB is added by the bundle source node, ipn:2.1.<a href="#appendix-A.3.4-1" class="pilcrow">¶</a></p>
<section id="appendix-A.3.4.1">
            <h5 id="name-configuration-parameters-and-r">
<a href="#appendix-A.3.4.1" class="section-number selfRef">A.3.4.1. </a><a href="#name-configuration-parameters-and-r" class="section-name selfRef">Configuration, Parameters, and Results</a>
            </h5>
<p id="appendix-A.3.4.1-1">
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.<a href="#appendix-A.3.4.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.3.4.1-2">
            This BCB has a single target, the payload block. 
            Two security results are generated: ciphertext that 
            replaces the plaintext block-type-specific data to
            encrypt the payload block and an authentication tag.<a href="#appendix-A.3.4.1-2" class="pilcrow">¶</a></p>
<span id="name-example-3-configuration-para"></span><div id="ex3_bcb_cpr">
<figure id="figure-19">
              <div class="alignCenter art-text artwork" id="appendix-A.3.4.1-3.1">
<pre>
 Content Encryption
                Key: h'71776572747975696f70617364666768'
                 IV: h'5477656c7665313231323132'
        AES Variant: A128GCM
        Scope Flags: 0x00
       Payload Data: h'526561647920746f2067656e65726174
                       6520612033322d62797465207061796c
                       6f6164'
                AAD: h'00'
 Authentication Tag: h'efa4b5ac0108e3816c5606479801bc04'
 Payload Ciphertext: h'3a09c1e63fe23a7f66a59c7303837241
                       e070b02619fc59c5214a22f08cd70795
                       e73e9a'
</pre>
</div>
<figcaption><a href="#figure-19" class="selfRef">Figure 19</a>:
<a href="#name-example-3-configuration-para" class="selfRef">Example 3 - Configuration, Parameters, and Results for the BCB</a>
              </figcaption></figure>
</div>
</section>
<section id="appendix-A.3.4.2">
            <h5 id="name-abstract-security-block-4">
<a href="#appendix-A.3.4.2" class="section-number selfRef">A.3.4.2. </a><a href="#name-abstract-security-block-4" class="section-name selfRef">Abstract Security Block</a>
            </h5>
<p id="appendix-A.3.4.2-1">
            The abstract security block structure of the BCB's
            block-type-specific data field for this application is as follows.<a href="#appendix-A.3.4.2-1" class="pilcrow">¶</a></p>
<span id="name-example-3-bcb-abstract-secu"></span><div id="ex3_bcb_asb">
<figure id="figure-20">
              <div id="appendix-A.3.4.2-2.1">
<pre class="lang-cbor-diag sourcecode">
[1],             / Security Target        - Payload block      /
2,               / Security Context ID    - BCB-AES-GCM        /
1,               / Security Context Flags - Parameters Present /
[2,[2, 1]],      / Security Source        - ipn:2.1            /
[                / Security Parameters    - 3 Parameters       /
  [1, h'5477656c7665313231323132'],    / Initialization Vector /
  [2, 1],                              / AES Variant - AES 128 /
  [4, 0]                   / Scope Flags - No Additional Scope /
],
[                                 / Security Results: 1 Result /
  [
     [1, h'efa4b5ac0108e3816c5606479801bc04'] / Payload Auth. Tag /
  ]
]
</pre>
</div>
<figcaption><a href="#figure-20" class="selfRef">Figure 20</a>:
<a href="#name-example-3-bcb-abstract-secu" class="selfRef">Example 3 - BCB Abstract Security Block (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.3.4.2-3">
            The CBOR encoding of the BCB block-type-specific data field 
            (the abstract security block) is:<a href="#appendix-A.3.4.2-3" class="pilcrow">¶</a></p>
<div id="appendix-A.3.4.2-4">
<pre class="sourcecode">
0x8101020182028202018382014c5477656c76653132313231328202018204008181
820150efa4b5ac0108e3816c5606479801bc04
</pre><a href="#appendix-A.3.4.2-4" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.3.4.3">
            <h5 id="name-representations-4">
<a href="#appendix-A.3.4.3" class="section-number selfRef">A.3.4.3. </a><a href="#name-representations-4" class="section-name selfRef">Representations</a>
            </h5>
<p id="appendix-A.3.4.3-1">
            The complete BCB is as follows.<a href="#appendix-A.3.4.3-1" class="pilcrow">¶</a></p>
<span id="name-example-3-bcb-cbor-diagnost"></span><div id="ex3_bcb">
<figure id="figure-21">
              <div id="appendix-A.3.4.3-2.1">
<pre class="lang-cbor-diag sourcecode">
[
  12, / type code                                          /
  4,  / block number                                       /
  1,  / flags - block must be replicated in every fragment /
  0,  / CRC type                                           /
  h'8101020182028202018382014c5477656c766531323132313282020182040081
    81820150efa4b5ac0108e3816c5606479801bc04'
]
</pre>
</div>
<figcaption><a href="#figure-21" class="selfRef">Figure 21</a>:
<a href="#name-example-3-bcb-cbor-diagnost" class="selfRef">Example 3 - BCB (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.3.4.3-3">
            The CBOR encoding of the BCB block is:<a href="#appendix-A.3.4.3-3" class="pilcrow">¶</a></p>
<div id="appendix-A.3.4.3-4">
<pre class="sourcecode">
0x850c04010058348101020182028202018382014c5477656c766531323132313282
02018204008181820150efa4b5ac0108e3816c5606479801bc04
</pre><a href="#appendix-A.3.4.3-4" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.3.5">
          <h4 id="name-final-bundle-3">
<a href="#appendix-A.3.5" class="section-number selfRef">A.3.5. </a><a href="#name-final-bundle-3" class="section-name selfRef">Final Bundle</a>
          </h4>
<p id="appendix-A.3.5-1">
          The CBOR encoding of the full output bundle, with the BIB and BCB added is:<a href="#appendix-A.3.5-1" class="pilcrow">¶</a></p>
<div id="appendix-A.3.5-2">
<pre class="sourcecode">
0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
00585c8200020101820282030082820105820300828182015820cac6ce8e4c5dae57
988b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9
7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596850c0401005834
8101020182028202018382014c5477656c7665313231323132820201820400818182
0150efa4b5ac0108e3816c5606479801bc0485070200004319012c85010100005823
3a09c1e63fe23a7f66a59c7303837241e070b02619fc59c5214a22f08cd70795e73e
9aff
</pre><a href="#appendix-A.3.5-2" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.4">
        <h3 id="name-example-4-security-blocks-w">
<a href="#appendix-A.4" class="section-number selfRef">A.4. </a><a href="#name-example-4-security-blocks-w" class="section-name selfRef">Example 4 - Security Blocks with Full Scope</a>
        </h3>
<p id="appendix-A.4-1">
        This example shows the addition of a BIB and BCB to 
        a sample bundle. A BIB is added to provide integrity 
        over the payload block, and a BCB is added for 
        confidentiality over the payload and BIB.<a href="#appendix-A.4-1" class="pilcrow">¶</a></p>
<p id="appendix-A.4-2">
        The integrity scope and additional authentication data 
        will bind the primary block, target header, and the 
        security header.<a href="#appendix-A.4-2" class="pilcrow">¶</a></p>
<section id="appendix-A.4.1">
          <h4 id="name-original-bundle-4">
<a href="#appendix-A.4.1" class="section-number selfRef">A.4.1. </a><a href="#name-original-bundle-4" class="section-name selfRef">Original Bundle</a>
          </h4>
<p id="appendix-A.4.1-1">
          The following diagram shows the original bundle before the
          security blocks have been added.<a href="#appendix-A.4.1-1" class="pilcrow">¶</a></p>
<span id="name-example-4-original-bundle"></span><figure id="figure-22">
            <div class="alignCenter art-text artwork" id="appendix-A.4.1-2.1">
<pre>
                  Block                    Block   Block
                in Bundle                  Type    Number
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
+----------------------------------------+-------+--------+
|  Payload Block                         |   1   |    1   |
+----------------------------------------+-------+--------+
</pre>
</div>
<figcaption><a href="#figure-22" class="selfRef">Figure 22</a>:
<a href="#name-example-4-original-bundle" class="selfRef">Example 4 - Original Bundle</a>
            </figcaption></figure>
<section id="appendix-A.4.1.1">
            <h5 id="name-primary-block-4">
<a href="#appendix-A.4.1.1" class="section-number selfRef">A.4.1.1. </a><a href="#name-primary-block-4" class="section-name selfRef">Primary Block</a>
            </h5>
<p id="appendix-A.4.1.1-1">
           The primary block used in this example is identical to the primary block
           presented for Example 1 in <a href="#ex_primary_block" class="xref">Appendix A.1.1.1</a>.<a href="#appendix-A.4.1.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.4.1.1-2"> 
            In summary, the CBOR encoding of the primary block is:<a href="#appendix-A.4.1.1-2" class="pilcrow">¶</a></p>
<div id="appendix-A.4.1.1-3">
<pre class="sourcecode">
0x88070000820282010282028202018202820201820018281a000f4240
</pre><a href="#appendix-A.4.1.1-3" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.4.1.2">
            <h5 id="name-payload-block-4">
<a href="#appendix-A.4.1.2" class="section-number selfRef">A.4.1.2. </a><a href="#name-payload-block-4" class="section-name selfRef">Payload Block</a>
            </h5>
<p id="appendix-A.4.1.2-1">
           The payload block used in this example is identical to the payload block
           presented for Example 1 in <a href="#ex_payload_block" class="xref">Appendix A.1.1.2</a>.<a href="#appendix-A.4.1.2-1" class="pilcrow">¶</a></p>
<p id="appendix-A.4.1.2-2"> 
            In summary, the CBOR encoding of the payload block is:<a href="#appendix-A.4.1.2-2" class="pilcrow">¶</a></p>
<div id="appendix-A.4.1.2-3">
<pre class="sourcecode">
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</pre><a href="#appendix-A.4.1.2-3" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.4.1.3">
            <h5 id="name-bundle-cbor-representation-4">
<a href="#appendix-A.4.1.3" class="section-number selfRef">A.4.1.3. </a><a href="#name-bundle-cbor-representation-4" class="section-name selfRef">Bundle CBOR Representation</a>
            </h5>
<p id="appendix-A.4.1.3-1">
            A BPv7 bundle is represented as an indefinite-length array consisting
            of the blocks comprising the bundle, with a terminator character at
            the end.<a href="#appendix-A.4.1.3-1" class="pilcrow">¶</a></p>
<p id="appendix-A.4.1.3-2">
            The CBOR encoding of the original bundle is:<a href="#appendix-A.4.1.3-2" class="pilcrow">¶</a></p>
<div id="appendix-A.4.1.3-3">
<pre class="sourcecode">
0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
</pre><a href="#appendix-A.4.1.3-3" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.4.2">
          <h4 id="name-security-operation-overview-4">
<a href="#appendix-A.4.2" class="section-number selfRef">A.4.2. </a><a href="#name-security-operation-overview-4" class="section-name selfRef">Security Operation Overview</a>
          </h4>
<p id="appendix-A.4.2-1">
          This example provides:<a href="#appendix-A.4.2-1" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-A.4.2-2.1"> 
              a BIB with the BIB-HMAC-SHA2 security context to provide an 
              integrity mechanism over the payload block.<a href="#appendix-A.4.2-2.1" class="pilcrow">¶</a>
</li>
            <li class="normal" id="appendix-A.4.2-2.2">
              a BCB with the BCB-AES-GCM security context to provide a
              confidentiality mechanism over the payload block and BIB.<a href="#appendix-A.4.2-2.2" class="pilcrow">¶</a>
</li>
          </ul>
<p id="appendix-A.4.2-3">
          The following diagram shows the resulting bundle after the 
          security blocks are added.<a href="#appendix-A.4.2-3" class="pilcrow">¶</a></p>
<span id="name-example-4-resulting-bundle"></span><figure id="figure-23">
            <div class="alignCenter art-text artwork" id="appendix-A.4.2-4.1">
<pre>
                  Block                    Block   Block
                in Bundle                  Type    Number
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
+----------------------------------------+-------+--------+
|  Block Integrity Block (Encrypted)     |   11  |    3   |
|  OP(bib-integrity, target=1)           |       |        |
+----------------------------------------+-------+--------+
|  Block Confidentiality Block           |   12  |    2   |
|  OP(bcb-confidentiality, targets=1, 3) |       |        |
+----------------------------------------+-------+--------+
|  Payload Block (Encrypted)             |   1   |    1   |
+----------------------------------------+-------+--------+
</pre>
</div>
<figcaption><a href="#figure-23" class="selfRef">Figure 23</a>:
<a href="#name-example-4-resulting-bundle" class="selfRef">Example 4 - Resulting Bundle</a>
            </figcaption></figure>
</section>
<section id="appendix-A.4.3">
          <h4 id="name-block-integrity-block-3">
<a href="#appendix-A.4.3" class="section-number selfRef">A.4.3. </a><a href="#name-block-integrity-block-3" class="section-name selfRef">Block Integrity Block</a>
          </h4>
<p id="appendix-A.4.3-1">
          In this example, a BIB is used to carry an integrity signature over
          the payload block. The IPPT contains the block-type-specific data
          of the payload block, the primary block data, the payload block
          header, and the BIB header. That is, all additional headers are
          included in the IPPT.<a href="#appendix-A.4.3-1" class="pilcrow">¶</a></p>
<section id="appendix-A.4.3.1">
            <h5 id="name-configuration-parameters-and-re">
<a href="#appendix-A.4.3.1" class="section-number selfRef">A.4.3.1. </a><a href="#name-configuration-parameters-and-re" class="section-name selfRef">Configuration, Parameters, and Results</a>
            </h5>
<p id="appendix-A.4.3.1-1">
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.<a href="#appendix-A.4.3.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.4.3.1-2">
            This BIB has a single target and includes a single security
            result: the calculated signature over the Payload block.<a href="#appendix-A.4.3.1-2" class="pilcrow">¶</a></p>
<span id="name-example-4-configuration-par"></span><div id="ex4_bib_cpr">
<figure id="figure-24">
              <div class="alignCenter art-text artwork" id="appendix-A.4.3.1-3.1">
<pre>
               Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
       SHA Variant: HMAC 384/384
       Scope Flags: 0x07  (all additional headers)
Primary Block Data: h'88070000820282010282028202018202
                      820201820018281a000f4240'
      Payload Data: h'526561647920746f2067656e65726174
                      6520612033322d62797465207061796c
                      6f6164'
    Payload Header: h'010100'
        BIB Header: h'0b0300'
              IPPT: h'07880700008202820102820282020182
                      02820201820018281a000f4240010100
                      0b03005823526561647920746f206765
                      6e657261746520612033322d62797465
                      207061796c6f6164'
 Payload Signature: h'f75fe4c37f76f046165855bd5ff72fbf
                      d4e3a64b4695c40e2b787da005ae819f
                      0a2e30a2e8b325527de8aefb52e73d71,
</pre>
</div>
<figcaption><a href="#figure-24" class="selfRef">Figure 24</a>:
<a href="#name-example-4-configuration-par" class="selfRef">Example 4 - Configuration, Parameters, and Results for the BIB</a>
              </figcaption></figure>
</div>
</section>
<section id="appendix-A.4.3.2">
            <h5 id="name-abstract-security-block-5">
<a href="#appendix-A.4.3.2" class="section-number selfRef">A.4.3.2. </a><a href="#name-abstract-security-block-5" class="section-name selfRef">Abstract Security Block</a>
            </h5>
<p id="appendix-A.4.3.2-1">
            The abstract security block structure of the BIB's
            block-type-specific data field for this application is as follows.<a href="#appendix-A.4.3.2-1" class="pilcrow">¶</a></p>
<span id="name-example-4-bib-abstract-secu"></span><div id="ex4_bib_asb">
<figure id="figure-25">
              <div id="appendix-A.4.3.2-2.1">
<pre class="lang-cbor-diag sourcecode">
[1],           / Security Target          - Payload block          /
1,             / Security Context ID      - BIB-HMAC-SHA2          /
1,             / Security Context Flags   - Parameters Present     /
[2,[2, 1]],    / Security Source          - ipn:2.1                /
[              / Security Parameters      - 2 Parameters           /
   [1, 6],     / SHA Variant              - HMAC 384/384           /
   [3, 0x07]   / Scope Flags              - All additional headers /
],
[              / Security Results: 1 Result                        /
  [            / Target 1 Results                                  /
    [1, h'f75fe4c37f76f046165855bd5ff72fbf         / MAC           /
          d4e3a64b4695c40e2b787da005ae819f
          0a2e30a2e8b325527de8aefb52e73d71']
  ]
]
</pre>
</div>
<figcaption><a href="#figure-25" class="selfRef">Figure 25</a>:
<a href="#name-example-4-bib-abstract-secu" class="selfRef">Example 4 - BIB Abstract Security Block (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.4.3.2-3">

            The CBOR encoding of the BIB block-type-specific data field (the abstract security block) is:<a href="#appendix-A.4.3.2-3" class="pilcrow">¶</a></p>
<div id="appendix-A.4.3.2-4">
<pre class="sourcecode">
0x81010101820282020182820106820307818182015830f75fe4c37f76f046165855
bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8aefb52
e73d71
</pre><a href="#appendix-A.4.3.2-4" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.4.3.3">
            <h5 id="name-representations-5">
<a href="#appendix-A.4.3.3" class="section-number selfRef">A.4.3.3. </a><a href="#name-representations-5" class="section-name selfRef">Representations</a>
            </h5>
<p id="appendix-A.4.3.3-1">
            The complete BIB is as follows.<a href="#appendix-A.4.3.3-1" class="pilcrow">¶</a></p>
<span id="name-example-4-bib-cbor-diagnost"></span><div id="ex4_bib">
<figure id="figure-26">
              <div id="appendix-A.4.3.3-2.1">
<pre class="lang-cbor-diag sourcecode">
[
  11, / type code    /
  3,  / block number /
  0,  / flags        /
  0,  / CRC type     /
  h'81010101820282020182820106820307818182015830f75fe4c37f76f0461658
    55bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8
    aefb52e73d71'
]
</pre>
</div>
<figcaption><a href="#figure-26" class="selfRef">Figure 26</a>:
<a href="#name-example-4-bib-cbor-diagnost" class="selfRef">Example 4 - BIB (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.4.3.3-3">
            The CBOR encoding of the BIB block is:<a href="#appendix-A.4.3.3-3" class="pilcrow">¶</a></p>
<div id="appendix-A.4.3.3-4">
<pre class="sourcecode">
0x850b030000584681010101820282020182820106820307818182015830f75fe4c3
7f76f046165855bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b3
25527de8aefb52e73d71
</pre><a href="#appendix-A.4.3.3-4" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.4.4">
          <h4 id="name-block-confidentiality-block-3">
<a href="#appendix-A.4.4" class="section-number selfRef">A.4.4. </a><a href="#name-block-confidentiality-block-3" class="section-name selfRef">Block Confidentiality Block</a>
          </h4>
<p id="appendix-A.4.4-1">
        In this example, a BCB is used encrypt the payload
        block and the BIB that provides integrity over
        the payload.<a href="#appendix-A.4.4-1" class="pilcrow">¶</a></p>
<section id="appendix-A.4.4.1">
            <h5 id="name-configuration-parameters-and-res">
<a href="#appendix-A.4.4.1" class="section-number selfRef">A.4.4.1. </a><a href="#name-configuration-parameters-and-res" class="section-name selfRef">Configuration, Parameters, and Results</a>
            </h5>
<p id="appendix-A.4.4.1-1">
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.<a href="#appendix-A.4.4.1-1" class="pilcrow">¶</a></p>
<p id="appendix-A.4.4.1-2">
          This BCB has two targets: the payload block and BIB. Four
          security results are generated: ciphertext that
          replaces the plaintext block-type-specific data of the 
          payload block, ciphertext to encrypt the BIB, and authentication
          tags for both the payload block and BIB.<a href="#appendix-A.4.4.1-2" class="pilcrow">¶</a></p>
<span id="name-example-4-configuration-para"></span><div id="ex4_bcb_cpr">
<figure id="figure-27">
              <div class="alignCenter art-ascii-art art-text artwork" id="appendix-A.4.4.1-3.1">
<pre>
               Key: h'71776572747975696f70617364666768
                      71776572747975696f70617364666768'
                IV: h'5477656c7665313231323132'
       AES Variant: A256GCM
       Scope Flags: 0x07  (All additional headers)
      Payload Data: h'526561647920746f2067656e65726174
                      6520612033322d62797465207061796c
                      6f6164'
          BIB Data: h'81010101820282020182820106820307
                      818182015830f75fe4c37f76f0461658
                      55bd5ff72fbfd4e3a64b4695c40e2b78
                      7da005ae819f0a2e30a2e8b325527de8
                      aefb52e73d71'
 Primary Block Data: h'88070000820282010282028202018202
                       820201820018281a000f4240'
     Payload Header: h'010100'
         BIB Header: h'0b0300'
         BCB Header: h'0c0201'
        Payload AAD: h'07880700008202820102820282020182
                       02820201820018281a000f4240010100
                       0c0201'
            BIB AAD: h'07880700008202820102820282020182
                       02820201820018281a000f42400b0300
                       0c0201'
     Payload Block
Authentication Tag: h'd2c51cb2481792dae8b21d848cede99b'
               BIB
Authentication Tag: h'220ffc45c8a901999ecc60991dd78b29'
Payload Ciphertext: h'90eab6457593379298a8724e16e61f83
                      7488e127212b59ac91f8a86287b7d076
                      30a122'
    BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0
                      902902064a2983910c4fb2340790bf42
                      0a7d1921d5bf7c4721e02ab87a93ab1e
                      0b75cf62e4948727c8b5dae46ed2af05
                      439b88029191'
</pre>
</div>
<figcaption><a href="#figure-27" class="selfRef">Figure 27</a>:
<a href="#name-example-4-configuration-para" class="selfRef">Example 4 - Configuration, Parameters, and Results for the BCB</a>
              </figcaption></figure>
</div>
</section>
<section id="appendix-A.4.4.2">
            <h5 id="name-abstract-security-block-6">
<a href="#appendix-A.4.4.2" class="section-number selfRef">A.4.4.2. </a><a href="#name-abstract-security-block-6" class="section-name selfRef">Abstract Security Block</a>
            </h5>
<p id="appendix-A.4.4.2-1">
          The abstract security block structure of the BCB's
          block-type-specific data field for this application is as follows.<a href="#appendix-A.4.4.2-1" class="pilcrow">¶</a></p>
<span id="name-example-4-bcb-abstract-secu"></span><div id="ex4_bcb_asb">
<figure id="figure-28">
              <div id="appendix-A.4.4.2-2.1">
<pre class="lang-cbor-diag sourcecode">
[3, 1],          / Security Targets                            /
2,               / Security Context ID    - BCB-AES-GCM        /
1,               / Security Context Flags - Parameters Present /
[2,[2, 1]],      / Security Source        - ipn:2.1            /
[                / Security Parameters    - 3 Parameters       /
  [1, h'5477656c7665313231323132'],    / Initialization Vector /
  [2, 3],                              / AES Variant - AES 256 /
  [4, 0x07]            / Scope Flags - All headers in SHA hash /
],
[                                / Security Results: 2 Results /
  [
     [1, h'220ffc45c8a901999ecc60991dd78b29']  / BIB Auth. Tag /
  ],
  [
     [1, h'd2c51cb2481792dae8b21d848cede99b'] / Payload Auth. Tag /
  ]
]
</pre>
</div>
<figcaption><a href="#figure-28" class="selfRef">Figure 28</a>:
<a href="#name-example-4-bcb-abstract-secu" class="selfRef">Example 4 - BCB Abstract Security Block (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.4.4.2-3">

          The CBOR encoding of the BCB block-type-specific data field 
          (the abstract security block) is:<a href="#appendix-A.4.4.2-3" class="pilcrow">¶</a></p>
<div id="appendix-A.4.4.2-4">
<pre class="sourcecode">
0x820301020182028202018382014c5477656c766531323132313282020382040782
81820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792dae8b2
1d848cede99b
</pre><a href="#appendix-A.4.4.2-4" class="pilcrow">¶</a>
</div>
</section>
<section id="appendix-A.4.4.3">
            <h5 id="name-representations-6">
<a href="#appendix-A.4.4.3" class="section-number selfRef">A.4.4.3. </a><a href="#name-representations-6" class="section-name selfRef">Representations</a>
            </h5>
<p id="appendix-A.4.4.3-1">
          The complete BCB is as follows.<a href="#appendix-A.4.4.3-1" class="pilcrow">¶</a></p>
<span id="name-example-4-bcb-cbor-diagnost"></span><div id="ex4_bcb">
<figure id="figure-29">
              <div id="appendix-A.4.4.3-2.1">
<pre class="lang-cbor-diag sourcecode">
[
  12, / type code                                          /
  2,  / block number                                       /
  1,  / flags - block must be replicated in every fragment /
  0,  / CRC type                                           /
  h'820301020182028202018382014c5477656c7665313231323132820203820407
    8281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792
    dae8b21d848cede99b'
]
</pre>
</div>
<figcaption><a href="#figure-29" class="selfRef">Figure 29</a>:
<a href="#name-example-4-bcb-cbor-diagnost" class="selfRef">Example 4 - BCB (CBOR Diagnostic Notation)</a>
              </figcaption></figure>
</div>
<p id="appendix-A.4.4.3-3">
            The CBOR encoding of the BCB block is:<a href="#appendix-A.4.4.3-3" class="pilcrow">¶</a></p>
<div id="appendix-A.4.4.3-4">
<pre class="sourcecode">
0x850c0201005849820301020182028202018382014c5477656c7665313231323132
8202038204078281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51c
b2481792dae8b21d848cede99b
</pre><a href="#appendix-A.4.4.3-4" class="pilcrow">¶</a>
</div>
</section>
</section>
<section id="appendix-A.4.5">
          <h4 id="name-final-bundle-4">
<a href="#appendix-A.4.5" class="section-number selfRef">A.4.5. </a><a href="#name-final-bundle-4" class="section-name selfRef">Final Bundle</a>
          </h4>
<p id="appendix-A.4.5-1">
        The CBOR encoding of the full output bundle, with the security blocks added and payload block and BIB encrypted is:<a href="#appendix-A.4.5-1" class="pilcrow">¶</a></p>
<div id="appendix-A.4.5-2">
<pre class="sourcecode">
0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
005846438ed6208eb1c1ffb94d952175167df0902902064a2983910c4fb2340790bf
420a7d1921d5bf7c4721e02ab87a93ab1e0b75cf62e4948727c8b5dae46ed2af0543
9b88029191850c0201005849820301020182028202018382014c5477656c76653132
313231328202038204078281820150220ffc45c8a901999ecc60991dd78b29818201
50d2c51cb2481792dae8b21d848cede99b8501010000582390eab6457593379298a8
724e16e61f837488e127212b59ac91f8a86287b7d07630a122ff
</pre><a href="#appendix-A.4.5-2" class="pilcrow">¶</a>
</div>
</section>
</section>
</section>
</div>
<div id="cddl">
<section id="appendix-B">
      <h2 id="name-cddl-expression">
<a href="#appendix-B" class="section-number selfRef">Appendix B. </a><a href="#name-cddl-expression" class="section-name selfRef">CDDL Expression</a>
      </h2>
<p id="appendix-B-1"> 
  For informational purposes, this section contains an  
  expression of the IPPT and AAD structures using the Concise Data  
  Definition Language (CDDL).<a href="#appendix-B-1" class="pilcrow">¶</a></p>
<p id="appendix-B-2">NOTES:<a href="#appendix-B-2" class="pilcrow">¶</a></p>
<ul class="normal">
<li class="normal" id="appendix-B-3.1">Wherever the CDDL expression is in disagreement with the textual representation of
      the security block specification presented in earlier sections of this document, 
      the textual representation rules.<a href="#appendix-B-3.1" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-3.2">
      The structure of BP bundles and BPSec security blocks are provided by other
      specifications; this appendix only provides the CDDL expression for structures uniquely
      defined in this specification. Items related to elements of a bundle, such as "primary-block",
      are defined in <span><a href="https://www.rfc-editor.org/rfc/rfc9171#appendix-B" class="relref">Appendix B</a> of the Bundle Protocol version 7 [<a href="#RFC9171" class="xref">RFC9171</a>]</span>.<a href="#appendix-B-3.2" class="pilcrow">¶</a>
</li>
        <li class="normal" id="appendix-B-3.3">
      The CDDL itself does not have the concept of unadorned CBOR sequences as
      a top-level subject of a specification. The current best practice, as documented in 
      <span><a href="https://www.rfc-editor.org/rfc/rfc8742#section-4.1" class="relref">Section 4.1</a> of [<a href="#RFC8742" class="xref">RFC8742</a>]</span>, requires representing the sequence as an
      array with a comment in the CDDL noting that the array represents a CBOR sequence.<a href="#appendix-B-3.3" class="pilcrow">¶</a>
</li>
      </ul>
<span id="name-ippt-and-aad-expressions"></span><div id="appendix_b">
<figure id="figure-30">
        <div id="appendix-B-4.1">
<pre class="lang-cddl sourcecode">
start = scope / AAD-list / IPPT-list ; satisfy CDDL decoders

scope = uint .bits scope-flags
scope-flags = &amp;(
    has-primary-ctx: 0,
    has-target-ctx: 1,
    has-security-ctx: 2,
)

; Encoded as a CBOR sequence
AAD-list = [
    AAD-structure
]

; Encoded as a CBOR sequence
IPPT-list = [
    AAD-structure,
    target-btsd: bstr ; block-type-specific data of the target block.
]

AAD-structure = (
    scope,
    ? primary-block,  ; present if has-primary-ctx flag set
    ? block-metadata, ; present if has-target-ctx flag set
    ? block-metadata, ; present if has-security-ctx flag set
)

; Selected fields of a canonical block
block-metadata = (
    block-type-code: uint,
    block-number: uint,
    block-control-flags,
)
</pre>
</div>
<figcaption><a href="#figure-30" class="selfRef">Figure 30</a>:
<a href="#name-ippt-and-aad-expressions" class="selfRef">IPPT and AAD Expressions</a>
        </figcaption></figure>
</div>
</section>
</div>
<div id="contr">
<section id="appendix-C">
      <h2 id="name-acknowledgments">
<a href="#name-acknowledgments" class="section-name selfRef">Acknowledgments</a>
      </h2>
<p id="appendix-C-1">
         <span class="contact-name">Amy Alford</span> of the Johns Hopkins University Applied Physics 
         Laboratory contributed useful review and analysis of these
         security contexts.<a href="#appendix-C-1" class="pilcrow">¶</a></p>
<p id="appendix-C-2"><span class="contact-name">Brian Sipos</span> kindly provided the CDDL expression in <a href="#cddl" class="xref">Appendix B</a>.<a href="#appendix-C-2" class="pilcrow">¶</a></p>
</section>
</div>
<div id="authors-addresses">
<section id="appendix-D">
      <h2 id="name-authors-addresses">
<a href="#name-authors-addresses" class="section-name selfRef">Authors' Addresses</a>
      </h2>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Edward J. Birrane, III</span></div>
<div dir="auto" class="left"><span class="org">The Johns Hopkins University Applied Physics Laboratory</span></div>
<div dir="auto" class="left"><span class="street-address">11100 Johns Hopkins Rd.</span></div>
<div dir="auto" class="left">
<span class="locality">Laurel</span>, <span class="region">MD</span> <span class="postal-code">20723</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20443%20778%207423" class="tel">+1 443 778 7423</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:Edward.Birrane@jhuapl.edu" class="email">Edward.Birrane@jhuapl.edu</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Alex White</span></div>
<div dir="auto" class="left"><span class="org">The Johns Hopkins University Applied Physics Laboratory</span></div>
<div dir="auto" class="left"><span class="street-address">11100 Johns Hopkins Rd.</span></div>
<div dir="auto" class="left">
<span class="locality">Laurel</span>, <span class="region">MD</span> <span class="postal-code">20723</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20443%20778%200845" class="tel">+1 443 778 0845</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:Alex.White@jhuapl.edu" class="email">Alex.White@jhuapl.edu</a>
</div>
</address>
<address class="vcard">
        <div dir="auto" class="left"><span class="fn nameRole">Sarah Heiner</span></div>
<div dir="auto" class="left"><span class="org">The Johns Hopkins University Applied Physics Laboratory</span></div>
<div dir="auto" class="left"><span class="street-address">11100 Johns Hopkins Rd.</span></div>
<div dir="auto" class="left">
<span class="locality">Laurel</span>, <span class="region">MD</span> <span class="postal-code">20723</span>
</div>
<div dir="auto" class="left"><span class="country-name">United States of America</span></div>
<div class="tel">
<span>Phone:</span>
<a href="tel:+1%20240%20592%203704" class="tel">+1 240 592 3704</a>
</div>
<div class="email">
<span>Email:</span>
<a href="mailto:Sarah.Heiner@jhuapl.edu" class="email">Sarah.Heiner@jhuapl.edu</a>
</div>
</address>
</section>
</div>
<script>const toc = document.getElementById("toc");
toc.querySelector("h2").addEventListener("click", e => {
  toc.classList.toggle("active");
});
toc.querySelector("nav").addEventListener("click", e => {
  toc.classList.remove("active");
});
</script>
</body>
</html>