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.
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
CABF SMIME BR 7.1.2.3.e - KeyUsages #757
CABF SMIME BR 7.1.2.3.e - KeyUsages #757
Changes from 9 commits
7ec20a6
27e1e73
3180bcd
a23fb9c
2163d6b
fa71834
9cfe218
137dd4a
a50d640
0b41122
c2776a2
cfb1d19
002b817
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Requirement: "For signing only, bit positions SHALL be set for digitalSignature and MAY be set for nonRepudiation.
For key management only, bit positions SHALL be set for keyAgreement and MAY be set for encipherOnly or decipherOnly. For dual use, bit positions SHALL be set for digitalSignature and keyAgreement and MAY be set for nonRepudiation and for encipherOnly or decipherOnly (only if keyAgreement is set)."
My understanding is that OR is either encipher or decipher, but not both. I think the current code permits the combination of both.
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.
I don't think the text is written in a way that makes your interpretation the only acceptable one. Generally speaking "or" means a&&!b, !a&&b, a&&b. I don't think the BRs support the narrower interpretation you're putting on them
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.
Thanks, I agree it's ambiguous - I'll raise this topic in the working group for clarification.
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.
Is there any usecase for doing so however?
The purpose of encipherOnly and decipherOnly is to limit the usage of the key. The absense of both, allows for both options to be used. As such, adding both, would be redundant.
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.
I'm a bit surprised that it's not written unambiguously anywhere that a cert can't have both EncipherOnly and DecipherOnly KUs. While writing my comment I checked RFC5280 and that doesn't actually say that it's not allowable to have both at the same time which I'm a little surprised by...