-
Notifications
You must be signed in to change notification settings - Fork 51
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
Improve name constraints testing and fix bugs found #18
Conversation
Codecov Report
@@ Coverage Diff @@
## main #18 +/- ##
==========================================
+ Coverage 86.00% 93.94% +7.93%
==========================================
Files 15 15
Lines 2351 2542 +191
==========================================
+ Hits 2022 2388 +366
+ Misses 329 154 -175
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
445e1a8
to
f5db345
Compare
On this one I have reimplemented the change, as the original one had a reachable panic in ipv6 addresses and fixing it wasn't easy without 128-bit integer support. However there is a test that acts as a regression case for it. |
c4c10e6
to
e1e8d98
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel very out of my depth here so I'm hoping this review is somewhat useful.
e1e8d98
to
f861fcb
Compare
(Note, there's a conflict to fix up.) |
f861fcb
to
6d91c38
Compare
7de4f3e
to
ae25632
Compare
I think this is ready to go now. |
We don't call anymore `presented_dns_id_matches_reference_dns_id`.
There were two bugs. webpki didn't: 1. read the X.509 Name Constraints field in its entirety, nor 2. check the certificate subject against the constraints correctly (1) is a simple fix, (2) requires reading the Common Name from the certificate. Requires lifting some DER parsing logic from ring to parse UTF8String and Set fields. Ring doesn't support those and isn't likely to in the near future, see briansmith/ring#1265. Closes #3.
This uses cryptography.io and can likely to be extended to test other features.
For -- and limited to -- server end-entity certificates, subject commonName can be a DNS name that should be subject to DNS name constraints. Name constraints can and should have an impact on path building and certificate validity, even if we don't actually use the commonName for name validation after this. This is annoying, though, because: - not all end-entity certs have a commonName, because it's no longer required, and a missing one shouldn't be considered a name constraints strike. - only server end-entity certs should be given this treatment: clients don't typically have DNS names (see: https://bugzilla.mozilla.org/show_bug.cgi?id=1523484)
Add a specific error for this, and avoid use of BadDER for cases where the DER encoding is actually fine but the syntax of the messages is incorrect.
This means adding new errors is not a breaking change, at the cost of disabling exhaustive matching of all errors in downstream code.
8579e91
to
8e9de6e
Compare
This incorporates:
{dns_name, ip_address}::presented_id_matches_constraint()
briansmith/webpki#239