formats
formats copied to clipboard
pem-rfc7468: allow parsing multiple encapsulated objects from single PEM file
I think it's pretty common to have a single .pem file that contains a bunch of public keys. Not sure what the best API for this is, maybe return the remaining string/byte slice on successful parse? I wrote a PEM encoder/decoder that follows this pattern, might be useful: https://gist.github.com/akhilles/1ebaa0a6f15e46d6b4414bdf7d8c8ced.
I think it's pretty common to have a single
.pemfile that contains a bunch of public keys.
It is? It's definitely common for X.509 certificate chains to be encoded as concatenated PEM files, but I don't think I've seen "a bunch of public keys" encoded that way before. What's the use case?
That aside, it shouldn't be too hard to support this if desired. A method that returns an Iterator that produces Item=pkcs8::PublicKeyDocument seems like a reasonable API.
I'm using it as a convenient way to represent a "committee" in a consensus model. Although, it might be better to just use a directory of .pem files so that the keys are easier to inspect with tools like openssl.
It is? It's definitely common for X.509 certificate chains to be encoded as concatenated PEM files, but I don't think I've seen "a bunch of public keys" encoded that way before. What's the use case?
I think @akhilles might have misspoken. It is a common use case to have multiple PEM-encoded public key certificates concatenated (not public keys). Many applications, such as Postfix, support PEM-encoded certificate chains in this fashion. Here is an example of where this practice is documented by a large PKI company: https://www.digicert.com/kb/ssl-support/pem-ssl-creation.htm.
On a side note, the PEM file format is supposed to tolerate "explanatory text" before, after, and between such objects: https://www.rfc-editor.org/rfc/rfc7468#section-5.2.
I think it would be constructive to implement this as Iterator<(type_label, data)>.
This functionality is definitely needed. I need it now and I will implement it and submit a PR, if you're open to it.
I think @akhilles might have misspoken. It is a common use case to have multiple PEM-encoded public key certificates concatenated
That's exactly what I said and what you just quoted?
On a side note, the PEM file format is supposed to tolerate "explanatory text" before...
Support for the "before" case for explanatory text was implemented in #40.
Again, I'm fine with adding support for iterating over sequences of encapsulated objects. Just please remember this crate has a guarantee of constant time operation which shouldn't be violated in service of implementing this feature.