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

This includes a quick recommendation on how to name loader docmentation.

Reviewed-by: Rich Salz <rsalz@openssl.org>
(Merged from https://github.com/openssl/openssl/pull/6350)

2 files changed, 76 insertions, 24 deletions

diff --git a/doc/man7/ossl_store-file.pod b/doc/man7/ossl_store-file.pod
new file mode 100644
index 0000000..1378427
--- /dev/null
+++ b/doc/man7/ossl_store-file.pod
@@ -0,0 +1,74 @@
+=pod
+
+=begin comment
+
+This is a recommended way to describe OSSL_STORE loaders,
+"ossl_store-{name}", where {name} is replaced with the name of the
+scheme it implements, in man section 7.
+
+=end comment
+
+=head1 NAME
+
+ossl_store-file - The store 'file' scheme loader
+
+=head1 SYNOPSIS
+
+=for comment generic
+
+#include <openssl/store.h>
+
+=head1 DESCRIPTION
+
+Support for the 'file' scheme is 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).
+
+=head1 NOTES
+
+When needed, the 'file' scheme loader will require a pass phrase by
+using the C<UI_METHOD> that was passed via OSSL_STORE_open().
+This pass phrase is used as it is, which may present some challenge
+when the file that's loaded contains a PKCS#12 object.
+See L<passphrase-encoding(7)> for more information.
+
+=begin comment
+
+The treatment of pass phrases is currently being worked on and may
+change.
+
+=end comment
+
+=head1 SEE ALSO
+
+L<ossl_store(7)>, L<passphrase-encoding(7)>
+
+=head1 COPYRIGHT
+
+Copyright 2018 The OpenSSL Project Authors. All Rights Reserved.
+
+Licensed under the OpenSSL license (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
diff --git a/doc/man7/ossl_store.pod b/doc/man7/ossl_store.pod
index 98cc04f..efa4780 100644
--- 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