Skip to content

refactor!: move most of the E2EI related code from crypto to e2e-identity#1891

Open
istankovic wants to merge 23 commits intomainfrom
ivan/x509-part-5
Open

refactor!: move most of the E2EI related code from crypto to e2e-identity#1891
istankovic wants to merge 23 commits intomainfrom
ivan/x509-part-5

Conversation

@istankovic
Copy link
Member

@istankovic istankovic commented Feb 24, 2026

This moves most of the E2EI related code from crypto to e2e-identity and removes the old enrollment API from crypto-ffi and bindings. Tests using the old enrollment flow have been left in crypto for the time being, but will be revisited in a later PR.

@istankovic istankovic force-pushed the ivan/x509-part-5 branch 5 times, most recently from 7bbc86c to 098191f Compare February 26, 2026 16:48
@istankovic istankovic changed the title wip refactor!: move most of the E2EI related code from crypto to e2e-identity Feb 27, 2026
@istankovic istankovic marked this pull request as ready for review February 27, 2026 08:26
@istankovic istankovic requested a review from a team February 27, 2026 08:27
@typfel
Copy link
Member

typfel commented Feb 27, 2026

Can we squash b450cd5 and 64224d1 together

@istankovic
Copy link
Member Author

istankovic commented Feb 27, 2026

Can we squash b450cd5 and 64224d1 together

Sure, there's probably going to be some conflicts, but let me try that.

@istankovic
Copy link
Member Author

Can we squash b450cd5 and 64224d1 together

Done. 👍

Copy link
Contributor

@coriolinus coriolinus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like this! Once CI is green, go for it.

They were only used for E2EI things, which has now been moved.
Also make ed25519-dalek non-optional.
The function calls RustCrypto::normalize_p521_secret_key and RustCrypto::normalize_ed25519_key
and the RustCrypto provider is not easily accessible from e2e-identity.
…:new

PkiKeypair::new is supposed to be called immediately after having
created a new signing key via signature_key_gen, and only with the
private portion of the key pair. So instead of calling normalize, just
make sure that the provided key has the right length. This also
avoids the pointless copying.
Because MLS provider is defined in the crypto crate and we cannot depend
on that crate in e2e-identity.
We're hitting the orphan rule here: Ciphersuite is defined in openmls,
and JwsAlgorithm is defined in rusty-jwt-tools.
We're keeping E2eiConversationState for the time being.
It has been moved from crypto to e2e-identity.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants