-
Notifications
You must be signed in to change notification settings - Fork 50
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
Allow path building to return the validated path #53
Comments
Reading the existing |
I thought I'd be able to smuggle out a Lines 93 to 94 in a0c2af2
I can't change |
Can you replace the |
I experimented with that and I think the catch there was that I also thought about having the caller transform the slice of DER references into I had to log off for the day but my thought for a next idea is to try to return references to the DER of the built chain intermediates instead of the parsed |
I think I'm going to take a different approach. I don't want to heavily refactor the existing path building just to support CRLs and haven't been able to arrive at a minimal change that's workable. I think it will be easier to consider the CRL path building and signature validation separate from the existing implementation to start. |
I need to add test coverage but I think I've figured out a way forward. I was making life harder for myself trying to handle CRL validation separately from path building. Threading the CRL data into the existing validation works out better and obviates the requirement to pull the validated path out. It's also a better match to how 5280 + friends recommend this be handled. |
Closing this since the approach I used in #66 doesn't require this and implementing it will require more significant changes to the core path building than I'm keen to bite off right now. |
Presently the
validate_cert.rs
implementation ofbuild_path
used for path-building only returns an indication of whether the operation failed or not:webpki/src/verify_cert.rs
Lines 20 to 28 in 15acd62
CRL validation also requires building a path from the issuer of the CRL to a trust anchor. Further, RFC 5280 6.3.3 says the path must be built to the same trust anchor used to validate the target end-entity certificate for which we're considering revocation status:
At a minimum, the
build_path
implementation should yield the finalTrustAnchor
that was used to build the validated path so that we can ensure this requirement is met.To avoid having to build a path from scratch from the issuer to that
TrustAnchor
it would be best ifbuild_path
could yield the full validated path including the intermediate certificates used. That would allow the CRL validation to proceed using the same validation path to the same root. This is the approach used by the gRPC implementation of CRL validation based on providing the implementation theverifiedChains [][]*x509.Certificate
produced by path building.Changing the implementation to yield just a
TrustAnchor
is fairly straight forward. Producing the full chain that was validated without making it requirealloc
is likely to be more difficult.Related issue: briansmith/webpki#264
The text was updated successfully, but these errors were encountered: