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

Added warning about SHA1 being used for response signing in ocsp.rst #10204

Merged
merged 5 commits into from
Jan 19, 2024

Conversation

Hacksawfred3232
Copy link
Contributor

@Hacksawfred3232 Hacksawfred3232 commented Jan 18, 2024

While SHA1 can't be used for signing requests/responses, it can still be used for adding certificates to the request/response. I am guessing this is allowable due to the fact that we're signing with a stronger algorithm (SHA256), preventing modification of digest made with a weaker algorithm (SHA1)

Despite this, there is not enough clarity to indicate this, as someone may see the SHA1 algorithm being used in the "add_response" function and thinking "Oh! We can use SHA1 here", despite that not being the case. This commits adds the needed clarity.

Added warning about SHA1 being used for sign()
Fixed spelling issues, at least according to en-GB dictionary.
Spell checker didn't catch "algorithim" somehow.
@Hacksawfred3232
Copy link
Contributor Author

Apparently dictionary didn't catch "algorithim" somehow... Should be all good now.

@alex
Copy link
Member

alex commented Jan 18, 2024

FYI the rust nightly failure is unrelated to this PR and we're identifying a fix.

Comment on lines 343 to 347
otherwise. This should not be the same algorithm used to add
a certificate to the response, as
:class:`~cryptography.hazmat.primitives.hashes.SHA1` can't be used
for signing, despite its compatibility requirement for certain
applications.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd suggest rephrasing to state that this does not need to be the same algorithm used in add_response (i.e., link to it) and separately that SHA1 is disallowed here even though it's allowed here.

We don't want people to think that if they pass SHA256 to add_response that they shouldn't use it here.

Copy link
Contributor Author

@Hacksawfred3232 Hacksawfred3232 Jan 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Edited it, I think I rephrased it well enough? Decided to be more direct.

Attempting to rephrase the warning.
Removing rouge space.
Copy link
Member

@alex alex left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks great. Will merge once we fix our CI issues. Thanks!

@alex alex enabled auto-merge (squash) January 18, 2024 15:50
@alex alex merged commit bd0a064 into pyca:main Jan 19, 2024
56 checks passed
@Hacksawfred3232 Hacksawfred3232 deleted the patch-1 branch January 21, 2024 17:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants