briansipos / dtn-bpsec-cose Goto Github PK

The current requirements in Section 3.2 under "EC Keypair Confidentiality" require the use of "PartyU Nonce" for static-static ECDH.

Per the discussion on COSE mailing list, the HKDF salt parameter is preferred to any of the PartyU or PartyV data to supply desired uniqueness for static ECDH.

The requirements on use of the "x5t" parameter in Section 2.6.1.1 do not include any mininum set of interoperable hash algorithms. Maybe in Section 3.2 or 3.3 there should be a list of interoperable "x5t" hash algorithms. The minimum should be SHA-256 (-16) and SHA-256/64 (-15).

For association-oriented keys, like what would be established between two peers with something like EDHOC, it is necessary to indicate the kid (4) header parameter as well as the kid context (10). The kid context would be for the whole association and the kid would be for each epoch of the association.

The MAC_structure and Enc_structure are not used to generate the crypto algorithm AAD.

The examples were not updated after adding encoded primary block to AAD.

The COSE_Encrypt result ID is 96 and some examples have 97.

The original COSE reference to RFC 8152 has been obsoleted by RFC 9052 and RFC 9053. This document should have its referenced updated accordingly. There is no change in actual technical behavior or CDDL symbol names.

The current text in Section 3.2 does not allow for the use of an external CEK for single-layer encryption that reuses the CEK.

This use case is valid and would correspond with something like a higher layer key exchange protocol that manages key lifetimes, use limits, and rollovers.

The current AAD structure (for both MAC/Sign and Encrypt) contains the same information as that of the Default security contexts of RFC 9173 but encodes it in a slightly different way. The RFC 9173 method should be used directly if possible.

The 05 spec says

Both additional header values contain a CBOR map which is to be merged with each of the result's unprotected headers.

but this isn't clear about which result headers when there are multiple layers.
The statement should indicate that is to be merged with the highest-numbered layer (i.e. the leaf recipient).

The recommended algorithms -31 "ECDH-ES + A256KW" and -34 "ECDH-SS + A256KW" use AESKW to wrap the CEK but this adds unnecessary size to the message if there is only a single recipient and the KW is not needed.

The related algorithms -25 "ECDH-ES + HKDF-256" and -27 "ECDH-SS + HKDF-256" use the same key agreement algorithm but don't need to KW and transfer the wrapped key.

Regarding "deterministic" encoding in the AAD, this should reference Section 4.2.1 of RFC 8949.

To avoid needing to have context-level understanding of COSE header parameters, the existing COSE_Key/x509 headers should be replaced by a more generic "additional unprotected headers" map which is merged with each security result (specific logic TBD).

This will future-proof the context parameter and not care how or why the COSE headers are used.

The Additional Unprotected headers parameter (and additional-unprotected CDDL rule) contains possibly large and not-protocol-bound tree of CBOR items. To avoid redundant processing needed by BPSec implementations, the structure could be bstr-wrapped in the same way that the Additional Protected parameter is. This presents an opaque bstr to the BPSec implementation but can be decoded by the security context.

Recent changes for COSE X509 require that certificate chains be included in external_aad to verify that signer cert chain really was sent by the claimed security source.

A change in BPSec -25 made the ASB field "Security Source" mandatory. This affects all of the example ASBs, which should have added dtn://src/ as the Security Source.

There is no need for the "AAD-value" CDDL definition. The "AAD-structure" is encoded directly as the COSE "external_data" content.

The examples in -04 draft are correct, the body CDDL and description is incorrect.

The current definition of keys in the AAD Scope map interprets them as block numbers to correlate to blocks in the parent bundle. When a single BIB or BCB has multiple target blocks though, the single AAD Scope parameter will not be able to indicate "the target block" generally for all targets.

One way to handle this is to use non-uint sentenel values. For example, have -1 represent the associated target block, maybe -2 indicate the associated security block.

The example in Figure 10 shows parameter ID value 101 (an old code point) instead of value 1

For COSE layer numbering, this document should be consistent with Appendix B of RFC 9052, where layer zero is the first layer.

Rather than be limited to just the primary block and the target block metadata, it would be helpful if the AAD Scope was able to specify block metadata and/or BTSD for other non-target blocks.

This would allow encrypting or signing the payload block #​1 and require that it arrives with extension blocks #​4 and #​5, for example. The block metadata just ensures that it exists with the same type, the BTSD ensures that it has the same content.

Without this I can encrypt the payload with a BCB but have no ability to ensure needed plaintext extensions are untouched without additional BIBs.