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

Should key usages be tracked as a HashSet instead? #265

Open
djc opened this issue Apr 8, 2024 · 2 comments
Open

Should key usages be tracked as a HashSet instead? #265

djc opened this issue Apr 8, 2024 · 2 comments
Labels
next-major-release breaking changes put off until next major release

Comments

@djc
Copy link
Member

djc commented Apr 8, 2024

In #264 code is pretty ugly because we're keeping track of whether an EKU already exists in the Vec that we hold. Should CertificateParams::key_usages and extended_key_usages be HashSet instead?

  • Does the order matter?
  • Is there a valid use case for having the same usage twice?

(I guess it could even be more like a bitset similar to what x509-parser apparently does.)

@djc djc added the next-major-release breaking changes put off until next major release label Apr 8, 2024
@est31
Copy link
Member

est31 commented Apr 8, 2024

Does the order matter

personally I'd like to keep rcgen as deterministic as possible, so IMO it would be good to have a consistent order.

edit: with that I mean to not introduce nondeterminism where there hasn't been such before.

@djc
Copy link
Member Author

djc commented Apr 9, 2024

We could order the key usages when we're writing out DER -- that would still generate a potentially different order than was retrieved from a parsed certificate but would at least be consistent/deterministic?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next-major-release breaking changes put off until next major release
Projects
None yet
Development

No branches or pull requests

2 participants