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
pkcs12: KDF support #1154
pkcs12: KDF support #1154
Changes from all commits
6dc0d09
e611e76
e14c270
6125b80
5286894
217783b
02a8193
236b957
c6b4928
1183d10
7e11f44
87cc22a
3dd8ece
282baa5
7537728
ebe05c2
8622bfd
30960c8
b04da8c
f669db8
23c364a
bf455d3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
The RFC talks about
BMPString
which happens to be UTF16, but renaming thatstr_to_bmpstring
or something would be great I think.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.
Hmm, I guess we should really add
BMPString
support toder
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 uncomfortable with the use of
str
for inputs here. This will backfire with any 4-Byte UTF8 character. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=c4edb02a6d7bf8fb45147475e43f1930I don't know what the best course of action is here though, the best I can think of would be to add a
der::asn1::BmpString
but it is meant to only be subtyped from what I can read (https://www.oss.com/asn1/resources/asn1-made-simple/asn1-quick-reference/bmpstring.html)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.
(sorry last comment was sent before I refreshed the page, well, go for a
BmpString
then)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.
The format of an ASN1
BMPString
differs slightly from what is here required: It has a leading id byte0x1e
, one or bytes indicating the length in bytes, and no terminating zeros. I.e. usingBMPString
would also requires some pre-processing. Multi-Byte UTF8 characters should work fine here, at least the example you provided gives the exact same result als openssl's functionPKCS12_gen_key_utf8
(see the added test case and the respective test program).Openssl provides similar functions for
PKCS12_gen_key_uni
andPCKS12_gen_asc
for unicode and ASCII string passwords (see here: https://www.openssl.org/docs/man3.0/man3/PKCS12_key_gen_utf8.html) Maybe a similar approach could be taken here.However, I am not sure how to interpret the remark "There are no Unicode byte order marks." in the RFC.
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.
last commit does not really fix the issue with unicode characters that do not encode on two bytes.
RFC 7292 does not really specify the behavior with those.
And I would be in favor of outright rejecting them (or maybe hide a
From<Vec<u8>>
underhazmat
feature flag for ader::asn1::BmpString
).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.
https://en.wikipedia.org/wiki/Byte_order_mark
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.
A BOM would precede the string, and if it had one in this case would be
FEFF
to indicate big endian.BmpString
(if it existed) would still be a nice place to handle all of the string conversions. The header doesn't matter: we can still useEncodeValue
to avoid it, and two trailing digest bytes are easily added to theDigest
prior to finalization.We can worry about that all later though. It isn't needed for an initial PR.
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.
RFC calls for a
c = ceiling(n/u)
and for the loop to be: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.
Using a
loop
instead has the advantage that the last step 6. could be skipped.