1 | =pod
|
---|
2 |
|
---|
3 | =head1 NAME
|
---|
4 |
|
---|
5 | provider-encoder - The OSSL_ENCODER library E<lt>-E<gt> provider functions
|
---|
6 |
|
---|
7 | =head1 SYNOPSIS
|
---|
8 |
|
---|
9 | #include <openssl/core_dispatch.h>
|
---|
10 |
|
---|
11 | /*
|
---|
12 | * None of these are actual functions, but are displayed like this for
|
---|
13 | * the function signatures for functions that are offered as function
|
---|
14 | * pointers in OSSL_DISPATCH arrays.
|
---|
15 | */
|
---|
16 |
|
---|
17 | /* Encoder parameter accessor and descriptor */
|
---|
18 | const OSSL_PARAM *OSSL_FUNC_encoder_gettable_params(void *provctx);
|
---|
19 | int OSSL_FUNC_encoder_get_params(OSSL_PARAM params[]);
|
---|
20 |
|
---|
21 | /* Functions to construct / destruct / manipulate the encoder context */
|
---|
22 | void *OSSL_FUNC_encoder_newctx(void *provctx);
|
---|
23 | void OSSL_FUNC_encoder_freectx(void *ctx);
|
---|
24 | int OSSL_FUNC_encoder_set_ctx_params(void *ctx, const OSSL_PARAM params[]);
|
---|
25 | const OSSL_PARAM *OSSL_FUNC_encoder_settable_ctx_params(void *provctx);
|
---|
26 |
|
---|
27 | /* Functions to check selection support */
|
---|
28 | int OSSL_FUNC_encoder_does_selection(void *provctx, int selection);
|
---|
29 |
|
---|
30 | /* Functions to encode object data */
|
---|
31 | int OSSL_FUNC_encoder_encode(void *ctx, OSSL_CORE_BIO *out,
|
---|
32 | const void *obj_raw,
|
---|
33 | const OSSL_PARAM obj_abstract[],
|
---|
34 | int selection,
|
---|
35 | OSSL_PASSPHRASE_CALLBACK *cb,
|
---|
36 | void *cbarg);
|
---|
37 |
|
---|
38 | /* Functions to import and free a temporary object to be encoded */
|
---|
39 | void *OSSL_FUNC_encoder_import_object(void *ctx, int selection,
|
---|
40 | const OSSL_PARAM params[]);
|
---|
41 | void OSSL_FUNC_encoder_free_object(void *obj);
|
---|
42 |
|
---|
43 |
|
---|
44 | =head1 DESCRIPTION
|
---|
45 |
|
---|
46 | I<We use the wide term "encode" in this manual. This includes but is
|
---|
47 | not limited to serialization.>
|
---|
48 |
|
---|
49 | The ENCODER operation is a generic method to encode a provider-native
|
---|
50 | object (I<obj_raw>) or an object abstraction (I<object_abstract>, see
|
---|
51 | L<provider-object(7)>) into an encoded form, and write the result to
|
---|
52 | the given OSSL_CORE_BIO. If the caller wants to get the encoded
|
---|
53 | stream to memory, it should provide a L<BIO_s_mem(3)> B<BIO>.
|
---|
54 |
|
---|
55 | The encoder doesn't need to know more about the B<OSSL_CORE_BIO>
|
---|
56 | pointer than being able to pass it to the appropriate BIO upcalls (see
|
---|
57 | L<provider-base(7)/Core functions>).
|
---|
58 |
|
---|
59 | The ENCODER implementation may be part of a chain, where data is
|
---|
60 | passed from one to the next. For example, there may be an
|
---|
61 | implementation to encode an object to DER (that object is assumed to
|
---|
62 | be provider-native and thereby passed via I<obj_raw>), and another one
|
---|
63 | that encodes DER to PEM (that one would receive the DER encoding via
|
---|
64 | I<obj_abstract>).
|
---|
65 |
|
---|
66 | =begin comment
|
---|
67 |
|
---|
68 | Having the DER encoding passed via I<obj_abstract> may seem
|
---|
69 | complicated. However, there may be associated meta-data, such as the
|
---|
70 | original data type, that need to be passed alongside it, and since
|
---|
71 | L<provider-object(7)> already defines a way to pass such data,
|
---|
72 | inventing another way to do it makes things even more complicated.
|
---|
73 |
|
---|
74 | =end comment
|
---|
75 |
|
---|
76 | The encoding using the L<OSSL_PARAM(3)> array form allows a
|
---|
77 | encoder to be used for data that's been exported from another
|
---|
78 | provider, and thereby allow them to exist independently of each
|
---|
79 | other.
|
---|
80 |
|
---|
81 | The encoding using a provider side object can only be safely used
|
---|
82 | with provider data coming from the same provider, for example keys
|
---|
83 | with the L<KEYMGMT|provider-keymgmt(7)> provider.
|
---|
84 |
|
---|
85 | All "functions" mentioned here are passed as function pointers between
|
---|
86 | F<libcrypto> and the provider in L<OSSL_DISPATCH(3)> arrays via
|
---|
87 | L<OSSL_ALGORITHM(3)> arrays that are returned by the provider's
|
---|
88 | provider_query_operation() function
|
---|
89 | (see L<provider-base(7)/Provider Functions>).
|
---|
90 |
|
---|
91 | All these "functions" have a corresponding function type definition
|
---|
92 | named B<OSSL_FUNC_{name}_fn>, and a helper function to retrieve the
|
---|
93 | function pointer from an L<OSSL_DISPATCH(3)> element named
|
---|
94 | B<OSSL_FUNC_{name}>.
|
---|
95 | For example, the "function" OSSL_FUNC_encoder_encode() has these:
|
---|
96 |
|
---|
97 | typedef int
|
---|
98 | (OSSL_FUNC_encoder_encode_fn)(void *ctx, OSSL_CORE_BIO *out,
|
---|
99 | const void *obj_raw,
|
---|
100 | const OSSL_PARAM obj_abstract[],
|
---|
101 | int selection,
|
---|
102 | OSSL_PASSPHRASE_CALLBACK *cb, void *cbarg);
|
---|
103 | static ossl_inline OSSL_FUNC_encoder_encode_fn
|
---|
104 | OSSL_FUNC_encoder_encode(const OSSL_DISPATCH *opf);
|
---|
105 |
|
---|
106 | L<OSSL_DISPATCH(3)> arrays are indexed by numbers that are provided as
|
---|
107 | macros in L<openssl-core_dispatch.h(7)>, as follows:
|
---|
108 |
|
---|
109 | OSSL_FUNC_encoder_get_params OSSL_FUNC_ENCODER_GET_PARAMS
|
---|
110 | OSSL_FUNC_encoder_gettable_params OSSL_FUNC_ENCODER_GETTABLE_PARAMS
|
---|
111 |
|
---|
112 | OSSL_FUNC_encoder_newctx OSSL_FUNC_ENCODER_NEWCTX
|
---|
113 | OSSL_FUNC_encoder_freectx OSSL_FUNC_ENCODER_FREECTX
|
---|
114 | OSSL_FUNC_encoder_set_ctx_params OSSL_FUNC_ENCODER_SET_CTX_PARAMS
|
---|
115 | OSSL_FUNC_encoder_settable_ctx_params OSSL_FUNC_ENCODER_SETTABLE_CTX_PARAMS
|
---|
116 |
|
---|
117 | OSSL_FUNC_encoder_does_selection OSSL_FUNC_ENCODER_DOES_SELECTION
|
---|
118 |
|
---|
119 | OSSL_FUNC_encoder_encode OSSL_FUNC_ENCODER_ENCODE
|
---|
120 |
|
---|
121 | OSSL_FUNC_encoder_import_object OSSL_FUNC_ENCODER_IMPORT_OBJECT
|
---|
122 | OSSL_FUNC_encoder_free_object OSSL_FUNC_ENCODER_FREE_OBJECT
|
---|
123 |
|
---|
124 | =head2 Names and properties
|
---|
125 |
|
---|
126 | The name of an implementation should match the type of object it handles.
|
---|
127 | For example, an implementation that encodes an RSA key should be named "RSA".
|
---|
128 | Likewise, an implementation that further encodes DER should be named "DER".
|
---|
129 |
|
---|
130 | Properties can be used to further specify details about an implementation:
|
---|
131 |
|
---|
132 | =over 4
|
---|
133 |
|
---|
134 | =item output
|
---|
135 |
|
---|
136 | This property is used to specify what type of output the implementation
|
---|
137 | produces.
|
---|
138 |
|
---|
139 | This property is I<mandatory>.
|
---|
140 |
|
---|
141 | OpenSSL providers recognize the following output types:
|
---|
142 |
|
---|
143 | =over 4
|
---|
144 |
|
---|
145 | =item text
|
---|
146 |
|
---|
147 | An implementation with that output type outputs human readable text, making
|
---|
148 | that implementation suitable for C<-text> output in diverse L<openssl(1)>
|
---|
149 | commands.
|
---|
150 |
|
---|
151 | =item pem
|
---|
152 |
|
---|
153 | An implementation with that output type outputs PEM formatted data.
|
---|
154 |
|
---|
155 | =item der
|
---|
156 |
|
---|
157 | An implementation with that output type outputs DER formatted data.
|
---|
158 |
|
---|
159 | =item msblob
|
---|
160 |
|
---|
161 | An implementation with that output type outputs MSBLOB formatted data.
|
---|
162 |
|
---|
163 | =item pvk
|
---|
164 |
|
---|
165 | An implementation with that output type outputs PVK formatted data.
|
---|
166 |
|
---|
167 | =back
|
---|
168 |
|
---|
169 | =item structure
|
---|
170 |
|
---|
171 | This property is used to specify the structure that is used for the encoded
|
---|
172 | object. An example could be C<pkcs8>, to specify explicitly that an object
|
---|
173 | (presumably an asymmetric key pair, in this case) will be wrapped in a
|
---|
174 | PKCS#8 structure as part of the encoding.
|
---|
175 |
|
---|
176 | This property is I<optional>.
|
---|
177 |
|
---|
178 | =back
|
---|
179 |
|
---|
180 | The possible values of both these properties is open ended. A provider may
|
---|
181 | very well specify output types and structures that libcrypto doesn't know
|
---|
182 | anything about.
|
---|
183 |
|
---|
184 | =head2 Subset selections
|
---|
185 |
|
---|
186 | Sometimes, an object has more than one subset of data that is interesting to
|
---|
187 | treat separately or together. It's possible to specify what subsets are to
|
---|
188 | be encoded, with a set of bits I<selection> that are passed in an B<int>.
|
---|
189 |
|
---|
190 | This set of bits depend entirely on what kind of provider-side object is
|
---|
191 | passed. For example, those bits are assumed to be the same as those used
|
---|
192 | with L<provider-keymgmt(7)> (see L<provider-keymgmt(7)/Key Objects>) when
|
---|
193 | the object is an asymmetric keypair.
|
---|
194 |
|
---|
195 | ENCODER implementations are free to regard the I<selection> as a set of
|
---|
196 | hints, but must do so with care. In the end, the output must make sense,
|
---|
197 | and if there's a corresponding decoder, the resulting decoded object must
|
---|
198 | match the original object that was encoded.
|
---|
199 |
|
---|
200 | OSSL_FUNC_encoder_does_selection() should tell if a particular implementation
|
---|
201 | supports any of the combinations given by I<selection>.
|
---|
202 |
|
---|
203 | =head2 Context functions
|
---|
204 |
|
---|
205 | OSSL_FUNC_encoder_newctx() returns a context to be used with the rest of
|
---|
206 | the functions.
|
---|
207 |
|
---|
208 | OSSL_FUNC_encoder_freectx() frees the given I<ctx>, if it was created by
|
---|
209 | OSSL_FUNC_encoder_newctx().
|
---|
210 |
|
---|
211 | OSSL_FUNC_encoder_set_ctx_params() sets context data according to parameters
|
---|
212 | from I<params> that it recognises. Unrecognised parameters should be
|
---|
213 | ignored.
|
---|
214 | Passing NULL for I<params> should return true.
|
---|
215 |
|
---|
216 | OSSL_FUNC_encoder_settable_ctx_params() returns a constant L<OSSL_PARAM(3)>
|
---|
217 | array describing the parameters that OSSL_FUNC_encoder_set_ctx_params()
|
---|
218 | can handle.
|
---|
219 |
|
---|
220 | See L<OSSL_PARAM(3)> for further details on the parameters structure used by
|
---|
221 | OSSL_FUNC_encoder_set_ctx_params() and OSSL_FUNC_encoder_settable_ctx_params().
|
---|
222 |
|
---|
223 | =head2 Import functions
|
---|
224 |
|
---|
225 | A provider-native object may be associated with a foreign provider, and may
|
---|
226 | therefore be unsuitable for direct use with a given ENCODER implementation.
|
---|
227 | Provided that the foreign provider's implementation to handle the object has
|
---|
228 | a function to export that object in L<OSSL_PARAM(3)> array form, the ENCODER
|
---|
229 | implementation should be able to import that array and create a suitable
|
---|
230 | object to be passed to OSSL_FUNC_encoder_encode()'s I<obj_raw>.
|
---|
231 |
|
---|
232 | OSSL_FUNC_encoder_import_object() should import the subset of I<params>
|
---|
233 | given with I<selection> to create a provider-native object that can be
|
---|
234 | passed as I<obj_raw> to OSSL_FUNC_encoder_encode().
|
---|
235 |
|
---|
236 | OSSL_FUNC_encoder_free_object() should free the object that was created with
|
---|
237 | OSSL_FUNC_encoder_import_object().
|
---|
238 |
|
---|
239 | =head2 Encoding functions
|
---|
240 |
|
---|
241 | OSSL_FUNC_encoder_encode() should take a provider-native object (in
|
---|
242 | I<obj_raw>) or an object abstraction (in I<obj_abstract>), and should output
|
---|
243 | the object in encoded form to the B<OSSL_CORE_BIO>. The I<selection> bits,
|
---|
244 | if relevant, should determine in greater detail what will be output.
|
---|
245 | The encoding functions also take an L<OSSL_PASSPHRASE_CALLBACK(3)> function
|
---|
246 | pointer along with a pointer to application data I<cbarg>, which should be
|
---|
247 | used when a pass phrase prompt is needed.
|
---|
248 |
|
---|
249 | =head2 Encoder operation parameters
|
---|
250 |
|
---|
251 | Operation parameters currently recognised by built-in encoders are as
|
---|
252 | follows:
|
---|
253 |
|
---|
254 | =over 4
|
---|
255 |
|
---|
256 | =item "cipher" (B<OSSL_ENCODER_PARAM_CIPHER>) <UTF8 string>
|
---|
257 |
|
---|
258 | The name of the encryption cipher to be used when generating encrypted
|
---|
259 | encoding. This is used when encoding private keys, as well as
|
---|
260 | other objects that need protection.
|
---|
261 |
|
---|
262 | If this name is invalid for the encoding implementation, the
|
---|
263 | implementation should refuse to perform the encoding, i.e.
|
---|
264 | OSSL_FUNC_encoder_encode_data() and OSSL_FUNC_encoder_encode_object()
|
---|
265 | should return an error.
|
---|
266 |
|
---|
267 | =item "properties" (B<OSSL_ENCODER_PARAM_PROPERTIES>) <UTF8 string>
|
---|
268 |
|
---|
269 | The properties to be queried when trying to fetch the algorithm given
|
---|
270 | with the "cipher" parameter.
|
---|
271 | This must be given together with the "cipher" parameter to be
|
---|
272 | considered valid.
|
---|
273 |
|
---|
274 | The encoding implementation isn't obligated to use this value.
|
---|
275 | However, it is recommended that implementations that do not handle
|
---|
276 | property strings return an error on receiving this parameter unless
|
---|
277 | its value NULL or the empty string.
|
---|
278 |
|
---|
279 | =item "save-parameters" (B<OSSL_ENCODER_PARAM_SAVE_PARAMETERS>) <integer>
|
---|
280 |
|
---|
281 | If set to 0 disables saving of key domain parameters. Default is 1.
|
---|
282 | It currently has an effect only on DSA keys.
|
---|
283 |
|
---|
284 | =back
|
---|
285 |
|
---|
286 | Parameters currently recognised by the built-in pass phrase callback:
|
---|
287 |
|
---|
288 | =over 4
|
---|
289 |
|
---|
290 | =item "info" (B<OSSL_PASSPHRASE_PARAM_INFO>) <UTF8 string>
|
---|
291 |
|
---|
292 | A string of information that will become part of the pass phrase
|
---|
293 | prompt. This could be used to give the user information on what kind
|
---|
294 | of object it's being prompted for.
|
---|
295 |
|
---|
296 | =back
|
---|
297 |
|
---|
298 | =head1 RETURN VALUES
|
---|
299 |
|
---|
300 | OSSL_FUNC_encoder_newctx() returns a pointer to a context, or NULL on
|
---|
301 | failure.
|
---|
302 |
|
---|
303 | OSSL_FUNC_encoder_set_ctx_params() returns 1, unless a recognised
|
---|
304 | parameter was invalid or caused an error, for which 0 is returned.
|
---|
305 |
|
---|
306 | OSSL_FUNC_encoder_settable_ctx_params() returns a pointer to an array of
|
---|
307 | constant L<OSSL_PARAM(3)> elements.
|
---|
308 |
|
---|
309 | OSSL_FUNC_encoder_does_selection() returns 1 if the encoder implementation
|
---|
310 | supports any of the I<selection> bits, otherwise 0.
|
---|
311 |
|
---|
312 | OSSL_FUNC_encoder_encode() returns 1 on success, or 0 on failure.
|
---|
313 |
|
---|
314 | =head1 SEE ALSO
|
---|
315 |
|
---|
316 | L<provider(7)>
|
---|
317 |
|
---|
318 | =head1 HISTORY
|
---|
319 |
|
---|
320 | The ENCODER interface was introduced in OpenSSL 3.0.
|
---|
321 |
|
---|
322 | =head1 COPYRIGHT
|
---|
323 |
|
---|
324 | Copyright 2019-2022 The OpenSSL Project Authors. All Rights Reserved.
|
---|
325 |
|
---|
326 | Licensed under the Apache License 2.0 (the "License"). You may not use
|
---|
327 | this file except in compliance with the License. You can obtain a copy
|
---|
328 | in the file LICENSE in the source distribution or at
|
---|
329 | L<https://www.openssl.org/source/license.html>.
|
---|
330 |
|
---|
331 | =cut
|
---|