mirror of https://github.com/openssl/openssl.git
				
				
				
			Document the implications of setting engine-based low-level methods
Reviewed-by: Dmitry Belyavskiy <beldmit@gmail.com>
Reviewed-by: Neil Horman <nhorman@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/23063)
(cherry picked from commit dbb478a51d)
			
			
This commit is contained in:
		
							parent
							
								
									9349432812
								
							
						
					
					
						commit
						be933cb742
					
				|  | @ -157,6 +157,14 @@ To ensure the future compatibility, the engines should be turned to providers. | |||
| To prefer the provider-based hardware offload, you can specify the default | ||||
| properties to prefer your provider. | ||||
| 
 | ||||
| Setting engine-based or application-based default low-level crypto method such | ||||
| as B<RSA_METHOD> or B<EC_KEY_METHOD> is still possible and keys inside the | ||||
| default provider will use the engine-based implementation for the crypto | ||||
| operations. However B<EVP_PKEY>s created by decoding by using B<OSSL_DECODER>, | ||||
| B<PEM_> or B<d2i_> APIs will be provider-based. To create a fully legacy | ||||
| B<EVP_PKEY>s L<EVP_PKEY_set1_RSA(3)>, L<EVP_PKEY_set1_EC_KEY(3)> or similar | ||||
| functions must be used. | ||||
| 
 | ||||
| =head3 Versioning Scheme | ||||
| 
 | ||||
| The OpenSSL versioning scheme has changed with the OpenSSL 3.0 release. The new | ||||
|  |  | |||
		Loading…
	
		Reference in New Issue