8000 [DRAFT] Expose selected certificate types in Cert Verify callbacks by dignifiedquire · Pull Request #2266 · rustls/rustls · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

[DRAFT] Expose selected certificate types in Cert Verify callbacks #2266

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.

Sign up for GitHub

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

Jump to bottom
Draft
wants to merge 3 commits into
base: main
Choose a base branch
from
Draft

[DRAFT] Expose selected certificate types in Cert Verify callbacks #2266

wants to merge 3 commits into from

Conversation

dignifiedquire
Copy link

Working on a design to solve #2258

Currently the design is based on the latest suggestion from @djc in #2258

PKI Types branch: https://github.com/dignifiedquire/pki-types

@dignifiedquire dignifiedquire mentioned this pull request Dec 10, 2024
Open
1 task
@djc
Copy link
Member
djc commented Dec 10, 2024

I wonder if it's feasible to do this backwards compatibly by introducing new methods in the verifier traits that just yield the appropriate response if they get an identity type they don't understand.

Also please make IdentityDer non-exhaustive.

@dignifiedquire
Copy link
Author
dignifiedquire commented Dec 10, 2024 •
edited
Loading

@djc good idea, added the appropriate methods, I think this should work asfaict. They will need some naming work, so for now I just prefixed them with yeet_ to make clear that these need better names

@ctz
Copy link
Member
ctz commented Dec 10, 2024

I would kind of expect IdentityDer to contain a certificate chain, not just an end-entity cert? That would make the invalid state of RPK + "intermediate" X509 certs unrepresentable at the level of the verifier traits.

@dignifiedquire
Copy link
Author

I would kind of expect IdentityDer to contain a certificate chain, not just an end-entity cert?

That makes sense, but if we do this, how would we use this type in (yeet_)verify_tls13_signature, where only the CertifcateDer is passed in? would the chain just be left empty always?

@dignifiedquire
Copy link
Author

Any more thoughts on if I should fill this out with logic, or do you think this is not realistic to merge this?

@cpu
Copy link
Member
cpu commented Feb 10, 2025 •
edited
Loading

Any more thoughts on if I should fill this out with logic, or do you think this is not realistic to merge this?

I'm fairly ambivalent personally but would be interested in what the other maintainers are thinking.

From my side I think it's introducing complexity that seems to only support a use case had by users in one particular niche that evaluated Rustls/TLS for their needs, found a traditional PKI a bad fit, and so deployed a hack that now complicates migration to a better solution. I'm sympathetic since the better solution wasn't available at the time, but I'm also not eager to complicate Rustls to support what seems like an improvement with a limited shelf-life (AIUI eventually all mixed deployments will be RPK only and new deployments should be RPK only from the jump).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@dignifiedquire @djc @ctz @cpu
0