cryptography
cryptography copied to clipboard
pyca
Support PSS X509 Signatures
First part of this is done, exposing the signature algorithm OID. Now we need to support this in sign.
Just leaving a comment for motivation. Would love to see this implemented.
I work with code signing systems that includes messing around with certificates, and some platforms require PSS in the certificate chains.
PSS end entity signatures or intermediates? (e.g. do you need signing or just parsing support?) Could you share the platform? It'd be useful to at least know where this is actually seen in the wild now. I was quietly hoping everything would just move to ECDSA (or EdDSA) signatures instead of RSA-PSS...
GlobalSign supports the RSASSA-PSS signing algorithm for all S/MIME Certificates issued via Enterprise PKI (effective October 29, 2018). As of January 1, 2019, the German Energy Sector requires the RSASSA-PSS algorithm to be used for secure email communications with energy and water industry market participants. Please review the steps below to configure your Enterprise PKI Profile to use the RSASSA-PSS algorithm.
https://support.globalsign.com/customer/en/portal/articles/2958431-rsassa-pss-signing-algorithm-support
Hi, I am also dropping a comment here as I would really like to use this feature. As a note, I would only need this for legacy reasons. An old implementation uses RSASSA-PSS signing algorithm and currently the certificates get signed with sha256WithRSAEncryption "1.2.840.113549.1.1.11".
Hi, I'm also having issues to create X509 certificates with RSASSA-PSS. Is there any way to create a x509 certificate with Signature algorithm OID:<ObjectIdentifier(oid=1.2.840.113549.1.1.10, name=RSASSA-PSS)> except using OpenSSL command line under python ? The sha256WithRSAEncryption isn't supported anymore on the IoT hardware devices I'm working on.
There is no mechanism in cryptography for generating PSS certs at this time. Implementing this is non-trivial so we continue to look for consistent use cases. Can you share what type of IoT devices require this?
Sure, current devices from Qualcomm and Mediatek (required for firmware signing)
See details for Qualcomm here: https://www.qualcomm.com/media/documents/files/secure-boot-and-image-authentication-technical-overview-v2-0.pdf. I can also provide real-world examples (certs) if needed.
Thanks for the details. We've seen this as a request for firmware signing before as well. Hopefully someone will feel ambitious enough to tackle the work at some point!
There is valid cert like https://www.d-trust.net/cgi-bin/D-TRUST_Root_CA_3_2021.crt use this signature hash algorithm. It would be great can support decode this kind of cert.
The boot firmware for Armv7-A and Armv8-A processors (Cortex-A, including the ubiquitous A55) is called Trusted Firmware-A:
https://github.com/ARM-software/arm-trusted-firmware
TF-A loads a "firmware image package" (FIP) at bootup, containing device trees and secondary bootloaders. To enable the "trusted boot" mode, this FIP must also contain several signatures. TF-A provides a tool for generating these signatures.
TF-A uses mbedtls as the backend for both generating and loading certificates. TF-A appears to only support RSASSA-PSS certificates (although the generator also seems to support ECDSA, this doesn't appear to be supported by the loader yet).
We use python in our test suite to modify parts of the FIP before each test -- we hoped to be able to generate certificates for the modified data without needing to shell out to an external program.
Above, reaperhulk mentioned:
There is no mechanism in cryptography for generating PSS certs at this time.
As of now, it looks like support for various padding schemes has been added to the private key, e.g.:
https://github.com/pyca/cryptography/blob/main/src/cryptography/hazmat/backends/openssl/rsa.py#L505
However, the CertificateBuilder still doesn't support specifying a padding scheme.
Is this mostly a matter of API design at this point?
Yes, if we can figure out the API design, actually supporting PSS in X.509 is very easy.
On Thu, Apr 13, 2023 at 10:51 AM Woodrow Barlow @.***> wrote:
The boot firmware for Armv7-A and Armv8-A processors (Cortex-A, including the ubiquitous A55) is called Trusted Firmware-A:
https://github.com/ARM-software/arm-trusted-firmware
TF-A loads a "firmware image package" (FIP) at bootup, containing device trees and secondary bootloaders. To enable the "trusted boot" mode, this FIP also must contain several signatures. TF-A provides a tool for generating these signatures.
TF-A uses mbedtls as the backend for both generating and loading certificates. TF-A appears to only support RSASSA-PSS certificates (although the generator also seems to support ECDSA, this doesn't appear to be supported by the loader yet).
We use python in our test suite to modify parts of the FIP before each test -- we hoped to be able to generate certificates for the modified data without needing to shell out to an external program.
Above, reaperhulk mentioned:
There is no mechanism in cryptography for generating PSS certs at this time.
As of now, it looks like support for various padding schemes has been added to the private key, e.g.:
https://github.com/pyca/cryptography/blob/main/src/cryptography/hazmat/backends/openssl/rsa.py#L505
However, the CertificateBuilder still doesn't support specifying a padding scheme.
Is this mostly a matter of API design at this point?
— Reply to this email directly, view it on GitHub https://github.com/pyca/cryptography/issues/2850#issuecomment-1507111679, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAGBALSD3LH35UFGONPLDXBAHG5ANCNFSM4B6W67VA . You are receiving this because you commented.Message ID: @.***>
-- All that is necessary for evil to succeed is for good people to do nothing.
Actually it's nothing that really needs to be "designed". The API does already implement it, but it was hardcoded in this project to pkcsv15. I've already ported the changes, but it affects several other modules, tests etc. as well, as it would allow to use padding in general. I'm going to do some tests the next days and once finished, I'll push a PR. It should be fully downwards compatible and shouldn't break anything, if it turns out as expected.
Thanks for working on this, we're looking forward to seeing the PR!
On Tue, May 2, 2023 at 12:32 PM Bjoern Kerler @.***> wrote:
Actually it's nothing that really needs to be "designed". The API does already implement it, but it was hardcoded in this project to pkcsv15. I've already ported the changes, but it affects several other modules, tests etc. as well, as it would allow to use padding in general. I'm going to do some tests the next days and once finished, I'll push a PR. It should be fully downwards compatible and shouldn't break anything, if it turns out as expected.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you commented.Message ID: @.***>
-- All that is necessary for evil to succeed is for good people to do nothing.
I've added the PR #8859 which should add support for padding of several different rsa certificate signing methods. pkcs7 might need further improvements, as padding support is prepared, but the documentation needs to show the possibility how to add padding different to pkcs1. Sorry if my rust stuff might be bad, but this is the first time I coded Rust at all :)
With https://github.com/pyca/cryptography/commit/b436fafa7cf43c96f66d50162ac495c99ade1f39 landed, it's now possible to read a PSS certificate usefully.