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

Allow more/custom labels in encodePemBlock #198

Open
spkersten opened this issue Mar 15, 2023 · 4 comments
Open

Allow more/custom labels in encodePemBlock #198

spkersten opened this issue Mar 15, 2023 · 4 comments
Labels
enhancement New feature or request pkg:pem

Comments

@spkersten
Copy link

spkersten commented Mar 15, 2023

For example, in some cases, other parties require "EC PRIVATE KEY" as a label. Which is not one of the options in PemLabel.

@spkersten spkersten added pending-triage Issue is pending triage pkg:pem labels Mar 15, 2023
@jonasfj jonasfj added enhancement New feature or request and removed pending-triage Issue is pending triage labels Mar 27, 2023
@jonasfj
Copy link
Member

jonasfj commented Mar 27, 2023

It's possible to parse with unsafeIgnoreLabel: true.

Are these labels documented anywhere, I don't see them in:
https://www.rfc-editor.org/rfc/rfc7468#section-4


I could see us allowing a custom string as label too... Maybe as an extra parameter, or as a separate constructor, or just as separate utility methods.

Finding a good place to stick in the label is not easy, maybe we shouldn't have used an enum in the first place.

On the flip side, if these cases are rare on non-spec'ed, maybe unsafeIgnoreLabel is the right choice.

@spkersten
Copy link
Author

For parsing unsafeIgnoreLabel is fine. But my problem was with serializing.

@jonasfj
Copy link
Member

jonasfj commented May 16, 2023

Are there any specifications that suggest using a label like "EC PRIVATE KEY"?

It's possible that dumb and simple thing we should do is take a string in the constructor and deprecate the PemLabel enum.

Is it common to use labels not specified in RFC 7468. If there is a longer list of common labels, then we can extend the enum. If it's common then we probably need to support string.

For the record: a simple workaround is just .replaceAll('PRIVATE KEY', 'EC PRIVATE KEY') on the serialized output.

@spkersten
Copy link
Author

OpenSSL seems to want "EC PRIVATE KEY".

The search and replace is what I've been using. It's just a bit ugly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request pkg:pem
Projects
None yet
Development

No branches or pull requests

2 participants