STORE: split off the description of the 'file' scheme loader

[openssl.git] / doc / man7 / ossl_store.pod

diff --git a/doc/man7/ossl_store.pod b/doc/man7/ossl_store.pod
index 98cc04f79a6a282616d2ac8e4ece67ad14b509d4..efa47806c7f9d0d31f97f2bef68d3fbe54afe61e 100644 (file)
--- a/doc/man7/ossl_store.pod
+++ b/doc/man7/ossl_store.pod
@@ -30,30 +30,8 @@ from which an OpenSSL type can be retrieved.
 Support for a URI scheme is called a STORE "loader", and can be added
 dynamically from the calling application or from a loadable engine.
 
-=head2 The 'file' scheme
-
-Support for the 'file' scheme is already built into C<libcrypto>.
-Since files come in all kinds of formats and content types, the 'file'
-scheme has its own layer of functionality called "file handlers",
-which are used to try to decode diverse types of file contents.
-
-In case a file is formatted as PEM, each called file handler receives
-the PEM name (everything following any 'C<-----BEGIN >') as well as
-possible PEM headers, together with the decoded PEM body.  Since PEM
-formatted files can contain more than one object, the file handlers
-are called upon for each such object.
-
-If the file isn't determined to be formatted as PEM, the content is
-loaded in raw form in its entirety and passed to the available file
-handlers as is, with no PEM name or headers.
-
-Each file handler is expected to handle PEM and non-PEM content as
-appropriate.  Some may refuse non-PEM content for the sake of
-determinism (for example, there are keys out in the wild that are
-represented as an ASN.1 OCTET STRING.  In raw form, it's not easily
-possible to distinguish those from any other data coming as an ASN.1
-OCTET STRING, so such keys would naturally be accepted as PEM files
-only).
+Support for the 'file' scheme is built into C<libcrypto>.
+See L<ossl_store-file(7)> for more information.
 
 =head1 EXAMPLES