SERIALIZER: New API for serialization of objects through providers#10394
SERIALIZER: New API for serialization of objects through providers#10394levitte wants to merge 59 commits intoopenssl:masterfrom
Conversation
levitte
changed the title
Backgroundwhen implementing key and domparam generation (#10289), I realised that we couldn't do much with the generated keys, apart from signing, verifying, that sort of thing. But no way whatsoever to save them. Some kind of solution was needed, and after a conversation with @mattcaswell, we came to the conclusion that the smoothest would be to provide serializers, and to allow the serializers to handle both provider side objects directly (they have to come from the same provider as the keymgmt that manages the key itself) as well as key data in OSSL_PARAM array form (which allows a serializer to handle anything it recognises coming from any other provider, as long as that provider allows export of said data). Why not an EVP API?Serializers may be extended some day to handle any type of data, such as X.509, which isn't an EVP layer object. Therefore, serializers need to be a higher level class. |
|
If anyone wonders, the mechanism this offers would allow us to extract the data from a key made in the FIPS provider module, and serialize it using serializers in the default provider. This is by design. |
levitte
changed the title
|
This is no longer WIP, so can take reviews |
|
I just realised that I do have DER serializers, but haven't hooked them in anywhere. So er, not as done as I thought... |
levitte
changed the title
|
(don't let that stop anyone from looking at what's already here, though) |
levitte
force-pushed
the
serialize-me
branch
from
376253b to
b83cbc3
Compare
levitte
changed the title
Reviewed-by: Matt Caswell <[email protected]> (Merged from #10394)
The BIO_vprintf() will allow the provider to print any text, given a BIO supplied by libcrypto. Additionally, we add a provider library with functions to collect all the currently supplied BIO upcalls, as well as wrappers around those upcalls. Reviewed-by: Matt Caswell <[email protected]> (Merged from #10394)
To support generic output of public keys wrapped in a X509_PUBKEY, additional PEM and i2d/d2i routines are added for that type. Reviewed-by: Matt Caswell <[email protected]> (Merged from #10394)
This also adds the missing accessor RSA_get0_pss_params(), so those parameters can be included in the PKCS#8 data structure without needing to know the inside of the RSA structure. Reviewed-by: Matt Caswell <[email protected]> (Merged from #10394)
Reviewed-by: Matt Caswell <[email protected]> (Merged from #10394)
Reviewed-by: Matt Caswell <[email protected]> (Merged from #10394)
This renames test/evp_fromdata_test.c to test/evp_pkey_provided_test.c, to encourage additional testing of provider made keys. Reviewed-by: Matt Caswell <[email protected]> (Merged from #10394)
Reviewed-by: Matt Caswell <[email protected]> (Merged from #10394)
The prototype checks shouldn't be performed on SYNOPSIS lines that aren't function prototypes. Reviewed-by: Matt Caswell <[email protected]> (Merged from #10394)
These are helper macros alongside the IMPLEMENT_ and DECLARE_ macros. Reviewed-by: Matt Caswell <[email protected]> (Merged from #10394)
|
Merged. 3d83c73 CORE: ossl_namemap_add_names(): new function to add multiple names |
6 participants
Serialization is needed to be able to take a provider object (such as
the provider side key data) and output it in PEM form, DER form, text
form (for display), and possibly other future forms (XML? JSON? JWK?)
The idea is that a serializer should be able to handle objects it has
intimate knowledge of, as well as object data in OSSL_PARAM form. The
latter will allow libcrypto to serialize some object with a different
provider than the one holding the data, if exporting of that data is
allowed and there is a serializer that can handle it.
We will provide serializers for the types of objects we know about,
which should be useful together with any other provider that provides
implementations of the same type of object.
Serializers are selected by method name and a couple of additional
properties:
used to tell what format the output should be in.
Possibilities could include "format=text",
"format=pem", "format=der", "format=pem-pkcs1"
(traditional), "format=der-pkcs1" (traditional)
used to tell exactly what type of data should be
output, for example "type=public" (the public part of
a key), "type=private" (the private part of a key),
"type=domainparams" (domain parameters).
Checklist