[dtn] BPSec ASB structure

[Brian Sipos <[e-mail]>]

Ed,
I started into implementing a very simple abstract security block (ASB) dissector and have come across two separate observations about the ASB security results:

  1.  The array-of-target-block-numbers is separate from the array-of-result-sets, which allows a well-formed CBOR structure to be invalid ASB and it's not something which can be enforced by current CDDL (in the example below, the "targets" array must be equal sized to the "target-results" array).
Is there a reason why the array-of-result-sets doesn't embed the target block number along with each target's result set? I could provide an updated CDDL-type example of what I mean.
The one benefit of the current split is that a security acceptor can see the targets without caring about the results, but that can be mitigated by #2 below.
  2.  Because each of the results is a direct CBOR item, a result with a complex structure cannot be easily skipped. A security acceptor for one result may need to do additional data handling to skip over unwanted results. The same way that the canonical block structure uses cbor-within-bstr encoding to allow skipping over chunks of structure without decoding them, the ASB could have each result value be a bstr but require that it contain encoded CBOR. Then an acceptor could skip over individual result value without decoding.

Untested CDDL for an ASB, with "TBD" block type code, based on the BPbis CDDL:

$extension-block-structure /= extension-block-use<TBD, embedded-cbor<ext-data-asb>>

ext-data-asb = [
  targets: [1* target-block-num],
  context-id: int,
  flags: uint .bits asb-flag-bits,
  ? source: eid,
  ? parameters: asb-id-val-pair,
  target-results: [1* asb-id-val-pair]
]
target-block-num = uint
asb-flag-bits = &(
  sec-params-present: 1,
  sec-source-present: 2
)
asb-id-val-pair = [
  id: uint,
  val: any
]