cjose

Implementation of JOSE for C/C++

JWS signing algorithms (alg):

The polymorphic EdDSA identifier of RFC 8037, deprecated by RFC 9864, and none are not accepted.

The ML-DSA algorithms sign with the AKP key type of RFC 9964. They are pure ML-DSA over the JWS signing input, with the empty context string RFC 9964 requires; HashML-DSA is not part of that specification and is not offered.

JWE key management algorithms (alg):

The PBES2 salt input (p2s) is generated for every encryption, as RFC 7518 section 4.8.1.1 requires, and a caller-supplied one is refused. The iteration count (p2c) can be set in the header, per recipient where a JWE has several, and defaults to 8192. Beyond the 8 octet salt input the RFC requires, cjose applies limits of its own: it writes no fewer than 1000 iterations, the RFC's recommendation, it neither writes nor accepts more than 1000000, and it accepts no salt input longer than 1024 octets. What it accepts when decrypting is otherwise what RFC 7518 section 4.8.1.2 allows, any positive count, so that a conformant producer's JWE is readable whatever count it chose; the ceiling is what bounds the key derivation an unauthenticated JWE can demand, per recipient. These are policy rather than RFC validation, and each is a build option (see Build Options).

JWE content encryption algorithms (enc):

JWK key types (kty):

JWEs can be produced and consumed in both the compact and the JSON serialization, with one or more recipients.

MAC OS X All of the prerequisites can be installed via brew.

• CMake (>= 3.22)
• A C17 compiler (LLVM/Clang >= 6.0, GCC >= 8.1 or MSVC >= 19.28)
• Check (>= 0.12.0) - unit testing (e.g. check-devel)
• Doxygen (>= 1.8) - API documentation (optional)
• clang-format - source formatting (optional)

• OpenSSL >= 3.0.0 (>= 3.5 for the ML-DSA signature algorithms, see the CJOSE_ENABLE_ML_DSA build option below)
• Jansson >= 2.3

cjose builds with CMake (>= 3.22):

git clone https://github.com/cisco/cjose.git
cd cjose
cmake -S . -B build
cmake --build build

By default both the shared and static libraries are built (and, when cjose is the top-level project, the unit tests).

Pass options with -D<OPTION>=<VALUE> at configure time:

The PBES2 iteration counts must keep the order MIN_ACCEPTED_ITERATIONS ≤ MIN_ITERATIONS ≤ DEFAULT_ITERATIONS ≤ MAX_ITERATIONS, so setting one may mean setting another; a combination that does not is refused when the library is compiled.

For example, to build only the static library in debug mode:

cmake -S . -B build -DCJOSE_BUILD_SHARED=OFF -DCMAKE_BUILD_TYPE=Debug
cmake --build build

OpenSSL and Jansson are located automatically. If they live in a custom prefix, point CMake at it:

cmake -S . -B build -DCMAKE_PREFIX_PATH="/usr/local/opt/openssl;/usr/local/opt/jansson"

To run the unit tests:

ctest --test-dir build --output-on-failure -V

To generate the Doxygen API documentation (requires Doxygen):

cmake --build build --target doxygen

The generated HTML is placed in build/doc/html.

cmake --install build --prefix /your/install/prefix

This installs the libraries, the public headers, a cjose.pc pkg-config file and a CMake package config.

After installing, consume cjose from a CMake project via find_package:

find_package(cjose REQUIRED)
target_link_libraries(myapp PRIVATE cjose::cjose)

The cjose::cjose target aliases the shared/dynamic library when it is built, or the static library when CJOSE_BUILD_SHARED=OFF. The explicit cjose::cjose_shared target is also available when that library type is built. Using the shared library does not require the OpenSSL or Jansson development packages on the consuming system.

Static consumers need cjose's private dependencies and can request them and the explicit static target with:

find_package(cjose REQUIRED COMPONENTS static)
target_link_libraries(myapp PRIVATE cjose::cjose_static)

Alternatively, embed the sources directly with add_subdirectory() or FetchContent; the same CMake targets are provided.

• Run cmake --build build --target clang-format
• Run ctest --test-dir build --output-on-failure -V