-
Notifications
You must be signed in to change notification settings - Fork 17.6k
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
proposal: x/crypto/ocsp: support request and response extensions #20001
Comments
/cc @agl |
OCSP nonces are unused in practice in the WebPKI, as far as I know. They require online signing of OCSP responses so I don't see that changing. Even if that were not the case, why not add elements to the |
I had only implemented it since openssl was complaining by default and it sticks to the RFC. Openssl stopped complaining when I implemented them even though I don't sign responses. |
An update to this issue, I have submitted a review for it: https://go-review.googlesource.com/c/crypto/+/101915 |
/cc @FiloSottile |
Change https://go.dev/cl/540735 mentions this issue: |
I've submitted a PR that adds the support without creating new functions: |
CL 540735 adds the following new fields to Request and Response.
/cc @golang/proposal-review @golang/security |
Hi @FiloSottile @ianlancetaylor, |
Everyone seems to be moving away from OCSP, so it seems like we should retire this proposal, not add anything new to this package. |
Based on the discussion above, this proposal seems like a likely decline. |
My 2¢. I'm using the modified library linked in this issue for a personal project and would appreciate its inclusion in the standard library. That said, I agree that the industry seems to be moving away from OCSP, e.g., Intent to End OCSP Service - Let's Encrypt. Regardless, I doubt the protocol will disappear completely anytime soon, so there may be users (including me) who would find this addition to the library useful. |
@CampinCarl what OCSP extensions are you using? |
So far just the nonce extension. I don't know how many clients actually use it outside of openssl though. My understanding is most public or high-volume responders don't use nonces (so they can cache responses). |
No change in consensus, so declined. |
@CampinCarl thanks. As was said in 2017, nonces are practically unused in the web PKI (the publicly trusted set of certificates used for HTTPS), and as such we are not convinced it is necessary to add support for them (or other OCSP extensions) to x/crypto/ocsp. We also don't want to encourage live signing of OCSP responses, which this would enable. Since the x/crypto/ocsp package is quite small, and is not particularly intertwined with other parts of the standard library, if you need this functionality I would suggest forking the package and applying the change proposed in https://go-review.googlesource.com/c/crypto/+/540735. x/crypto/ocsp is unlikely to significantly change in the future, so any fork is unlikely to drift out of sync with upstream. |
Good morning @rolandshoemaker. You're welcome, and thank you for considering the proposal. I totally understand the reasoning behind the decision (and my use case is admittedly niche). I'm using the patched library in my project, so I'm good to go. |
Go Version: go version go1.7 darwin/amd64
GOARCH="amd64"
GOOS="darwin"
I was writing code dealing with OCSP and found that extensions inside the tbsRequest are not supported in the current x/crypto/ocsp code. This is required to implement the nonce extension common to OCSP requests (openssl ocsp uses it by default). RFC 6960 defines that the TBSRequest should support extensions in section 4.1.1.
The RFC additionally defines the ResponseData structure to have responseExtensions which is also missing from the go OCSP code. This is presented in section 4.2.1.
I have already written code to address this issue but it would break existing code that uses the library. If this issue is accepted I will change it up so it doesn't do that and submit a Gerrit review request for it.
That code can be found here
UPDATE: a gerrit review of the actual code is here
The changes of note are on lines 95, 126, 414 in the ParseRequest function, and 702 in the CreateResponse function.
My proposed fix would be to move the ParseRequest code to a new function ParseRequestWithExtensions, which would look similar to my posted implementation of ParseRequest. ParseRequest would call ParseRequestWithExtensions and throw out the extensions keeping the current functionality. It would also add response extensions to the response via the response template passed into the CreateResponse function (line 702).
Please comment with any requests for clarification or if I am out of line on wanting this to go into master :)
The text was updated successfully, but these errors were encountered: