Found 4 records.

Status: Reported (4)

RFC 9172, "Bundle Protocol Security (BPSec)", January 2022

Errata ID: 7672
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Brian Sipos
Date Reported: 2023-10-10

Section 3.6 says:

Security Context Id:
 This field identifies the security context used to implement
 the security service represented by this block and applied to
 each security target.  This field SHALL be represented by a
 CBOR unsigned integer.  The values for this Id should come from
 the registry defined in Section 11.3.

It should say:

Security Context Id:
 This field identifies the security context used to implement
 the security service represented by this block and applied to
 each security target.  This field SHALL be represented by a
 CBOR unsigned or negative integer.  The values for this Id should
 come from the registry defined in Section 11.3.

Notes:

Per the IANA sub-registry in Section 11.3 the Context ID has "The value range: signed 16-bit integer." and negative values are reserved for private use, so the value can be either an unsigned or a negative integer.

Errata ID: 8312
Status: Reported
Type: Technical
Publication Format(s) : HTML
Reported By: Brian Sipos
Date Reported: 2025-02-24

Section 3.6 says:

/none/

It should say:

Any fields of the ASB, including the Security Source, MAY be treated 
as untrusted input for key material lookup in support of processing 
a security operation as a validator or acceptor.
Any fields of the ASB SHALL NOT be used for making other decisions 
on a node unless they are covered as additional authenticated data 
by an successfully validated or accepted integrity or confidentiality 
operation on that node.

Notes:

There was no original text restricting how the fields of the ASB can be used by a node. This errata explicitly restricts untrusted inputs in the ASB from influencing node processing, including logic or telemetry based on the Security Source. The default security contexts of RFC 9173 do not yet have the possibility to include the Security Source as additional authenticated data.

Errata ID: 8681
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Lukas Holst
Date Reported: 2025-12-17

Section 5.1.1 says:

   If an encrypted payload block cannot be decrypted (i.e., the
   ciphertext cannot be authenticated), then the bundle MUST be
   discarded and processed no further.  If an encrypted security target
   other than the payload block cannot be decrypted, then the associated
   security target and all security blocks associated with that target
   MUST be discarded and processed no further.  In both cases, requested
   status reports (see [RFC9171]) MAY be generated to reflect bundle or
   block deletion.

It should say:

   If an encrypted payload block cannot be decrypted (i.e., the 
   ciphertext cannot be authenticated), then the bundle MUST be deleted
   and processed no further. If requested, a deletion status report (see
   [RFC9171]) MAY be generated using the appropriate Bundle Status 
   Report Reason Codes (see Section 11.2) to report bundle deletion. If 
   an encrypted security target other than the payload block cannot be 
   decrypted, then the associated security target and all security 
   blocks associated with that target MUST be discarded and processed 
   no further.

Notes:

There exists no block deletion status report in RFC9171.

Errata ID: 8723
Status: Reported
Type: Technical
Publication Format(s) : TEXT, HTML
Reported By: Lukas Holst
Date Reported: 2026-01-29

Section 3.3 says:

   *  None of the security operations conflict with security operations
      already present in the bundle.

It should say:

   *  None of the security operations conflict with security operations
      already present in the bundle.

   *  In a set of integrity security operations, none of the operations
      target the security block metadata with their associated 
      authenticated data, as this interferes with the processing of BIB
      encryption.

Notes:

Combining two or more integrity operations in a single security block, while the associated authenticated data targets the security block metadata, can lead to invalidation of a security result when following the rules of Section 3.9. When a BIB result is moved into a new BIB, then the security block number changes, thereby invalidating the BIB result. This additional constraint for combining security results prevents this invalidation.

Report New Errata