<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>

<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-dtn-bpsec-default-sc-11" number="9173" ipr="trust200902" obsoletes="" submissionType="IETF" category="std" consensus="true" updates="" xml:lang="en" tocInclude="true" symRefs="true" consensus="true" sortRefs="true" version="3">

  <!-- xml2rfc v2v3 conversion 3.9.0 -->
  <front>
    <title>BPSec

    <title abbrev="BPSec Default Security Contexts</title> Contexts">Default Security Contexts for Bundle Protocol Security (BPSec)</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-dtn-bpsec-default-sc-11"/> name="RFC" value="9173"/>
    <author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, III" initials="E.J." surname="Birrane"> III">
      <organization abbrev="JHU/APL">The Johns Hopkins University Applied
      Physics Laboratory</organization>
      <address>
        <postal>
          <street>11100 Johns Hopkins Rd.</street>
          <city>Laurel</city>
          <region>MD</region>
          <code>20723</code>
          <country>US</country>
        </postal>
        <phone>+1 443 778 7423</phone>
        <email>Edward.Birrane@jhuapl.edu</email>
      </address>
    </author>
    <author fullname="Alex White" initials="A." surname="White">
      <organization abbrev="JHU/APL">The Johns Hopkins University Applied
      Physics Laboratory</organization>
      <address>
        <postal>
          <street>11100 Johns Hopkins Rd.</street>
          <city>Laurel</city>
          <region>MD</region>
          <code>20723</code>
          <country>US</country>
        </postal>
        <phone>+1 443 778 0845</phone>
        <email>Alex.White@jhuapl.edu</email>
      </address>
    </author>
    <author fullname="Sarah Heiner" initials="S." surname="Heiner">
      <organization abbrev="JHU/APL">The Johns Hopkins University Applied
      Physics Laboratory</organization>
      <address>
        <postal>
          <street>11100 Johns Hopkins Rd.</street>
          <city>Laurel</city>
          <region>MD</region>
          <code>20723</code>
          <country>US</country>
        </postal>
        <phone>+1 240 592 3704</phone>
        <email>Sarah.Heiner@jhuapl.edu</email>
      </address>
    </author>
    <date month="July" day="25" year="2021"/> month="January" year="2022"/>
    <!-- Meta-data -->

    <area>General</area>
    <workgroup>Delay-Tolerant Networking</workgroup>
    <keyword>security</keyword>
    <keyword>bundle</keyword>
    <keyword>integrity</keyword>
    <keyword>confidentiality</keyword>
    <abstract>
      <t>
         This document defines default integrity and confidentiality security
         contexts that can be used with the Bundle Protocol Security Protocol
         (BPSec) implementations.  These security contexts are intended to be
         used for 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.
      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="intro" toc="default" numbered="true">
      <name>Introduction</name>
      <t>
         The Bundle Protocol Security Protocol (BPSec) specification
         <xref target="I-D.ietf-dtn-bpsec" target="RFC9172" format="default"/> specification provides inter-bundle
         integrity and confidentiality operations for networks deploying the
         Bundle Protocol (BP) <xref target="I-D.ietf-dtn-bpbis" target="RFC9171" format="default"/>. BPSec defines
         BP extension blocks to carry security information produced under the
         auspices of some security context.
      </t>
      <t>
         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.
      </t>
      <t>
         These contexts generate information that MUST <bcp14>MUST</bcp14> be encoded using
         the CBOR Concise Binary Object Representation (CBOR) specification documented in <xref target="RFC8949" format="default"/>.
      </t>
    </section>
    <section anchor="term" toc="default" numbered="true">
      <name>Requirements Language</name>
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
         NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",
         "MAY", "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
    NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as
    described in BCP 14 BCP&nbsp;14 <xref target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174" format="default"/> target="RFC8174"/>
    when, and only when, they appear in all capitals, as shown here.
        </t>

    </section>
    <section numbered="true" toc="default"> toc="default" anchor="first-context">
      <name>Integrity Security Context BIB-HMAC-SHA2</name>
      <section numbered="true" toc="default">
        <name>Overview</name>
        <t>
            The BIB-HMAC-SHA2 security context provides a keyed-hash
            Message Authentication Code (MAC) over a
            set of plain text plaintext information. This context uses the Secure
            Hash Algorithm 2 (SHA-2) discussed in <xref target="SHS" format="default"/> combined
            with the HMAC Hashed Message Authentication Code (HMAC) keyed hash discussed in <xref target="RFC2104" format="default"/>. The combination
            of HMAC and SHA-2 as the integrity mechanism for this security
            context was selected for two reasons:

        </t>
        <ol spacing="normal" type="1"><li> 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.
              </li>
          <li>
                The combination HMAC-SHA2 represents a well-supported and well-understood
                integrity mechanism with multiple implementations available.
              </li>
        </ol>
        <t>
            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", HMAC 256/256, HMAC 384/384, and "HMAC 512/512" HMAC 512/512 as
            defined in <xref target="RFC8152" format="default"/> Table 7: HMAC 7 ("HMAC Algorithm Values. Values") of <xref target="RFC8152" format="default"/>.
            The selection of which variant is used by this context is
            provided as a security context parameter.
        </t>
        <t>
            The output of the HMAC MUST <bcp14>MUST</bcp14> 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.
        </t>
        <t>
            The BIB-HMAC-SHA2 security context MUST <bcp14>MUST</bcp14> have the security context
            identifier specified in <xref target="sc_ids" format="default"/>.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Scope</name>
        <t>
          The scope of BIB-HMAC-SHA2 is the set of information used
          to produce the plain text plaintext over which a keyed hash is calculated. This
          plain text
          plaintext is termed the "Integrity Protected Plain Text" (IPPT). "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, integrity are discussed as follows.

        </t>

        <dl newline="true" spacing="normal" indent="4"> indent="3">
          <dt>Security target contents</dt>
          <dd>
              The contents of the block-type-specific data field of the security
              target MUST <bcp14>MUST</bcp14> 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.
            </dd>
          <dt>IPPT Scope</dt> scope</dt>
          <dd>
              The determination of which optional types of information were
              used when constructing the IPPT MUST, itself, <bcp14>MUST</bcp14> 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.
            </dd>
          <dt>Primary block</dt>
          <dd>
            <t>
              The primary block identifies a bundle and, 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.
            </t>
            <t>
              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.
            </t>
            <t>
              Including this information in the IPPT protects the integrity
              of the association of the security target with a specific bundle.
            </t>
          </dd>
          <dt>Security target other fields</dt>
          <dt>Other fields of the security target</dt>
          <dd>
            <t>
              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.
            </t>
            <t>
              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 source, then the policy for
              handling the security target has been modified.
            </t>
            <t>
              Including this information in the IPPT protects the integrity
              of the policy and identification of the security target data.
            </t>
          </dd>
          <dt>BIB other fields</dt>
          <dt>Other fields of the BIB</dt>
          <dd>
            <t>
              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.
            </t>
            <t>
              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.
            </t>
            <t>
              Including this information in the IPPT protects the integrity
              of the policy and identification of the security service in the bundle.
            </t>
	    <aside>
            <t>
              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 re-used reused across security
              contexts,
              contexts and because the integrity scope flags used to define
              the IPPT are included in the IPPT itself.
            </t>
	    </aside>
          </dd>
        </dl>
        <t>
          The scope of the BIB-HMAC-SHA2 security context is configured using
          an optional security context parameter.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Parameters</name>
        <t>
          BIB-HMAC-SHA2 can be parameterized to select SHA-2 variants,
          communicate key information, and define the scope of the IPPT.
        </t>
        <section numbered="true" toc="default">
          <name>SHA Variant</name>
          <t>
            This optional parameter identifies which variant of the SHA-2
            algorithm is to be used in the generation of the authentication code.
          </t>
          <t>
            This value MUST <bcp14>MUST</bcp14> be encoded as a CBOR unsigned integer.
          </t>
          <t>
            Valid values for this parameter are as follows.
          </t>
          <t keepWithNext="true">
              SHA Variant Parameter Values
          </t>
          <table align="center" anchor="sha_var">
          <name>SHA Variant Parameter Values</name>
            <thead>
              <tr>
                <th align="center">Value</th>
                <th align="center">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">5</td>
                <td align="center">HMAC
                <td>HMAC 256/256 as defined in <xref target="RFC8152" format="default"/> Table 7: HMAC 7 ("HMAC Algorithm Values</td> Values") of <xref target="RFC8152" format="default"/></td>
              </tr>
              <tr>
                <td align="center">6</td>
                <td align="center">HMAC
                <td>HMAC 384/384 as defined in <xref target="RFC8152" format="default"/> Table 7: HMAC 7 ("HMAC Algorithm Values</td> Values") of <xref target="RFC8152" format="default"/></td>
              </tr>
              <tr>
                <td align="center">7</td>
                <td align="center">HMAC
                <td>HMAC 512/512 as defined in <xref target="RFC8152" format="default"/> Table 7: HMAC 7 ("HMAC Algorithm Values</td> Values") of <xref target="RFC8152" format="default"/></td>
              </tr>
            </tbody>
          </table>
          <t>
            When not provided, implementations SHOULD <bcp14>SHOULD</bcp14> 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.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Wrapped Key</name>

          <t>
	    This optional parameter contains the output of the AES key wrap
            authenticated encryption function (KW-AE) as defined in <xref target="RFC5649" target="RFC3394" format="default"/>.  Specifically, this parameter holds the cipher text ciphertext produced when running the KW-AE 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 (KW-AD) 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.
          </t>
          <t>
            This value MUST <bcp14>MUST</bcp14> be encoded as a CBOR byte string.
          </t>
          <t>
            If this parameter is not present present, then security verifiers
            and acceptors MUST <bcp14>MUST</bcp14> determine the proper key as a function of their local BPSec policy
            and configuration.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Integrity Scope Flags</name>
          <t>
            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.
          </t>
          <t>
            This value MUST <bcp14>MUST</bcp14> be represented as a CBOR unsigned
            integer, the value of which MUST <bcp14>MUST</bcp14> be processed as a 16-bit field.
            The maximum value of this field, as a CBOR unsigned integer, MUST <bcp14>MUST</bcp14> be
            65535.
          </t>
	  <t>When not provided, implementations <bcp14>SHOULD</bcp14> 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.
	  </t>
          <t>
            Implementations MUST <bcp14>MUST</bcp14> 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 MUST NOT <bcp14>MUST NOT</bcp14> be altered until the
            security service is completed at the security acceptor in the
            network and removed from the bundle.
          </t>
          <t>
            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.
          </t>
          <ul empty="true" spacing="normal">
            <li>- Bit

          <dl>
            <dt>Bit 0 (the low-order bit, 0x0001): Primary Block Flag. </li>
            <li>- Bit 0x0001):</dt><dd>Include primary block flag</dd>
            <dt>Bit 1 (0x0002): Target Header Flag.</li>
            <li>- Bit (0x0002):</dt><dd>Include target header flag</dd>
            <dt>Bit 2 (0x0004): Security Header Flag. </li>
            <li>- Bits 3-7 are reserved.</li>
            <li>- Bits 8-15 are unassigned.</li>
          </ul> (0x0004):</dt><dd>Include security header flag</dd>
            <dt>Bits 3-7:</dt><dd>Reserved</dd>
            <dt>Bits 8-15:</dt><dd>Unassigned</dd>
          </dl>

        </section>
        <section numbered="true" toc="default">
          <name>Enumerations</name>
          <t>
            The BIB-HMAC-SHA2 security context parameters are listed in
            <xref target="bib_parm_table" format="default"/>. In this table, the "Parm Id" column
            refers to the expected Parameter Identifier parameter identifier described in
             <xref target="I-D.ietf-dtn-bpsec" format="default"/>, Section 3.10 "Parameter
             <xref target="RFC9172" section="3.10" sectionFormat="bare">"Parameter
             and Result Identification". Identification"</xref> of <xref target="RFC9172"/>.
          </t>
          <t>
            If the default value
            An empty "Default Value" column is empty, this  indicates that the
            security context parameter does not have a default value.
          </t>
          <t keepWithNext="true">
               BIB-HMAC-SHA2 Security Parameters
          </t>

          <table align="center" anchor="bib_parm_table">
          <name>BIB-HMAC-SHA2 Security Context Parameters</name>
            <thead>
              <tr>
                <th align="center">Parm Id</th>
                <th align="center">Parm
                <th>Parm Name</th>
                <th align="center">CBOR
                <th>CBOR Encoding Type</th>
                <th align="center">Default
                <th>Default Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">1</td>
                <td align="center">SHA
                <td>SHA Variant</td>
                <td align="center">unsigned
                <td>unsigned integer</td>
                <td align="center">6</td>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="center">Wrapped
                <td>Wrapped Key</td>
                <td align="center">Byte String</td>
                <td>byte string</td>
                <td align="center"/>
              </tr>
              <tr>
                <td align="center">3</td>
                <td align="center">Integrity
                <td>Integrity Scope Flags</td>
                <td align="center">unsigned
                <td>unsigned integer</td>
                <td align="center">7</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="bib_results" numbered="true" toc="default">
        <name>Results</name>
        <t>
            The BIB-HMAC-SHA2 security context results are listed in
            <xref target="bib_res_table" format="default"/>. In this table, the "Result Id" column
            refers to the expected Result Identifier result identifier described in
             <xref target="I-D.ietf-dtn-bpsec" format="default"/>, Section 3.10 "Parameter
             <xref target="RFC9172" section="3.10" sectionFormat="bare">"Parameter
             and Result Identification".
        </t>
        <t keepWithNext="true">
               BIB-HMAC-SHA2 Security Results Identification"</xref> of <xref target="RFC9172"/>.
        </t>
        <table align="center" anchor="bib_res_table">
        <name>BIB-HMAC-SHA2 Security Results</name>
          <thead>
            <tr>
              <th align="center">Result Id</th>
              <th align="center">Result Name</th>
              <th align="center">CBOR Encoding Type</th>
              <th align="center">Description</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">1</td>
              <td align="center">Expected HMAC</td>
              <td align="center">byte string</td>
              <td align="center">The
              <td>The output of the HMAC calculation at the security source.</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section anchor="bib_key_mgmt" numbered="true" toc="default">
        <name>Key Considerations</name>
        <t>
          HMAC keys used with this context MUST <bcp14>MUST</bcp14> be symmetric and MUST <bcp14>MUST</bcp14> have
          a key length equal to the output of the HMAC. For this reason, HMAC
          key lengths will be integer integers divisible by 8 bytes bytes, and special padding-aware
          AES key wrap algorithms are not needed.
        </t>
        <t>
          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:

        </t>
        <ul empty="true" spacing="normal">
          <li> Pre-placed keys selected based on local policy. </li>
          <li> Keys extracted from material carried in the BIB. </li>
          <li> Session keys negotiated via a mechanism external to the BIB. </li>
        </ul>
        <t>
          When an AES-KW AES Key Wrap (AES-KW) <xref target="RFC3394"
          format="default"/> 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.
        </t>
        <t>
          As discussed in <xref target="SecCons" format="default"/> and emphasized here, it is
          strongly recommended that keys be protected once generated, both
          when they are stored and when they are transmitted.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Security Processing Considerations</name>

        <t>
          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 plain text and a
          plaintext, guess at an HMAC tag tag, and observe the behavior of a
          verifier.  With a modest number of trials, a side-channel attack
          could produce an HMAC tag for attacher-provided plain text attacker-provided plaintext without
          the attacker ever knowing the HMAC key.
        </t>
        <t>
          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.
        </t>
        <t>
          A constant-time comparison function SHOULD <bcp14>SHOULD</bcp14> 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.
        </t>
      </section>
      <section anchor="bib_canon" numbered="true" toc="default">
        <name>Canonicalization Algorithms</name>
        <t>
          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.
        </t>

        <t>
          In all cases, the canonical form of any portion of an extension block
          MUST
          <bcp14>MUST</bcp14> be performed created as described in <xref target="I-D.ietf-dtn-bpsec" target="RFC9172" format="default"/>.
          The canonicalization algorithms defined in <xref target="I-D.ietf-dtn-bpsec" target="RFC9172" format="default"/>
          adhere to the canonical forms for extension blocks defined in
          <xref target="I-D.ietf-dtn-bpbis" target="RFC9171" format="default"/> but resolve ambiguities related to
          how values are represented in CBOR.
        </t>
        <t>
          The IPPT is constructed using the following process. While integrity
          scope flags might not be included in the BIB representing the
          security operation, they MUST <bcp14>MUST</bcp14> be included in the IPPT value itself.

        </t>
        <ol spacing="normal" type="1"><li>
              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.
            </li>
          <li>
If the primary block flag of the integrity scope flags is set to 1, 1 and the
security target is not the bundle's primary block, then a canonical form of
the bundle's primary block MUST <bcp14>MUST</bcp14> be calculated and the result
appended to the IPPT.
            </li>
          <li>
If the target header flag of the integrity scope flags is set to 1, 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 MUST <bcp14>MUST</bcp14> be calculated and, in
that order, appended to the IPPT.
            </li>
          <li>
              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 MUST <bcp14>MUST</bcp14> be calculated and, in that order, appended to the IPPT.
            </li>
          <li>
The canonical form of the security target block-type-specific
              data MUST <bcp14>MUST</bcp14> 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.
            </li>
        </ol>
	<aside>
	  <t>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.
	  </t>
	</aside>
      </section>
      <section numbered="true" toc="default">
        <name>Processing</name>
        <section numbered="true" toc="default">
          <name>Keyed Hash Generation</name>
          <t>
            During keyed hash generation, two inputs are prepared for
            the
            the appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT.
            These data items MUST <bcp14>MUST</bcp14> be generated as follows.

          </t>
          <ul empty="true" spacing="normal">

            <li>
                The HMAC key MUST <bcp14>MUST</bcp14> 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 <xref
                target="bib_key_mgmt" format="default"/>.
              </li>
              <li>
                Prior to the generation of the IPPT, if a CRC Cyclic Redundancy Check (CRC) value is present
                for the target block of the BIB, then that CRC value MUST <bcp14>MUST</bcp14> be
                removed from the target block. This involves both removing the
                CRC value from the target block and setting the CRC Type type field
                of the target block to "no CRC is present."
              </li>
            <li>
                Once CRC information is removed, the IPPT MUST <bcp14>MUST</bcp14> be generated as
                discussed in <xref target="bib_canon" format="default"/>.
              </li>
          </ul>

          <t>
            Upon successful hash generation generation, the following actions MUST action <bcp14>MUST</bcp14> occur.

          </t>
          <ul empty="true" spacing="normal">
            <li>
                The keyed hash produced by the HMAC/SHA2 variant MUST <bcp14>MUST</bcp14> be added
                as a security result for the BIB representing the security
                operation on this security target, as discussed
                in <xref target="bib_results" format="default"/>.
              </li>
          </ul>
          <t>
            Finally, the BIB containing information about this security operation
            MUST
            <bcp14>MUST</bcp14> be updated as follows. These operations can occur in any order.
          </t>
          <ul empty="true" spacing="normal">
            <li>
                The security context identifier for the BIB MUST <bcp14>MUST</bcp14> be set to the context
                identifier for BIB-HMAC-SHA2.
              </li>
            <li>
                Any local flags used to generate the IPPT MUST <bcp14>MUST</bcp14> 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.
              </li>

            <li>
                The HMAC key MAY <bcp14>MAY</bcp14> be included as a security parameter context parameter, in which case
                it MUST <bcp14>MUST</bcp14> be wrapped using the NIST AES-KW algorithm AES key wrap function as defined in <xref target="RFC3394" format="default"/> and
                the results of the wrapping added as the wrapped key
                security context parameter for the BIB.
              </li>
            <li>
                The SHA variant used by this security context SHOULD <bcp14>SHOULD</bcp14> be added as
                the SHA variant security context parameter for the BIB if it differs from
                the default key length. Otherwise, this parameter MAY <bcp14>MAY</bcp14> be
                omitted if doing so provides a useful reduction in message sizes.
              </li>
          </ul>
          <t>
            Problems encountered in the keyed hash generation MUST <bcp14>MUST</bcp14> be
            processed in accordance with local BPSec security policy.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Keyed Hash Verification</name>
          <t>
            During keyed hash verification, the input of the security target
            and a an HMAC key are provided to the appropriate HMAC/SHA2 algorithm.
          </t>
          <t>
            During keyed hash verification, two inputs are prepared for
            the appropriate HMAC/SHA2 algorithm: the HMAC key and the IPPT.
            These data items MUST <bcp14>MUST</bcp14> be generated as follows.

          </t>
          <ul empty="true" spacing="normal">
            <li>
                The HMAC key MUST <bcp14>MUST</bcp14> 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
                MUST
                <bcp14>MUST</bcp14> be derived in accordance with security policy at the
                verifying node as discussed in <xref target="bib_key_mgmt" format="default"/>.
              </li>
            <li>
                The IPPT MUST <bcp14>MUST</bcp14> be generated as discussed in <xref target="bib_canon" format="default"/>
                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 parameters, then these flags MAY <bcp14>MAY</bcp14> be derived
                from local security policy.
              </li>
          </ul>
          <t>
            The calculated HMAC output MUST <bcp14>MUST</bcp14> 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 MUST <bcp14>MUST</bcp14> be considered a success. Otherwise,
            the verification MUST <bcp14>MUST</bcp14> be considered a failure.
          </t>
          <t>
            If the verification fails or otherwise experiences an error, error or if any
            needed parameters are missing, then
            the verification MUST <bcp14>MUST</bcp14> be treated as failed and processed in accordance
            with local security policy.
          </t>

          <t>
            This security service is removed from the bundle at the
            security acceptor as required by the BPSec specification. specification <xref target="RFC9172" format="default"/>. 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 MUST <bcp14>MUST</bcp14> be included for the target block. The CRC type, as determined
            by policy, is set in the target block's CRC type field field, and the
            corresponding CRC value is added as the CRC field for that block.
          </t>
        </section>
      </section>
    </section>
    <section numbered="true" toc="default"> toc="default" anchor="second-context">
      <name>Security Context BCB-AES-GCM</name>
      <section numbered="true" toc="default">
        <name>Overview</name>
        <t>
          The BCB-AES-GCM security context replaces the block-type-specific data
          field of its security target with cipher text ciphertext generated using the
          Advanced Encryption Standard (AES) cipher operating in Galois/Counter Mode
          (GCM) <xref target="AES-GCM" format="default"/>. The use of AES-GCM was selected
          as the cipher suite for this confidentiality mechanism for several reasons:

        </t>
        <ol spacing="normal" type="1"><li> The selection of a symmetric-key cipher suite allows for relatively smaller
              keys than asymmetric-key cipher suites.
            </li>
          <li> 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.
            </li>
          <li>
              The use of the Galois/Counter Mode produces cipher-text ciphertext with the same size as
              the plain text plaintext making the replacement of target block information easier as
              length fields do not need to be changed.
            </li>
          <li>
              The AES-GCM cipher suite provides authenticated encryption, as required by the
              BPSec protocol.
            </li>
        </ol>
        <t>
          Additionally, the BCB-AES-GCM security context generates an
          authentication tag based on the plain text plaintext value of the block-type-specific
          data and other additional authenticated data (AAD) that might be specified
          via parameters to this security context.
        </t>
        <t>
          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 <xref target="RFC8152" format="default"/> Table 9: Algorithm 9 ("Algorithm Value for AES-GCM. AES-GCM") of <xref target="RFC8152" format="default"/>.
        </t>
        <t>
          The BCB-AES-GCM security context MUST <bcp14>MUST</bcp14> have the security context identifier
          specified in <xref target="sc_ids" format="default"/>.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Scope</name>
        <t>
          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 cipher text. ciphertext. The second
          defines the set of information used to generate an authentication tag.
        </t>
        <t>
          The scope of the confidentiality service defines the set of information
          provided to the AES-GCM cipher for the purpose of producing cipher text. ciphertext.
          This MUST <bcp14>MUST</bcp14> be the full set of plain text plaintext contained in the
          block-type-specific data field of the security target.
        </t>

        <t>
          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, service and the scope flags used to identify other
          optional information, and MAY information; it <bcp14>MAY</bcp14> include other information
          (additional authenticated data), as follows.

        </t>
        <dl newline="true" spacing="normal" indent="4"> indent="3">
          <dt>Primary block</dt>
          <dd>
            <t>
              The primary block identifies a bundle and, 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.
            </t>
            <t>
              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.
            </t>
            <t>
              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.
            </t>
          </dd>
          <dt>Security target other fields</dt>
          <dt>Other fields of the security target</dt>
          <dd>
            <t>
              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.
            </t>
            <t>
              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 source, then the policy for
              handling the security target has been modified.
            </t>
            <t>
              Including this information as part of additional authenticated data
              ensures that the cipher text ciphertext in the security target will not be used
              with a different set of block policy than originally set at the
              time of encryption.
            </t>
          </dd>
          <dt>BCB other fields</dt>
          <dt>Other fields of the BCB</dt>
          <dd>
            <t>
              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.
            </t>
            <t>
              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 source, then the policy for
              handling the BCB has been modified.
            </t>
            <t>
              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.
            </t>
	    <aside>
            <t>
              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 re-used reused across security
              contexts,
              contexts and because the AAD scope flags used to identify
              the AAD are included in the AAD.
            </t>
	    </aside>
          </dd>
        </dl>
        <t>
          The scope of the BCB-AES-GCM security context is configured using
          an optional security context parameter.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Parameters</name>
        <t>
          BCB-AES-GCM can be parameterized to specify the AES variant,
          initialization vector, key information, and identify additional
          authenticated data.
        </t>
        <section numbered="true" toc="default">
          <name>Initialization Vector (IV)</name>
          <t>
            This optional parameter identifies the initialization vector (IV)
            used to initialize the AES-GCM cipher.
          </t>
          <t>
            The length of the initialization vector, prior to any CBOR encoding,
            MUST
            <bcp14>MUST</bcp14> be between 8-16 bytes. A value of 12 bytes SHOULD <bcp14>SHOULD</bcp14> be used
            unless local security policy requires a different length.
          </t>
          <t>
            This value MUST <bcp14>MUST</bcp14> be encoded as a CBOR byte string.
          </t>
          <t>
            The initialization vector can have any value value, with the caveat that a
            value MUST NOT <bcp14>MUST NOT</bcp14> be re-used reused for multiple encryptions using the same
            encryption key. This value MAY <bcp14>MAY</bcp14> be re-used 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.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>AES Variant</name>
          <t>
            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.
          </t>
          <t>
            This value MUST <bcp14>MUST</bcp14> be encoded as a CBOR unsigned integer.
          </t>
          <t>
            Valid values for this parameter are as follows.
          </t>
          <t keepWithNext="true">
              AES Variant Parameter Values
          </t>
          <table align="center">
          <name>AES Variant Parameter Values</name>
            <thead>
              <tr>
                <th align="center">Value</th>
                <th align="center">Description</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">1</td>
                <td align="center">A128GCM
                <td>A128GCM as defined in <xref target="RFC8152" format="default"/> Table 9: Algorithm Values 9 ("Algorithm Value for AES-GCM</td> AES-GCM") of <xref target="RFC8152" format="default"/></td>
              </tr>
              <tr>
                <td align="center">3</td>
                <td align="center">A256GCM
                <td>A256GCM as defined in <xref target="RFC8152" format="default"/> Table 9: Algorithm Values 9 ("Algorithm Value for AES-GCM</td> AES-GCM") of <xref target="RFC8152" format="default"/></td>
              </tr>
            </tbody>
          </table>
          <t>
            When not provided, implementations SHOULD <bcp14>SHOULD</bcp14> 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.
          </t>
          <t>
            Regardless of the variant, the generated authentication tag MUST <bcp14>MUST</bcp14>
            always be 128 bits.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Wrapped Key</name>
          <t>
	    This optional parameter contains the output of the AES key wrap
            authenticated encryption function (KW-AE) as defined in <xref target="RFC5649" target="RFC3394" format="default"/>.  Specifically, this parameter holds the cipher text ciphertext produced when running the KW-AE 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 (KW-AD) 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.
          </t>
          <t>
            This value MUST <bcp14>MUST</bcp14> be encoded as a CBOR byte string.
          </t>
          <t>
            If this parameter is not present present, then security verifiers
            and acceptors MUST <bcp14>MUST</bcp14> determine the proper key as a function of their local BPSec policy
            and configuration.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>AAD Scope Flags</name>
          <t>
            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).
          </t>
          <t>
            This value MUST <bcp14>MUST</bcp14> be represented as a CBOR unsigned
            integer, the value of which MUST <bcp14>MUST</bcp14> be processed as a 16-bit field.
            The maximum value of this field, as a CBOR unsigned integer, MUST <bcp14>MUST</bcp14> be
            65535.
          </t>
	  <t>When not provided, implementations <bcp14>SHOULD</bcp14> 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.
	  </t>
          <t>
            Implementations MUST <bcp14>MUST</bcp14> 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 MUST NOT <bcp14>MUST NOT</bcp14> be altered until the
            security service is completed at the security acceptor in the
            network and removed from the bundle.
          </t>
          <t>
            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.
          </t>
          <ul empty="true" spacing="normal">
            <li>- Bit

          <dl>
            <dt>Bit 0 (the low-order bit, 0x0001): Primary Block Flag. </li>
            <li>- Bit 0x0001):</dt><dd>Include primary block flag</dd>
            <dt>Bit 1 (0x0002): Target Header Flag.</li>
            <li>- Bit (0x0002):</dt><dd>Include target header flag</dd>
            <dt>Bit 2 (0x0004): Security Header Flag. </li>
            <li>- Bits 3-7 are reserved.</li>
            <li>- Bits 8-15 are unassigned.</li>
          </ul> (0x0004):</dt><dd>Include security header flag</dd>
            <dt>Bits 3-7:</dt><dd>Reserved</dd>
            <dt>Bits 8-15:</dt><dd>Unassigned</dd>
          </dl>
        </section>
        <section numbered="true" toc="default">
          <name>Enumerations</name>
          <t>
            The BCB-AES-GCM security context parameters are listed in
            <xref target="bcb_parm_table" format="default"/>. In this table, the "Parm Id" column
            refers to the expected Parameter Identifier parameter identifier described in
             <xref target="I-D.ietf-dtn-bpsec" format="default"/>, Section 3.10 "Parameter
<xref target="RFC9172" section="3.10" sectionFormat="bare">"Parameter
             and Result Identification". Identification"</xref> of <xref target="RFC9172"/>.
          </t>
          <t>
            If the default value
            An empty "Default Value" column is empty, this indicates that the
            security context parameter does not have a default value.
          </t>
          <t keepWithNext="true">
               BCB-AES-GCM Security Parameters
          </t>
          <table align="center" anchor="bcb_parm_table">
          <name>BCB-AES-GCM Security Context Parameters</name>
            <thead>
              <tr>
                <th align="center">Parm Id</th>
                <th align="center">Parm Name</th>
                <th align="center">CBOR Encoding Type</th>
                <th align="center">Default Value</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">1</td>
                <td align="center">Initialization Vector</td>
                <td align="center">Byte String</td> align="center">byte string</td>
                <td align="center"/>
              </tr>
              <tr>
                <td align="center">2</td>
                <td align="center">AES Variant</td>
                <td align="center">Unsigned Integer</td> align="center">unsigned integer</td>
                <td align="center">3</td>
              </tr>
              <tr>
                <td align="center">3</td>
                <td align="center">Wrapped Key</td>
                <td align="center">Byte String</td> align="center">byte string</td>
                <td align="center"/>
              </tr>
              <tr>
                <td align="center">4</td>
                <td align="center">AAD Scope Flags</td>
                <td align="center">Unsigned Integer</td> align="center">unsigned integer</td>
                <td align="center">7</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="bcb_results" numbered="true" toc="default">
        <name>Results</name>
        <t>
        The BCB-AES-GCM security context produces a single security result
        carried in the security block: the authentication tag.
        </t>
        <t>
        NOTES:
        </t>
        <ul spacing="normal">

          <li>
            The cipher text 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
            cipher text
            ciphertext of the same size as its plain text and, plaintext; therefore,
            no additional logic is required to handle padding or overflow caused
            by the encryption in most cases (see below). cases.
          </li>
          <li>
            If the authentication tag can be separated from the cipher text, ciphertext, then
            the tag MAY <bcp14>MAY</bcp14> be separated and stored in the authentication tag
            security result field. Otherwise, the security target block MUST <bcp14>MUST</bcp14> be
            resized to accommodate the additional 128 bits of authentication
            tag included with the generated cipher text ciphertext replacing the
            block-type-specific-data
            block-type-specific data field of the security target block.
          </li>
        </ul>
        <section numbered="true" toc="default">
          <name>Authentication Tag</name>
          <t>
          The authentication tag is generated by the cipher suite over the
          security target plain text plaintext input to the cipher suite as combined with
          any optional additional authenticated data. This tag is used to ensure
          that the plain text plaintext (and important information associated with the
          plain text)
          plaintext) is authenticated prior to decryption.
          </t>
          <t>
          If the authentication tag is included in the cipher text ciphertext placed
          in the security target block-type-specific data field, then this
          security result MUST NOT <bcp14>MUST NOT</bcp14> be included in the BCB for that security
          target.
          </t>
          <t>
          The length of the authentication tag, prior to any CBOR encoding,
          MUST
          <bcp14>MUST</bcp14> be 128 bits.
          </t>
          <t>
          This value MUST <bcp14>MUST</bcp14> be encoded as a CBOR byte string.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Enumerations</name>

          <t>
          The BCB-AES-GCM security context results are listed in
            <xref target="bcb_res_table" format="default"/>. In this table, the "Result Id" column
            refers to the expected Result Identifier result identifier described in
             <xref target="I-D.ietf-dtn-bpsec" format="default"/>, Section 3.10 "Parameter
             <xref target="RFC9172" section="3.10" sectionFormat="bare">"Parameter
             and Result Identification".
          </t>
          <t keepWithNext="true">BCB-AES-GCM Security Results Identification"</xref> of <xref target="RFC9172"/>.
          </t>
          <table align="center" anchor="bcb_res_table">
          <name>BCB-AES-GCM Security Results</name>
            <thead>
              <tr>
                <th align="center">Result Id</th>
                <th align="center">Result Name</th>
                <th align="center">CBOR Encoding Type</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">1</td>
                <td align="center">Authentication Tag</td>
                <td align="center">Byte String</td> align="center">byte string</td>
              </tr>
            </tbody>
          </table>
        </section>
      </section>
      <section anchor="bcb_key_mgmt" numbered="true" toc="default">
        <name>Key Considerations</name>
        <t>
        Keys used with this context MUST <bcp14>MUST</bcp14> be symmetric and MUST <bcp14>MUST</bcp14> 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 integer integers divisible by 8 bytes bytes, and special padding-aware AES
        key wrap algorithms are not needed.
        </t>
        <t>
        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.

        </t>
        <ul empty="true" spacing="normal">
          <li> Pre-placed
          <li>Pre-placed keys selected based on local policy. </li>
          <li> Keys
          <li>Keys extracted from material carried in the BCB. </li>
          <li> Session
          <li>Session keys negotiated via a mechanism external to the BCB. </li>
        </ul>
        <t>
        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 key encryption
        key (KEK)
        KEK used in the wrapping of the symmetric AES content-encrypting key.
        </t>
        <t>
        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^64, 2<sup>64</sup>, as
        described in Appendix B of <xref target="AES-GCM" format="default"/>.
        </t>
        <t>
        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^32, 2<sup>32</sup>, as described in Section
        8.3 of <xref target="AES-GCM" format="default"/>.
        </t>
        <t>
        As discussed in <xref target="SecCons" format="default"/> and emphasized here, it is
        strongly recommended that keys be protected once generated, both
        when they are stored and when they are transmitted.
        </t>
      </section>
      <section anchor="GcmCons" numbered="true" toc="default">
        <name>GCM Considerations</name>
        <t>
        The GCM cryptographic mode of AES has specific requirements that
        MUST
        <bcp14>MUST</bcp14> be followed by implementers for the secure function of the
        BCB-AES-GCM security context. While these requirements are well
        documented in <xref target="AES-GCM" format="default"/>, some of them are
        repeated here for emphasis.
        </t>
        <ul empty="true" spacing="normal">
          <li>
            <t>
            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
            MUST
            <bcp14>MUST</bcp14> be unique. A per-invocation IV MUST NOT <bcp14>MUST NOT</bcp14> be used with a security
            key more than one time. If a per-invocation IV and key pair are repeated 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 <xref target="AES-GCM" format="default"/>.
            </t>

            <t>
            Methods of generating unique IV values are provided in Chapter Section 8
            of <xref target="AES-GCM" format="default"/>. For example, one method decomposes the
            IV value into a fixed field and an invocation field. The fixed field
            being
            is a constant value associated with a device device, and the invocation
            field changing changes on each invocation (such as by incrementing an
            integer counter). Implementers SHOULD <bcp14>SHOULD</bcp14> carefully read
            all relevant sections of <xref target="AES-GCM" format="default"/> when generating
            any mechanism to create unique IVs.
            </t>
          </li>
          <li>
            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, and thus is distinct from the aforementioned
            requirement related to per-invocation IVs.
          </li>
          <li>
            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
            SHOULD
            <bcp14>SHOULD</bcp14> 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 <xref target="AES-GCM" format="default"/>.
          </li>
          <li>
            As discussed in Appendix B of <xref target="AES-GCM" format="default"/>,
            implementations SHOULD <bcp14>SHOULD</bcp14> 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 have been be used at least
            once.
          </li>
          <li>
            As discussed in the Security Considerations section Section
            <xref target="RFC9172" section="8" sectionFormat="bare">"Security Considerations"</xref> of <xref target="I-D.ietf-dtn-bpsec" format="default"/>, target="RFC9172"/>, 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 SHOULD <bcp14>SHOULD</bcp14> attempt to detect replay attacks
            by using mechanisms such as those described in Appendix D of
            <xref target="AES-GCM" format="default"/>.
          </li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>Canonicalization Algorithms</name>
        <t>
        This section defines the canonicalization algorithms used to prepare
        the inputs used to generate both the cipher text ciphertext and the
        authentication tag.
        </t>
        <t>
        In all cases, the canonical form of any portion of an extension block
        MUST
        <bcp14>MUST</bcp14> be performed created as described in <xref target="I-D.ietf-dtn-bpsec" target="RFC9172" format="default"/>.
        The canonicalization algorithms defined in <xref target="I-D.ietf-dtn-bpsec" target="RFC9172" format="default"/>
        adhere to the canonical forms for extension blocks defined in
        <xref target="I-D.ietf-dtn-bpbis" target="RFC9171" format="default"/> but resolve ambiguities related to
        how values are represented in CBOR.
        </t>
        <section anchor="bcb_canon_cipher" numbered="true" toc="default">
          <name>Cipher text related calculations</name>
          <name>Calculations Related to Ciphertext</name>
          <t>
          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 plain text plaintext
          used during encryption MUST <bcp14>MUST</bcp14> be calculated as the value of the
          block-type-specific data field of the security target
          excluding the BP CBOR encoding.
          </t>
          <t>
          Consider the following
          <xref target="enc_ex"/> shows two CBOR encoded CBOR-encoded examples and the
          plain text
          plaintext that would be extracted from them. The first example
          is an unsigned integer, while the second is a byte string.
          </t>
          <t keepWithNext="true">
             CBOR Plain Text Extraction Examples
          </t>
          <table align="center" anchor="enc_ex">
          <name>CBOR Plaintext Extraction Examples</name>
            <thead>
              <tr>
                <th align="center">CBOR Encoding (Hex)</th>
                <th align="center">CBOR Part (Hex)</th>
                <th align="center">Plain Text align="center">Plaintext Part (Hex)</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td align="center">18ED</td>
                <td align="center">18</td>
                <td align="center">ED</td>
              </tr>
              <tr>
                <td align="center">C24CDEADBEEFDEADBEEFDEADBEEF</td>
                <td align="center">C24C</td>
                <td align="center">DEADBEEFDEADBEEFDEADBEEF</td>
              </tr>
            </tbody>
          </table>

          <t>
          Similarly, the cipher text
          The ciphertext used during decryption MUST <bcp14>MUST</bcp14> 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.
          </t>
          <t>
          All other fields of the security target (such as the block type code,
          block number, block processing control flags, or any CRC information)
          MUST NOT
          <bcp14>MUST NOT</bcp14> be considered as part of encryption or decryption.
          </t>
        </section>
        <section anchor="bcb_canon_aad" numbered="true" toc="default">
          <name>Additional Authenticated Data</name>
          <t>
          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.
          </t>
          <t>
          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 MUST <bcp14>MUST</bcp14> be included in the AAD value itself. This process MUST <bcp14>MUST</bcp14> be
          followed when generating AAD for either encryption or decryption.

          </t>
          <ol spacing="normal" type="1"><li>
              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.
            </li>
            <li>
              If the primary block flag of the AAD scope flags is set to
              1, then a canonical form of the bundle's primary
              block MUST <bcp14>MUST</bcp14> be calculated and the result appended to the AAD.
            </li>
            <li>
              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 MUST <bcp14>MUST</bcp14> be calculated and, in that order, appended
              to the AAD.
            </li>
            <li>
              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 MUST <bcp14>MUST</bcp14> be calculated and, in that order, appended to the AAD.
            </li>
          </ol>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>Processing</name>
        <section numbered="true" toc="default">
          <name>Encryption</name>

          <t>
          During encryption, four inputs data elements are prepared for input to the
          AES/GCM
          AES-GCM cipher: the encryption key, the IV,
          the security target plain text plaintext to be encrypted, and any
          additional authenticated data. These data items MUST <bcp14>MUST</bcp14> be generated
          as follows.
          </t>
          <t>
          Prior to encryption, if a CRC value is present for the target block,
          then that CRC value MUST <bcp14>MUST</bcp14> 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."
          </t>
          <ul empty="true" spacing="normal">
            <li>
              The encryption key MUST <bcp14>MUST</bcp14> 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 <xref target="bcb_key_mgmt"
              format="default"/>.
            </li>
            <li>
              The IV selected MUST <bcp14>MUST</bcp14> 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 MUST
              NOT <bcp14>MUST
              NOT</bcp14> be used more than once.
            </li>
            <li>
              The security target plain text plaintext for encryption MUST <bcp14>MUST</bcp14> be generated as
              discussed in <xref target="bcb_canon_cipher" format="default"/>.
            </li>
            <li>
              Additional authenticated data MUST <bcp14>MUST</bcp14> be generated as
              discussed in <xref target="bcb_canon_aad" format="default"/> format="default"/>, with the value of
              AAD scope flags being taken from local security policy.
            </li>
          </ul>
          <t>
          Upon successful encryption encryption, the following actions MUST <bcp14>MUST</bcp14> occur.

          </t>
          <ul empty="true" spacing="normal">
            <li>
              The cipher text ciphertext produced by AES/GCM MUST AES-GCM <bcp14>MUST</bcp14> replace the bytes used
              to define the plain text plaintext in the security target block's
              block-type-specific data field. The block length of the security
              target MUST <bcp14>MUST</bcp14> be updated if the generated cipher text ciphertext is larger
              than the plain text plaintext (which can occur when the authentication
              tag is included in the cipher text ciphertext calculation, as discussed
              in <xref target="bcb_results" format="default"/>).
            </li>
            <li>
              The authentication tag calculated by the AES/GCM AES-GCM cipher MAY <bcp14>MAY</bcp14> be
              added as a security result for the security target in the BCB
              holding results for this security operation, in which case it
              MUST
              <bcp14>MUST</bcp14> be processed as described in <xref target="bcb_results" format="default"/>.
            </li>
            <li>
              The authentication tag MUST <bcp14>MUST</bcp14> be included either as a security
              result in the BCB representing the security operation or
              (with the cipher text) ciphertext) in the security target block-type-specific
              data field.
            </li>
          </ul>
          <t>
          Finally, the BCB containing information about this security operation
          MUST
          <bcp14>MUST</bcp14> be updated as follows. These operations can occur in any order.
          </t>
          <ul empty="true" spacing="normal">
            <li>
              The security context identifier for the BCB MUST <bcp14>MUST</bcp14> be set to the context
              identifier for BCB-AES-GCM.
            </li>
            <li>
              The IV input to the cipher MUST <bcp14>MUST</bcp14> be added as the
              IV security context parameter for the BCB.
            </li>
            <li>
              Any local flags used to generated generate AAD for this cipher MUST <bcp14>MUST</bcp14> 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.
            </li>
            <li>
              The encryption key MAY <bcp14>MAY</bcp14> be included as a security parameter
              context parameter, in which case it MUST <bcp14>MUST</bcp14> be
              wrapped using the NIST AES-KW algorithm AES key wrap function as defined in <xref
              target="RFC3394" format="default"/> and the results of the
              wrapping added as the wrapped key security context parameter for
              the BCB.
            </li>
            <li>
              The AES variant used by this security context SHOULD <bcp14>SHOULD</bcp14> be added as
              the AES variant security context parameter for the BCB if it differs from
              the default key length. Otherwise, this parameter MAY <bcp14>MAY</bcp14> be
              omitted if doing so provides a useful reduction in message sizes.
            </li>
          </ul>
          <t>
           Problems encountered in the encryption MUST <bcp14>MUST</bcp14> be processed in accordance
           with local security policy. This MAY <bcp14>MAY</bcp14> 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.
          </t>
        </section>
        <section numbered="true" toc="default">
          <name>Decryption</name>
          <t>
          During decryption, five inputs data elements are prepared for input to the
          AES/GCM
          AES-GCM cipher: the decryption key, the IV,
          the security target cipher text ciphertext to be decrypted, any additional
          authenticated data, and the authentication tag generated from the
          original encryption. These data items MUST <bcp14>MUST</bcp14> be generated as follows.
          </t>
          <ul empty="true" spacing="normal">
            <li>
              The decryption key MUST <bcp14>MUST</bcp14> be derived using the wrapped key
              security context parameter if such a parameter is included in the
              security context parameters of the BCB. Otherwise Otherwise, this key
              MUST
              <bcp14>MUST</bcp14> be derived in accordance with local security policy at the
              decrypting node as discussed in <xref target="bcb_key_mgmt" format="default"/>.
            </li>
            <li>
              The IV MUST <bcp14>MUST</bcp14> 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 MAY <bcp14>MAY</bcp14> be derived
              as a function of local security policy and other BCB contents contents, or
              a lack of an IV security context parameter in the BCB MAY <bcp14>MAY</bcp14> be treated
              as an error by the decrypting node.
            </li>
            <li>
              The security target cipher text ciphertext for decryption MUST <bcp14>MUST</bcp14> be generated as
              discussed in <xref target="bcb_canon_cipher" format="default"/>.
            </li>
            <li>
              Additional authenticated data MUST <bcp14>MUST</bcp14> be generated as
              discussed in <xref target="bcb_canon_aad" format="default"/> 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 parameters, then these flags
              MAY
              <bcp14>MAY</bcp14> be derived from local security policy in cases where the
              set of such flags is determinable in the network.
            </li>
            <li>
              The authentication tag MUST <bcp14>MUST</bcp14> be present either as a security
              result in the BCB representing the security operation or
              (with the cipher text) ciphertext) in the security target block-type-specific
              data field.
            </li>
          </ul>
          <t>
          Upon successful decryption decryption, the following actions MUST action <bcp14>MUST</bcp14> occur.

          </t>
          <ul empty="true" spacing="normal">
            <li>
              The plain text plaintext produced by AES/GCM MUST AES-GCM <bcp14>MUST</bcp14> replace
              the bytes used to define the cipher text ciphertext in the security target
              block's block-type-specific data field. Any changes to the
              security target block length field MUST <bcp14>MUST</bcp14> be
              corrected in cases where the plain
              text plaintext has a different length
              than the replaced cipher text. ciphertext.
            </li>
          </ul>
          <t>
          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 MUST <bcp14>MUST</bcp14> 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.
          </t>
          <t>
          If the cipher text ciphertext fails to authenticate, if any needed parameters
          are missing, or if there are other problems in the decryption decryption, then
          the decryption MUST <bcp14>MUST</bcp14> be treated as failed and processed in accordance
          with local security policy.
          </t>
        </section>
      </section>
    </section>
    <section anchor="IANA" toc="default" numbered="true">
      <name>IANA Considerations</name>
      <section anchor="sc_ids" numbered="true" toc="default">
        <name>Security Context Identifiers</name>
        <t>
        This specification allocates two security context identifiers from the
        "BPSec Security Context Identifiers" registry defined in
        <xref target="I-D.ietf-dtn-bpsec" target="RFC9172" format="default"/>.
        </t>
        <t keepWithNext="true">Additional
        <table align="center" anchor="iana_table">
        <name>Additional Entries for the BPSec Security Context Identifiers Registry:</t>
        <table align="center" anchor="iana_table"> Registry</name>
          <thead>
            <tr>
              <th align="center">Value</th>
              <th align="center">Description</th>
              <th align="center">Reference</th>
              <th>Description</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">TBA</td>
              <td align="center">BIB-HMAC-SHA2</td>
              <td align="center">This document</td> align="center">1</td>
              <td>BIB-HMAC-SHA2</td>
              <td>RFC 9173</td>
            </tr>
            <tr>
              <td align="center">TBA</td>
              <td align="center">BCB-AES-GCM</td>
              <td align="center">This document</td> align="center">2</td>
              <td>BCB-AES-GCM</td>
              <td>RFC 9173</td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="default">
        <name>Integrity Scope Flags</name>
        <t>
          The BIB-HMAC-SHA2 security context has an Integrity Scope Flags field for
          which IANA is requested to create has created and maintain now maintains a new registry named
          "BPSec BIB-HMAC-SHA2 Integrity Scope Flags" on the Bundle Protocol "Bundle Protocol" registry page.
          Initial
          <xref target="bib_flags"/> shows the initial values for this registry are given below. registry.
        </t>
        <t>
          The registration policy for this registry is: is Specification Required. Required <xref target="RFC8126"/>.
        </t>
        <t>
          The value range is unsigned 16-bit integer.
        </t>
        <t keepWithNext="true">
            BPSec

        <table align="center" anchor="bib_flags">
        <name>BPSec BIB-HMAC-SHA2 Integrity Scope Flags Registry
        </t>
        <table align="center" anchor="bib_flags"> Registry</name>
          <thead>
            <tr>
              <th align="center">Bit Position (right to left)</th>
              <th align="center">Description</th>
              <th align="center">Reference</th>
              <th>Description</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0</td>
              <td align="center">Include
              <td>Include primary block</td>
              <td align="center">This document</td> block flag</td>
              <td>RFC 9173</td>
            </tr>
            <tr>
              <td align="center">1</td>
              <td align="center">Include
              <td>Include target header flag</td>
              <td align="center">This document</td>
              <td>RFC 9173</td>
            </tr>
            <tr>
              <td align="center">2</td>
              <td align="center">Include
              <td>Include security header flag</td>
              <td align="center">This document</td>
              <td>RFC 9173</td>
            </tr>
            <tr>
              <td align="center">3-7</td>
              <td align="center">reserved</td>
              <td align="center">This document</td>
              <td>Reserved</td>
              <td>RFC 9173</td>
            </tr>
            <tr>
              <td align="center">8-15</td>
              <td align="center">unassigned</td>
              <td align="center">This document</td>
              <td>Unassigned</td>
              <td></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="default">
        <name>AAD Scope Flags</name>
        <t>
          The BCB-AES-GCM security context has an AAD Scope Flags field for
          which IANA is requested to create has created and maintain now maintains a new registry named
          "BPSec BCB-AES-GCM AAD Scope Flags" on the Bundle Protocol "Bundle Protocol" registry page.
          Initial
          <xref target="bcb_flags"/> shows the initial values for this registry
          are given below. registry.
        </t>
        <t>
          The registration policy for this registry is: is Specification Required.
        </t>
        <t>
          The value range is unsigned 16-bit integer.
        </t>
        <t keepWithNext="true">
            BPSec
        <table align="center" anchor="bcb_flags">
        <name>BPSec BCB-AES-GCM AAD Scope Flags Registry
        </t>
        <table align="center" anchor="bcb_flags"> Registry</name>
          <thead>
            <tr>
              <th align="center">Bit Position (right to left)</th>
              <th align="center">Description</th>
              <th align="center">Reference</th>
              <th>Description</th>
              <th>Reference</th>
            </tr>
          </thead>
          <tbody>
            <tr>
              <td align="center">0</td>
              <td align="center">Include
              <td>Include primary block</td>
              <td align="center">This document</td> block flag</td>
              <td>RFC 9173</td>
            </tr>
            <tr>
              <td align="center">1</td>
              <td align="center">Include
              <td>Include target header flag</td>
              <td align="center">This document</td>
              <td>RFC 9173</td>
            </tr>
            <tr>
              <td align="center">2</td>
              <td align="center">Include
              <td>Include security header flag</td>
              <td align="center">This document</td>
              <td>RFC 9173</td>
            </tr>
            <tr>
              <td align="center">3-7</td>
              <td align="center">reserved</td>
              <td align="center">This document</td>
              <td>Reserved</td>
              <td>RFC 9173</td>
            </tr>
            <tr>
              <td align="center">8-15</td>
              <td align="center">unassigned</td>
              <td align="center">This document</td>
              <td>Unassigned</td>
              <td></td>
            </tr>
          </tbody>
        </table>
      </section>
      <section numbered="true" toc="default">
        <name>Guidance for Designated Experts</name>
        <t>
            New assignments within the "BPSec BIB-HMAC-SHA2
            Integrity Scope Flags Registry Flags" and the
            "BPSec BCB-AES-GCM AAD Scope Flags Registry 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.

        </t>
        <ul spacing="normal">
          <li>
                Ascertain the existence of suitable documentation
                (a specification) as described in <xref target="RFC8126" format="default"/>
                and to verify that the document is permanently and
                publicly available.
              </li>

          <li>
                Ensure that any changes to the "BPSec BIB-HMAC-SHA2 Integrity Scope Flags 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.
              </li>
          <li>
                Ensure that any changes to the "BPSec BCB-AES-GCM AAD Scope Flags 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.
              </li>
          <li>
                Ensure that any processing changes proposed with new assignments
                do not alter any required behavior in this specification.
              </li>
        </ul>
      </section>
    </section>
    <section anchor="SecCons" numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>
      Security considerations specific to a single security context are
      provided in the description of that context. context (see Sections <xref target="first-context" format="counter"/> and <xref target="second-context" format="counter"/>). 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 they should also be
      reviewed by security context implementors.
      </t>
      <section numbered="true" toc="default">
        <name>Key Management</name>
        <t>
        The delayed and disrupted nature of DTNs Delay-Tolerant
   Networking (DTN) complicates the process of key management
        because there might not be reliable, timely 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 bi-directional bidirectional
        communication.
        </t>
        <t>
        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 a DTN.
        </t>
        <t>
        For these reasons, the default security contexts described in this document rely
        on symmetric key symmetric-key cryptographic mechanisms because asymmetric key asymmetric-key infrastructure (such
        as a public key infrastructure) might be impractical in this environment.
        </t>
        <t>
        BPSec assumes that "key management is handled as a separate part of network management"
        <xref target="I-D.ietf-dtn-bpsec" target="RFC9172" format="default"/>. This assumption is also made
        by the security contexts defined in this document document, which do not define new protocols for
        key derivation, exchange of key-encrypting keys, KEKs, revocation of existing keys,
        or the security configuration or policy used to select certain keys for certain
        security operations.
        </t>
        <t>
        Nodes using these security contexts need to perform the following kinds of
        activities, independent of the construction, transmission, and processing of
        BPSec security blocks.

        </t>
        <ul empty="true" spacing="normal">
          <li>
            Establish shared key-encrypting-keys KEKs with other nodes in the network using
            an out-of-band mechanism. This might include pre-sharing of key encryption
            keys KEKs
            or the use of traditional older key establishment mechanisms prior to the
            exchange of BPsec BPSec security blocks.
          </li>
          <li>
            Determine when a key is considered exhausted and no longer to be used in
            the generation, verification, or acceptance of a security block.
          </li>

          <li>
            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 to include mechanisms, including local security policy,
            time relative to the generation or use of the key, or as other mechanisms
            specified through network management.
          </li>
          <li>
            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.
          </li>
        </ul>
        <t>
        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.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Key Handling</name>
        <t>
        Once generated, keys should be handled as follows.

        </t>
        <ul empty="true" spacing="normal">
          <li>
            It is strongly RECOMMENDED <bcp14>RECOMMENDED</bcp14> that implementations protect keys both
            when they are stored and when they are transmitted.
          </li>
          <li>
            In the event that a key is compromised, any security operations using
            a security context associated with that key SHOULD <bcp14>SHOULD</bcp14> also be
            considered compromised. This means that the BIB-HMAC-SHA2 security context
            SHOULD NOT
            <bcp14>SHOULD NOT</bcp14> be treated as providing integrity when used with a compromised key key, and
            BCB-AES-GCM SHOULD NOT <bcp14>SHOULD NOT</bcp14> be treated as providing confidentiality when used with a compromised key.
          </li>
          <li>
            The same key, whether a key-encrypting-key KEK or a wrapped key, MUST NOT <bcp14>MUST NOT</bcp14>
            be used for different algorithms as doing so might leak information
            about the key.
          </li>
          <li>
            A key-encrypting-key MUST NOT KEK <bcp14>MUST NOT</bcp14> be used to encrypt keys for different security
            contexts. Any key-encrypting-key KEK used by a security context defined in this document MUST <bcp14>MUST</bcp14>
            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 key-encrypting-key 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 key-encrypting-key KEK to unwrap keys
            for different security contexts.
          </li>
        </ul>
      </section>
      <section numbered="true" toc="default">
        <name>AES GCM</name>
        <t>
        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 <xref target="GcmCons" format="default"/> as part of the documentation
        of the BCB-AES-GCM security context.
        </t>
        <t>
        The length of the cipher text ciphertext produced by the
        GCM mode of AES will be equal to the length of the plain text plaintext input
        to the cipher suite. The authentication tag also produced by this
        cipher suite is separate from the cipher text. ciphertext. However, it should be
        noted that implementations of the AES-GCM cipher suite might not separate
        the concept of cipher text ciphertext and authentication tag in their application
        programming interface Application
        Programming Interface (API).
        </t>
        <t>
        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 cipher text ciphertext replacing the block-type-specific-data block-type-specific data
        field of the target block. Implementations MAY <bcp14>MAY</bcp14> use the authentication tag
        security result in cases where keeping target block length unchanged is an
        important processing concern. In all cases, the cipher text ciphertext and authentication
        tag MUST <bcp14>MUST</bcp14> be processed in accordance with the API of the AES-GCM cipher suites
        at the security source and security acceptor.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>AES Key Wrap</name>
        <t>
        The AES key wrap (AES-KW) 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 key encryption key KEK provided by local security policy at the security verifier
        or security acceptor.
        </t>
      </section>
      <section numbered="true" toc="default">
        <name>Bundle Fragmentation</name>
        <t>
        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.

        </t>
        <ul empty="true" spacing="normal">
          <li>
            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 processing
            agent Bundle Protocol
            Agent (BPA) will not know that the target block has been encrypted.
          </li>

          <li>
            A security block can be cryptographically bound to a bundle by setting the
            Integrity Scope Flags
            integrity scope flags (for BIB-HMAC-SHA2) or the AAD Scope Flags 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.
          </li>
          <li>
            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.
          </li>
        </ul>
        <t>
        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.
        </t>
      </section>
    </section>
  </middle>
  <back>
    <references>
      <name>Normative References</name>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8152.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8949.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8742.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.3394.xml"/>

      <reference anchor="AES-GCM">
        <front>
          <title>NIST Special Publication 800-38D:
              Recommendation
          <title>Recommendation for Block Cipher Modes of Operation:
              Galois/Counter Mode (GCM) and GMAC.</title> GMAC</title>
          <author initials="M." surname="Dworkin"/>
          <date year="2007" month="November"/>
        </front>
<seriesInfo name='NIST Special Publication' value='800-38D' />
<seriesInfo name='DOI' value='10.6028/NIST.SP.800-38D' />
      </reference>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5649.xml"/>

      <reference anchor="SHS"> anchor="SHS" target="https://csrc.nist.gov/publications/detail/fips/180/4/final">
        <front>
          <title>Secure Hash Standard (SHS).</title> (SHS)</title>
          <author>
            <organization>US NIST</organization>
            <organization>National Institute of Standards and Technology</organization>
          </author>
          <date year="2015" month="August"/>
        </front>
        <!-- This is an abuse of this field, but I could not get the
              rendering order I wanted otherwise. -->
         <seriesInfo name="FIPS-180-4," value="Gaithersburg, MD, USA"/>
        <annotation> https://csrc.nist.gov/publications/detail/fips/180/4/final</annotation> name="FIPS PUB" value="180-4"/>
         <seriesInfo name='DOI' value='10.6028/NIST.FIPS.180-4' />
      </reference>

      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2104.xml"/>
      <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8126.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-dtn-bpbis.xml"/>
      <xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-dtn-bpsec.xml"/>

<!-- [I-D.ietf-dtn-bpbis] RFC-to-be 9171 -->

<reference anchor='RFC9171'>
<front>
<title>Bundle Protocol Version 7</title>
<author initials='S' surname='Burleigh' fullname='Scott Burleigh'>
<organization />
</author>
<author initials='K' surname='Fall' fullname='Kevin Fall'>
<organization />
</author>
<author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, III">
<organization />
</author>
<date year='2022' month='January' />

</front>
<seriesInfo name="RFC" value="9171"/>
<seriesInfo name="DOI" value="10.17487/RFC9171"/>
</reference>

<!-- [I-D.ietf-dtn-bpsec] RFC-to-be 9172 -->

<reference anchor='RFC9172'>
<front>
<title>Bundle Protocol Security (BPSec)</title>
<author initials="E." surname="Birrane, III" fullname="Edward J. Birrane, III">
<organization />
</author>
<author initials='K' surname='McKeever' fullname='Kenneth McKeever'>
<organization />
</author>
<date year='2022' month='January' />
</front>
<seriesInfo name="RFC" value="9172"/>
<seriesInfo name="DOI" value="10.17487/RFC9172"/>
</reference>

    </references>

    <section anchor="vectors" toc="default" numbered="true">
      <name>Examples</name>

      <t> This appendix is informative. </t>
      <t>
      This section 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.
      </t>
      <t>
      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.
      </t>
      <t>
      NOTE: The
      NOTES: </t>
<ul>
<li>The bundle diagrams in this section appendix are patterned after the bundle
      diagrams used in <xref target="I-D.ietf-dtn-bpsec" format="default"/> Section 3.11 "BSP <xref target="RFC9172" section="3.11"
      sectionFormat="bare">"BPSec Block Examples".
      </t>
      <t>
      NOTE: Examples"</xref> of <xref target="RFC9172"/>.
      </li>
      <li>
Figures in this section appendix identified as "(CBOR Diagnostic Notation)"
      are represented using the CBOR diagnostic notation defined in <xref target="RFC8949" format="default"/>.
      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
      <xref target="RFC8742" format="default"/>.
      </t>
      <t>
      NOTE:
      </li>

      <li>
      Examples in this section appendix use the "ipn" URI scheme for EndpointID endpoint ID
      naming, as defined in <xref target="I-D.ietf-dtn-bpbis" target="RFC9171" format="default"/>.
      </t>
      <t>
      NOTE:
      </li>
      <li>
      The bundle source is presumed to be the security source for all
      security blocks in this section, appendix, unless otherwise noted.
      </t>
      </li>
</ul>
      <section numbered="true" toc="default">
        <name>Example 1: 1 - Simple Integrity</name>
        <t>
        This example shows the addition of a BIB to a sample bundle
        to provide integrity for the payload block.
        </t>
        <section numbered="true" toc="default">
          <name>Original Bundle</name>
          <t>
          The following diagram shows the original bundle before the
          BIB has been added.
          </t>
          <figure anchor="ex1_orig_bundle">

	  <figure>
	    <name>Example 1 - Original Bundle</name>
	    <artwork align="center" name="" type="" alt="">
<!--

          --> align="center">
                  Block                    Block   Block
<!--
          -->
                in Bundle                  Type    Number
<!--
          -->+========================================+=======+========+
<!--
          -->|
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|
+----------------------------------------+-------+--------+
|  Payload Block                         |   1   |    1   |
<!--
          -->+----------------------------------------+-------+--------+
+----------------------------------------+-------+--------+
	    </artwork>
	  </figure>

          <section anchor="ex_primary_block" numbered="true" toc="default">
            <name>Primary Block</name>
            <t>
            The BPv7 Bundle Protocol version 7 (BPv7) bundle has no special block
            and bundle processing flags 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.
            </t>
            <t>
            The bundle is sourced at the source node ipn:2.1 and destined for
            the destination node ipn:1.2.
The bundle creation time uses a DTN
            creation time of 0 is set to 0, indicating lack of an accurate clock and clock,
	    with a
            sequence number of 40. The lifetime of the bundle is given as
            1,000,000 milliseconds since the bundle creation time.
            </t>
            <t>
            The primary block is provided as follows.

            </t>
            <figure anchor="ex_bdl_prim">
              <name>Primary Block (CBOR Diagnostic Notation)</name>
              <artwork align="left" type="cbor" name="" alt=""><![CDATA[
              <sourcecode type="cbor-diag" name=""><![CDATA[
[
  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              /
]
              ]]></artwork>
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the primary block is 0x88070000820282010282028202018202820201820018281a000f4240. is:
            </t>
<sourcecode>
0x88070000820282010282028202018202820201820018281a000f4240
</sourcecode>
          </section>
          <section anchor="ex_payload_block" numbered="true" toc="default">
            <name>Payload Block</name>

            <t>
            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 32 byte string
            whose value is "Ready Generate a 32 byte payload". 35-byte string.
            </t>
            <t>
            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 "Ready Generate a 32 byte payload" is
            0x52656164792047656e657261746520612033322062797465207061796c6f6164. is:
            </t>
<sourcecode>
0x526561647920746f2067656e657261746520612033322d62797465207061796c6f
6164
</sourcecode>
            <t>
            The payload block is provided as follows.

            </t>
            <figure>
              <name>Payload Block (CBOR Diagnostic Notation)</name>
              <artwork align="left" type="cbor" name="" alt=""><![CDATA[
              <sourcecode type="cbor-diag" name=""><![CDATA[
[
  1,                       / type code: Payload block       /
  1,                       / block number                   /
  0,                       / block processing control flags /
  0,                       / CRC Type type                       /
  h'52656164792047656e65726174652061
  h'526561647920746f206765 / type-specific-data: payload    /
    2033322062797465207061796c6f6164'
  6e657261746520612033322d
  62797465207061796c6f6164'
]
              ]]></artwork>
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the payload block is 0x8501010000582052656164792047656e657261746520612033322062797465207061796c6f6164. is:
            </t>
<sourcecode>
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Bundle CBOR Representation</name>
            <t>
            A BPv7 bundle is represented as an indefinite-length array consisting
            of the blocks comprising the bundle, with a terminator character at
            the end.
            </t>
            <t>
            The CBOR encoding of the original bundle is 0x9f88070000820282010282028202018202820201820018281a000f42408501010000582052656164792047656e657261746520612033322062797465207061796c6f6164ff. is:
            </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
</sourcecode>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Security Operation Overview</name>
          <t>
          This example adds a BIB to the bundle using the BIB-HMAC-SHA2 security
          context to provide an integrity mechanism over the payload block.
          </t>
          <t>
          The following diagram shows the resulting bundle after the
          BIB is added.

          </t>
          <figure anchor="ex1_res_bundle">

	  <figure>
	    <name>Example 1 - Resulting Bundle</name>
	    <artwork align="center" name="" type="" alt="">
<!--

          --> align="center">
                  Block                    Block   Block
<!--
          -->
                in Bundle                  Type    Number
<!--
          -->+========================================+=======+========+
<!--
          -->|
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|  Bundle
+----------------------------------------+-------+--------+
|  Block Integrity Block                 |   11  |    2   |
<!--
          -->|
|  OP(bib-integrity, target=1)           |       |        |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|
+----------------------------------------+-------+--------+
|  Payload Block                         |   1   |    1   |
<!--
          -->+----------------------------------------+-------+--------+
+----------------------------------------+-------+--------+
	    </artwork>
	  </figure>

        </section>
        <section numbered="true" toc="default">
          <name>Bundle
          <name>Block Integrity Block</name>
          <t>
          In this example, a BIB is used to carry an integrity signature over
          the payload block.
          </t>
          <section numbered="true" toc="default">
            <name>Configuration, Parameters, and Results</name>
            <t>
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.
            </t>
            <t>
            This BIB has a single target and includes a single security
            result: the calculated signature over the payload block.
            </t>
            <figure anchor="ex1_cpr">
              <name>Example 1: 1 - Configuration, Parameters, and Results</name>
              <artwork align="center" name="" type="" alt="">
<!--
--> alt="" align="center">
 Key         : h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
<!--
-->
 SHA Variant : HMAC 512/512
<!--
-->
 Scope Flags : 0x00
<!--
-->
 Payload Data: h'52656164792047656e65726174652061
<!--
-->                 2033322062797465207061796c6f6164'
<!--
--> h'526561647920746f2067656e65726174
                 6520612033322d62797465207061796c
                 6f6164'
 IPPT        : h'005823526561647920746f2067656e65
                 7261746520612033322d627974652070
                 61796c6f6164'
 Signature   : h'0654d65992803252210e377d66d0a8dc
<!--
-->                 18a1e8a392269125ae9ac198a9a598be
<!--
-->                 4b83d5daa8be2f2d16769ec1c30cfc34
<!--
-->                 8e2205fba4b3be2b219074fdd5ea8ef0'
<!--
--> h'3bdc69b3a34a2b5d3a8554368bd1e808
                 f606219d2a10a846eae3886ae4ecc83c
                 4ee550fdfb1cc636b904e2f1a73e303d
                 cd4b6ccece003e95e8164dcc89a156e1'
        </artwork>
            </figure>
          </section>
          <section numbered="true" toc="default">
            <name>Abstract Security Block</name>
            <t>
            The abstract security block structure of the BIB's
            block-type-specific-data
            block-type-specific data field for this application is as follows.

            </t>
            <figure anchor="ex1_bib_asb">
              <name>Example 1: 1 - BIB Abstract Security Block (CBOR Diagnostic Notation)</name>
              <artwork align="left" type="cbor" name="" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[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'0654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598b
   e4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0'] h'3bdc69b3a34a2b5d3a8554368bd1e808         / MAC      /
          f606219d2a10a846eae3886ae4ecc83c
          4ee550fdfb1cc636b904e2f1a73e303d
          cd4b6ccece003e95e8164dcc89a156e1']
  ]
]
              ]]></artwork>
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the BIB block-type-specific-data block-type-specific data field (the abstract security block) is
            0x8101010182028202018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0. is:
            </t>
<sourcecode>
0x810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a8554
368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2f1a7
3e303dcd4b6ccece003e95e8164dcc89a156e1
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Representations</name>

            <t>
            The complete BIB wrapping this abstract security block is as follows.

            </t>
            <figure anchor="ex1_bib">
              <name>Example 1: 1 - BIB (CBOR Diagnostic Notation)</name>
              <artwork align="left" type="cbor" name="" alt=""><![CDATA[
              <sourcecode type="cbor-diag" name=""><![CDATA[
[
  11, / type code    /
  2,  / block number /
  0,  / flags        /
  0,  / CRC type     /
  h'8101010182028202018282010782030081820158400654d65992803252210e377d66
  d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc34
  8e2205fba4b3be2b219074fdd5ea8ef0',
  h'810101018202820201828201078203008181820158403bdc69b3a34a
  2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550
  fdfb1cc636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1'
]
              ]]></artwork>
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the BIB block is 0x850b02000058558101010182028202018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef0. is:
            </t>
<sourcecode>
0x850b0200005856810101018202820201828201078203008181820158403bdc69b3
a34a2b5d3a8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1c
c636b904e2f1a73e303dcd4b6ccece003e95e8164dcc89a156e1
</sourcecode>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Final Bundle</name>
          <t>
          The CBOR encoding of the full output bundle, with the BIB: 0x9f88070000820282010282028202018202820201820018281a000f4240850b02000058558101010182028202018282010782030081820158400654d65992803252210e377d66d0a8dc18a1e8a392269125ae9ac198a9a598be4b83d5daa8be2f2d16769ec1c30cfc348e2205fba4b3be2b219074fdd5ea8ef08501010000582052656164792047656e657261746520612033322062797465207061796c6f6164ff.
          </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f4240850b0200
005856810101018202820201828201078203008181820158403bdc69b3a34a2b5d3a
8554368bd1e808f606219d2a10a846eae3886ae4ecc83c4ee550fdfb1cc636b904e2
f1a73e303dcd4b6ccece003e95e8164dcc89a156e185010100005823526561647920
746f2067656e657261746520612033322d62797465207061796c6f6164ff
</sourcecode>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>Example 2: 2 - Simple Confidentiality with Key Wrap</name>
        <t>
        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.
        </t>
        <section numbered="true" toc="default">
          <name>Original Bundle</name>
          <t>
          The following diagram shows the original bundle before the
          BCB has been added.

          </t>
	  <figure anchor="ex2_orig_bundle"> align="center">
	    <name>Example 2 - Original Bundle</name>
	    <artwork align="center" name="" type="" alt="">
<!--

          --> align="center">
                  Block                    Block   Block
<!--
          -->
                in Bundle                  Type    Number
<!--
          -->+========================================+=======+========+
<!--
          -->|
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|
+----------------------------------------+-------+--------+
|  Payload Block                         |   1   |    1   |
<!--
          -->+----------------------------------------+-------+--------+
+----------------------------------------+-------+--------+
	    </artwork>
	  </figure>

          <section numbered="true" toc="default">
            <name>Primary Block</name>
            <t>
           The primary block used in this example is identical to the primary block
           presented in for Example 1 in <xref target="ex_primary_block" format="default"/>.
            </t>
            <t>
            In summary, the CBOR encoding of the primary block is
            0x88070000820282010282028202018202820201820018281a000f4240. is:
            </t>
<sourcecode>
0x88070000820282010282028202018202820201820018281a000f4240
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Payload Block</name>
            <t>
           The payload block used in this example is identical to the payload block
           presented in for Example 1 in <xref target="ex_payload_block" format="default"/>.
            </t>
            <t>
            In summary, the CBOR encoding of the payload block is
            0x8501010000582052656164792047656e657261746520612033322062797465207061796c6f6164. is:
            </t>
<sourcecode>
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Bundle CBOR Representation</name>
            <t>
            A BPv7 bundle is represented as an indefinite-length array consisting
            of the blocks comprising the bundle, with a terminator character at
            the end.
            </t>
            <t>
            The CBOR encoding of the original bundle is
            0x9f88070000820282010282028202018202820201820018281a000f42408501010000582052656164792047656e657261746520612033322062797465207061796c6f6164ff. is:
            </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
</sourcecode>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Security Operation Overview</name>
          <t>
          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.
          </t>
          <t>
          The following diagram shows the resulting bundle after the
          BCB is added.

          </t>
	  <figure anchor="ex2_res_bundle"> align="center">
	    <name>Example 2 - Resulting Bundle</name>

	    <artwork align="center" name="" type="" alt="">
<!--

          --> align="center">
                  Block                    Block   Block
<!--
          -->
                in Bundle                  Type    Number
<!--
          -->+========================================+=======+========+
<!--
          -->|
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|  Bundle
+----------------------------------------+-------+--------+
|  Block Confidentiality Block           |   12  |    2   |
<!--
          -->|
|  OP(bcb-confidentiality, target=1)     |       |        |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|
+----------------------------------------+-------+--------+
|  Payload Block (Encrypted)             |   1   |    1   |
<!--
          -->+----------------------------------------+-------+--------+
+----------------------------------------+-------+--------+
	    </artwork>
	  </figure>

        </section>
        <section numbered="true" toc="default">
          <name>Bundle
          <name>Block Confidentiality Block</name>

          <t>
  In this example, a BCB is used to encrypt the payload block block, and uses AES key
  wrap is used to transmit encode the symmetric key. key prior to its inclusion in the BCB.
          </t>
          <section numbered="true" toc="default">
            <name>Configuration, Parameters, and Results</name>
            <t>
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.
            </t>
            <t>
            This BCB has a single target, target -- the payload block. Three
            security results are generated: cipher text which ciphertext that
            replaces the plain text plaintext block-type-specific data to
            encrypt the payload block, an authentication tag, and
            the AES wrapped key.
            </t>

            <figure anchor="ex2_cpr">
              <name>Example 2: 2 - Configuration, Parameters, and Results</name>
              <artwork align="left" align="center" name="" type="" alt="">
<!--
-->
 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'52656164792047656e65726174652061
<!--
-->                       2033322062797465207061796c6f6164'
<!--
--> h'526561647920746f2067656e65726174
                       6520612033322d62797465207061796c
                       6f6164'
                AAD: h'00'
 Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97'
<!--
--> h'efa4b5ac0108e3816c5606479801bc04'
 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354
<!--
-->                       a563e32648b700c2784e26a990d91f9d'
<!--
--> h'3a09c1e63fe23a7f66a59c7303837241
                       e070b02619fc59c5214a22f08cd70795
                       e73e9a'
        </artwork>
            </figure>
          </section>
          <section numbered="true" toc="default">
            <name>Abstract Security Block</name>
            <t>
            The abstract security block structure of the BCB's
            block-type-specific-data
            block-type-specific data field for this application is as follows.

            </t>
            <figure anchor="ex2_bcb_asb">
              <name>Example 2: 2 - BCB Abstract Security Block (CBOR Diagnostic Notation)</name>
              <artwork align="left" type="cbor" name="" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[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'da08f4d8936024ad7c6b3b800e73dd97'] h'efa4b5ac0108e3816c5606479801bc04']  / Payload Auth. Tag /
  ]
              ]]></artwork>
]
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the BCB block-type-specific-data block-type-specific data field
            (the abstract security block) is
            0x8101020182028202018482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e73dd97. is:
            </t>
<sourcecode>
0x8101020182028202018482014c5477656c76653132313231328202018203581869
c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150efa4b5
ac0108e3816c5606479801bc04
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Representations</name>
            <t>
            The complete BCB wrapping this abstract security block is as follows.

            </t>
            <figure anchor="ex2_bcb">
              <name>Example 2: 2 - BCB (CBOR Diagnostic Notation)</name>
              <artwork align="left" type="cbor" name="" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[
  12, / type code                                          /
  2,  / block number                                       /
  1,  / flags - block must be replicated in every fragment /
  0,  / CRC type                                           /
  h'8101020182028202018482014c5477656c766531323132313282020182035818
    69c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da
    08f4d8936024ad7c6b3b800e73dd97'
    69c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150
    efa4b5ac0108e3816c5606479801bc04'
]
              ]]></artwork>
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the BCB block is 0x850c020100584f8101020182028202018482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e73dd97. is:
            </t>
<sourcecode>
0x850c02010058508101020182028202018482014c5477656c766531323132313282
02018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081
81820150efa4b5ac0108e3816c5606479801bc04
</sourcecode>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Final Bundle</name>
          <t>
          The CBOR encoding of the full output bundle, with the BCB: 0x9f88070000820282010282028202018202820201820018281a000f4240850c020100584f8101020182028202018482014c5477656c76653132313231328202018203581869c411276fecddc4780df42c8a2af89296fabf34d7fae70082040081820150da08f4d8936024ad7c6b3b800e73dd97850101000058203a09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff.
          </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f4240850c0201
0058508101020182028202018482014c5477656c7665313231323132820201820358
1869c411276fecddc4780df42c8a2af89296fabf34d7fae7008204008181820150ef
a4b5ac0108e3816c5606479801bc04850101000058233a09c1e63fe23a7f66a59c73
03837241e070b02619fc59c5214a22f08cd70795e73e9aff
</sourcecode>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>Example 3: 3 - Security Blocks from Multiple Sources</name>
        <t>
        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
        endpoint, and the BIB is added by a forwarding node.
        </t>
        <t>
        The resulting bundle contains a BCB to encrypt the
        Payload Block and a BIB to provide integrity to the
        Primary
        primary block and Bundle Age Block.
        </t>
        <section numbered="true" toc="default">
          <name>Original Bundle</name>
          <t>
          The following diagram shows the original bundle before the
          security blocks have been added.
          </t>

	  <figure anchor="ex3_orig_bundle"> align="center">
	    <name>Example 3 - Original Bundle</name>
	    <artwork align="center" name="" type="" alt="">
<!--

          --> align="center">
                  Block                    Block   Block
<!--
          -->
                in Bundle                  Type    Number
<!--
          -->+========================================+=======+========+
<!--
          -->|
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|
+----------------------------------------+-------+--------+
|  Extension Block: Bundle Age Block     |   7   |    2   |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|
+----------------------------------------+-------+--------+
|  Payload Block                         |   1   |    1   |
<!--
          -->+----------------------------------------+-------+--------+
+----------------------------------------+-------+--------+
	    </artwork>
	  </figure>

          <section numbered="true" toc="default">
            <name>Primary Block</name>
            <t>
           The primary block used in this example is identical to the primary block
           presented in for Example 1 in <xref target="ex_primary_block" format="default"/>.
            </t>
            <t>
            In summary, the CBOR encoding of the primary block is
            0x88070000820282010282028202018202820201820018281a000f4240. is:
            </t>
<sourcecode>
0x88070000820282010282028202018202820201820018281a000f4240
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Bundle Age Block</name>

            <t>
          A bundle age block 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
          as
          recommended because the bundle source does not have an accurate
          clock (as indicated by the DTN time of 0).
            </t>
            <t>
          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.
            </t>
            <t>
          The bundle age Bundle Age extension block is provided as follows.

            </t>
            <figure anchor="ex_bdl_age">
              <name>Bundle Age Block (CBOR Diagnostic Notation)</name>
              <artwork align="left" type="cbor" name="" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[
  7,      / type code: Bundle Age block Block    /
  2,      / block number                   /
  0,      / block processing control flags /
  0,      / CRC Type type                       /
  <<300>> / type-specific-data: age        /
]
            ]]></artwork>
            ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the bundle age block is 0x85070200004319012c. Bundle Age Block is:
            </t>
<sourcecode>
0x85070200004319012c
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Payload Block</name>
            <t>
           The payload block used in this example is identical to the payload block
           presented in for Example 1 in <xref target="ex_payload_block" format="default"/>.
            </t>
            <t>
            In summary, the CBOR encoding of the payload block is
            0x8501010000582052656164792047656e657261746520612033322062797465207061796c6f6164. is:
            </t>
<sourcecode>
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Bundle CBOR Representation</name>
            <t>
            A BPv7 bundle is represented as an indefinite-length array consisting
            of the blocks comprising the bundle, with a terminator character at
            the end.
            </t>
            <t>
            The CBOR encoding of the original bundle is
            0x9f88070000820282010282028202018202820201820018281a000f424085070200004319012c8501010000582052656164792047656e657261746520612033322062797465207061796c6f6164ff. is:
            </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f424085070200
004319012c85010100005823526561647920746f2067656e65726174652061203332
2d62797465207061796c6f6164ff
</sourcecode>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Security Operation Overview</name>
          <t>
          This example provides:

          </t>
          <ul empty="true" spacing="normal">
            <li>
              a BIB with the BIB-HMAC-SHA2 security context to provide an
              integrity mechanism over the primary block and bundle age
              block. Bundle Age
              Block.
            </li>
            <li>
              a BCB with the BCB-AES-GCM security context to provide a
              confidentiality mechanism over the payload block.
            </li>
          </ul>
          <t>
          The following diagram shows the resulting bundle after the
          security blocks are added.
          </t>
          <figure anchor="ex3_res_bundle">

	  <figure>
	    <name>Example 3 - Resulting Bundle</name>
	    <artwork align="center" name="" type="" alt="">
<!--

          --> align="center">
                  Block                    Block   Block
<!--
          -->
                in Bundle                  Type    Number
<!--
          -->+========================================+=======+========+
<!--
          -->|
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|  Bundle
+----------------------------------------+-------+--------+
|  Block Integrity Block                 |   11  |    3   |
<!--
          -->|
|  OP(bib-integrity, targets=0, 2)       |       |        |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|  Bundle
+----------------------------------------+-------+--------+
|  Block Confidentiality Block           |   12  |    4   |
<!--
          -->|
|  OP(bcb-confidentiality, target=1)     |       |        |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|
+----------------------------------------+-------+--------+
|  Extension Block: Bundle Age Block     |   7   |    2   |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|
+----------------------------------------+-------+--------+
|  Payload Block (Encrypted)             |   1   |    1   |
<!--
          -->+----------------------------------------+-------+--------+
+----------------------------------------+-------+--------+
	    </artwork>
	  </figure>

        </section>
        <section numbered="true" toc="default">
          <name>Bundle
          <name>Block Integrity Block</name>
          <t>
          In this example, a BIB is used to carry an integrity signature over
          the bundle age block Bundle Age Block and an additional signature over the
          payload block. The BIB is added by a waypoint node, node -- ipn:3.0.
          </t>
          <section numbered="true" toc="default">
            <name>Configuration, Parameters, and Results</name>
            <t>
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.
            </t>
            <t>
            This BIB has two security targets and includes two
            security results, holding the calculated signatures over
            the bundle age block Bundle Age Block and primary block.
            </t>
            <figure anchor="ex3_bib_cpr">
              <name>Example 3: 3 - Configuration, Parameters, and Results for the BIB</name>
              <artwork align="left" align="center" name="" type="" alt="">
<!--
-->
                Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
<!--
-->
        SHA Variant: HMAC 256/256
<!--
-->
        Scope Flags: 0x00
<!--
-->
 Primary Block Data: h'88070000820282010282028202018202
<!--
-->
                       820201820018281a000f4240'
<!--
-->
 Bundle Age Block
<!--
-->
               Data: h'85070200004319012c'
<!--
--> h'4319012c'
 Primary Block IPPT: h'00581c88070000820282010282028202
                       018202820201820018281a000f4240'
Bundle Age Block
               IPPT: h'004319012c'
 Primary Block
<!--
-->
          Signature: h'8e059b8e71f7218264185a666bf3e453
<!--
-->                       076f2b883f4dce9b3cdb6464ed0dcf0f'
<!--
--> h'cac6ce8e4c5dae57988b757e49a6dd14
                       31dc04763541b2845098265bc817241b'
 Bundle Age Block
<!--
-->
          Signature: h'72dee8eba049a22978e84a95d0496466
<!--
-->                       8eb131b1ca4800c114206d70d9065c80'
<!--
--> h'3ed614c0d97f49b3633627779aa18a33
                       8d212bf3c92b97759d9739cd50725596'
        </artwork>
            </figure>
          </section>
          <section numbered="true" toc="default">
            <name>Abstract Security Block</name>
            <t>
            The abstract security block structure of the BIB's
            block-type-specific-data
            block-type-specific data field for this application is as follows.

            </t>
            <figure anchor="ex3_bib_asb">
              <name>Example 3: 3 - BIB Abstract Security Block (CBOR Diagnostic Notation)</name>
              <artwork align="left" type="cbor" name="" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[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/256 256            /
   [3, 0x00] 0]       / Scope Flags            - No Additional Scope /
],
[               / Security Results: 2 Results                  /
   [1, h'8e059b8e71f7218264185a666bf3e453
         076f2b883f4dce9b3cdb6464ed0dcf0f'],
   [            / Primary Block Results                        /
       [1, h'72dee8eba049a22978e84a95d0496466
         8eb131b1ca4800c114206d70d9065c80'] h'cac6ce8e4c5dae57988b757e49a6dd14
             31dc04763541b2845098265bc817241b']       / MAC    /
    ],
    [           / Bundle Age Block Results                     /
       [1, h'3ed614c0d97f49b3633627779aa18a33
             8d212bf3c92b97759d9739cd50725596']       / MAC    /
    ]
              ]]></artwork>
]
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the BIB block-type-specific-data block-type-specific data field (the abstract security block) is
            0x820002010182028203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80. is:
            </t>
<sourcecode>
0x8200020101820282030082820105820300828182015820cac6ce8e4c5dae57988b
757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d97f49
b3633627779aa18a338d212bf3c92b97759d9739cd50725596
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Representations</name>
            <t>
            The complete BIB wrapping this abstract security block is as follows.

            </t>
            <figure anchor="ex3_bib">
              <name>Example 3: 3 - BIB (CBOR Diagnostic Notation)</name>
              <artwork align="left" type="cbor" name="" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[
  11, / type code    /
  3,  / block number /
  0,  / flags        /
  0,  / CRC type     /
  h'820002010182028203008282010582030082820158208e059b8e71f721826418
    5a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049
    a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80',
  h'8200020101820282030082820105820300828182015820cac6ce8e4c5dae5798
  8b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9
  7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596'
]
              ]]></artwork>
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the BIB block is 0x850b030000585a820002010182028203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80. is:
            </t>
<sourcecode>
0x850b030000585c8200020101820282030082820105820300828182015820cac6ce
8e4c5dae57988b757e49a6dd1431dc04763541b2845098265bc817241b8182015820
3ed614c0d97f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596
</sourcecode>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Bundle
          <name>Block Confidentiality Block</name>
          <t>
          In this example, a BCB is used encrypt the payload
          block. The BCB is added by the bundle source node, ipn:2.1.
          </t>
          <section numbered="true" toc="default">
            <name>Configuration, Parameters, and Results</name>
            <t>
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.
            </t>
            <t>
            This BCB has a single target, the payload block.
            Two security results are generated: cipher text which ciphertext that
            replaces the plain text plaintext block-type-specific data to
            encrypt the payload block, block and an authentication tag.
            </t>
            <figure anchor="ex3_bcb_cpr">
              <name>Example 3: 3 - Configuration, Parameters, and Results for the BCB</name>
              <artwork align="left" align="center" name="" type="" alt="">
<!--
-->
 Content Encryption
<!--
-->
                Key: h'71776572747975696f70617364666768'
<!--
-->
                 IV: h'5477656c7665313231323132'
<!--
-->
        AES Variant: A128GCM
<!--
-->
        Scope Flags: 0x00
<!--
-->
       Payload Data: h'52656164792047656e65726174652061
<!--
-->                       2033322062797465207061796c6f6164'
<!--
--> h'526561647920746f2067656e65726174
                       6520612033322d62797465207061796c
                       6f6164'
                AAD: h'00'
 Authentication Tag: h'da08f4d8936024ad7c6b3b800e73dd97'
<!--
--> h'efa4b5ac0108e3816c5606479801bc04'
 Payload Ciphertext: h'3a09c1e63fe2097528a78b7c12943354
<!--
-->                       a563e32648b700c2784e26a990d91f9d' h'3a09c1e63fe23a7f66a59c7303837241
                       e070b02619fc59c5214a22f08cd70795
                       e73e9a'
        </artwork>
            </figure>
          </section>
          <section numbered="true" toc="default">
            <name>Abstract Security Block</name>
            <t>
            The abstract security block structure of the BCB's
            block-type-specific-data
            block-type-specific data field for this application is as follows.

            </t>
            <figure anchor="ex3_bcb_asb">
              <name>Example 3: 3 - BCB Abstract Security Block (CBOR Diagnostic Notation)</name>
              <artwork type="cbor" name="" align="left" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[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, 0x00] 0]                   / Scope Flags - No Additional Scope /
],
[                                 / Security Results: 1 Result /
  [
     [1, h'da08f4d8936024ad7c6b3b800e73dd97'] h'efa4b5ac0108e3816c5606479801bc04'] / Payload Auth. Tag /
  ]
              ]]></artwork>
]
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the BCB block-type-specific-data block-type-specific data field
            (the abstract security block) is
            0x8101020182028202018382014c5477656c766531323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd97. is:
            </t>
<sourcecode>
0x8101020182028202018382014c5477656c76653132313231328202018204008181
820150efa4b5ac0108e3816c5606479801bc04
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Representations</name>
            <t>
            The complete BCB wrapping this abstract security block is as follows.

            </t>
            <figure anchor="ex3_bcb">
              <name>Example 3: 3 - BCB (CBOR Diagnostic Notation)</name>
              <artwork type="cbor" name="" align="left" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[
  12, / type code                                          /
  4,  / block number                                       /
  1,  / flags - block must be replicated in every fragment /
  0,  / CRC type                                           /
  h'8101020182028202018382014c5477656c766531323132313282020182040081
    820150da08f4d8936024ad7c6b3b800e73dd97',
    81820150efa4b5ac0108e3816c5606479801bc04'
]
              ]]></artwork>
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the BCB block is 0x850c04010058338101020182028202018382014c5477656c766531323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd97. is:
            </t>
<sourcecode>
0x850c04010058348101020182028202018382014c5477656c766531323132313282
02018204008181820150efa4b5ac0108e3816c5606479801bc04
</sourcecode>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Final Bundle</name>
          <t>
          The CBOR encoding of the full output bundle, with the BIB and BCB added is:
          0x9f88070000820282010282028202018202820201820018281a000f4240850b030000585a820002010182028203008282010582030082820158208e059b8e71f7218264185a666bf3e453076f2b883f4dce9b3cdb6464ed0dcf0f8201582072dee8eba049a22978e84a95d04964668eb131b1ca4800c114206d70d9065c80850c04010058338101020182028202018382014c5477656c766531323132313282020182040081820150da08f4d8936024ad7c6b3b800e73dd9785070200004319012c850101000058203a09c1e63fe2097528a78b7c12943354a563e32648b700c2784e26a990d91f9dff.
          </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
00585c8200020101820282030082820105820300828182015820cac6ce8e4c5dae57
988b757e49a6dd1431dc04763541b2845098265bc817241b81820158203ed614c0d9
7f49b3633627779aa18a338d212bf3c92b97759d9739cd50725596850c0401005834
8101020182028202018382014c5477656c7665313231323132820201820400818182
0150efa4b5ac0108e3816c5606479801bc0485070200004319012c85010100005823
3a09c1e63fe23a7f66a59c7303837241e070b02619fc59c5214a22f08cd70795e73e
9aff
</sourcecode>
        </section>
      </section>
      <section numbered="true" toc="default">
        <name>Example 4: 4 - Security Blocks with Full Scope</name>
        <t>
        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 block, and a BCB is added for
        confidentiality over the payload and BIB.
        </t>
        <t>
        The integrity scope and additional authentication data
        will bind the primary block, target header, and the
        security header.
        </t>
        <section numbered="true" toc="default">
          <name>Original Bundle</name>
          <t>
          The following diagram shows the original bundle before the
          security blocks have been added.
          </t>
          <figure anchor="ex4_orig_bundle">

	  <figure>
	    <name>Example 4 - Original Bundle</name>
	    <artwork align="center" name="" type="" alt="">
<!--

          --> align="center">
                  Block                    Block   Block
<!--
          -->
                in Bundle                  Type    Number
<!--
          -->+========================================+=======+========+
<!--
          -->|
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|
+----------------------------------------+-------+--------+
|  Payload Block                         |   1   |    1   |
<!--
          -->+----------------------------------------+-------+--------+
+----------------------------------------+-------+--------+
	    </artwork>
	  </figure>

          <section numbered="true" toc="default">
            <name>Primary Block</name>
            <t>
           The primary block used in this example is identical to the primary block
           presented in for Example 1 in <xref target="ex_primary_block" format="default"/>.
            </t>
            <t>
            In summary, the CBOR encoding of the primary block is
            0x88070000820282010282028202018202820201820018281a000f4240. is:
            </t>
<sourcecode>
0x88070000820282010282028202018202820201820018281a000f4240
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Payload Block</name>
            <t>
           The payload block used in this example is identical to the payload block
           presented in for Example 1 in <xref target="ex_payload_block" format="default"/>.
            </t>
            <t>
            In summary, the CBOR encoding of the payload block is
            0x8501010000582052656164792047656e657261746520612033322062797465207061796c6f6164. is:
            </t>
<sourcecode>
0x85010100005823526561647920746f2067656e657261746520612033322d627974
65207061796c6f6164
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Bundle CBOR Representation</name>
            <t>
            A BPv7 bundle is represented as an indefinite-length array consisting
            of the blocks comprising the bundle, with a terminator character at
            the end.
            </t>
            <t>
            The CBOR encoding of the original bundle is
            0x9f88070000820282010282028202018202820201820018281a000f42408501010000582052656164792047656e657261746520612033322062797465207061796c6f6164ff. is:
            </t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f424085010100
005823526561647920746f2067656e657261746520612033322d6279746520706179
6c6f6164ff
</sourcecode>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Security Operation Overview</name>
          <t>
          This example provides:

          </t>
          <ul empty="true" spacing="normal">
            <li>
              a BIB with the BIB-HMAC-SHA2 security context to provide an
              integrity mechanism over the payload block.
            </li>
            <li>
              a BCB with the BCB-AES-GCM security context to provide a
              confidentiality mechanism over the payload block and BIB.
            </li>
          </ul>
          <t>
          The following diagram shows the resulting bundle after the
          security blocks are added.
          </t>
          <figure anchor="ex4_res_bundle">

	  <figure>
	    <name>Example 4 - Resulting Bundle</name>
	    <artwork align="center" name="" type="" alt="">
<!--

          --> align="center">
                  Block                    Block   Block
<!--
          -->
                in Bundle                  Type    Number
<!--
          -->+========================================+=======+========+
<!--
          -->|
+========================================+=======+========+
|  Primary Block                         |  N/A  |    0   |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|  Bundle
+----------------------------------------+-------+--------+
|  Block Integrity Block (Encrypted)     |   11  |    3   |
<!--
          -->|
|  OP(bib-integrity, target=1)           |       |        |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|  Bundle
+----------------------------------------+-------+--------+
|  Block Confidentiality Block           |   12  |    2   |
<!--
          -->|
|  OP(bcb-confidentiality, targets=1, 3) |       |        |
<!--
          -->+----------------------------------------+-------+--------+
<!--
          -->|
+----------------------------------------+-------+--------+
|  Payload Block (Encrypted)             |   1   |    1   |
<!--
          -->+----------------------------------------+-------+--------+
+----------------------------------------+-------+--------+
	    </artwork>
	  </figure>
        </section>
        <section numbered="true" toc="default">
          <name>Bundle
          <name>Block Integrity Block</name>

          <t>
          In this example, a BIB is used to carry an integrity signature over
          the payload block. The IPPT contains the payload block block-type-specific data, 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.
          </t>
          <section numbered="true" toc="default">
            <name>Configuration, Parameters, and Results</name>
            <t>
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.
            </t>
            <t>
            This BIB has a single target and includes a single security
            result: the calculated signature over the Payload block.
            </t>
            <figure anchor="ex4_bib_cpr">
              <name>Example 4: 4 - Configuration, Parameters, and Results for the BIB</name>
              <artwork align="center" name="" type="" alt="">
<!--
          --> alt="" align="center">
               Key: h'1a2b1a2b1a2b1a2b1a2b1a2b1a2b1a2b'
<!--
          -->
       SHA Variant: HMAC 384/384
<!--
          -->
       Scope Flags: 0x07  (all additional headers)
<!--
          -->
Primary Block Data: h'88070000820282010282028202018202
<!--
          -->                       820201820018281a000f4240
<!--
          -->
                      820201820018281a000f4240'
      Payload Data: h'52656164792047656e65726174652061
<!--
          -->                       2033322062797465207061796c6f6164'
<!--
          --> h'526561647920746f2067656e65726174
                      6520612033322d62797465207061796c
                      6f6164'
    Payload Header: h'85010100005820'
<!--
          --> h'010100'
        BIB Header: h'850b0300005845'
<!--
          --> h'0b0300'
              IPPT: h'07880700008202820102820282020182
                      02820201820018281a000f4240010100
                      0b03005823526561647920746f206765
                      6e657261746520612033322d62797465
                      207061796c6f6164'
 Payload Signature: h'07c84d929f83bee4690130729d77a1bd
<!--
          -->                       da9611cd6598e73d0659073ea74e8c27
<!--
          -->                       523b02193cb8ba64be58dbc556887aca h'f75fe4c37f76f046165855bd5ff72fbf
                      d4e3a64b4695c40e2b787da005ae819f
                      0a2e30a2e8b325527de8aefb52e73d71,
        </artwork>
            </figure>
          </section>
          <section numbered="true" toc="default">
            <name>Abstract Security Block</name>
            <t>
            The abstract security block structure of the BIB's
            block-type-specific-data
            block-type-specific data field for this application is as follows.

            </t>
            <figure anchor="ex4_bib_asb">
              <name>Example 4: 4 - BIB Abstract Security Block (CBOR Diagnostic Notation)</name>
              <artwork type="cbor" name="" align="left" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[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 in the SHA Hash /
],
[              / Security Results: 1 Result                        /
  [            / Target 1 Results                                  /
    [1, h'07c84d929f83bee4690130729d77a1bdda9611cd6598e73d
         0659073ea74e8c27523b02193cb8ba64be58dbc556887aca'] h'f75fe4c37f76f046165855bd5ff72fbf         / MAC           /
          d4e3a64b4695c40e2b787da005ae819f
          0a2e30a2e8b325527de8aefb52e73d71']
  ]
              ]]></artwork>
]
              ]]></sourcecode>
            </figure>
            <t>

            The CBOR encoding of the BIB block-type-specific-data block-type-specific data field (the abstract security block) is
            0x81010101820282020182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca. is:
            </t>
<sourcecode>
0x81010101820282020182820106820307818182015830f75fe4c37f76f046165855
bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8aefb52
e73d71
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Representations</name>
            <t>
            The complete BIB wrapping this abstract security block is as follows.

            </t>
            <figure anchor="ex4_bib">
              <name>Example 4: 4 - BIB (CBOR Diagnostic Notation)</name>
              <artwork type="cbor" name="" align="left" alt=""><![CDATA[
              <sourcecode type="cbor-diag" name=""><![CDATA[
[
  11, / type code    /
  3,  / block number /
  0,  / flags        /
  0,  / CRC type     /
  h'81010101820282020182820106820307818201583007c84d929f83bee4690130
    729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58db
    c556887aca',
  h'81010101820282020182820106820307818182015830f75fe4c37f76f0461658
    55bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b325527de8
    aefb52e73d71'
]
              ]]></artwork>
              ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the BIB block is 0x850b030000584581010101820282020182820106820307818201583007c84d929f83bee4690130729d77a1bdda9611cd6598e73d0659073ea74e8c27523b02193cb8ba64be58dbc556887aca. is:
            </t>
<sourcecode>
0x850b030000584681010101820282020182820106820307818182015830f75fe4c3
7f76f046165855bd5ff72fbfd4e3a64b4695c40e2b787da005ae819f0a2e30a2e8b3
25527de8aefb52e73d71
</sourcecode>
          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Bundle
          <name>Block Confidentiality Block</name>
          <t>
        In this example, a BCB is used encrypt the payload
        block and the BIB that provides integrity over
        the payload.
          </t>
          <section numbered="true" toc="default">
            <name>Configuration, Parameters, and Results</name>
            <t>
            For this example, the following configuration and security context
            parameters are used to generate the security results
            indicated.
            </t>
            <t>
          This BCB has two targets: the payload block and BIB. Four
          security results are generated: cipher text which ciphertext that
          replaces the plain text plaintext block-type-specific data of the
          payload block, cipher text ciphertext to encrypt the BIB, and authentication
          tags for both the payload block and BIB.
            </t>
            <figure anchor="ex4_bcb_cpr">
              <name>Example 4: 4 - Configuration, Parameters, and Results for the BCB</name>
              <artwork align="center" name="" type="ascii-art" alt="">
<!--
          --> alt="" align="center">
               Key: h'71776572747975696f70617364666768
<!--
          -->
                      71776572747975696f70617364666768'
<!--
          -->
                IV: h'5477656c7665313231323132'
<!--
          -->
       AES Variant: A256GCM
<!--
          -->
       Scope Flags: 0x07  (All additional headers)
<!--
          -->
      Payload Data: h'52656164792047656e65726174652061
<!--
          -->                       2033322062797465207061796c6f6164'
<!--
          --> h'526561647920746f2067656e65726174
                      6520612033322d62797465207061796c
                      6f6164'
          BIB Data: h'81010101820282020182820106820307
<!--
          -->                       818201583007c84d929f83bee4690130
<!--
          -->                       729d77a1bdda9611cd6598e73d065907
<!--
          -->                       3ea74e8c27523b02193cb8ba64be58db
<!--
          -->                       c556887aca
<!--
          -->
                      818182015830f75fe4c37f76f0461658
                      55bd5ff72fbfd4e3a64b4695c40e2b78
                      7da005ae819f0a2e30a2e8b325527de8
                      aefb52e73d71'
 Primary Block Data: h'88070000820282010282028202018202
                       820201820018281a000f4240'
     Payload Header: h'010100'
         BIB
<!--
          --> Authentication Tag: h'c95ed4534769b046d716e1cdfd00830e'
<!--
          --> Header: h'0b0300'
         BCB Header: h'0c0201'
        Payload AAD: h'07880700008202820102820282020182
                       02820201820018281a000f4240010100
                       0c0201'
            BIB AAD: h'07880700008202820102820282020182
                       02820201820018281a000f42400b0300
                       0c0201'
     Payload Block
<!--
          -->
Authentication Tag: h'0e365c700e4bb19c0d991faff5345aff'
<!--
          --> h'd2c51cb2481792dae8b21d848cede99b'
               BIB
Authentication Tag: h'220ffc45c8a901999ecc60991dd78b29'
Payload Ciphertext: h'90eab64575930498d6aa654107f15e96
<!--
          -->                       319bb227706000abc8fcac3b9bb9c87e'
<!--
          --> h'90eab6457593379298a8724e16e61f83
                      7488e127212b59ac91f8a86287b7d076
                      30a122'
    BIB Ciphertext: h'438ed6208eb1c1ffb94d952175167df0
<!--
          -->                       902a815f221ebc837a134efc13bfa82a
<!--
          -->                       2d5d317747da3eb54acef4ca839bd961
<!--
          -->                       487284404259b60be12b8aed2f3e8a36
<!--
          -->                       2836529f66'
                      902902064a2983910c4fb2340790bf42
                      0a7d1921d5bf7c4721e02ab87a93ab1e
                      0b75cf62e4948727c8b5dae46ed2af05
                      439b88029191'
        </artwork>
            </figure>
          </section>
          <section numbered="true" toc="default">
            <name>Abstract Security Block</name>
            <t>
          The abstract security block structure of the BCB's
          block-type-specific-data
          block-type-specific data field for this application is as follows.

            </t>
            <figure anchor="ex4_bcb_asb">
              <name>Example 4: 4 - BCB Abstract Security Block (CBOR Diagnostic Notation)</name>
              <artwork type="cbor" name="" align="left" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[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'c95ed4534769b046d716e1cdfd00830e'], h'220ffc45c8a901999ecc60991dd78b29']  / BIB Auth. Tag /
  ],
  [
     [1, h'0e365c700e4bb19c0d991faff5345aff'] h'd2c51cb2481792dae8b21d848cede99b'] / Payload Auth. Tag /
  ]
            ]]></artwork>
]
            ]]></sourcecode>
            </figure>
            <t>

          The CBOR encoding of the BCB block-type-specific-data block-type-specific data field
          (the abstract security block) is
          0x820301020182028202018382014c5477656c766531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff. is:
           </t>
<sourcecode>
0x820301020182028202018382014c5477656c766531323132313282020382040782
81820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792dae8b2
1d848cede99b
</sourcecode>
          </section>
          <section numbered="true" toc="default">
            <name>Representations</name>
            <t>
          The complete BCB wrapping this abstract security block is as follows.

            </t>
            <figure anchor="ex4_bcb">
              <name>Example 4: 4 - BCB (CBOR Diagnostic Notation)</name>
              <artwork type="cbor" name="" align="left" alt=""><![CDATA[
              <sourcecode type="cbor-diag"><![CDATA[
[
  12, / type code                                          /
  2,  / block number                                       /
  1,  / flags - block must be replicated in every fragment /
  0,  / CRC type                                           /
  h'820301020182028202018382014c5477656c7665313231323132820203820407
    82820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d
    991faff5345aff',
    8281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51cb2481792
    dae8b21d848cede99b'
]
            ]]></artwork>
            ]]></sourcecode>
            </figure>
            <t>
            The CBOR encoding of the BCB block is 0x850c0201005847820301020182028202018382014c5477656c766531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff. is:
           </t>

<sourcecode>
0x850c0201005849820301020182028202018382014c5477656c7665313231323132
8202038204078281820150220ffc45c8a901999ecc60991dd78b2981820150d2c51c
b2481792dae8b21d848cede99b
</sourcecode>

          </section>
        </section>
        <section numbered="true" toc="default">
          <name>Final Bundle</name>
          <t>
        The CBOR encoding of the full output bundle, with the security blocks added and payload block and BIB encrypted is: 0x9f88070000820282010282028202018202820201820018281a000f4240850b0300005845438ed6208eb1c1ffb94d952175167df0902a815f221ebc837a134efc13bfa82a2d5d317747da3eb54acef4ca839bd961487284404259b60be12b8aed2f3e8a362836529f66 850c0201005847820301020182028202018382014c5477656c766531323132313282020382040782820150c95ed4534769b046d716e1cdfd00830e8201500e365c700e4bb19c0d991faff5345aff8501010000582090eab64575930498d6aa654107f15e96319bb227706000abc8fcac3b9bb9c87eff.
          </t> is:</t>
<sourcecode>
0x9f88070000820282010282028202018202820201820018281a000f4240850b0300
005846438ed6208eb1c1ffb94d952175167df0902902064a2983910c4fb2340790bf
420a7d1921d5bf7c4721e02ab87a93ab1e0b75cf62e4948727c8b5dae46ed2af0543
9b88029191850c0201005849820301020182028202018382014c5477656c76653132
313231328202038204078281820150220ffc45c8a901999ecc60991dd78b29818201
50d2c51cb2481792dae8b21d848cede99b8501010000582390eab6457593379298a8
724e16e61f837488e127212b59ac91f8a86287b7d07630a122ff
</sourcecode>
        </section>
      </section>
    </section>
    <section anchor="cddl" toc="default" numbered="true">
      <name>CDDL Expression</name>

      <t>
  For informational purposes, Brian Sipos has kindly provided this section contains an
  expression of the IPPT and AAD structures using the Concise Data
  Definition Language (CDDL). That CDDL expression is presented below.
      </t>
      <t>
      Note that wherever
      <t>NOTES:</t>
<ul spacing="normal">
      <li>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.
      </t>
      <t>
      Note that the
      </li>
      <li>
      The structure of BP bundles and BPSec security blocks are provided by other
      specifications and
      specifications; this section 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 Appendix B of the <xref target="RFC9171" sectionFormat="of" section="B">the Bundle Protocol Version 7 <xref target="I-D.ietf-dtn-bpbis" format="default"/>.
      </t>
      <t>
      Note that the version 7</xref>.
      </li>
      <li>
      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
      Section 4.1 of
      <xref target="RFC8742" format="default"/>, sectionFormat="of" section="4.1"/>, requires representing the sequence as an
      array with a comment in the CDDL noting that the array represents a CBOR sequence.
      </t>
      </li>
</ul>
      <figure anchor="appendix_b">
        <name>IPPT and AAD Expressions</name>
        <artwork type="cbor" name="" align="left" alt=""><![CDATA[
        <sourcecode type="cddl" name=""><![CDATA[
start = scope / AAD-list / IPPT-list ; satisfy CDDL decoders

scope = uint .bits scope-flags
scope-flags = &(
    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 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,
)
        ]]></artwork>
        ]]></sourcecode>
      </figure>
    </section>
    <section anchor="contr" toc="default" numbered="true">
      <name>Acknowledgements</name> numbered="false">
      <name>Acknowledgments</name>
      <t>
         Amy Alford
         <contact fullname="Amy Alford"/> of the Johns Hopkins University Applied Physics
         Laboratory contributed useful review and analysis of these
         security contexts.
      </t>
      <t><contact fullname="Brian Sipos"/> kindly provided the CDDL expression in <xref target="cddl"/>.
      </t>
    </section>
  </back>

</rfc>