get type of PEM data

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

get type of PEM data

JordanBrown

I'm finding that it would be helpful to have a function that would, given PEM data (in memory or in a file) return an indication of what kind of object it represents:  a certificate, a private key, et cetera.  The ideal function would basically tell me which PEM_read_bio_foobar function I would use to read the PEM data (and thus what C type it represents).  It would lump all private key formats into one type, since PEM_read_PrivateKey would work on all of them and return an EVP_PKEY.

Does such a function already exist?  Any thoughts?

-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: get type of PEM data

Michael Wojcik
enum pem_type {
        PEM_TYPE_NONE = 0,
        PEM_TYPE_CERTIFICATE,
        PEM_TYPE_RSA_PRIVATE
};

struct pem_map {
        enum pem_type type;
        const char *pem_string;
};

#include <openssl/pem.h>

enum pem_type identify_pem(const char *pem) {
        static const struct pem_map map[] = {
                { PEM_TYPE_CERTIFICATE, PEM_STRING_X509 "-----" },
                { PEM_TYPE_RSA_PRIVATE, PEM_STRING_RSA "-----" },
        };
        const char *pem_begin;
        int idx;

        if (!pem) return PEM_TYPE_NONE;

        if (! (pem_begin = strstr(pem, "-----BEGIN "))) return PEM_TYPE_NONE;
        pem_begin += 11;

        for (idx = 0; idx < sizeof map / sizeof *map; idx++) {
                if (strncmp(pem_begin, map[idx].pem_string, strlen(map[idx].pem_string)) == 0) {
                        return map[idx].type;
                }
        }

        return PEM_TYPE_NONE;
}

Untested. Extending to the remainder of the PEM types (see pem.h) is left as an exercise for the reader.

--
Michael Wojcik
Distinguished Engineer, Micro Focus



                       
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: get type of PEM data

Viktor Dukhovni
In reply to this post by JordanBrown


> On Mar 28, 2018, at 11:02 AM, Jordan Brown <[hidden email]> wrote:
>
> I'm finding that it would be helpful to have a function that would, given PEM data (in memory or in a file) return an indication of what kind of object it represents:  a certificate, a private key, et cetera.  The ideal function would basically tell me which PEM_read_bio_foobar function I would use to read the PEM data (and thus what C type it represents).  It would lump all private key formats into one type, since PEM_read_PrivateKey would work on all of them and return an EVP_PKEY.
>
> Does such a function already exist?  Any thoughts?

PEM_read_bio() reads a generic PEM object.  The header name
can then be compared with the various PEM_STRING_... constants.

OpenSSL can already read keys in a general way.  See,
PEM_read_bio_PrivateKey() returning an EVP_PKEY.  So you
don't need to reinvent this.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: get type of PEM data

Matt Caswell-2
In reply to this post by JordanBrown
Take a look at the new STORE functions in 1.1.1. They do something like
what you are describing. They can take a URI and load whatever objects
it finds there using the right kind of loader based on the PEM type. You
can also search for particular objects in your store. See:

https://www.openssl.org/docs/man1.1.1/man3/OSSL_STORE_load.html
https://www.openssl.org/docs/man1.1.1/man3/OSSL_STORE_INFO.html
https://www.openssl.org/docs/man1.1.1/man3/OSSL_STORE_SEARCH.html

Matt


On 28/03/18 16:02, Jordan Brown wrote:

> I'm finding that it would be helpful to have a function that would,
> given PEM data (in memory or in a file) return an indication of what
> kind of object it represents:  a certificate, a private key, et cetera. 
> The ideal function would basically tell me which PEM_read_bio_foobar
> function I would use to read the PEM data (and thus what C type it
> represents).  It would lump all private key formats into one type, since
> PEM_read_PrivateKey would work on all of them and return an EVP_PKEY.
>
> Does such a function already exist?  Any thoughts?
>
> --
> Jordan Brown, Oracle Solaris
>
>
>
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: get type of PEM data

Richard Levitte - VMS Whacker-2
In reply to this post by JordanBrown
In message <[hidden email]> on Wed, 28 Mar 2018 08:02:37 -0700, Jordan Brown <[hidden email]> said:

openssl> I'm finding that it would be helpful to have a function that
openssl> would, given PEM data (in memory or in a file) return an
openssl> indication of what kind of object it represents: a
openssl> certificate, a private key, et cetera. The ideal function
openssl> would basically tell me which PEM_read_bio_foobar function I
openssl> would use to read the PEM data (and thus what C type it
openssl> represents). It would lump all private key formats into one
openssl> type, since PEM_read_PrivateKey would work on all of them and
openssl> return an EVP_PKEY.
openssl>
openssl> Does such a function already exist? Any thoughts?

PEM_read and PEM_read_bio should do what you want.  You need to
provide three buffers, |name|, |header| and |data|.  |name| will
contain the name from the -----BEGIN line, that string describes the
type of data you have in |data|.

I suggest you read the manual on these functions, there are a few
things you need to do to decode something that's encrypted, for
example.

Cheers,
Richard
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: get type of PEM data

JordanBrown
In reply to this post by Michael Wojcik
Thanks, all.

Michael:  Yeah, that was my fallback idea, but I really didn't want my application to have to know about every "---BEGIN" line for every type of private key.  (And similarly if there's more than one kind of certificate, but I don't think there is.)
Viktor, Richard:  PEM_read_bio certainly helps, avoids the chore associated with discarding leading noise, but as above I was hoping to not need to know about every type of private key.
Matt:  Indeed, looks very promising.  Now if only we were on 1.1.1 :-(.  I'm a little surprised that it doesn't read from a BIO.

So, net, there's stuff in 1.0.x that will help and stuff in 1.1.x that will likely do exactly what I need.  That answers my question, thanks!
-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: get type of PEM data

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Wed, 28 Mar 2018 17:10:40 -0700, Jordan Brown <[hidden email]> said:

openssl> Matt: Indeed, looks very promising. Now if only we were on
openssl> 1.1.1 :-(. I'm a little surprised that it doesn't read from a
openssl> BIO.

It's certainly possible to add such an API.  As a matter of fact, we
do have that internally, specifically for PEM files...  have a look in
1.1.1's crypto/include/internal/store_int.h.  That's not the initial
intention with the API, though...

Also, I can't quite shake the feeling that a BIO API would be a bit
shaky.  Internally, the file: scheme loader opens all files in binary
mode, as it's designed to detect if the file is a PEM file or raw DER,
so the question remains, if we would open up a BIO STORE API, what are
th expectations?  Will people open such files in binary mode at all
times?  Should that be a content type agnostic interface (i.e. should
it detect if the file is PEM or raw DER), or should there be separate
functions for PEM and raw DER content?

Please note that for each question, we're getting further and further
away from the idea of having an interface where the caller doesn't
need to know much more than how to indicate where to load stuff from,
to an API that almost becomes a 1:1 mapping of PEM and d2i functions.
When we've come that far, what have we gained?
But I dunno...  I'm ambivalent around these ideas, and considering
those internal functions I mentioned, we do have some kind of base set
up already, so it would probably not be that hard to open up that kind
of functionality to the public.  Perhaps as a side thing, like STORE
UTILS?

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: get type of PEM data

Jakob Bohm-7
On 29/03/2018 10:08, Richard Levitte wrote:

> In message <[hidden email]> on Wed, 28 Mar 2018 17:10:40 -0700, Jordan Brown <[hidden email]> said:
>
> openssl> Matt: Indeed, looks very promising. Now if only we were on
> openssl> 1.1.1 :-(. I'm a little surprised that it doesn't read from a
> openssl> BIO.
>
> It's certainly possible to add such an API.  As a matter of fact, we
> do have that internally, specifically for PEM files...  have a look in
> 1.1.1's crypto/include/internal/store_int.h.  That's not the initial
> intention with the API, though...
>
> Also, I can't quite shake the feeling that a BIO API would be a bit
> shaky.  Internally, the file: scheme loader opens all files in binary
> mode, as it's designed to detect if the file is a PEM file or raw DER,
> so the question remains, if we would open up a BIO STORE API, what are
> th expectations?  Will people open such files in binary mode at all
> times?  Should that be a content type agnostic interface (i.e. should
> it detect if the file is PEM or raw DER), or should there be separate
> functions for PEM and raw DER content?
>
> Please note that for each question, we're getting further and further
> away from the idea of having an interface where the caller doesn't
> need to know much more than how to indicate where to load stuff from,
> to an API that almost becomes a 1:1 mapping of PEM and d2i functions.
> When we've come that far, what have we gained?
> But I dunno...  I'm ambivalent around these ideas, and considering
> those internal functions I mentioned, we do have some kind of base set
> up already, so it would probably not be that hard to open up that kind
> of functionality to the public.  Perhaps as a side thing, like STORE
> UTILS?
>
In general, if there is an API that can load something from a file,
there should be a matching API that can load it from a BIO (in fact,
the file API could/should be a wrapper for the the BIO API).

Typical use would be for a program to set up a BIO type that loads
from something program specific, such as compiled-in "resources" or
a compressed format or a database or ..., and then proceed directly
without storing in temporary files and risking race conditions against
malicious outside manipulation.

For URL support, it would also make sense to allow the caller to
substitute their own URL/protocol library via the BIO interface if the
application already has its own library for that (as many, but not all,
network applications are likely to anyway).

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: get type of PEM data

JordanBrown
In reply to this post by Richard Levitte - VMS Whacker-2
On 3/29/2018 1:08 AM, Richard Levitte wrote:
In message [hidden email] on Wed, 28 Mar 2018 17:10:40 -0700, Jordan Brown [hidden email] said:

openssl> Matt: Indeed, looks very promising. Now if only we were on
openssl> 1.1.1 :-(. I'm a little surprised that it doesn't read from a
openssl> BIO.

It's certainly possible to add such an API.  As a matter of fact, we
do have that internally, specifically for PEM files...  have a look in
1.1.1's crypto/include/internal/store_int.h.  That's not the initial
intention with the API, though...

To be clear:  it doesn't bother me one way or the other.  It just seemed like the general design for "reading data from a stream" for OpenSSL is to read from a BIO, rather than directly providing "read from file", "read from memory buffer", et cetera.  I was surprised to see a new feature that didn't follow that pattern.  I *do* need "read from memory" for my application, but writing a temporary file would not be a problem.


Also, I can't quite shake the feeling that a BIO API would be a bit
shaky.  Internally, the file: scheme loader opens all files in binary
mode, as it's designed to detect if the file is a PEM file or raw DER,
so the question remains, if we would open up a BIO STORE API, what are
th expectations?  Will people open such files in binary mode at all
times?  Should that be a content type agnostic interface (i.e. should
it detect if the file is PEM or raw DER), or should there be separate
functions for PEM and raw DER content?

I would expect the behavior to be identical for a BIO interface and any other - which, I guess, would mean that the BIO would need to be in binary mode.

Please note that for each question, we're getting further and further
away from the idea of having an interface where the caller doesn't
need to know much more than how to indicate where to load stuff from,
to an API that almost becomes a 1:1 mapping of PEM and d2i functions.
When we've come that far, what have we gained?

Agreed that for this interface the caller shouldn't need to know what's being read.
-- 
Jordan Brown, Oracle Solaris

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

STORE (was: get type of PEM data)

Richard Levitte - VMS Whacker-2
In message <[hidden email]> on Fri, 30 Mar 2018 10:29:52 -0700, Jordan Brown <[hidden email]> said:

openssl> [re STORE design]
openssl> To be clear: it doesn't bother me one way or the other. It
openssl> just seemed like the general design for "reading data from a
openssl> stream" for OpenSSL is to read from a BIO, rather than
openssl> directly providing "read from file", "read from memory
openssl> buffer", et cetera. I was surprised to see a new feature that
openssl> didn't follow that pattern. I *do* need "read from memory"
openssl> for my application, but writing a temporary file would not be
openssl> a problem.

Well, thing is that the source of data might not be something that
lends itself well for a BIO interface...  For example certificates and
keys hidden by an HSM of some sort.  So the STORE is an abstraction of
any sort of storage for that kind of protected data, and to directly
translate it to usable objects, something that would be quite
difficult with the BIO API.

Cheers,
Richard

--
Richard Levitte         [hidden email]
OpenSSL Project         http://www.openssl.org/~levitte/
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users