Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Move the description of the core types into their own pages
This expands on some of the core type descriptions, and also makes it easier to find the documentation for each type, at least on Unix, with a simple call like "man OSSL_ALGORITHM". Reviewed-by: Hugo Landau <hlandau@openssl.org> Reviewed-by: Tomas Mraz <tomas@openssl.org> (Merged from #19842) (cherry picked from commit 801e54d)
- Loading branch information
Showing
7 changed files
with
400 additions
and
84 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,151 @@ | ||
| =pod | ||
|
|
||
| =head1 NAME | ||
|
|
||
| OSSL_ALGORITHM - OpenSSL Core type to define a fetchable algorithm | ||
|
|
||
| =head1 SYNOPSIS | ||
|
|
||
| #include <openssl/core.h> | ||
|
|
||
| typedef struct ossl_algorithm_st OSSL_ALGORITHM; | ||
| struct ossl_algorithm_st { | ||
| const char *algorithm_names; /* key */ | ||
| const char *property_definition; /* key */ | ||
| const OSSL_DISPATCH *implementation; | ||
| const char *algorithm_description; | ||
| }; | ||
|
|
||
| =head1 DESCRIPTION | ||
|
|
||
| The B<OSSL_ALGORITHM> type is a I<public structure> that describes an | ||
| algorithm that a L<provider(7)> provides. Arrays of this type are returned | ||
| by providers on demand from the OpenSSL libraries to describe what | ||
| algorithms the providers provide implementations of, and with what | ||
| properties. | ||
|
|
||
| Arrays of this type must be terminated with a tuple where I<algorithm_names> | ||
| is NULL. | ||
|
|
||
| This type of array is typically returned by the provider's operation querying | ||
| function, further described in L<provider-base(7)/Provider Functions>. | ||
|
|
||
| =head2 B<OSSL_ALGORITHM> fields | ||
|
|
||
| =over 4 | ||
|
|
||
| =item I<algorithm_names> | ||
|
|
||
| This string is a colon separated set of names / identities, and is used by | ||
| the appropriate fetching functionality (such as L<EVP_CIPHER_fetch(3)>, | ||
| L<EVP_MD_fetch(3)>, etc) to find the desired algorithm. | ||
|
|
||
| Multiple names / identities allow a specific algorithm implementation to be | ||
| fetched multiple ways. For example, the RSA algorithm has the following | ||
| known identities: | ||
|
|
||
| =over 4 | ||
|
|
||
| =item * | ||
|
|
||
| C<RSA> | ||
|
|
||
| =item * | ||
|
|
||
| C<rsaEncryption> | ||
|
|
||
| This is the name of the algorithm's OBJECT IDENTIFIER (OID), as given by the | ||
| L<PKCS#1 RFC's ASN.1 module|https://www.rfc-editor.org/rfc/rfc8017#appendix-C> | ||
|
|
||
| =item * | ||
|
|
||
| C<1.2.840.113549.1.1.1> | ||
|
|
||
| This is the OID itself for C<rsaEncryption>, in canonical decimal text form. | ||
|
|
||
| =back | ||
|
|
||
| The resulting I<algorithm_names> string would look like this: | ||
|
|
||
| "RSA:rsaEncryption:1.2.840.113549.1.1.1" | ||
|
|
||
| The OpenSSL libraries use the first of the algorithm names as the main | ||
| or canonical name, on a per algorithm implementation basis. | ||
|
|
||
| See the notes L</On the subject of algorithm names> below for a more in | ||
| depth discussion on I<algorithm_names> and how that may interact with | ||
| applications and libraries, including OpenSSL's. | ||
|
|
||
| =item I<property_definition> | ||
|
|
||
| This string defines a set of properties associated with a particular | ||
| algorithm implementation, and is used by the appropriate fetching | ||
| functionality (such as L<EVP_CIPHER_fetch(3)>, L<EVP_MD_fetch(3)>, etc) for | ||
| a finer grained lookup of an algorithm implementation, which is useful in | ||
| case multiple implementations of the same algorithm are available. | ||
|
|
||
| See L<property(7)> for a further description of the contents of this | ||
| string. | ||
|
|
||
| =item I<implementation> | ||
|
|
||
| Pointer to an L<OSSL_DISPATCH(3)> array, containing pointers to the | ||
| functions of a particular algorithm implementation. | ||
|
|
||
| =item I<algorithm_description> | ||
|
|
||
| A string with a short human-readable description of the algorithm. | ||
|
|
||
| =back | ||
|
|
||
| =head1 NOTES | ||
|
|
||
| =head2 On the subject of algorithm names | ||
|
|
||
| Providers may find the need to register ASN.1 OIDs for algorithms using | ||
| L<OBJ_create(3)> (via the B<core_obj_create> upcall described in | ||
| L<provider-base(7)>, because some application or library -- possibly still | ||
| the OpenSSL libraries, even -- use NIDs to look up algorithms. | ||
|
|
||
| In that scenario, you must make sure that the corresponding B<OSSL_ALGORITHM>'s | ||
| I<algorithm_names> includes both the short and the long name. | ||
|
|
||
| Most of the time, registering ASN.1 OIDs like this shouldn't be necessary, | ||
| and applications and libraries are encouraged to use L<OBJ_obj2txt(3)> to | ||
| get a text representation of the OID, which may be a long or short name for | ||
| OIDs that are registered, or the OID itself in canonical decimal text form | ||
| if not (or if L<OBJ_obj2txt(3)> is called with I<no_name> = 1). | ||
|
|
||
| It's recommended to make sure that the corresponding B<OSSL_ALGORITHM>'s | ||
| I<algorithm_names> include known names as well as the OID itself in | ||
| canonical decimal text form. That should cover all scenarios. | ||
|
|
||
| =begin comment RETURN VALUES doesn't make sense for a manual that only | ||
| describes a type, but document checkers still want that section, and | ||
| to have more than just the section title. | ||
|
|
||
| =head1 RETURN VALUES | ||
|
|
||
| txt | ||
|
|
||
| =end comment | ||
|
|
||
| =head1 SEE ALSO | ||
|
|
||
| L<crypto(7)>, L<provider-base(7)>, L<openssl-core.h(7)>, | ||
| L<openssl-core_dispatch.h(7)>, L<OSSL_DISPATCH(3)> | ||
|
|
||
| =head1 HISTORY | ||
|
|
||
| B<OSSL_ALGORITHM> was added in OpenSSL 3.0 | ||
|
|
||
| =head1 COPYRIGHT | ||
|
|
||
| Copyright 2022 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 | ||
| L<https://www.openssl.org/source/license.html>. | ||
|
|
||
| =cut |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,77 @@ | ||
| =pod | ||
|
|
||
| =head1 NAME | ||
|
|
||
| OSSL_CALLBACK, OSSL_PASSPHRASE_CALLBACK - OpenSSL Core type to define callbacks | ||
|
|
||
| =head1 SYNOPSIS | ||
|
|
||
| #include <openssl/core.h> | ||
| typedef int (OSSL_CALLBACK)(const OSSL_PARAM params[], void *arg); | ||
| typedef int (OSSL_PASSPHRASE_CALLBACK)(char *pass, size_t pass_size, | ||
| size_t *pass_len, | ||
| const OSSL_PARAM params[], | ||
| void *arg); | ||
|
|
||
| =head1 DESCRIPTION | ||
|
|
||
| For certain events or activities, provider functionality may need help from | ||
| the application or the calling OpenSSL libraries themselves. For example, | ||
| user input or direct (possibly optional) user output could be implemented | ||
| this way. | ||
|
|
||
| Callback functions themselves are always provided by or through the calling | ||
| OpenSSL libraries, along with a generic pointer to data I<arg>. As far as | ||
| the function receiving the pointer to the function pointer and I<arg> is | ||
| concerned, the data that I<arg> points at is opaque, and the pointer should | ||
| simply be passed back to the callback function when it's called. | ||
|
|
||
| =over 4 | ||
|
|
||
| =item B<OSSL_CALLBACK> | ||
|
|
||
| This is a generic callback function. When calling this callback function, | ||
| the caller is expected to build an B<OSSL_PARAM> array of data it wants or | ||
| is expected to pass back, and pass that as I<params>, as well as the opaque | ||
| data pointer it received, as I<arg>. | ||
|
|
||
| =item B<OSSL_PASSPHRASE_CALLBACK> | ||
|
|
||
| This is a specialised callback function, used specifically to prompt the | ||
| user for a passphrase. When calling this callback function, a buffer to | ||
| store the pass phrase needs to be given with I<pass>, and its size with | ||
| I<pass_size>. The length of the prompted pass phrase will be given back in | ||
| I<*pass_len>. | ||
|
|
||
| Additional parameters can be passed with the B<OSSL_PARAM> array I<params>, | ||
|
|
||
| =back | ||
|
|
||
| =begin comment RETURN VALUES doesn't make sense for a manual that only | ||
| describes a type, but document checkers still want that section, and | ||
| to have more than just the section title. | ||
|
|
||
| =head1 RETURN VALUES | ||
|
|
||
| txt | ||
|
|
||
| =end comment | ||
|
|
||
| =head1 SEE ALSO | ||
|
|
||
| L<openssl-core.h(7)> | ||
|
|
||
| =head1 HISTORY | ||
|
|
||
| The types described here were added in OpenSSL 3.0. | ||
|
|
||
| =head1 COPYRIGHT | ||
|
|
||
| Copyright 2022 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 | ||
| L<https://www.openssl.org/source/license.html>. | ||
|
|
||
| =cut |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,81 @@ | ||
| =pod | ||
|
|
||
| =head1 NAME | ||
|
|
||
| OSSL_DISPATCH - OpenSSL Core type to define a dispatchable function table | ||
|
|
||
| =head1 SYNOPSIS | ||
|
|
||
| #include <openssl/core.h> | ||
|
|
||
| typedef struct ossl_dispatch_st OSSL_DISPATCH; | ||
| struct ossl_dispatch_st { | ||
| int function_id; | ||
| void (*function)(void); | ||
| }; | ||
|
|
||
| =head1 DESCRIPTION | ||
|
|
||
| This type is a tuple of function identity and function pointer. | ||
| Arrays of this type are passed between the OpenSSL libraries and the | ||
| providers to describe what functionality one side provides to the other. | ||
|
|
||
| Arrays of this type must be terminated with a tuple having function identity | ||
| zero and function pointer NULL. | ||
|
|
||
| =head2 B<OSSL_DISPATCH> fields | ||
|
|
||
| =over 4 | ||
|
|
||
| =item I<function_id> | ||
|
|
||
| OpenSSL defined function identity of the implemented function. | ||
|
|
||
| =item I<function> | ||
|
|
||
| Pointer to the implemented function itself. Despite the generic definition | ||
| of this field, the implemented function it points to must have a function | ||
| signature that corresponds to the I<function_id> | ||
|
|
||
| =back | ||
|
|
||
| Available function identities and corresponding function signatures are | ||
| defined in L<openssl-core_dispatch.h(7)>. | ||
| Furthermore, the chosen function identities and associated function | ||
| signature must be chosen specifically for the operation that it's intended | ||
| for, as determined by the intended L<OSSL_ALGORITHM(3)> array. | ||
|
|
||
| Any function identity not recognised by the recipient of this type | ||
| will be ignored. | ||
| This ensures that providers built with one OpenSSL version in mind | ||
| will work together with any other OpenSSL version that supports this | ||
| mechanism. | ||
|
|
||
| =begin comment RETURN VALUES doesn't make sense for a manual that only | ||
| describes a type, but document checkers still want that section, and | ||
| to have more than just the section title. | ||
|
|
||
| =head1 RETURN VALUES | ||
|
|
||
| txt | ||
|
|
||
| =end comment | ||
|
|
||
| =head1 SEE ALSO | ||
|
|
||
| L<crypto(7)>, L<openssl-core_dispatch.h(7)>, L<OSSL_ALGORITHM(3)> | ||
|
|
||
| =head1 HISTORY | ||
|
|
||
| B<OSSL_DISPATCH> was added in OpenSSL 3.0. | ||
|
|
||
| =head1 COPYRIGHT | ||
|
|
||
| Copyright 2022 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 | ||
| L<https://www.openssl.org/source/license.html>. | ||
|
|
||
| =cut |
Oops, something went wrong.