X509: Refactor X509_PUBKEY processing to include provider side keys#14281
Closed
levitte wants to merge 2 commits intoopenssl:masterfrom
Closed
X509: Refactor X509_PUBKEY processing to include provider side keys#14281levitte wants to merge 2 commits intoopenssl:masterfrom
levitte wants to merge 2 commits intoopenssl:masterfrom
Conversation
When a SubjectPublicKeyInfo (SPKI) is decoded into an X509_PUBKEY structure, the corresponding EVP_PKEY is automatically added as well. This used to only support our built-in keytypes, and only in legacy form. This is now refactored by making The ASN1 implementation of the X509_PUBKEY an EXTERN_ASN1, resulting in a more manual implementation of the basic support routines. Specifically, the d2i routine will do what was done in the callback before, and try to interpret the input as an EVP_PKEY, first in legacy form, and then using OSSL_DECODER. Fixes openssl#13893
levitte
added
branch: master
paulidale
reviewed
Feb 22, 2021
Contributor
paulidale
left a comment
paulidale
left a comment
There was a problem hiding this comment.
Does this need a test case?
crypto/x509/x_pubkey.c
Outdated
| #include <openssl/dsa.h> | ||
| #include <openssl/decoder.h> | ||
| #include <openssl/encoder.h> | ||
| #include <openssl/decoder.h> |
Contributor
There was a problem hiding this comment.
Twice? I know it's a good header file but still...
Member
Author
There was a problem hiding this comment.
I guess I include with enthusiasm!
Yeahok, I'll remove one of them
Member
There was a problem hiding this comment.
Ummmm.....did I miss something. The original header was encoder, and this adds decoder? i.e. its not the same header twice.
Member
Author
There was a problem hiding this comment.
That's because the conversation page only shows you two diff lines by default. Here's what it looks like when you go look at the file changes
paulidale
approved these changes
Feb 23, 2021
levitte
added
approval: done
Member
Author
|
Merged 1031585 X509: Refactor X509_PUBKEY processing to include provider side keys |
openssl-machine
pushed a commit
that referenced
this pull request
Feb 24, 2021
When a SubjectPublicKeyInfo (SPKI) is decoded into an X509_PUBKEY structure, the corresponding EVP_PKEY is automatically added as well. This used to only support our built-in keytypes, and only in legacy form. This is now refactored by making The ASN1 implementation of the X509_PUBKEY an EXTERN_ASN1, resulting in a more manual implementation of the basic support routines. Specifically, the d2i routine will do what was done in the callback before, and try to interpret the input as an EVP_PKEY, first in legacy form, and then using OSSL_DECODER. Fixes #13893 Reviewed-by: Paul Dale <[email protected]> (Merged from #14281)
This was referenced Feb 24, 2021
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
3 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.
When a SubjectPublicKeyInfo (SPKI) is decoded into an X509_PUBKEY
structure, the corresponding EVP_PKEY is automatically added as well.
This used to only support our built-in keytypes, and only in legacy
form.
This is now refactored by making The ASN1 implementation of the
X509_PUBKEY an EXTERN_ASN1, resulting in a more manual implementation
of the basic support routines. Specifically, the d2i routine will do
what was done in the callback before, and try to interpret the input
as an EVP_PKEY, first in legacy form, and then using OSSL_DECODER.
Fixes #13893