proposal: x/crypto/ocsp: support request and response extensions

[wumb0]

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 :)

[odeke-em]

/cc @agl

[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 Request structure rather than change the function signature?

[wumb0]

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.
My proposed addition (different than the example code) would modify the request structure, but also add another function for those that wanted to get extensions back from a function call for further processing.
Modifying the Request structure doesn't make sense because these extensions are in the tbsRequest.
I see your point about nonces not being necessary, though. I don't know where this protocol will be going in the future so it may be helpful to have access to those extensions at some point.

[wumb0]

An update to this issue, I have submitted a review for it: https://go-review.googlesource.com/c/crypto/+/101915
The code has been modified to not break existing implementations but to add a function that will return request extensions with the parsed request and also enable a developer to add response extensions to their response via template.

[andybons]

/cc @FiloSottile

[gopherbot]

Change https://go.dev/cl/540735 mentions this issue: ocsp: support for request and response extensions

[maraino]

I've submitted a PR that adds the support without creating new functions:
https://go-review.googlesource.com/c/crypto/+/540735

[FiloSottile]

CL 540735 adds the following new fields to Request and Response.

// Request represents an OCSP request. See RFC 6960.
type Request struct {
	// ...
	Extensions     []pkix.Extension
}

// Response represents an OCSP response containing a single SingleResponse. See
// RFC 6960.
type Response struct {
	// ...

	// ResponseExtensions contains raw X.509 extensions from the
	// responseExtensions field of the OCSP response. When marshaling OCSP
	// responses, the ResponseExtensions field is ignored, see
	// ResponseExtraExtensions.
	ResponseExtensions []pkix.Extension

	// ResponseExtraExtensions contains extensions to be copied, raw, into any
	// marshaled OCSP response (in the responseExtensions field). Values
	// override any extensions that would otherwise be produced based on the
	// other fields. The ResponseExtraExtensions field is not populated when
	// parsing certificates, see ResponseExtensions.
	ResponseExtraExtensions []pkix.Extension
}

/cc @golang/proposal-review @golang/security

[supreetdeshpande21]

Hi @FiloSottile @ianlancetaylor,
Any plans on adding the Request Extension to support OCSP?
I noticed the Response Extension support is already in this library and the CL 540735 has been out for a while.

[rsc]

Everyone seems to be moving away from OCSP, so it seems like we should retire this proposal, not add anything new to this package.

[rsc]

Based on the discussion above, this proposal seems like a likely decline.
— rsc for the proposal review group

[CampinCarl]

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.

[rolandshoemaker]

@CampinCarl what OCSP extensions are you using?

[CampinCarl]

@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).

[gopherbot]

No change in consensus, so declined.
— aclements for the proposal review group

[rolandshoemaker]

@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.

[CampinCarl]

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.