-
Notifications
You must be signed in to change notification settings - Fork 9
[PM-20361] Signature keys #207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: km/cose
Are you sure you want to change the base?
Conversation
Great job, no security vulnerabilities found in this Pull Request |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## km/cose #207 +/- ##
===========================================
+ Coverage 67.02% 67.47% +0.45%
===========================================
Files 212 214 +2
Lines 16208 16487 +279
===========================================
+ Hits 10863 11125 +262
- Misses 5345 5362 +17 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
} | ||
} | ||
} | ||
let Some(signature_namespace) = signature_namespace else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any options to represent this better? This feels highly unergonomic....
|
🎟️ 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.
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