Allow RSA_NO_PADDING padding mode in PKCS11_private_encrypt.#11
Closed
sadt wants to merge 1 commit intoOpenSC:masterfrom
Closed
Allow RSA_NO_PADDING padding mode in PKCS11_private_encrypt.#11sadt wants to merge 1 commit intoOpenSC:masterfrom
sadt wants to merge 1 commit intoOpenSC:masterfrom
Conversation
Permitting raw RSA operations is usefull when the software (e.g. openssl) wants to do the padding itself.
nmav
pushed a commit
to nmav/libp11
that referenced
this pull request
Jun 26, 2015
…ized. That includes calling C_Initialize and reopening any sessions. The reinitialization takes place during the next use of the object.
nmav
pushed a commit
to nmav/libp11
that referenced
this pull request
Jun 27, 2015
…ized. That includes calling C_Initialize and reopening any sessions. The reinitialization takes place during the next use of the object.
nmav
pushed a commit
to nmav/libp11
that referenced
this pull request
Jul 9, 2015
…ized. That includes calling C_Initialize and reopening any sessions. The reinitialization takes place during the next use of the object.
nmav
pushed a commit
to nmav/libp11
that referenced
this pull request
Jul 13, 2015
…ized. That includes calling C_Initialize and reopening any sessions. The reinitialization takes place during the next use of the object.
dwmw2
added a commit
that referenced
this pull request
Jul 13, 2015
Transparent handling of PKCS #11 reinitialization after fork
Contributor
|
Hello @sadt could you enhance the test suite to check for both signing operations? I'm planning a release, and if there is a test case for that, I'll include it. |
Contributor
Author
|
Hi @nmav, |
Contributor
|
That's the idea. You can put it in tests and use a wrapper script on top (see testpkcs11.softhsm) so that is automatically run using softhsm on "make check". |
Contributor
Author
|
I've just made a new pull request #31 which includes a test pgm rawrsasign.c in addition to the initial enhancement code. |
Merged
Closed
This was referenced Jan 17, 2019
stanislavlevin
added a commit
to stanislavlevin/libp11
that referenced
this pull request
Oct 2, 2019
According to https://tools.ietf.org/html/rfc7512#page-9: """ 2.4. PKCS OpenSC#11 URI Scheme Query Attribute Semantics An application can always ask for a PIN by any means it decides to. What is more, in order not to limit PKCS OpenSC#11 URI portability, the "pin-source" attribute value format and interpretation is left to be implementation specific. However, the following rules SHOULD be followed in descending order for the value of the "pin-source" attribute: o If the value represents a URI, it SHOULD be treated as an object containing the PIN. Such a URI may be "file:", "https:", another PKCS OpenSC#11 URI, or something else. o If the value contains "|<absolute-command-path>", the implementation SHOULD read the PIN from the output of an application specified with absolute path "<absolute-command- path>". Note that character "|" representing a pipe does not have to be percent-encoded in the query component of a PKCS OpenSC#11 URI. o Interpret the value as needed in an implementation-dependent way. """ This patch is based on: OpenSC#236, but implements only the first clause of RFC, since the second one is considered as dangerous. For example, such functionality is required by FreeIPA (Bind + OpenDNSSEC). Fixes: OpenSC#273 Co-authored-by: Ortigali Bazarov <ortigali.bazarov@gmail.com> Signed-off-by: Stanislav Levin <slev@altlinux.org>
stanislavlevin
added a commit
to stanislavlevin/libp11
that referenced
this pull request
Oct 2, 2019
According to https://tools.ietf.org/html/rfc7512#page-9: """ 2.4. PKCS OpenSC#11 URI Scheme Query Attribute Semantics An application can always ask for a PIN by any means it decides to. What is more, in order not to limit PKCS OpenSC#11 URI portability, the "pin-source" attribute value format and interpretation is left to be implementation specific. However, the following rules SHOULD be followed in descending order for the value of the "pin-source" attribute: o If the value represents a URI, it SHOULD be treated as an object containing the PIN. Such a URI may be "file:", "https:", another PKCS OpenSC#11 URI, or something else. o If the value contains "|<absolute-command-path>", the implementation SHOULD read the PIN from the output of an application specified with absolute path "<absolute-command- path>". Note that character "|" representing a pipe does not have to be percent-encoded in the query component of a PKCS OpenSC#11 URI. o Interpret the value as needed in an implementation-dependent way. """ This patch is based on: OpenSC#236, but implements only the first clause of RFC, since the second one is considered as dangerous. For example, such functionality is required by FreeIPA (Bind + OpenDNSSEC). Fixes: OpenSC#273 Co-authored-by: Ortigali Bazarov <ortigali.bazarov@gmail.com> Signed-off-by: Stanislav Levin <slev@altlinux.org>
mtrojnar
pushed a commit
that referenced
this pull request
Oct 4, 2019
According to https://tools.ietf.org/html/rfc7512#page-9: """ 2.4. PKCS #11 URI Scheme Query Attribute Semantics An application can always ask for a PIN by any means it decides to. What is more, in order not to limit PKCS #11 URI portability, the "pin-source" attribute value format and interpretation is left to be implementation specific. However, the following rules SHOULD be followed in descending order for the value of the "pin-source" attribute: o If the value represents a URI, it SHOULD be treated as an object containing the PIN. Such a URI may be "file:", "https:", another PKCS #11 URI, or something else. o If the value contains "|<absolute-command-path>", the implementation SHOULD read the PIN from the output of an application specified with absolute path "<absolute-command- path>". Note that character "|" representing a pipe does not have to be percent-encoded in the query component of a PKCS #11 URI. o Interpret the value as needed in an implementation-dependent way. """ This patch is based on: #236, but implements only the first clause of RFC, since the second one is considered as dangerous. For example, such functionality is required by FreeIPA (Bind + OpenDNSSEC). Fixes: #273 Co-authored-by: Ortigali Bazarov <ortigali.bazarov@gmail.com> Signed-off-by: Stanislav Levin <slev@altlinux.org>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
Permitting raw RSA operations is usefull when the software
(e.g. openssl) wants to do the padding itself.