Git Product home page Git Product logo

coset's Introduction

COSET

Docs CI Status codecov

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.

Features

The std feature of the crate enables an implementation of std::error::Error for CoseError.

no_std Support

This crate supports no_std (when the std feature is not set, which is the default), but uses the alloc crate.

Minimum Supported Rust Version

MSRV is 1.58.

Integer Ranges

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_cbor crate uses a single i128 integer type for all integer values, which means that all CBOR integer values can be expressed, but there are also i128 values that cannot be encoded in CBOR. This also means that data size is larger.
  • The ciborium also uses a single i128 integer type internally, but wraps it in its own Integer type and only implements TryFrom (not From) for i128 / u128 conversions so that unrepresentable numbers can be rejected.
  • The sk-cbor crate 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 i64 cover [0, 263 - 1]
  • negative numbers in i64 cover [-263, -1]

and so there are large values – both positive and negative – which are not supported by this crate.

Working on the Code

Local coding conventions are enforced by the continuous integration jobs and include:

  • Build cleanly and pass all tests.
  • Free of Clippy warnings.
  • Formatted with rustfmt using the local rustfmt.toml settings.
  • Compliance with local conventions:
    • All TODO markers should be of form TODO(#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.

Disclaimer

This is not an officially supported Google product.

coset's People

Contributors

alanstokes avatar ciphergoth avatar daviddrysdale avatar dependabot[bot] avatar falko17 avatar henrylyons avatar scouten-adobe avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

coset's Issues

Police duplicate items in maps

We want to detect if a CBOR map has duplicate keys and generate a warning/error. However, this doesn't seem to be possible with serde-cbor.

CoseSign1Builder.create_signature closure should allow errors to propagate.

See https://docs.rs/coset/0.1.1/coset/struct.CoseSign1Builder.html#method.create_signature.

This API is defined as:

pub fn create_signature<F>(self, aad: &[u8], signer: F) -> Self
where
    F: FnOnce(&[u8]) -> Vec<u8>

Some signature providers (for instance, openssl::sign::Signer.sign_oneshot), return a Result, but there is no way to propagate an Error response through this API.

Please consider redesigning this API (or providing an alternative) which would allow safe propagation of errors.

CoseError doesn't seem to implement std::error::Error.

The CoseError doesn't seem to implement the standard Error trait, and it makes this error hard to manage when building other types of errors with other tools, such as thiserror, or anyhow. Even a simple impl line for this should be sufficient:

impl std::error::Error for CoseError{}

but this has to be done inside of the coset crate.

IANA example

This is a feedback on the documentation, not on the implementation.

I miss having an example that uses ClaimsSet and IANA-defined values. I spent lot of time searching the repository to find and understand how to use the library correctly.

The first example in the docs uses a string payload, although it has value, it doesn't show many of the features of the library.

Also related to that, there are some type alias that are not always easy to find, like ClaimName. I think it would be worth to add "suggested alias" to the root types documentation, e.g. RegisteredLabelWithPrivate

Feature request - one-shot support for signing and verifying detached content

CoseSign1Builder.create_signature() and CoseSign1.verify_signature() construct the Sig_structure for signing/verification using the payload from the CoseSign1 message. However, these methods are more difficult to use when the content payload is detached (payload is null).

For example, the recipient of a CoseSign1 message with detached content would have to first decode the CBOR data into a CoseSign1 message and then create a copy of that message with the payload bytes, before calling verify_signature, in order to get the expected result.

The ask is to update this library to support one-shot signing and verification of CoseSign1 messages with detached content, e.g., verify_detached_signature(aad, payload, ...). Other COSE message types may benefit from this functionality as well.

For reference, here is the COSE RFC statement about detached content (https://datatracker.ietf.org/doc/html/rfc8152#page-8): "The content may be detached, but the location is still used. The content is wrapped in a bstr when present and is a nil value when detached."

Please implement Display trait on CoseError type

We are using this crate as part of another as-yet-unreleased crate and are following the patterns described in Nick Groenen's post on error handling in modern Rust.

Specifically, we are using the thiserror crate to forward and share detailed error information from downstream crates.

It would be much easier to forward this error type if it included a Display impl.

LMK if a pull request to that effect would be welcome.

New release schedule?

I'd like to make use of #45 in our project; would you please make a new release sometime soon? Thanks!

Support decoding COSE_Sign1_Tagged messages

When I used this crate to decode a COSE_Sign1_Tagged message, I got the following error: "got tag, expected array".

Attached is a COSE_Sign1_Tagged message which can be used to repro this issue. The first byte of this message is D2 (tag value 18) - this value (18) is registered with IANA as Cose_Sign1 (https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml).

Please add support for decoding COSE_Sign1_Tagged messages, to make this crate more interoperable with other COSE implementations.

repro.zip

Implement Error for CoseError

Is there any reason for CoseError not to implement Error?
This causes issues when working with other libraries, like thiserror

Plans to Implement Signing and Verification Operations

Currently, coset users have to provide closures to perform signing and verification operations. Do you have any plans to implement these operations in coset itself, or a separate crate? This functionality would be valuable for the Rust community and COSE users.

Wrong context identifier for AE algorithms

Issue:
Additional authenticated data is not empty.

Context:
I'm doing encryption without additional authenticated data.

    let out = CoseEncrypt0Builder::new()
         ...
        .try_create_ciphertext(&claims.to_vec()?, b"", |claims, _| encrypt(claims))?
        .build();

When decrypting, the associated data is not empty:

    let claims = CoseEncrypt0::from_slice(&out)?.decrypt(b"", |claims, aad| {
        if !aad.is_empty() {
            return Err(Error::Foo); \\ <- Error here!!!
        }

        decrypt(claims)
    })?;

I debugged the error and found Encrypt0 in the content. From the specification, this string should only be added for encryption with additional authenticated data.

ci: unpin/update cargo-tarpaulin

#55 pins cargo-tarpaulin to get around a build problem where the recently-updated version uses a recent dep that isn't visible to the GitHub action for some reason.

This issue is a reminder to come back and check later, so this doesn't end up pinned to a old version forever.

Set custom claim to ClaimSet

I was able to set a custom claim using ClaimsSetBuilder::text_claim but I don't see a way of setting an integer value for the the ClaimName.

I was able to add it directly to ClaimsSet::rest, is this the expected way of doing it?

Support for async signatures.

Sorry to circle back with another feature request so soon, but I'm looking into signing via HSM, which is necessarily an async task. Any chance we could further adapt the new try_create_* functions to accept async closures?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.