[WIP] PEP 543: Update for TLS PEP#527
Closed
tiran wants to merge 1 commit into
Closed
Conversation
Auto-detection of PEM / DER is rather complicated and may not always work reliable. All PEM parsers (that I know) ignore extra data before and after the BEGIN/END block. Some data may look like DER at the beginning and then turn out to be PEM later. Instead of guessing the format, how about a format argument with PEM as default? Most people will use PEM anyway. Related to that, OpenSSL has a file format "TRUSTED CERTIFICATE", which is a standard PEM + additional AUX data at the end of the certificate blob. With a format argument, we can easily support additional formats for load and dump. The certificate class can only load the first certificate from a PEM bundle. Except for trivial test cases, a chain and CA bundle are made up from multiple certs. IMO dedicated load methods for chain and batch of certs would be useful for multiple reasons. It's easier and more efficient to use existing load functions extract all certs from a PEM bundle. A chain bundle can contain private key, too. With a dedicated function we can avoid to load the private key into Python memory. And OpenSSL makes it a bit more awkward because it loads the EE cert differently than the rest of the chain, https://github.com/openssl/openssl/blob/master/ssl/ssl_rsa.c#L619 Signed-off-by: Christian Heimes <[email protected]>
Member
Author
|
PoC implementation of new APIs for CPython at python/cpython@master...tiran:ssl_x509 |
5 tasks
Member
|
@tiran Is this waiting for something? Since you're one of the PEP authors I'm tempted to just merge it, except there's a list of TODO items. You should be able to merge it yourself too. |
Member
|
@tiran I'm closing this as it has been sitting open for over a year. If you're ready to merge it then please do so. |
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
4 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.
Auto-detection of PEM / DER is rather complicated and may not always
work reliable. All PEM parsers (that I know) ignore extra data before
and after the BEGIN/END block. Some data may look like DER at the
beginning and then turn out to be PEM later. Instead of guessing the
format, how about a format argument with PEM as default? Most people
will use PEM anyway.
Related to that, OpenSSL has a file format "TRUSTED CERTIFICATE", which
is a standard PEM + additional AUX data at the end of the certificate
blob. With a format argument, we can easily support additional formats
for load and dump.
The certificate class can only load the first certificate from a PEM
bundle. Except for trivial test cases, a chain and CA bundle are made up
from multiple certs. IMO dedicated load methods for chain and batch of
certs would be useful for multiple reasons. It's easier and more
efficient to use existing load functions extract all certs from a PEM
bundle. A chain bundle can contain private key, too. With a dedicated
function we can avoid to load the private key into Python memory. And
OpenSSL makes it a bit more awkward because it loads the EE cert
differently than the rest of the chain,
https://github.com/openssl/openssl/blob/master/ssl/ssl_rsa.c#L619
Signed-off-by: Christian Heimes [email protected]
TODO