Concise Binary Object Representation (CBOR) Architecture and COSE Cryptography
A standards-based guide to CBOR’s data model, compact encoding, protocol-defined determinism, and the boundary between serialization and COSE security objects.
Publication & corrections: infostoa · Editorial standards
Individual author and specialist reviewer information is not provided for this article.
Concise Binary Object Representation (CBOR) is an IETF binary format for structured data, with a model related to but broader than JSON. Small values can use fewer bytes, which may help constrained devices, but CBOR is not always smaller and does not provide cryptography itself. RFC 8949 defines the format; RFC 9052 defines COSE security structures for CBOR objects.
A JSON-related model with additional types
CBOR extends JSON-like values—integers, strings, arrays, maps, booleans, and null—with byte strings, tags, and a broader numeric range. It is not just compressed JSON: conversion requires choices for values JSON cannot express directly.
An initial byte identifies the major type and carries additional information; larger values or strings need more length bytes. RFC 8949 encodes 0 as 00 and 24 as 18 18. Savings depend on values, repeated keys, protocol headers, and encoder choices.
When compact encoding can help
Compact numbers and maps can help small sensor messages and constrained links; integer keys can replace repeated labels. The trade-offs are harder manual inspection and the need to maintain schema and key assignments. If readability matters more than wire size, JSON may fit better.
Measure representative and worst-case payloads. Key length, repeated strings, numeric ranges, framing, cryptographic tags, and transport overhead all affect the result. A compact sample does not prove lower production cost.
Deterministic encoding is a protocol choice
Equivalent CBOR values can have different encodings, for example through map order or numeric width. RFC 8949 lets each protocol define deterministic rules and require decoders to check them; there is no universal canonical byte sequence for every application.
For hashes, signatures, or cache keys, both sides need the same rules for map order, numeric forms, lengths, and tags. Library defaults are not universal: different encoders may produce different bytes and break verification or cache matching. Define determinism as an interoperability requirement.
COSE adds security-object structures
COSE defines CBOR structures for signing, message authentication, and encryption. RFC 9052’s COSE_Sign supports multiple signatures; COSE_Sign1 is for one signer. They cannot be converted without invalidating verification. Signed objects contain protected and unprotected headers, payload, and signature data.
An expert asks which bytes and headers are authenticated and how detached content stays unchanged. RFC 9052 addresses protected algorithm headers and leaves detached-payload integrity in transit to the application. COSE does not itself solve key management, algorithm policy, replay prevention, or authorization.
Checks before adopting CBOR
Define values that must survive conversion, including byte strings, large integers, tags, floats, map keys, and schema changes. Test normal and boundary inputs, malformed or truncated data, unknown tags, and duplicate keys; RFC 8949 requires rejecting ill-formed items.
Document deterministic rules and test byte-for-byte agreement across implementations. Review COSE structure and algorithms separately, and verify the signed payload. Measure size, processing, memory, recovery, and observability on target devices before adopting added schema and tooling.
CBOR’s value is not established by the word “binary” alone. Its compact representation and extensible types can suit constrained systems, but they also bring responsibilities for determinism, schemas, and secure message handling. Keeping RFC 8949 serialization rules distinct from RFC 9052 COSE structures makes it possible to evaluate size and interoperability together.