-
Notifications
You must be signed in to change notification settings - Fork 693
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
certificate_signature_preferences field contains unnecessary information #4435
Comments
Why is one of the possible solutions not to start enforcing the secp256rl part of the signature scheme?
We have the full certificate chain though, don't we? Why can't we consider more than one certificate at a time? |
Given a goal of enforcing "key preferences", enforcing the key type in the IANA signature scheme would be necessary but not sufficient. IANA signature schemes are generally poorly suited to representing signature and key preferences because (nonexhaustively)
We do have the full certificate chain, but only after validation, and all of its requisite expensive crypto operations have completed. If we are going to reject a cert, we should do that as early as possible to avoid throwing away work. Implementing path-aware validation before X509_verify has completed would mean that s2n-tls has to figure out the potential path. While this is solvable, it's complexity that I would prefer not to deal with. |
Problem:
The
certificate_signature_preferences
field could be specific more succintly.s2n-tls/tls/s2n_security_policies.h
Lines 57 to 63 in a9a3f8c
This field can contains things like
s2n_ecdsa_secp256r1_sha256
. However, having this included in the signature preferences might be confusing to readers because thesecp256r1
part of the signature is never validated. Only the signature type (ECDSA
) and the digest (SHA256
) are validated.This is also present when trying to distinguish between
Given only a single certificate and it's signature, you can't tell whether the signing key had an OID of rsaEncryption or rsassaPss, so we can't distinguish between
s2n_rsa_pss_pss_sha512
ands2n_rsa_pss_rsae_sha512
.Solution:
Some possible solutions
The text was updated successfully, but these errors were encountered: