-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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
x/crypto/ocsp: response should not contain param element for hashingAlgorithm #69078
Comments
cc @golang/security |
Technically it's more correct to omit the NULL parameter, but it's common practice in the WebPKI to include it (I surveyed OCSP responses from Sectigo, Let's Encrypt, DigiCert, and Google Trust Services). RFC 4055 (which is transitively referenced by RFC 6960) explains why:
The WebPKI has yet to precisely profile OCSP, but if it does, it will probably require the NULL parameter, just as it already does for AlgorithmIdentifiers in certificate. Since Go targets the WebPKI, I think this should be WONTFIX. |
@AGWA thank you for pointing out to history of the AlgorithmIdentifier parameter. I believe common OCSP responders that you are referring are built on top of golang. That may be reason we are seeing NULL parameter element in their response. But if you see the OCSP response from OpenSSL OCSP responder, it does not have NULL parameter in the response. golang is a new age language and it would be correct to remove the NULL parameter for hashing algorithm from OCSP response and keeping the behavior intact(NULL or empty accept) in OCSP response processing side. |
I'm curious why you believe Sectigo and DigiCert's OCSP responders use Go? And it's not just them - Microsoft, GlobalSign, Entrust, Identrust, ssl.com also include the NULL parameter in OCSP responses. But the more important point is that WebPKI policy already requires the NULL parameter in certificates, and accordingly Go diverges from OpenSSL's behavior when encoding certificates (see #38014). While there is not currently the same policy requirement for OCSP, there may be in the future, since the WebPKI prefers having one encoding for things. For AlgorithmIdentifiers, that means including NULL parameters. Note that omitting the parameters is a "SHOULD", meaning Go can ignore it if it has valid reasons to do so. Consistency with certificate encoding, consistency with WebPKI practice, and anticipation of future WebPKI policy requirements are all valid reasons to ignore the requirement. |
Go version
go 1.23
Output of
go env
in your module/workspace:What did you do?
The code is present here https://go.dev/play/p/OKCJFUwCu83
I am trying to generate OCSP response. The generated OCSP response is not as per the RFC recommendations.
What did you see happen?
The generated OCSP response is below(in hex format).
The decoded data you can see https://lapo.it/asn1js/#MIGjoRswGTEXMBUGA1UEAxMOT0NTUCBSZXNwb25kZXIYDzIwMDkxMTEwMjMwMDAwWjBzMHEwSTAJBgUrDgMCGgUABBTA_gJ4_JkYiJGz8hLpx-GyGre_wAQUDfwd8Kng8Bzn8rITF35vjRV81PYCEAF_d96zvLsjXUTMx9umLnKAABgPMjAxMDA3MDcxNTAxMDVaoBEYDzIwMTAwNzA3MTgzNTE3Wg
What did you expect to see?
The RFC https://datatracker.ietf.org/doc/html/rfc5912#section-3 that governs the OCSP response->CertID->hashingAlgorithm says that the parameter (which is coming as a NULL element from the go OCSP response) should not be encoded(should not be present) in the structure for the message digest algorithms.
go OCSP response should not have the NULL param element for the hashing algorithm.
The text was updated successfully, but these errors were encountered: