[PM-20361] Signature keys #207
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Great job, no security vulnerabilities found in this Pull Request |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #207 +/- ##
==========================================
+ Coverage 69.56% 70.00% +0.44%
==========================================
Files 213 215 +2
Lines 16644 16965 +321
==========================================
+ Hits 11578 11877 +299
- Misses 5066 5088 +22 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
quexten
commented
Apr 17, 2025
| } | ||
| } | ||
| } | ||
| let Some(signature_namespace) = signature_namespace else { |
There was a problem hiding this comment.
Any options to represent this better? This feels highly unergonomic....
quexten
force-pushed
the
km/cose-signatures
branch
from
f8044bd to
c9b80df
Compare
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🎟️ Tracking
https://bitwarden.atlassian.net/browse/PM-20361
📔 Objective
This PR adds signing/verifying operations, and keys, including serialization to COSE for both the keys, and for the signatures. This does not use these yet. The interface is strongly domain separated.
The one implemented algorithm type is ed25519.
Keys are represented as enums such that it is easy to add other signing key types (ML-DSA for post-quantum crypto, PoC here: #216) later on.
Further, we enforce strong domain separation by adding a namespace to the protected header. This ensures not having to worry about cross-protocol attacks / swapping messages between contexts.
The signature is represented as a Cose Sign1 message (https://www.rfc-editor.org/rfc/rfc9052.html#name-signing-with-one-signer), with a detached payload. Specifically, the payload is detached because we may want to allow application level logic providing multiple signatures on an object without having to modify the entire object (two-way signed org memberships).
The namespace is separated by setting the protected header. Since this is included in the signed data, and since this is validated on verifying the signature, and since the values are unique, domain separation is enforced. We only ever want to expose the safe function outside of the crate (if we even expose it out of the crate).
Note: This does not yet add code for consuming these keys or signatures, hence there are a lot of "allow dead code" attributes. This also does not yet implement keycontext signing keys.
The first use-case for this will be signing an "Account Encryption Metadata" object, proving to the user certain features of their account (icon url hash enforcement). After this, signed emergency access and signed organization memberships follow.
⏰ Reminders before review
team
🦮 Reviewer guidelines
:+1:) or similar for great changes:memo:) or ℹ️ (:information_source:) for notes or general info:question:) for questions:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmedissue and could potentially benefit from discussion
:art:) for suggestions / improvements:x:) or:warning:) for more significant problems or concerns needing attention:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt:pick:) for minor or nitpick changes