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

Add support for PEM headers or explanatory text. #45

Open
adiroiban opened this issue Apr 9, 2020 · 4 comments
Open

Add support for PEM headers or explanatory text. #45

adiroiban opened this issue Apr 9, 2020 · 4 comments

Comments

@adiroiban
Copy link
Contributor

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-value


In https://tools.ietf.org/html/rfc7468 the headers/comments are described as being stored outside of the armor markers

Subject: CN=Atlantis
Issuer: CN=Atlantis
Validity: from 7/9/2012 3:10:38 AM UTC to 7/9/2013 3:10:37 AM UTC
-----BEGIN CERTIFICATE-----
MIIBmTCCAUegAwIBAgIBKjAJBgUrDgMCHQUAMBMxETAPBgNVBAMTCEF0bGFudGlz
MB4XDTEyMDcwOTAzMTAzOFoXDTEzMDcwOTAzMTAzN1owEzERMA8GA1UEAxMIQXRs
YW50aXMwXDANBgkqhkiG9w0BAQEFAANLADBIAkEAu+BXo+miabDIHHx+yquqzqNh
Ryn/XtkJIIHVcYtHvIX+S1x5ErgMoHehycpoxbErZmVR4GCq1S2diNmRFZCRtQID
AQABo4GJMIGGMAwGA1UdEwEB/wQCMAAwIAYDVR0EAQH/BBYwFDAOMAwGCisGAQQB
gjcCARUDAgeAMB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDAzA1BgNVHQEE
LjAsgBA0jOnSSuIHYmnVryHAdywMoRUwEzERMA8GA1UEAxMIQXRsYW50aXOCASow
CQYFKw4DAh0FAANBAKi6HRBaNEL5R0n56nvfclQNaXiDT174uf+lojzA4lhVInc0
ILwpnZ1izL4MlI9eCSHhVQBHEp2uQdXJB+d5Byg=
-----END CERTIFICATE-----

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

---- BEGIN SSH2 PUBLIC KEY ----

Comment: "rsa-key-20160402"
AAAAB3NzaC1yc2EAAAABJQAAAgEAiL0jjDdFqK/kYThqKt7THrjABTPWvXmB3URI
MORE_DATA_HERE

or PGP

   -----BEGIN PGP MESSAGE-----
   Version: OpenPrivacy 0.99

   yDgBO22WxBHv7O8X7O/jygAEzol56iUKiXmV+XmpCtmpqQUKiQrFqclFqUDBovzS
   vBSFjNSiVHsuAA==
   =njUN
   -----END PGP MESSAGE-----

@hynek
Copy link
Owner

hynek commented Apr 10, 2020

Would a dict be enough or are the fields properly standardized for certain types?

@adiroiban
Copy link
Contributor Author

adiroiban commented Apr 10, 2020

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:

  1. the outside explanatory text for https://tools.ietf.org/html/rfc7468
  2. PEM inside headers https://tools.ietf.org/html/rfc1421
  3. The inside headers from OpenPGP standard https://tools.ietf.org/html/rfc4880#section-6.2
  4. SSH Public key https://tools.ietf.org/html/rfc4716

@adiroiban
Copy link
Contributor Author

Would a dict be enough or are the fields properly standardized for certain types?

I think that a dict should be enough... and the dict can have different semantic based on the PEM object type.

hynek added a commit that referenced this issue Jun 20, 2023
hynek added a commit that referenced this issue Jun 20, 2023
hynek added a commit that referenced this issue Jun 20, 2023
* Add support for headers

Ref #45

* Add PR #

* Add fake unreachable code for coverage

* Clarify docstr

* Expand explanation
@hynek
Copy link
Owner

hynek commented Jun 20, 2023

I've added the support for headers in #75.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants