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

w_serial_number_low_entropy lint should return an error: #187

Closed
szank opened this issue Dec 14, 2017 · 6 comments

Comments

@szank
Copy link
Contributor

commented Dec 14, 2017

Suprisingly, some CAs can't get even this right:
https://crt.sh/?id=277579245&opt=cablint,x509lint,zlint

As per the CA/B BR wording this should be an error. Any objections ?

@szank

This comment has been minimized.

Copy link
Contributor Author

commented Dec 14, 2017

@zakird

This comment has been minimized.

Copy link
Member

commented Dec 14, 2017

Agree, this looks more like an error than a warning given the SHALL.

@titanous

This comment has been minimized.

Copy link
Member

commented Dec 14, 2017

This is intentionally not an error as it's not possible to programmatically detect a violation of this clause with 100% accuracy: #112 (comment)

@szank

This comment has been minimized.

Copy link
Contributor Author

commented Dec 15, 2017

Sigh that's fair enough. It have been some time since I have read about the reasoning about this requirement. It was about a known prefix attack, right ?

The question is, does the missing bytes in the serial number ( if they CSPRNG outputs bits with leading zeroes ) facilitate the attack> I guess not, because the length of the prefix cannot be predicted anyway in such case. Can someone please correct me here?
I am not very keen on digging into it again.

If encoding the serial number on smaller number of bytes makes the attack easier, I think this lint should return an error in the end. It is trivial to prepend the output from the CSPRNG with a fixed byte > 0 if one wanted to enforce a minimum byte length of the SN.

@titanous

This comment has been minimized.

Copy link
Member

commented Dec 15, 2017

Sigh that's fair enough. It have been some time since I have read about the reasoning about this requirement. It was about a known prefix attack, right ?

It was introduced in response to the MD5/SHA-1 weaknesses in order to change the level of attack necessary to forge a certificate with a broken hash algorithm from chosen-prefix collision to random-prefix collision: https://cabforum.org/pipermail/public/2016-June/007858.html

The question is, does the missing bytes in the serial number ( if they CSPRNG outputs bits with leading zeroes ) facilitate the attack> I guess not, because the length of the prefix cannot be predicted anyway in such case. Can someone please correct me here?

No, the byte length itself doesn't matter.

If encoding the serial number on smaller number of bytes makes the attack easier, I think this lint should return an error in the end. It is trivial to prepend the output from the CSPRNG with a fixed byte > 0 if one wanted to enforce a minimum byte length of the SN.

While this is trivial, it is not required by the Baseline Requirements, and so I don't think it's reasonable to trigger an error given that a few CAs do not do this and appear to generate exactly 64 bits of entropy before encoding it as the serial number.

@zakird

This comment has been minimized.

Copy link
Member

commented Dec 28, 2017

It looks like this has been addressed in the conversation here. I'm going to close this issue.

@zakird zakird closed this Dec 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.