1OSSL_PARAM(3ossl)                   OpenSSL                  OSSL_PARAM(3ossl)
2
3
4

NAME

6       OSSL_PARAM - a structure to pass or request object parameters
7

SYNOPSIS

9        #include <openssl/core.h>
10
11        typedef struct ossl_param_st OSSL_PARAM;
12        struct ossl_param_st {
13            const char *key;             /* the name of the parameter */
14            unsigned char data_type;     /* declare what kind of content is in data */
15            void *data;                  /* value being passed in or out */
16            size_t data_size;            /* data size */
17            size_t return_size;          /* returned size */
18        };
19

DESCRIPTION

21       OSSL_PARAM is a type that allows passing arbitrary data for some object
22       between two parties that have no or very little shared knowledge about
23       their respective internal structures for that object.
24
25       A typical usage example could be an application that wants to set some
26       parameters for an object, or wants to find out some parameters of an
27       object.
28
29       Arrays of this type can be used for the following purposes:
30
31       •   Setting parameters for some object
32
33           The caller sets up the OSSL_PARAM array and calls some function
34           (the setter) that has intimate knowledge about the object that can
35           take the data from the OSSL_PARAM array and assign them in a
36           suitable form for the internal structure of the object.
37
38       •   Request parameters of some object
39
40           The caller (the requester) sets up the OSSL_PARAM array and calls
41           some function (the responder) that has intimate knowledge about the
42           object, which can take the internal data of the object and copy
43           (possibly convert) that to the memory prepared by the requester and
44           pointed at with the OSSL_PARAM data.
45
46       •   Request parameter descriptors
47
48           The caller gets an array of constant OSSL_PARAM, which describe
49           available parameters and some of their properties; name, data type
50           and expected data size.  For a detailed description of each field
51           for this use, see the field descriptions below.
52
53           The caller may then use the information from this descriptor array
54           to build up its own OSSL_PARAM array to pass down to a setter or
55           responder.
56
57       Normally, the order of the an OSSL_PARAM array is not relevant.
58       However, if the responder can handle multiple elements with the same
59       key, those elements must be handled in the order they are in.
60
61       An OSSL_PARAM array must have a terminating element, where key is NULL.
62       The usual full terminating template is:
63
64           { NULL, 0, NULL, 0, 0 }
65
66       This can also be specified using OSSL_PARAM_END(3).
67
68   Functional support
69       Libcrypto offers a limited set of helper functions to handle OSSL_PARAM
70       items and arrays, please see OSSL_PARAM_get_int(3).  Developers are
71       free to extend or replace those as they see fit.
72
73   OSSL_PARAM fields
74       key The identity of the parameter in the form of a string.
75
76           In an OSSL_PARAM array, an item with this field set to NULL is
77           considered a terminating item.
78
79       data_type
80           The data_type is a value that describes the type and organization
81           of the data.  See "Supported types" below for a description of the
82           types.
83
84       data
85       data_size
86           data is a pointer to the memory where the parameter data is (when
87           setting parameters) or shall (when requesting parameters) be
88           stored, and data_size is its size in bytes.  The organization of
89           the data depends on the parameter type and flag.
90
91           The data_size needs special attention with the parameter type
92           OSSL_PARAM_UTF8_STRING in relation to C strings.  When setting
93           parameters, the size should be set to the length of the string, not
94           counting the terminating NUL byte.  When requesting parameters, the
95           size should be set to the size of the buffer to be populated, which
96           should accommodate enough space for a terminating NUL byte.
97
98           When requesting parameters, it's acceptable for data to be NULL.
99           This can be used by the requester to figure out dynamically exactly
100           how much buffer space is needed to store the parameter data.  In
101           this case, data_size is ignored.
102
103           When the OSSL_PARAM is used as a parameter descriptor, data should
104           be ignored.  If data_size is zero, it means that an arbitrary data
105           size is accepted, otherwise it specifies the maximum size allowed.
106
107       return_size
108           When an array of OSSL_PARAM is used to request data, the responder
109           must set this field to indicate size of the parameter data,
110           including padding as the case may be.  In case the data_size is an
111           unsuitable size for the data, the responder must still set this
112           field to indicate the minimum data size required.  (further notes
113           on this in "NOTES" below).
114
115           When the OSSL_PARAM is used as a parameter descriptor, return_size
116           should be ignored.
117
118       NOTE:
119
120       The key names and associated types are defined by the entity that
121       offers these parameters, i.e. names for parameters provided by the
122       OpenSSL libraries are defined by the libraries, and names for
123       parameters provided by providers are defined by those providers, except
124       for the pointer form of strings (see data type descriptions below).
125       Entities that want to set or request parameters need to know what those
126       keys are and of what type, any functionality between those two entities
127       should remain oblivious and just pass the OSSL_PARAM array along.
128
129   Supported types
130       The data_type field can be one of the following types:
131
132       OSSL_PARAM_INTEGER
133       OSSL_PARAM_UNSIGNED_INTEGER
134           The parameter data is an integer (signed or unsigned) of arbitrary
135           length, organized in native form, i.e. most significant byte first
136           on Big-Endian systems, and least significant byte first on Little-
137           Endian systems.
138
139       OSSL_PARAM_REAL
140           The parameter data is a floating point value in native form.
141
142       OSSL_PARAM_UTF8_STRING
143           The parameter data is a printable string.
144
145       OSSL_PARAM_OCTET_STRING
146           The parameter data is an arbitrary string of bytes.
147
148       OSSL_PARAM_UTF8_PTR
149           The parameter data is a pointer to a printable string.
150
151           The difference between this and OSSL_PARAM_UTF8_STRING is that data
152           doesn't point directly at the data, but to a pointer that points to
153           the data.
154
155           If there is any uncertainty about which to use,
156           OSSL_PARAM_UTF8_STRING is almost certainly the correct choice.
157
158           This is used to indicate that constant data is or will be passed,
159           and there is therefore no need to copy the data that is passed,
160           just the pointer to it.
161
162           data_size must be set to the size of the data, not the size of the
163           pointer to the data.  If this is used in a parameter request,
164           data_size is not relevant.  However, the responder will set
165           return_size to the size of the data.
166
167           Note that the use of this type is fragile and can only be safely
168           used for data that remains constant and in a constant location for
169           a long enough duration (such as the life-time of the entity that
170           offers these parameters).
171
172       OSSL_PARAM_OCTET_PTR
173           The parameter data is a pointer to an arbitrary string of bytes.
174
175           The difference between this and OSSL_PARAM_OCTET_STRING is that
176           data doesn't point directly at the data, but to a pointer that
177           points to the data.
178
179           If there is any uncertainty about which to use,
180           OSSL_PARAM_OCTET_STRING is almost certainly the correct choice.
181
182           This is used to indicate that constant data is or will be passed,
183           and there is therefore no need to copy the data that is passed,
184           just the pointer to it.
185
186           data_size must be set to the size of the data, not the size of the
187           pointer to the data.  If this is used in a parameter request,
188           data_size is not relevant.  However, the responder will set
189           return_size to the size of the data.
190
191           Note that the use of this type is fragile and can only be safely
192           used for data that remains constant and in a constant location for
193           a long enough duration (such as the life-time of the entity that
194           offers these parameters).
195

NOTES

197       Both when setting and requesting parameters, the functions that are
198       called will have to decide what is and what is not an error.  The
199       recommended behaviour is:
200
201       •   Keys that a setter or responder doesn't recognise should simply be
202           ignored.  That in itself isn't an error.
203
204       •   If the keys that a called setter recognises form a consistent
205           enough set of data, that call should succeed.
206
207       •   Apart from the return_size, a responder must never change the
208           fields of an OSSL_PARAM.  To return a value, it should change the
209           contents of the memory that data points at.
210
211       •   If the data type for a key that it's associated with is incorrect,
212           the called function may return an error.
213
214           The called function may also try to convert the data to a suitable
215           form (for example, it's plausible to pass a large number as an
216           octet string, so even though a given key is defined as an
217           OSSL_PARAM_UNSIGNED_INTEGER, is plausible to pass the value as an
218           OSSL_PARAM_OCTET_STRING), but this is in no way mandatory.
219
220       •   If data for a OSSL_PARAM_OCTET_STRING or a OSSL_PARAM_UTF8_STRING
221           is NULL, the responder should set return_size to the size of the
222           item to be returned and return success. Later the responder will be
223           called again with data pointing at the place for the value to be
224           put.
225
226       •   If a responder finds that some data sizes are too small for the
227           requested data, it must set return_size for each such OSSL_PARAM
228           item to the minimum required size, and eventually return an error.
229
230       •   For the integer type parameters (OSSL_PARAM_UNSIGNED_INTEGER and
231           OSSL_PARAM_INTEGER), a responder may choose to return an error if
232           the data_size isn't a suitable size (even if data_size is bigger
233           than needed).  If the responder finds the size suitable, it must
234           fill all data_size bytes and ensure correct padding for the native
235           endianness, and set return_size to the same value as data_size.
236

EXAMPLES

238       A couple of examples to just show how OSSL_PARAM arrays could be set
239       up.
240
241       Example 1
242
243       This example is for setting parameters on some object:
244
245           #include <openssl/core.h>
246
247           const char *foo = "some string";
248           size_t foo_l = strlen(foo);
249           const char bar[] = "some other string";
250           OSSL_PARAM set[] = {
251               { "foo", OSSL_PARAM_UTF8_PTR, &foo, foo_l, 0 },
252               { "bar", OSSL_PARAM_UTF8_STRING, (void *)&bar, sizeof(bar) - 1, 0 },
253               { NULL, 0, NULL, 0, 0 }
254           };
255
256       Example 2
257
258       This example is for requesting parameters on some object:
259
260           const char *foo = NULL;
261           size_t foo_l;
262           char bar[1024];
263           size_t bar_l;
264           OSSL_PARAM request[] = {
265               { "foo", OSSL_PARAM_UTF8_PTR, &foo, 0 /*irrelevant*/, 0 },
266               { "bar", OSSL_PARAM_UTF8_STRING, &bar, sizeof(bar), 0 },
267               { NULL, 0, NULL, 0, 0 }
268           };
269
270       A responder that receives this array (as params in this example) could
271       fill in the parameters like this:
272
273           /* OSSL_PARAM *params */
274
275           int i;
276
277           for (i = 0; params[i].key != NULL; i++) {
278               if (strcmp(params[i].key, "foo") == 0) {
279                   *(char **)params[i].data = "foo value";
280                   params[i].return_size = 9; /* length of "foo value" string */
281               } else if (strcmp(params[i].key, "bar") == 0) {
282                   memcpy(params[i].data, "bar value", 10);
283                   params[i].return_size = 9; /* length of "bar value" string */
284               }
285               /* Ignore stuff we don't know */
286           }
287

SEE ALSO

289       openssl-core.h(7), OSSL_PARAM_get_int(3), OSSL_PARAM_dup(3)
290

HISTORY

292       OSSL_PARAM was added in OpenSSL 3.0.
293
295       Copyright 2019-2023 The OpenSSL Project Authors. All Rights Reserved.
296
297       Licensed under the Apache License 2.0 (the "License").  You may not use
298       this file except in compliance with the License.  You can obtain a copy
299       in the file LICENSE in the source distribution or at
300       <https://www.openssl.org/source/license.html>.
301
302
303
3043.1.1                             2023-08-31                 OSSL_PARAM(3ossl)
Impressum