-
-
Notifications
You must be signed in to change notification settings - Fork 37
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
Add support for PEM headers or explanatory text. #45
Comments
Would a dict be enough or are the fields properly standardized for certain types? |
At this point I am trying to gather the documentation/specification for this feature. First we need to add basic payload parsing for each RFC... and then we can look at the headers. Based on the RFCs that I found, I think a dict is enough. I think that this needs to be implemented in more parts based on each RFC:
|
I think that a dict should be enough... and the dict can have different semantic based on the PEM object type. |
* Add support for headers Ref #45 * Add PR # * Add fake unreachable code for coverage * Clarify docstr * Expand explanation
I've added the support for headers in #75. |
Maybe this should be split into 2 tickets... one for RFC 7468 explanatory text and another one for internal comments/headers.
Feel free to close this ticket if is not relevant. I just wanted to highlight this issue.
The use case is that some people might want to tag a certain key (public or private...or certificate).
For example to signal if a key is for testing or for production and to not accidentally copy/use a testing file in production.
As a start, I think that this data can be exported as
explanatory_raw
and just have the raw text without trying to parse it in list of key-valueIn https://tools.ietf.org/html/rfc7468 the headers/comments are described as being stored outside of the armor markers
Some SSH or PGP formats include support for headers... which are free text values found before the payload but inside the armor and which usually are not signed or protected or encrypted.
They are more like a kind of comment or meta-data
or PGP
The text was updated successfully, but these errors were encountered: