{ "name": "provider-object(7ssl)", "mode": "man", "parameter": "provider-object", "section": "7ssl", "url": "/phpMan.php/man/provider-object/7ssl/json", "generated": "2026-05-27T16:07:33Z", "synopsis": "#include \n#include ", "sections": [ { "name": "NAME", "level": 1, "content": "provider-object - A specification for a provider-native object abstraction\n", "subsections": [] }, { "name": "SYNOPSIS", "level": 1, "content": "#include \n#include \n", "subsections": [] }, { "name": "DESCRIPTION", "level": 1, "content": "The provider-native object abstraction is a set of OSSLPARAM(3) keys and values that can be\nused to pass provider-native objects to OpenSSL library code or between different provider\noperation implementations with the help of OpenSSL library code.\n\nThe intention is that certain provider-native operations can pass any sort of object that\nbelong with other operations, or with OpenSSL library code.\n\nAn object may be passed in the following manners:\n\n1. By value\n\nThis means that the object data is passed as an octet string or an UTF8 string, which can\nbe handled in diverse ways by other provided implementations. The encoding of the object\ndepends on the context it's used in; for example, OSSLDECODER(3) allows multiple\nencodings, depending on existing decoders. If central OpenSSL library functionality is\nto handle the data directly, it must be encoded in DER for all object types except for\nOSSLOBJECTNAME (see \"Parameter reference\" below), where it's assumed to a plain UTF8\nstring.\n\n2. By reference\n\nThis means that the object data isn't passed directly, an object reference is passed\ninstead. It's an octet string that only the correct provider understands correctly.\n\nObjects by value can be used by anything that handles DER encoded objects.\n\nObjects by reference need a higher level of cooperation from the implementation where the\nobject originated (let's call it X) and its target implementation (let's call it Y):\n\n1. An object loading function in the target implementation\n\nThe target implementation (Y) may have a function that can take an object reference.\nThis can only be used if the target implementation is from the same provider as the one\noriginating the object abstraction in question (X).\n\nThe exact target implementation to use is determined from the object type and possibly\nthe object data type. For example, when the OpenSSL library receives an object\nabstraction with the object type OSSLOBJECTPKEY, it will fetch a provider-keymgmt(7)\nusing the object data type as its key type (the second argument in EVPKEYMGMTfetch(3)).\n\n2. An object exporter in the originating implementation\n\nThe originating implementation (X) may have an exporter function. This exporter function\ncan be used to export the object in OSSLPARAM(3) form, that can then be imported by the\ntarget implementation's imported function.\n\nThis can be used when it's not possible to fetch the target implementation (Y) from the\nsame provider.\n", "subsections": [ { "name": "Parameter reference", "level": 2, "content": "A provider-native object abstraction is an OSSLPARAM(3) with a selection of the following\nparameters:\n\n\"data\" (OSSLOBJECTPARAMDATA) or \nThe object data passed by value.\n\n\"reference\" (OSSLOBJECTPARAMREFERENCE) \nThe object data passed by reference.\n\n\"type\" (OSSLOBJECTPARAMTYPE) \nThe object type, a number that may have any of the following values (all defined in\n):\n\nOSSLOBJECTNAME\nThe object data may only be passed by value, and should be a UTF8 string.\n\nThis is useful for provider-storemgmt(7) when a URI load results in new URIs.\n\nOSSLOBJECTPKEY\nThe object data is suitable as provider-native EVPPKEY key data. The object data\nmay be passed by value or passed by reference.\n\nOSSLOBJECTCERT\nThe object data is suitable as X509 data. The object data for this object type can\nonly be passed by value, and should be an octet string.\n\nSince there's no provider-native X.509 object, OpenSSL libraries that receive this\nobject abstraction are expected to convert the data to a X509 object with d2iX509().\n\nOSSLOBJECTCRL\nThe object data is suitable as X509CRL data. The object data can only be passed by\nvalue, and should be an octet string.\n\nSince there's no provider-native X.509 CRL object, OpenSSL libraries that receive\nthis object abstraction are expected to convert the data to a X509CRL object with\nd2iX509CRL().\n\n\"data-type\" (OSSLOBJECTPARAMDATATYPE) \nThe specific type of the object content. Legitimate values depend on the object type; if\nit is OSSLOBJECTPKEY, the data type is expected to be a key type suitable for fetching\na provider-keymgmt(7) that can handle the data.\n\n\"data-structure\" (OSSLOBJECTPARAMDATASTRUCTURE) \nThe outermost structure of the object content. Legitimate values depend on the object\ntype.\n\n\"desc\" (OSSLOBJECTPARAMDESC) \nA human readable text that describes extra details on the object.\n\nWhen a provider-native object abtraction is used, it must contain object data in at least one\nform (object data passed by value, i.e. the \"data\" item, or object data passed by reference,\ni.e. the \"reference\" item). Both may be present at once, in which case the OpenSSL library\ncode that receives this will use the most optimal variant.\n\nFor objects with the object type OSSLOBJECTNAME, that object type must be given.\n" }, { "name": "SEE ALSO", "level": 2, "content": "provider(7), OSSLDECODER(3)\n" } ] }, { "name": "HISTORY", "level": 1, "content": "The concept of providers and everything surrounding them was introduced in OpenSSL 3.0.\n", "subsections": [] }, { "name": "COPYRIGHT", "level": 1, "content": "Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved.\n\nLicensed under the Apache License 2.0 (the \"License\"). You may not use this file except in\ncompliance with the License. You can obtain a copy in the file LICENSE in the source\ndistribution or at .\n\n\n\n3.0.2 2026-04-07 PROVIDER-OBJECT(7SSL)", "subsections": [] } ] }