[Cbor] Re: Bundle protocol RFC 9171 design problems

[Vadim Goncharov <[e-mail]>]

On Tue, 7 Jul 2026 09:29:40 +0200
Anders Rundgren <[e-mail]> wrote:

> On 2026-07-06 22:46, Laurence Lundblade wrote:
> > (Sticking to serialization draft and bundle, not other tags that require
> > library tweaks, EU payments,…)
> > 
> > 1) I am planning some reframing in Appendix G to talk about CBOR libraries
> > that support signing/hashing without byte string wrapping. It is something
> > like this:
> > 
> >     Byte string wrapping has the advantage of needing no special features
> > from the CBOR library. That said, some libraries do have an additional
> > feature that gives access to the encoded bytes of sub-parts of a CBOR
> > message.
> > 
> > I didn’t check a lot of libraries carefully, but QCBOR and fxamacker both
> > provide some access to encoded sub-parts.
> > 
> > The idea is to say byte string wrapping works with any library so it is
> > preferred, but direct hashing can be made to work with the right library.  
> 
> Apparently there is no incentive for describing possible *advantages* of
> hashing/signing non-wrapped CBOR data.  Here is my personal #1 feature:

I've done it slightly from other side in a message about IP example...

> In a messaging system using multiple objects, including objects that in turn
> may embed other signed or non-signed objects, it is convenient to mark each
> object with a type-specific identifier. Using CBOR that would be a Tag.
> 
> This arrangement doesn't work particularly well for messaging schemes using
> COSE since COSE has its own Tag.  The RFC9596 workaround is not comparable.
> Embedded signatures address this issue with minimal effort including signing
> the [optional] object Tag itself.

Probably you meant some other RFC? RFC9596 is short and do not even have word
"tag".

As for in general, CBOR allows an item to have several tags (and bstr-wrapped
CBOR can also have tags, though it's different).

[...]
> >> If the blocks CRCed/hashed were byte-string wrapped — the input to the
> >> CRC/hash was the byte string — then any CBOR library would work.
> >>
> >> If the determinism wasn’t broken, then the CRCed/hashed bytes could be
> >> reconstructed and fed to the hash/CRC.  
> 
> Embedded signatures appear to suffer from the same issue.
> 
> However, in a high-level, object-oriented CBOR implementation, the decoder
> only needs to perform a handful of "standard" methods to cope with this:
> 
> let object = CBOR.decode(cborBinary);              // Decode CBOR object
> let csf = object.get(CSF_CONTAINER_LBL);           // Get embedded signature
> container let alg = csf.get(CSF_ALG_LBL).getInt32();         // Get COSE
> algorithm let sigVal = csf.remove(CSF_SIG_LBL).getBytes();   // Get and
> REMOVE signature value let actualSig = hmac(alg,                          //
> Calculate signature over SHARED_KEY,                   // the current
> (modified) object object.encode());             // encode(): all but the
> signature value
> 
> Note: minimalist example showing the principle.

This example uses re-encoding of object to get signature, which will be poor
from performance-point of view. That's why Laurence talks about offsets etc.

-- 
WBR, @nuclight