Skip to content
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

Add safe use of AAD to Safe Extensions framework #29

Merged
merged 5 commits into from
Oct 21, 2024

Conversation

rohanmahy
Copy link
Contributor

Incorporate AAD in the safe extensions framework to make a safe muxing of potentially multiple sources of authenticated_data

@kkohbrok
Copy link
Contributor

It's been a while since we discussed this. @rohanmahy did you want to add a brief discussion noting that in contrast to other safe extension framework features, the use of the AAD is a little different, because the application can typically also just use the AAD? I know we discussed this but I can't remember what we decided on.

@rohanmahy
Copy link
Contributor Author

Hi, if two extensions (safe or not) want to add AAD, there needs to be a way to mux and demux that data. I'm open to suggestions about what additional text you'd like added.

@kkohbrok
Copy link
Contributor

I guess my question is how the implementation would know when to expect a SafeAAD item in the authenticated_data field. We probably need a rule that says something like: "If there is an extension (probably a group context extension) that sometimes makes use of the AAD field, then there MUST always be a SafeAAD item in authenticated_data, even if it's empty. Does that make sense? Otherwise the implementation won't know if it's parsing for a SafeAAD item or the application's (unsafe) AAD.

@rohanmahy
Copy link
Contributor Author

I guess my question is how the implementation would know when to expect a SafeAAD item in the authenticated_data field. We probably need a rule that says something like: "If there is an extension (probably a group context extension) that sometimes makes use of the AAD field, then there MUST always be a SafeAAD item in authenticated_data, even if it's empty. Does that make sense? Otherwise the implementation won't know if it's parsing for a SafeAAD item or the application's (unsafe) AAD.

I think there needs to be a SafeAAD GC extension. If it exists in a group, the first octet(s) of the AAD is/are the length of the SafeAAD vector (which could be zero). If there is any AAD left after that, it is non-Safe AAD.

Is that concept OK?

@kkohbrok
Copy link
Contributor

That sounds good. Could you add/clarify that in the PR?

Copy link
Contributor

@kkohbrok kkohbrok left a comment

Choose a reason for hiding this comment

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

Thanks, looks good to me!

@raphaelrobert
Copy link
Member

Let's get this in. @rohanmahy can you please resolve the conflict?

@rohanmahy
Copy link
Contributor Author

Let's get this in. @rohanmahy can you please resolve the conflict?

Done!

@raphaelrobert raphaelrobert merged commit f880364 into mlswg:main Oct 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

3 participants