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

RFC 6960 updates OCSP validation algorithm to SHA256 #65

Open
Sprinterfreak opened this issue Jul 1, 2023 · 1 comment
Open

RFC 6960 updates OCSP validation algorithm to SHA256 #65

Sprinterfreak opened this issue Jul 1, 2023 · 1 comment

Comments

@Sprinterfreak
Copy link
Contributor

cryptography.io states

SHA256 is in this example because while RFC 5019 originally
required SHA1 RFC 6960 updates that to SHA256.
However, depending on your requirements you may need to use SHA1
for compatibility reasons.

Is there any reason, why we still default to sha1?

Quick tests with validate_ocsp: 'sha256' did not indicate any issues for me so far.

@Kishi85
Copy link
Contributor

Kishi85 commented Jul 12, 2023

The reason is simple: The OCSP request spec is still based on RFC5019 and RFC6950 does not obsolete or update that (see https://datatracker.ietf.org/doc/html/rfc6960).

RFC5019 explicitly states that "Clients MUST use SHA1 as the hashing algorithm for the CertID.issuerNameHash and the CertID.issuerKeyHash values." (see https://datatracker.ietf.org/doc/html/rfc5019#section-2.1.1) and thats where the default comes from.

RFC6960 only states that an OCSP client has to be capable of processing responses signed with sha256 and should be able to process sha1 as well (see https://datatracker.ietf.org/doc/html/rfc6960#section-4.3). So IHMO the information on cryptography.io might just be a misunderstanding?

Anyway as long as RFC5019 is the leading standard there is no reason to update this default and cause potential breakage or problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants