This crate holds a set of Rust types for working with CBOR Object Signing and Encryption (COSE) objects, as defined in
RFC 8152. It builds on the core CBOR
parsing functionality from the ciborium crate.
See crate docs, or the signature example for documentation on how to use the code.
This repo is under construction and so details of the API and the code may change without warning.
The std feature of the crate enables an implementation of std::error::Error for CoseError.
This crate supports no_std (when the std feature is not set, which is the default), but uses the alloc crate.
MSRV is 1.58.
CBOR supports integers in the range:
[-18_446_744_073_709_551_616, -1] ∪ [0, 18_446_744_073_709_551_615]
which is [-264, -1] ∪ [0, 264 - 1].
This does not map onto a single Rust integer type, so different CBOR crates take different approaches.
- The
serde_cborcrate uses a singlei128integer type for all integer values, which means that all CBOR integer values can be expressed, but there are alsoi128values that cannot be encoded in CBOR. This also means that data size is larger. - The
ciboriumalso uses a singlei128integer type internally, but wraps it in its ownIntegertype and only implementsTryFrom(notFrom) fori128/u128conversions so that unrepresentable numbers can be rejected. - The
sk-cborcrate uses distinct types:- positive numbers as u64, covering [0, 264 - 1]
- negative numbers as i64, covering [-263, -1] (which means that some theoretically-valid large negative values are not represented).
This crate uses a single type to encompass both positive and negative values, but uses i64 for that type to keep data
sizes smaller. This means that:
- positive numbers in
i64cover [0, 263 - 1] - negative numbers in
i64cover [-263, -1]
and so there are large values – both positive and negative – which are not supported by this crate.
Local coding conventions are enforced by the continuous integration jobs and include:
- Build cleanly and pass all tests.
- Free of Clippy warnings.
- Formatted with
rustfmtusing the local rustfmt.toml settings. - Compliance with local conventions:
- All
TODOmarkers should be of formTODO(#99)and refer to an open GitHub issue. - Calls to functions that can panic (
panic!,unwrap,expect) should have a comment on the same line in the form// safe: reason(or/* safe: reason */) to document the reason why panicking is acceptable.
- All
This is not an officially supported Google product.