-
Notifications
You must be signed in to change notification settings - Fork 129
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
x509-cert: support for non-RFC5280 profiles #984
Comments
|
@lumag if I understand correctly that's in the context of supporting a mixed RFC5280/non-RFC5280 mode, where it's suggesting you perform the same set of checks for all of the certificates, rather than selectively applying RFC5280 to some of the certificates. However, in a pure RFC5280 mode, definitionally you do want those checks to ensure all certificates are valid according to the profile. Question 2 was asking how that would be implemented (i.e. in such a way that non-conforming certs won't accidentally be considered) |
I think 6.1 tells that even if the app has such checks, they should be separate from path-validation algorithm. |
Perhaps we could have something like: pub struct Certificate<Profile = Rfc5280> { ... } ...which would allow different profiles to define different validation rules. |
I think "profile" and "validation" are a bit overloaded. Maybe "<Linter = Rfc5280>" would be closer. |
"Profile" is the term of art from RFC5280. It's used in the name of the RFC and throughout the body, including in comparisons to earlier X.509 profiles (e.g. in Section 6.1) |
Yeah, but also in more concrete sense in certificate policies. It's fine. |
I like the Profile idea. I'm guessing it means refactoring a bit, so that the base x509, for example, doesn't check on the length of the serial number, while the RFC5280 one does the enforcement. Something like It would be good to have something like a complies method in the profile, so you can test if it's okay to cast :) |
This intends to allow user to relax checks when parsing certificate and cover for non rfc5280 compliant x509 certificates. Fixes RustCrypto#978 Fixes RustCrypto#984
This allow the user to relax checks when parsing certificate and cover for non rfc5280 compliant x509 certificates. Fixes RustCrypto#978 Fixes RustCrypto#984
This allow the user to relax checks when parsing certificate and cover for non rfc5280 compliant x509 certificates. Fixes RustCrypto#978 Fixes RustCrypto#984
This crate is described as implementing RFC5280, however we've had a number of requests to support various things which don't conform to the profile, namely serial numbers longer than 20 octets and negative serial numbers.
Some questions:
The text was updated successfully, but these errors were encountered: