-
Notifications
You must be signed in to change notification settings - Fork 361
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
Support additional public key algorithms #82
Comments
The signature algorithms (SHA1, etc.) are all supported so it should not matter. Do you know what the public key algorithms are (RSA, ECDSA, etc.) ? Can I have a look at these certificates? |
For sure. I believe they are all ECDSA: SHA1 SHA384 Appreciate you bearing with me. I’m just coming up to speed on the internal formats and low-level crypto. |
No problem - so from looking at the certificates:
|
Thanks for checking into that @nabla-c0d3. I agree with view on 1024/legacy, we’re still discussing it. I’ll relay this back to the Paranoids, but sometimes things aren’t as clean when you run with well over 6,000 certs. |
Sure - we are directly in touch with the Paranoids too (we've worked with them for the past three years =) - some of the Yahoo Apps are already using TrustKit) so feel free to open an email thread or we can have a quick call with everyone if that helps. |
Moved that discussion to ✉️ |
I have some certificates that use public key algorithms that aren’t supported by TrustKit. Specifically, Yahoo has 3 certs that fail pin generation: one future-proof SHA384 and two older SHA1. Ideally TrustKit can support these formats as well (and then might as support SHA512 and SHA224).
It looks like they can be supported by adding the appropriate asn1 headers, and patching the python pin generator.
Is there any reason why these other algorithms can not or should not be supported by TrustKit?
The text was updated successfully, but these errors were encountered: