-algorithms and modes - ENGINEs will support different numbers and
-combinations of these. In the case of other abstractions like RSA, DSA,
-etc, there is only one "algorithm" so all implementations implicitly
-register using the same 'nid' index. ENGINEs can be B<registered> into
-these tables to make themselves available for use automatically by the
-various abstractions, eg. RSA. For illustrative purposes, we continue with
-the RSA example, though all comments apply similarly to the other
-abstractions (they each get their own table and linkage to the
-corresponding section of openssl code).
-
-When a new RSA key is being created, ie. in RSA_new_method(), a
-"get_default" call will be made to the ENGINE subsystem to process the RSA
-state table and return a functional reference to an initialised ENGINE
-whose RSA_METHOD should be used. If no ENGINE should (or can) be used, it
-will return NULL and the RSA key will operate with a NULL ENGINE handle by
-using the conventional RSA implementation in OpenSSL (and will from then on
-behave the way it used to before the ENGINE API existed - for details see
-L<RSA_new_method(3)|RSA_new_method(3)>).
+algorithms and modes, and ENGINEs can support arbitrarily many of them.
+In the case of other abstractions like RSA, DSA, etc, there is only one
+"algorithm" so all implementations implicitly register using the same 'nid'
+index.
+
+When a default ENGINE is requested for a given abstraction/algorithm/mode, (eg.
+when calling RSA_new_method(NULL)), a "get_default" call will be made to the
+ENGINE subsystem to process the corresponding state table and return a
+functional reference to an initialised ENGINE whose implementation should be
+used. If no ENGINE should (or can) be used, it will return NULL and the caller
+will operate with a NULL ENGINE handle - this usually equates to using the
+conventional software implementation. In the latter case, OpenSSL will from
+then on behave the way it used to before the ENGINE API existed.