# provider-object(7ssl) - man - phpMan [PROVIDER-OBJECT(7SSL)] OpenSSL [PROVIDER-OBJECT(7SSL)] ## NAME provider-object - A specification for a provider-native object abstraction ## SYNOPSIS #include #include ## DESCRIPTION The provider-native object abstraction is a set of **OSSL**___**[PARAM**(3)] keys and values that can be used to pass provider-native objects to OpenSSL library code or between different provider operation implementations with the help of OpenSSL library code. The intention is that certain provider-native operations can pass any sort of object that belong with other operations, or with OpenSSL library code. An object may be passed in the following manners: 1. _By_ _value_ This means that the _object_ _data_ is passed as an octet string or an UTF8 string, which can be handled in diverse ways by other provided implementations. The encoding of the object depends on the context it's used in; for example, **OSSL**___**[DECODER**(3)] allows multiple encodings, depending on existing decoders. If central OpenSSL library functionality is to handle the data directly, it **must** be encoded in DER for all object types except for **OSSL**___**OBJECT**___**NAME** (see "Parameter reference" below), where it's assumed to a plain UTF8 string. 2. _By_ _reference_ This means that the _object_ _data_ isn't passed directly, an _object_ _reference_ is passed instead. It's an octet string that only the correct provider understands correctly. Objects _by_ _value_ can be used by anything that handles DER encoded objects. Objects _by_ _reference_ need a higher level of cooperation from the implementation where the object originated (let's call it X) and its target implementation (let's call it Y): 1. _An_ _object_ _loading_ _function_ _in_ _the_ _target_ _implementation_ The target implementation (Y) may have a function that can take an _object_ _reference_. This can only be used if the target implementation is from the same provider as the one originating the object abstraction in question (X). The exact target implementation to use is determined from the _object_ _type_ and possibly the _object_ _data_ _type_. For example, when the OpenSSL library receives an object abstraction with the _object_ _type_ **OSSL**___**OBJECT**___**PKEY**, it will fetch a [**provider-keymgmt**(7)] using the _object_ _data_ _type_ as its key type (the second argument in **EVP**___**KEYMGMT**___**[fetch**(3)]). 2. _An_ _object_ _exporter_ _in_ _the_ _originating_ _implementation_ The originating implementation (X) may have an exporter function. This exporter function can be used to export the object in **OSSL**___**[PARAM**(3)] form, that can then be imported by the target implementation's imported function. This can be used when it's not possible to fetch the target implementation (Y) from the same provider. ### Parameter reference A provider-native object abstraction is an **OSSL**___**[PARAM**(3)] with a selection of the following parameters: "data" (**OSSL**___**OBJECT**___**PARAM**___**DATA**) or The object data _passed_ _by_ _value_. "reference" (**OSSL**___**OBJECT**___**PARAM**___**REFERENCE**) The object data _passed_ _by_ _reference_. "type" (**OSSL**___**OBJECT**___**PARAM**___**TYPE**) The _object_ _type_, a number that may have any of the following values (all defined in __): **OSSL**___**OBJECT**___**NAME** The object data may only be _passed_ _by_ _value_, and should be a UTF8 string. This is useful for [**provider-storemgmt**(7)] when a URI load results in new URIs. **OSSL**___**OBJECT**___**PKEY** The object data is suitable as provider-native **EVP**___**PKEY** key data. The object data may be _passed_ _by_ _value_ or _passed_ _by_ _reference_. **OSSL**___**OBJECT**___**CERT** The object data is suitable as **X509** data. The object data for this object type can only be _passed_ _by_ _value_, and should be an octet string. Since there's no provider-native X.509 object, OpenSSL libraries that receive this object abstraction are expected to convert the data to a **X509** object with **d2i**___**X509()**. **OSSL**___**OBJECT**___**CRL** The object data is suitable as **X509**___**CRL** data. The object data can only be _passed_ _by_ _value_, and should be an octet string. Since there's no provider-native X.509 CRL object, OpenSSL libraries that receive this object abstraction are expected to convert the data to a **X509**___**CRL** object with **d2i**___**X509**___**CRL()**. "data-type" (**OSSL**___**OBJECT**___**PARAM**___**DATA**___**TYPE**) The specific type of the object content. Legitimate values depend on the object type; if it is **OSSL**___**OBJECT**___**PKEY**, the data type is expected to be a key type suitable for fetching a [**provider-keymgmt**(7)] that can handle the data. "data-structure" (**OSSL**___**OBJECT**___**PARAM**___**DATA**___**STRUCTURE**) The outermost structure of the object content. Legitimate values depend on the object type. "desc" (**OSSL**___**OBJECT**___**PARAM**___**DESC**) A human readable text that describes extra details on the object. When a provider-native object abtraction is used, it _must_ contain object data in at least one form (object data _passed_ _by_ _value_, i.e. the "data" item, or object data _passed_ _by_ _reference_, i.e. the "reference" item). Both may be present at once, in which case the OpenSSL library code that receives this will use the most optimal variant. For objects with the object type **OSSL**___**OBJECT**___**NAME**, that object type _must_ be given. ### SEE ALSO [**provider**(7)], **OSSL**___**[DECODER**(3)] ## HISTORY The concept of providers and everything surrounding them was introduced in OpenSSL 3.0. ## COPYRIGHT Copyright 2020-2021 The OpenSSL Project Authors. All Rights Reserved. Licensed under the Apache License 2.0 (the "License"). You may not use this file except in compliance with the License. You can obtain a copy in the file LICENSE in the source distribution or at <>. 3.0.2 2026-04-07 [PROVIDER-OBJECT(7SSL)]