briansipos / dtn-bpsec-cose Goto Github PK
View Code? Open in Web Editor NEWDTN Bundle Protocol Security (BPSec) COSE Context
License: GNU Lesser General Public License v3.0
DTN Bundle Protocol Security (BPSec) COSE Context
License: GNU Lesser General Public License v3.0
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 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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.