1# COSET 2 3[](https://docs.rs/coset) 4[](https://github.com/google/coset/actions?query=workflow%3ACI) 5[](https://codecov.io/gh/google/coset) 6 7This crate holds a set of Rust types for working with CBOR Object Signing and Encryption (COSE) objects, as defined in 8[RFC 8152](https://tools.ietf.org/html/rfc8152). It builds on the core [CBOR](https://tools.ietf.org/html/rfc7049) 9parsing functionality from the [`ciborium` crate](https://docs.rs/ciborium). 10 11See [crate docs](https://docs.rs/coset), or the [signature 12example](examples/signature.rs) for documentation on how to use the code. 13 14**This repo is under construction** and so details of the API and the code may change without warning. 15 16## Features 17 18The `std` feature of the crate enables an implementation of `std::error::Error` for `CoseError`. 19 20## `no_std` Support 21 22This crate supports `no_std` (when the `std` feature is not set, which is the default), but uses the `alloc` crate. 23 24## Minimum Supported Rust Version 25 26MSRV is 1.58. 27 28## Integer Ranges 29 30CBOR supports integers in the range: 31 32```text 33[-18_446_744_073_709_551_616, -1] ∪ [0, 18_446_744_073_709_551_615] 34``` 35 36which is [-2<sup>64</sup>, -1] ∪ [0, 2<sup>64</sup> - 1]. 37 38This does not map onto a single Rust integer type, so different CBOR crates take different approaches. 39 40- The [`serde_cbor`](https://docs.rs/serde_cbor) crate uses a single `i128` integer type for all integer values, which 41 means that all CBOR integer values can be expressed, but there are also `i128` values that cannot be encoded in CBOR. 42 This also means that data size is larger. 43- The [`ciborium`](https://docs.rs/ciborium) also uses a single `i128` integer type internally, but wraps it in its own 44 [`Integer`](https://docs.rs/ciborium/latest/ciborium/value/struct.Integer.html) type and only implements `TryFrom` 45 (not `From`) for `i128` / `u128` conversions so that unrepresentable numbers can be rejected. 46- The [`sk-cbor`](https://docs.rs/sk-cbor) crate uses distinct types: 47 - positive numbers as u64, covering [0, 2<sup>64</sup> - 1] 48 - negative numbers as i64, covering [-2<sup>63</sup>, -1] (which means that some theoretically-valid large negative 49 values are not represented). 50 51This crate uses a single type to encompass both positive and negative values, but uses `i64` for that type to keep data 52sizes smaller. This means that: 53 54- positive numbers in `i64` cover [0, 2<sup>63</sup> - 1] 55- negative numbers in `i64` cover [-2<sup>63</sup>, -1] 56 57and so there are large values – both positive and negative – which are not supported by this crate. 58 59## Working on the Code 60 61Local coding conventions are enforced by the [continuous integration jobs](.github/workflows) and include: 62 63- Build cleanly and pass all tests. 64- Free of [Clippy](https://github.com/rust-lang/rust-clippy) warnings. 65- Formatted with `rustfmt` using the local [rustfmt.toml](.rustfmt.toml) settings. 66- Compliance with local conventions: 67 - All `TODO` markers should be of form `TODO(#99)` and refer to an open GitHub issue. 68 - Calls to functions that can panic (`panic!`, `unwrap`, `expect`) should have a comment on the same line in the 69 form `// safe: reason` (or `/* safe: reason */`) to document the reason why panicking is acceptable. 70 71## Disclaimer 72 73This is not an officially supported Google product. 74