1OSSL_PARAM(3ossl) OpenSSL OSSL_PARAM(3ossl)
2
6 OSSL_PARAM - a structure to pass or request object parameters
7
9 #include <openssl/core.h>
10 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
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 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 Arrays of this type can be used for the following purposes:
30 • Setting parameters for some object
32 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 • Request parameters of some object
39 The caller (the requestor) 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 requestor and
44 pointed at with the OSSL_PARAM data.
45 • Request parameter descriptors
47 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 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 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 An OSSL_PARAM array must have a terminating element, where key is NULL.
62 The usual full terminating template is:
63 { NULL, 0, NULL, 0, 0 }
65 This can also be specified using OSSL_PARAM_END(3).
67 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 OSSL_PARAM fields
74 key The identity of the parameter in the form of a string.
75 In an OSSL_PARAM array, an item with this field set to NULL is
77 considered a terminating item.
78 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 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 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 accomodate enough space for a terminating NUL byte.
97 When requesting parameters, it's acceptable for data to be NULL.
99 This can be used by the requestor 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 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 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 When the OSSL_PARAM is used as a parameter descriptor, return_size
116 should be ignored.
117 NOTE:
119 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 Supported types
130 The data_type field can be one of the following types:
131 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 OSSL_PARAM_REAL
140 The parameter data is a floating point value in native form.
141 OSSL_PARAM_UTF8_STRING
143 The parameter data is a printable string.
144 OSSL_PARAM_OCTET_STRING
146 The parameter data is an arbitrary string of bytes.
147 OSSL_PARAM_UTF8_PTR
149 The parameter data is a pointer to a printable string.
150 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 If there is any uncertainty about which to use,
156 OSSL_PARAM_UTF8_STRING is almost certainly the correct choice.
157 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 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 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 OSSL_PARAM_OCTET_PTR
173 The parameter data is a pointer to an arbitrary string of bytes.
174 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 If there is any uncertainty about which to use,
180 OSSL_PARAM_OCTET_STRING is almost certainly the correct choice.
181 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 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 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
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 • Keys that a setter or responder doesn't recognise should simply be
202 ignored. That in itself isn't an error.
203 • If the keys that a called setter recognises form a consistent
205 enough set of data, that call should succeed.
206 • 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 • If the data type for a key that it's associated with is incorrect,
212 the called function may return an error.
213 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 • If a responder finds that some data sizes are too small for the
221 requested data, it must set return_size for each such OSSL_PARAM
222 item to the minimum required size, and eventually return an error.
223 • For the integer type parameters (OSSL_PARAM_UNSIGNED_INTEGER and
225 OSSL_PARAM_INTEGER), a responder may choose to return an error if
226 the data_size isn't a suitable size (even if data_size is bigger
227 than needed). If the responder finds the size suitable, it must
228 fill all data_size bytes and ensure correct padding for the native
229 endianness, and set return_size to the same value as data_size.
230
232 A couple of examples to just show how OSSL_PARAM arrays could be set
233 up.
234 Example 1
236 This example is for setting parameters on some object:
238 #include <openssl/core.h>
240 const char *foo = "some string";
242 size_t foo_l = strlen(foo);
243 const char bar[] = "some other string";
244 OSSL_PARAM set[] = {
245 { "foo", OSSL_PARAM_UTF8_PTR, &foo, foo_l, 0 },
246 { "bar", OSSL_PARAM_UTF8_STRING, (void *)&bar, sizeof(bar) - 1, 0 },
247 { NULL, 0, NULL, 0, 0 }
248 };
249 Example 2
251 This example is for requesting parameters on some object:
253 const char *foo = NULL;
255 size_t foo_l;
256 char bar[1024];
257 size_t bar_l;
258 OSSL_PARAM request[] = {
259 { "foo", OSSL_PARAM_UTF8_PTR, &foo, 0 /*irrelevant*/, 0 },
260 { "bar", OSSL_PARAM_UTF8_STRING, &bar, sizeof(bar), 0 },
261 { NULL, 0, NULL, 0, 0 }
262 };
263 A responder that receives this array (as params in this example) could
265 fill in the parameters like this:
266 /* OSSL_PARAM *params */
268 int i;
270 for (i = 0; params[i].key != NULL; i++) {
272 if (strcmp(params[i].key, "foo") == 0) {
273 *(char **)params[i].data = "foo value";
274 params[i].return_size = 9; /* length of "foo value" string */
275 } else if (strcmp(params[i].key, "bar") == 0) {
276 memcpy(params[i].data, "bar value", 10);
277 params[i].return_size = 9; /* length of "bar value" string */
278 }
279 /* Ignore stuff we don't know */
280 }
281
283 openssl-core.h(7), OSSL_PARAM_get_int(3), OSSL_PARAM_dup(3)
284
286 OSSL_PARAM was added in OpenSSL 3.0.
287
289 Copyright 2019-2022 The OpenSSL Project Authors. All Rights Reserved.
290 Licensed under the Apache License 2.0 (the "License"). You may not use
292 this file except in compliance with the License. You can obtain a copy
293 in the file LICENSE in the source distribution or at
294 <https://www.openssl.org/source/license.html>.
2953.0.5 2022-11-01 OSSL_PARAM(3ossl)