Skip to content
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: Return ocsp.Request from CreateRequest instead of []byte #37219

Open
divjotarora opened this issue Feb 14, 2020 · 1 comment
Labels
Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Milestone

Comments

@divjotarora
Copy link

The ocsp.CreateRequest function returns an OCSP request as a []byte. It would be helpful to instead have it return ocsp.Request, which can then be marshalled into []byte if needed.

My specific use case is implementing a cache for OCSP responses. Per https://community.digicert.com/en/blogs.entry.html/2015/02/26/what-is-ocsp.html, the cache key should be the CertID sequence for the OCSP request (issueNameHash + issueKeyHash + serialNumber). All of these fields are calculated in ocsp.CreateRequest but because that function returns a []byte, accessing them after it's been called would require an additional call to ocsp.ParseRequest, which seems wasteful.

I'm not sure what the stability guarantee is for the x/crypto/ocsp library, but if changing the return type for the existing function isn't feasible, perhaps a new function could be added or the existing function could be deprecated and split into two functions.

@gopherbot gopherbot added this to the Proposal milestone Feb 14, 2020
@ianlancetaylor ianlancetaylor added the Proposal-Crypto Proposal related to crypto packages or other security issues label Jan 6, 2021
@ianlancetaylor ianlancetaylor added this to Incoming in Proposals (old) Jan 6, 2021
@rolandshoemaker
Copy link
Member

This API is used enough that we cannot change it at this point. Also given that the vast majority of use cases involve simply sending the generated bytes without any further inspection I don't think it makes sense to alter the API, or introduce a new one, for this particular use case.

ocsp.Request already has a Marshal method, if you feel that adding another invocation of ocsp.ParseRequest is too expensive I'd suggest just forking ocsp.CreateRequest in such a way that you can access the values you need before the marshal step.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Proposal Proposal-Crypto Proposal related to crypto packages or other security issues
Projects
Status: Incoming
Development

No branches or pull requests

4 participants