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

Are there enough use cases for external_aad to warrant its inclusion? #16

Closed
selfissued opened this issue Nov 1, 2015 · 1 comment
Closed

Comments

@selfissued
Copy link

The “external_aad” field appears in the Sig_structure, Enc_structure, and MAC_structure. Many other cryptographic specs have gotten along fine without this, and are simpler as a result. Is its inclusion warranted by common use cases, or is this an edge case not satisfying the 80/20 rule for inclusion? The simpler way of achieving this is to include these values as part of the payload.

Note also that some places in the spec prohibit supplying this value. For instance, 5.4 (Encryption algorithm for AE algorithms) includes the instruction “Verify that there was no external additional authenticated data supplied for this operation.” That makes me think that having external_aad at all is a likely source of implementation and usage errors and interoperability problems.

@jimsch
Copy link

jimsch commented Nov 3, 2015

Per discussion at the f2f meeting: This is a required feature for the CoAP world so that headers in the message can be integrity protected without having to duplicate them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants