This commit was generated by cvs2git to track changes on a CVS vendor

branch.

25 files changed, 1774 insertions, 6 deletions

diff --git a/src/lib/libcrypto/doc/EVP_PKEY_new.pod b/src/lib/libcrypto/doc/EVP_PKEY_new.pod
new file mode 100644
index 0000000000..10687e458d
--- /dev/null
+++ b/src/lib/libcrypto/doc/EVP_PKEY_new.pod
@@ -0,0 +1,47 @@
+=pod
+
+=head1 NAME
+
+EVP_PKEY_new, EVP_PKEY_free - private key allocation functions.
+
+=head1 SYNOPSIS
+
+ #include <openssl/evp.h>
+
+ EVP_PKEY *EVP_PKEY_new(void);
+ void EVP_PKEY_free(EVP_PKEY *key);
+
+
+=head1 DESCRIPTION
+
+The EVP_PKEY_new() function allocates an empty B<EVP_PKEY> 
+structure which is used by OpenSSL to store private keys.
+
+EVP_PKEY_free() frees up the private key B<key>.
+
+=head1 NOTES
+
+The B<EVP_PKEY> structure is used by various OpenSSL functions
+which require a general private key without reference to any
+particular algorithm.
+
+The structure returned by EVP_PKEY_new() is empty. To add a
+private key to this empty structure the functions described in
+L<EVP_PKEY_set1_RSA(3)|EVP_PKEY_set1_RSA(3)> should be used.
+
+=head1 RETURN VALUES
+
+EVP_PKEY_new() returns either the newly allocated B<EVP_PKEY>
+structure of B<NULL> if an error occurred.
+
+EVP_PKEY_free() does not return a value.
+
+=head1 SEE ALSO
+
+L<EVP_PKEY_set1_RSA(3)|EVP_PKEY_set1_RSA(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/EVP_PKEY_set1_RSA.pod b/src/lib/libcrypto/doc/EVP_PKEY_set1_RSA.pod
new file mode 100644
index 0000000000..2db692e271
--- /dev/null
+++ b/src/lib/libcrypto/doc/EVP_PKEY_set1_RSA.pod
@@ -0,0 +1,80 @@
+=pod
+
+=head1 NAME
+
+EVP_PKEY_set1_RSA, EVP_PKEY_set1_DSA, EVP_PKEY_set1_DH, EVP_PKEY_set1_EC_KEY,
+EVP_PKEY_get1_RSA, EVP_PKEY_get1_DSA, EVP_PKEY_get1_DH, EVP_PKEY_get1_EC_KEY,
+EVP_PKEY_assign_RSA, EVP_PKEY_assign_DSA, EVP_PKEY_assign_DH, EVP_PKEY_assign_EC_KEY,
+EVP_PKEY_type - EVP_PKEY assignment functions.
+
+=head1 SYNOPSIS
+
+ #include <openssl/evp.h>
+
+ int EVP_PKEY_set1_RSA(EVP_PKEY *pkey,RSA *key);
+ int EVP_PKEY_set1_DSA(EVP_PKEY *pkey,DSA *key);
+ int EVP_PKEY_set1_DH(EVP_PKEY *pkey,DH *key);
+ int EVP_PKEY_set1_EC_KEY(EVP_PKEY *pkey,EC_KEY *key);
+
+ RSA *EVP_PKEY_get1_RSA(EVP_PKEY *pkey);
+ DSA *EVP_PKEY_get1_DSA(EVP_PKEY *pkey);
+ DH *EVP_PKEY_get1_DH(EVP_PKEY *pkey);
+ EC_KEY *EVP_PKEY_get1_EC_KEY(EVP_PKEY *pkey);
+
+ int EVP_PKEY_assign_RSA(EVP_PKEY *pkey,RSA *key);
+ int EVP_PKEY_assign_DSA(EVP_PKEY *pkey,DSA *key);
+ int EVP_PKEY_assign_DH(EVP_PKEY *pkey,DH *key);
+ int EVP_PKEY_assign_EC_KEY(EVP_PKEY *pkey,EC_KEY *key);
+
+ int EVP_PKEY_type(int type);
+
+=head1 DESCRIPTION
+
+EVP_PKEY_set1_RSA(), EVP_PKEY_set1_DSA(), EVP_PKEY_set1_DH() and
+EVP_PKEY_set1_EC_KEY() set the key referenced by B<pkey> to B<key>.
+
+EVP_PKEY_get1_RSA(), EVP_PKEY_get1_DSA(), EVP_PKEY_get1_DH() and
+EVP_PKEY_get1_EC_KEY() return the referenced key in B<pkey> or
+B<NULL> if the key is not of the correct type.
+
+EVP_PKEY_assign_RSA() EVP_PKEY_assign_DSA(), EVP_PKEY_assign_DH()
+and EVP_PKEY_assign_EC_KEY() also set the referenced key to B<key>
+however these use the supplied B<key> internally and so B<key>
+will be freed when the parent B<pkey> is freed.
+
+EVP_PKEY_type() returns the type of key corresponding to the value
+B<type>. The type of a key can be obtained with
+EVP_PKEY_type(pkey->type). The return value will be EVP_PKEY_RSA,
+EVP_PKEY_DSA, EVP_PKEY_DH or EVP_PKEY_EC for the corresponding
+key types or NID_undef if the key type is unassigned.
+
+=head1 NOTES
+
+In accordance with the OpenSSL naming convention the key obtained
+from or assigned to the B<pkey> using the B<1> functions must be
+freed as well as B<pkey>.
+
+EVP_PKEY_assign_RSA() EVP_PKEY_assign_DSA(), EVP_PKEY_assign_DH()
+EVP_PKEY_assign_EC_KEY() are implemented as macros.
+
+=head1 RETURN VALUES
+
+EVP_PKEY_set1_RSA(), EVP_PKEY_set1_DSA(), EVP_PKEY_set1_DH() and
+EVP_PKEY_set1_EC_KEY() return 1 for success or 0 for failure.
+
+EVP_PKEY_get1_RSA(), EVP_PKEY_get1_DSA(), EVP_PKEY_get1_DH() and
+EVP_PKEY_get1_EC_KEY() return the referenced key or B<NULL> if 
+an error occurred.
+
+EVP_PKEY_assign_RSA() EVP_PKEY_assign_DSA(), EVP_PKEY_assign_DH()
+and EVP_PKEY_assign_EC_KEY() return 1 for success and 0 for failure.
+
+=head1 SEE ALSO
+
+L<EVP_PKEY_new(3)|EVP_PKEY_new(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/OBJ_nid2obj.pod b/src/lib/libcrypto/doc/OBJ_nid2obj.pod
new file mode 100644
index 0000000000..7dcc07923f
--- /dev/null
+++ b/src/lib/libcrypto/doc/OBJ_nid2obj.pod
@@ -0,0 +1,149 @@
+=pod
+
+=head1 NAME
+
+OBJ_nid2obj, OBJ_nid2ln, OBJ_nid2sn, OBJ_obj2nid, OBJ_txt2nid, OBJ_ln2nid, OBJ_sn2nid,
+OBJ_cmp, OBJ_dup, OBJ_txt2obj, OBJ_obj2txt, OBJ_create, OBJ_cleanup - ASN1 object utility
+functions
+
+=head1 SYNOPSIS
+
+ ASN1_OBJECT * OBJ_nid2obj(int n);
+ const char *  OBJ_nid2ln(int n);
+ const char *  OBJ_nid2sn(int n);
+
+ int OBJ_obj2nid(const ASN1_OBJECT *o);
+ int OBJ_ln2nid(const char *ln);
+ int OBJ_sn2nid(const char *sn);
+
+ int OBJ_txt2nid(const char *s);
+
+ ASN1_OBJECT * OBJ_txt2obj(const char *s, int no_name);
+ int OBJ_obj2txt(char *buf, int buf_len, const ASN1_OBJECT *a, int no_name);
+
+ int OBJ_cmp(const ASN1_OBJECT *a,const ASN1_OBJECT *b);
+ ASN1_OBJECT * OBJ_dup(const ASN1_OBJECT *o);
+
+ int OBJ_create(const char *oid,const char *sn,const char *ln);
+ void OBJ_cleanup(void);
+
+=head1 DESCRIPTION
+
+The ASN1 object utility functions process ASN1_OBJECT structures which are
+a representation of the ASN1 OBJECT IDENTIFIER (OID) type.
+
+OBJ_nid2obj(), OBJ_nid2ln() and OBJ_nid2sn() convert the NID B<n> to 
+an ASN1_OBJECT structure, its long name and its short name respectively,
+or B<NULL> is an error occurred.
+
+OBJ_obj2nid(), OBJ_ln2nid(), OBJ_sn2nid() return the corresponding NID
+for the object B<o>, the long name <ln> or the short name <sn> respectively
+or NID_undef if an error occurred.
+
+OBJ_txt2nid() returns NID corresponding to text string <s>. B<s> can be
+a long name, a short name or the numerical respresentation of an object.
+
+OBJ_txt2obj() converts the text string B<s> into an ASN1_OBJECT structure.
+If B<no_name> is 0 then long names and short names will be interpreted
+as well as numerical forms. If B<no_name> is 1 only the numerical form
+is acceptable.
+
+OBJ_obj2txt() converts the B<ASN1_OBJECT> B<a> into a textual representation.
+The representation is written as a null terminated string to B<buf>
+at most B<buf_len> bytes are written, truncating the result if necessary.
+The total amount of space required is returned. If B<no_name> is 0 then
+if the object has a long or short name then that will be used, otherwise
+the numerical form will be used. If B<no_name> is 1 then the numerical
+form will always be used.
+
+OBJ_cmp() compares B<a> to B<b>. If the two are identical 0 is returned.
+
+OBJ_dup() returns a copy of B<o>.
+
+OBJ_create() adds a new object to the internal table. B<oid> is the 
+numerical form of the object, B<sn> the short name and B<ln> the
+long name. A new NID is returned for the created object.
+
+OBJ_cleanup() cleans up OpenSSLs internal object table: this should
+be called before an application exits if any new objects were added
+using OBJ_create().
+
+=head1 NOTES
+
+Objects in OpenSSL can have a short name, a long name and a numerical
+identifier (NID) associated with them. A standard set of objects is
+represented in an internal table. The appropriate values are defined
+in the header file B<objects.h>.
+
+For example the OID for commonName has the following definitions:
+
+ #define SN_commonName                   "CN"
+ #define LN_commonName                   "commonName"
+ #define NID_commonName                  13
+
+New objects can be added by calling OBJ_create().
+
+Table objects have certain advantages over other objects: for example
+their NIDs can be used in a C language switch statement. They are
+also static constant structures which are shared: that is there
+is only a single constant structure for each table object.
+
+Objects which are not in the table have the NID value NID_undef.
+
+Objects do not need to be in the internal tables to be processed,
+the functions OBJ_txt2obj() and OBJ_obj2txt() can process the numerical
+form of an OID.
+
+=head1 EXAMPLES
+
+Create an object for B<commonName>:
+
+ ASN1_OBJECT *o;
+ o = OBJ_nid2obj(NID_commonName);
+
+Check if an object is B<commonName>
+
+ if (OBJ_obj2nid(obj) == NID_commonName)
+        /* Do something */
+
+Create a new NID and initialize an object from it:
+
+ int new_nid;
+ ASN1_OBJECT *obj;
+ new_nid = OBJ_create("1.2.3.4", "NewOID", "New Object Identifier");
+
+ obj = OBJ_nid2obj(new_nid);
+ 
+Create a new object directly:
+
+ obj = OBJ_txt2obj("1.2.3.4", 1);
+
+=head1 BUGS
+
+OBJ_obj2txt() is awkward and messy to use: it doesn't follow the 
+convention of other OpenSSL functions where the buffer can be set
+to B<NULL> to determine the amount of data that should be written.
+Instead B<buf> must point to a valid buffer and B<buf_len> should
+be set to a positive value. A buffer length of 80 should be more
+than enough to handle any OID encountered in practice.
+
+=head1 RETURN VALUES
+
+OBJ_nid2obj() returns an B<ASN1_OBJECT> structure or B<NULL> is an
+error occurred.
+
+OBJ_nid2ln() and OBJ_nid2sn() returns a valid string or B<NULL>
+on error.
+
+OBJ_obj2nid(), OBJ_ln2nid(), OBJ_sn2nid() and OBJ_txt2nid() return
+a NID or B<NID_undef> on error.
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/PKCS12_create.pod b/src/lib/libcrypto/doc/PKCS12_create.pod
new file mode 100644
index 0000000000..48f3bb8cb8
--- /dev/null
+++ b/src/lib/libcrypto/doc/PKCS12_create.pod
@@ -0,0 +1,57 @@
+=pod
+
+=head1 NAME
+
+PKCS12_create - create a PKCS#12 structure
+
+=head1 SYNOPSIS
+
+ #include <openssl/pkcs12.h>
+
+ PKCS12 *PKCS12_create(char *pass, char *name, EVP_PKEY *pkey, X509 *cert, STACK_OF(X509) *ca,
+                                int nid_key, int nid_cert, int iter, int mac_iter, int keytype);
+
+=head1 DESCRIPTION
+
+PKCS12_create() creates a PKCS#12 structure.
+
+B<pass> is the passphrase to use. B<name> is the B<friendlyName> to use for
+the supplied certifictate and key. B<pkey> is the private key to include in
+the structure and B<cert> its corresponding certificates. B<ca>, if not B<NULL>
+is an optional set of certificates to also include in the structure.
+
+B<nid_key> and B<nid_cert> are the encryption algorithms that should be used
+for the key and certificate respectively. B<iter> is the encryption algorithm
+iteration count to use and B<mac_iter> is the MAC iteration count to use.
+B<keytype> is the type of key.
+
+=head1 NOTES
+
+The parameters B<nid_key>, B<nid_cert>, B<iter>, B<mac_iter> and B<keytype>
+can all be set to zero and sensible defaults will be used.
+
+These defaults are: 40 bit RC2 encryption for certificates, triple DES
+encryption for private keys, a key iteration count of PKCS12_DEFAULT_ITER
+(currently 2048) and a MAC iteration count of 1.
+
+The default MAC iteration count is 1 in order to retain compatibility with
+old software which did not interpret MAC iteration counts. If such compatibility
+is not required then B<mac_iter> should be set to PKCS12_DEFAULT_ITER.
+
+B<keytype> adds a flag to the store private key. This is a non standard extension
+that is only currently interpreted by MSIE. If set to zero the flag is omitted,
+if set to B<KEY_SIG> the key can be used for signing only, if set to B<KEY_EX>
+it can be used for signing and encryption. This option was useful for old
+export grade software which could use signing only keys of arbitrary size but
+had restrictions on the permissible sizes of keys which could be used for
+encryption.
+
+=head1 SEE ALSO
+
+L<d2i_PKCS12(3)|d2i_PKCS12(3)>
+
+=head1 HISTORY
+
+PKCS12_create was added in OpenSSL 0.9.3
+
+=cut
diff --git a/src/lib/libcrypto/doc/PKCS12_parse.pod b/src/lib/libcrypto/doc/PKCS12_parse.pod
new file mode 100644
index 0000000000..51344f883a
--- /dev/null
+++ b/src/lib/libcrypto/doc/PKCS12_parse.pod
@@ -0,0 +1,50 @@
+=pod
+
+=head1 NAME
+
+PKCS12_parse - parse a PKCS#12 structure
+
+=head1 SYNOPSIS
+
+ #include <openssl/pkcs12.h>
+
+int PKCS12_parse(PKCS12 *p12, const char *pass, EVP_PKEY **pkey, X509 **cert, STACK_OF(X509) **ca);
+
+=head1 DESCRIPTION
+
+PKCS12_parse() parses a PKCS12 structure.
+
+B<p12> is the B<PKCS12> structure to parse. B<pass> is the passphrase to use.
+If successful the private key will be written to B<*pkey>, the corresponding
+certificate to B<*cert> and any additional certificates to B<*ca>.
+
+=head1 NOTES
+
+The parameters B<pkey> and B<cert> cannot be B<NULL>. B<ca> can be <NULL>
+in which case additional certificates will be discarded. B<*ca> can also
+be a valid STACK in which case additional certificates are appended to
+B<*ca>. If B<*ca> is B<NULL> a new STACK will be allocated.
+
+The B<friendlyName> and B<localKeyID> attributes (if present) on each certificate
+will be stored in the B<alias> and B<keyid> attributes of the B<X509> structure.
+
+=head1 BUGS
+
+Only a single private key and corresponding certificate is returned by this function.
+More complex PKCS#12 files with multiple private keys will only return the first
+match.
+
+Only B<friendlyName> and B<localKeyID> attributes are currently stored in certificates.
+Other attributes are discarded.
+
+Attributes currently cannot be store in the private key B<EVP_PKEY> structure.
+
+=head1 SEE ALSO
+
+L<d2i_PKCS12(3)|d2i_PKCS12(3)>
+
+=head1 HISTORY
+
+PKCS12_parse was added in OpenSSL 0.9.3
+
+=cut
diff --git a/src/lib/libcrypto/doc/PKCS7_decrypt.pod b/src/lib/libcrypto/doc/PKCS7_decrypt.pod
new file mode 100644
index 0000000000..b0ca067b89
--- /dev/null
+++ b/src/lib/libcrypto/doc/PKCS7_decrypt.pod
@@ -0,0 +1,53 @@
+=pod
+
+=head1 NAME
+
+PKCS7_decrypt - decrypt content from a PKCS#7 envelopedData structure
+
+=head1 SYNOPSIS
+
+int PKCS7_decrypt(PKCS7 *p7, EVP_PKEY *pkey, X509 *cert, BIO *data, int flags);
+
+=head1 DESCRIPTION
+
+PKCS7_decrypt() extracts and decrypts the content from a PKCS#7 envelopedData
+structure. B<pkey> is the private key of the recipient, B<cert> is the
+recipients certificate, B<data> is a BIO to write the content to and
+B<flags> is an optional set of flags.
+
+=head1 NOTES
+
+OpenSSL_add_all_algorithms() (or equivalent) should be called before using this
+function or errors about unknown algorithms will occur.
+
+Although the recipients certificate is not needed to decrypt the data it is needed
+to locate the appropriate (of possible several) recipients in the PKCS#7 structure.
+
+The following flags can be passed in the B<flags> parameter.
+
+If the B<PKCS7_TEXT> flag is set MIME headers for type B<text/plain> are deleted
+from the content. If the content is not of type B<text/plain> then an error is
+returned.
+
+=head1 RETURN VALUES
+
+PKCS7_decrypt() returns either 1 for success or 0 for failure.
+The error can be obtained from ERR_get_error(3)
+
+=head1 BUGS
+
+PKCS7_decrypt() must be passed the correct recipient key and certificate. It would
+be better if it could look up the correct key and certificate from a database.
+
+The lack of single pass processing and need to hold all data in memory as
+mentioned in PKCS7_sign() also applies to PKCS7_verify().
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<PKCS7_encrypt(3)|PKCS7_encrypt(3)>
+
+=head1 HISTORY
+
+PKCS7_decrypt() was added to OpenSSL 0.9.5
+
+=cut
diff --git a/src/lib/libcrypto/doc/PKCS7_encrypt.pod b/src/lib/libcrypto/doc/PKCS7_encrypt.pod
new file mode 100644
index 0000000000..1a507b22a2
--- /dev/null
+++ b/src/lib/libcrypto/doc/PKCS7_encrypt.pod
@@ -0,0 +1,65 @@
+=pod
+
+=head1 NAME
+
+PKCS7_encrypt - create a PKCS#7 envelopedData structure
+
+=head1 SYNOPSIS
+
+PKCS7 *PKCS7_encrypt(STACK_OF(X509) *certs, BIO *in, const EVP_CIPHER *cipher, int flags);
+
+=head1 DESCRIPTION
+
+PKCS7_encrypt() creates and returns a PKCS#7 envelopedData structure. B<certs>
+is a list of recipient certificates. B<in> is the content to be encrypted.
+B<cipher> is the symmetric cipher to use. B<flags> is an optional set of flags.
+
+=head1 NOTES
+
+Only RSA keys are supported in PKCS#7 and envelopedData so the recipient certificates
+supplied to this function must all contain RSA public keys, though they do not have to
+be signed using the RSA algorithm.
+
+EVP_des_ede3_cbc() (triple DES) is the algorithm of choice for S/MIME use because
+most clients will support it.
+
+Some old "export grade" clients may only support weak encryption using 40 or 64 bit
+RC2. These can be used by passing EVP_rc2_40_cbc() and EVP_rc2_64_cbc() respectively.
+
+The algorithm passed in the B<cipher> parameter must support ASN1 encoding of its
+parameters. 
+
+Many browsers implement a "sign and encrypt" option which is simply an S/MIME 
+envelopedData containing an S/MIME signed message. This can be readily produced
+by storing the S/MIME signed message in a memory BIO and passing it to
+PKCS7_encrypt().
+
+The following flags can be passed in the B<flags> parameter.
+
+If the B<PKCS7_TEXT> flag is set MIME headers for type B<text/plain> are prepended
+to the data.
+
+Normally the supplied content is translated into MIME canonical format (as required
+by the S/MIME specifications) if B<PKCS7_BINARY> is set no translation occurs. This
+option should be used if the supplied data is in binary format otherwise the translation
+will corrupt it. If B<PKCS7_BINARY> is set then B<PKCS7_TEXT> is ignored.
+
+=head1 RETURN VALUES
+
+PKCS7_encrypt() returns either a valid PKCS7 structure or NULL if an error occurred.
+The error can be obtained from ERR_get_error(3).
+
+=head1 BUGS
+
+The lack of single pass processing and need to hold all data in memory as
+mentioned in PKCS7_sign() also applies to PKCS7_verify().
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<PKCS7_decrypt(3)|PKCS7_decrypt(3)>
+
+=head1 HISTORY
+
+PKCS7_decrypt() was added to OpenSSL 0.9.5
+
+=cut
diff --git a/src/lib/libcrypto/doc/PKCS7_sign.pod b/src/lib/libcrypto/doc/PKCS7_sign.pod
new file mode 100644
index 0000000000..fc7e649b34
--- /dev/null
+++ b/src/lib/libcrypto/doc/PKCS7_sign.pod
@@ -0,0 +1,85 @@
+=pod
+
+=head1 NAME
+
+PKCS7_sign - create a PKCS#7 signedData structure
+
+=head1 SYNOPSIS
+
+PKCS7 *PKCS7_sign(X509 *signcert, EVP_PKEY *pkey, STACK_OF(X509) *certs, BIO *data, int flags);
+
+=head1 DESCRIPTION
+
+PKCS7_sign() creates and returns a PKCS#7 signedData structure. B<signcert>
+is the certificate to sign with, B<pkey> is the corresponsding private key.
+B<certs> is an optional additional set of certificates to include in the
+PKCS#7 structure (for example any intermediate CAs in the chain). 
+
+The data to be signed is read from BIO B<data>.
+
+B<flags> is an optional set of flags.
+
+=head1 NOTES
+
+Any of the following flags (ored together) can be passed in the B<flags> parameter.
+
+Many S/MIME clients expect the signed content to include valid MIME headers. If
+the B<PKCS7_TEXT> flag is set MIME headers for type B<text/plain> are prepended
+to the data.
+
+If B<PKCS7_NOCERTS> is set the signer's certificate will not be included in the
+PKCS7 structure, the signer's certificate must still be supplied in the B<signcert>
+parameter though. This can reduce the size of the signature if the signers certificate
+can be obtained by other means: for example a previously signed message.
+
+The data being signed is included in the PKCS7 structure, unless B<PKCS7_DETACHED> 
+is set in which case it is omitted. This is used for PKCS7 detached signatures
+which are used in S/MIME plaintext signed messages for example.
+
+Normally the supplied content is translated into MIME canonical format (as required
+by the S/MIME specifications) if B<PKCS7_BINARY> is set no translation occurs. This
+option should be used if the supplied data is in binary format otherwise the translation
+will corrupt it.
+
+The signedData structure includes several PKCS#7 autenticatedAttributes including
+the signing time, the PKCS#7 content type and the supported list of ciphers in
+an SMIMECapabilities attribute. If B<PKCS7_NOATTR> is set then no authenticatedAttributes
+will be used. If B<PKCS7_NOSMIMECAP> is set then just the SMIMECapabilities are
+omitted.
+
+If present the SMIMECapabilities attribute indicates support for the following
+algorithms: triple DES, 128 bit RC2, 64 bit RC2, DES and 40 bit RC2. If any
+of these algorithms is disabled then it will not be included.
+
+=head1 BUGS
+
+PKCS7_sign() is somewhat limited. It does not support multiple signers, some
+advanced attributes such as counter signatures are not supported.
+
+The SHA1 digest algorithm is currently always used.
+
+When the signed data is not detached it will be stored in memory within the
+B<PKCS7> structure. This effectively limits the size of messages which can be
+signed due to memory restraints. There should be a way to sign data without
+having to hold it all in memory, this would however require fairly major
+revisions of the OpenSSL ASN1 code.
+
+Clear text signing does not store the content in memory but the way PKCS7_sign()
+operates means that two passes of the data must typically be made: one to compute
+the signatures and a second to output the data along with the signature. There
+should be a way to process the data with only a single pass.
+
+=head1 RETURN VALUES
+
+PKCS7_sign() returns either a valid PKCS7 structure or NULL if an error occurred.
+The error can be obtained from ERR_get_error(3).
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<PKCS7_verify(3)|PKCS7_verify(3)>
+
+=head1 HISTORY
+
+PKCS7_sign() was added to OpenSSL 0.9.5
+
+=cut
diff --git a/src/lib/libcrypto/doc/PKCS7_verify.pod b/src/lib/libcrypto/doc/PKCS7_verify.pod
new file mode 100644
index 0000000000..07c9fdad40
--- /dev/null
+++ b/src/lib/libcrypto/doc/PKCS7_verify.pod
@@ -0,0 +1,116 @@
+=pod
+
+=head1 NAME
+
+PKCS7_verify - verify a PKCS#7 signedData structure
+
+=head1 SYNOPSIS
+
+int PKCS7_verify(PKCS7 *p7, STACK_OF(X509) *certs, X509_STORE *store, BIO *indata, BIO *out, int flags);
+
+int PKCS7_get0_signers(PKCS7 *p7, STACK_OF(X509) *certs, int flags);
+
+=head1 DESCRIPTION
+
+PKCS7_verify() verifies a PKCS#7 signedData structure. B<p7> is the PKCS7
+structure to verify. B<certs> is a set of certificates in which to search for
+the signer's certificate. B<store> is a trusted certficate store (used for
+chain verification). B<indata> is the signed data if the content is not
+present in B<p7> (that is it is detached). The content is written to B<out>
+if it is not NULL.
+
+B<flags> is an optional set of flags, which can be used to modify the verify
+operation.
+
+PKCS7_get0_signers() retrieves the signer's certificates from B<p7>, it does
+B<not> check their validity or whether any signatures are valid. The B<certs>
+and B<flags> parameters have the same meanings as in PKCS7_verify().
+
+=head1 VERIFY PROCESS
+
+Normally the verify process proceeds as follows.
+
+Initially some sanity checks are performed on B<p7>. The type of B<p7> must
+be signedData. There must be at least one signature on the data and if
+the content is detached B<indata> cannot be B<NULL>.
+
+An attempt is made to locate all the signer's certificates, first looking in
+the B<certs> parameter (if it is not B<NULL>) and then looking in any certificates
+contained in the B<p7> structure itself. If any signer's certificates cannot be
+located the operation fails.
+
+Each signer's certificate is chain verified using the B<smimesign> purpose and
+the supplied trusted certificate store. Any internal certificates in the message
+are used as untrusted CAs. If any chain verify fails an error code is returned.
+
+Finally the signed content is read (and written to B<out> is it is not NULL) and
+the signature's checked.
+
+If all signature's verify correctly then the function is successful.
+
+Any of the following flags (ored together) can be passed in the B<flags> parameter
+to change the default verify behaviour. Only the flag B<PKCS7_NOINTERN> is
+meaningful to PKCS7_get0_signers().
+
+If B<PKCS7_NOINTERN> is set the certificates in the message itself are not 
+searched when locating the signer's certificate. This means that all the signers
+certificates must be in the B<certs> parameter.
+
+If the B<PKCS7_TEXT> flag is set MIME headers for type B<text/plain> are deleted
+from the content. If the content is not of type B<text/plain> then an error is
+returned.
+
+If B<PKCS7_NOVERIFY> is set the signer's certificates are not chain verified.
+
+If B<PKCS7_NOCHAIN> is set then the certificates contained in the message are
+not used as untrusted CAs. This means that the whole verify chain (apart from
+the signer's certificate) must be contained in the trusted store.
+
+If B<PKCS7_NOSIGS> is set then the signatures on the data are not checked.
+
+=head1 NOTES
+
+One application of B<PKCS7_NOINTERN> is to only accept messages signed by
+a small number of certificates. The acceptable certificates would be passed
+in the B<certs> parameter. In this case if the signer is not one of the
+certificates supplied in B<certs> then the verify will fail because the
+signer cannot be found.
+
+Care should be taken when modifying the default verify behaviour, for example
+setting B<PKCS7_NOVERIFY|PKCS7_NOSIGS> will totally disable all verification 
+and any signed message will be considered valid. This combination is however
+useful if one merely wishes to write the content to B<out> and its validity
+is not considered important.
+
+Chain verification should arguably be performed  using the signing time rather
+than the current time. However since the signing time is supplied by the
+signer it cannot be trusted without additional evidence (such as a trusted
+timestamp).
+
+=head1 RETURN VALUES
+
+PKCS7_verify() returns 1 for a successful verification and zero or a negative
+value if an error occurs.
+
+PKCS7_get0_signers() returns all signers or B<NULL> if an error occurred.
+
+The error can be obtained from L<ERR_get_error(3)|ERR_get_error(3)>
+
+=head1 BUGS
+
+The trusted certificate store is not searched for the signers certificate,
+this is primarily due to the inadequacies of the current B<X509_STORE>
+functionality.
+
+The lack of single pass processing and need to hold all data in memory as
+mentioned in PKCS7_sign() also applies to PKCS7_verify().
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<PKCS7_sign(3)|PKCS7_sign(3)>
+
+=head1 HISTORY
+
+PKCS7_verify() was added to OpenSSL 0.9.5
+
+=cut
diff --git a/src/lib/libcrypto/doc/SMIME_read_PKCS7.pod b/src/lib/libcrypto/doc/SMIME_read_PKCS7.pod
new file mode 100644
index 0000000000..ffafa37887
--- /dev/null
+++ b/src/lib/libcrypto/doc/SMIME_read_PKCS7.pod
@@ -0,0 +1,71 @@
+=pod
+
+=head1 NAME
+
+SMIME_read_PKCS7 - parse S/MIME message.
+
+=head1 SYNOPSIS
+
+PKCS7 *SMIME_read_PKCS7(BIO *in, BIO **bcont);
+
+=head1 DESCRIPTION
+
+SMIME_read_PKCS7() parses a message in S/MIME format.
+
+B<in> is a BIO to read the message from.
+
+If cleartext signing is used then the content is saved in
+a memory bio which is written to B<*bcont>, otherwise
+B<*bcont> is set to B<NULL>.
+
+The parsed PKCS#7 structure is returned or B<NULL> if an
+error occurred.
+
+=head1 NOTES
+
+If B<*bcont> is not B<NULL> then the message is clear text
+signed. B<*bcont> can then be passed to PKCS7_verify() with
+the B<PKCS7_DETACHED> flag set.
+
+Otherwise the type of the returned structure can be determined
+using PKCS7_type().
+
+To support future functionality if B<bcont> is not B<NULL>
+B<*bcont> should be initialized to B<NULL>. For example:
+
+ BIO *cont = NULL;
+ PKCS7 *p7;
+
+ p7 = SMIME_read_PKCS7(in, &cont);
+
+=head1 BUGS
+
+The MIME parser used by SMIME_read_PKCS7() is somewhat primitive.
+While it will handle most S/MIME messages more complex compound
+formats may not work.
+
+The parser assumes that the PKCS7 structure is always base64
+encoded and will not handle the case where it is in binary format
+or uses quoted printable format.
+
+The use of a memory BIO to hold the signed content limits the size
+of message which can be processed due to memory restraints: a
+streaming single pass option should be available.
+
+=head1 RETURN VALUES
+
+SMIME_read_PKCS7() returns a valid B<PKCS7> structure or B<NULL>
+is an error occurred. The error can be obtained from ERR_get_error(3).
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<PKCS7_type(3)|PKCS7_type(3)>
+L<SMIME_read_PKCS7(3)|SMIME_read_PKCS7(3)>, L<PKCS7_sign(3)|PKCS7_sign(3)>,
+L<PKCS7_verify(3)|PKCS7_verify(3)>, L<PKCS7_encrypt(3)|PKCS7_encrypt(3)>
+L<PKCS7_decrypt(3)|PKCS7_decrypt(3)>
+
+=head1 HISTORY
+
+SMIME_read_PKCS7() was added to OpenSSL 0.9.5
+
+=cut
diff --git a/src/lib/libcrypto/doc/SMIME_write_PKCS7.pod b/src/lib/libcrypto/doc/SMIME_write_PKCS7.pod
new file mode 100644
index 0000000000..2cfad2e049
--- /dev/null
+++ b/src/lib/libcrypto/doc/SMIME_write_PKCS7.pod
@@ -0,0 +1,59 @@
+=pod
+
+=head1 NAME
+
+SMIME_write_PKCS7 - convert PKCS#7 structure to S/MIME format.
+
+=head1 SYNOPSIS
+
+int SMIME_write_PKCS7(BIO *out, PKCS7 *p7, BIO *data, int flags);
+
+=head1 DESCRIPTION
+
+SMIME_write_PKCS7() adds the appropriate MIME headers to a PKCS#7
+structure to produce an S/MIME message.
+
+B<out> is the BIO to write the data to. B<p7> is the appropriate
+B<PKCS7> structure. If cleartext signing (B<multipart/signed>) is
+being used then the signed data must be supplied in the B<data> 
+argument. B<flags> is an optional set of flags.
+
+=head1 NOTES
+
+The following flags can be passed in the B<flags> parameter.
+
+If B<PKCS7_DETACHED> is set then cleartext signing will be used,
+this option only makes sense for signedData where B<PKCS7_DETACHED>
+is also set when PKCS7_sign() is also called.
+
+If the B<PKCS7_TEXT> flag is set MIME headers for type B<text/plain>
+are added to the content, this only makes sense if B<PKCS7_DETACHED>
+is also set.
+
+If cleartext signing is being used then the data must be read twice:
+once to compute the signature in PKCS7_sign() and once to output the
+S/MIME message.
+
+=head1 BUGS
+
+SMIME_write_PKCS7() always base64 encodes PKCS#7 structures, there
+should be an option to disable this.
+
+There should really be a way to produce cleartext signing using only
+a single pass of the data.
+
+=head1 RETURN VALUES
+
+SMIME_write_PKCS7() returns 1 for success or 0 for failure.
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<PKCS7_sign(3)|PKCS7_sign(3)>,
+L<PKCS7_verify(3)|PKCS7_verify(3)>, L<PKCS7_encrypt(3)|PKCS7_encrypt(3)>
+L<PKCS7_decrypt(3)|PKCS7_decrypt(3)>
+
+=head1 HISTORY
+
+SMIME_write_PKCS7() was added to OpenSSL 0.9.5
+
+=cut
diff --git a/src/lib/libcrypto/doc/X509_NAME_ENTRY_get_object.pod b/src/lib/libcrypto/doc/X509_NAME_ENTRY_get_object.pod
new file mode 100644
index 0000000000..d287c18564
--- /dev/null
+++ b/src/lib/libcrypto/doc/X509_NAME_ENTRY_get_object.pod
@@ -0,0 +1,72 @@
+=pod
+
+=head1 NAME
+
+X509_NAME_ENTRY_get_object, X509_NAME_ENTRY_get_data,
+X509_NAME_ENTRY_set_object, X509_NAME_ENTRY_set_data,
+X509_NAME_ENTRY_create_by_txt, X509_NAME_ENTRY_create_by_NID,
+X509_NAME_ENTRY_create_by_OBJ - X509_NAME_ENTRY utility functions
+
+=head1 SYNOPSIS
+
+ASN1_OBJECT * X509_NAME_ENTRY_get_object(X509_NAME_ENTRY *ne);
+ASN1_STRING * X509_NAME_ENTRY_get_data(X509_NAME_ENTRY *ne);
+
+int X509_NAME_ENTRY_set_object(X509_NAME_ENTRY *ne, ASN1_OBJECT *obj);
+int X509_NAME_ENTRY_set_data(X509_NAME_ENTRY *ne, int type, unsigned char *bytes, int len);
+
+X509_NAME_ENTRY *X509_NAME_ENTRY_create_by_txt(X509_NAME_ENTRY **ne, char *field, int type, unsigned char *bytes, int len);
+X509_NAME_ENTRY *X509_NAME_ENTRY_create_by_NID(X509_NAME_ENTRY **ne, int nid, int type,unsigned char *bytes, int len);
+X509_NAME_ENTRY *X509_NAME_ENTRY_create_by_OBJ(X509_NAME_ENTRY **ne, ASN1_OBJECT *obj, int type,unsigned char *bytes, int len);
+
+=head1 DESCRIPTION
+
+X509_NAME_ENTRY_get_object() retrieves the field name of B<ne> in
+and B<ASN1_OBJECT> structure.
+
+X509_NAME_ENTRY_get_data() retrieves the field value of B<ne> in
+and B<ASN1_STRING> structure.
+
+X509_NAME_ENTRY_set_object() sets the field name of B<ne> to B<obj>.
+
+X509_NAME_ENTRY_set_data() sets the field value of B<ne> to string type
+B<type> and value determined by B<bytes> and B<len>.
+
+X509_NAME_ENTRY_create_by_txt(), X509_NAME_ENTRY_create_by_NID()
+and X509_NAME_ENTRY_create_by_OBJ() create and return an 
+B<X509_NAME_ENTRY> structure.
+
+=head1 NOTES
+
+X509_NAME_ENTRY_get_object() and X509_NAME_ENTRY_get_data() can be
+used to examine an B<X509_NAME_ENTRY> function as returned by 
+X509_NAME_get_entry() for example.
+
+X509_NAME_ENTRY_create_by_txt(), X509_NAME_ENTRY_create_by_NID(),
+and X509_NAME_ENTRY_create_by_OBJ() create and return an 
+
+X509_NAME_ENTRY_create_by_txt(), X509_NAME_ENTRY_create_by_OBJ(),
+X509_NAME_ENTRY_create_by_NID() and X509_NAME_ENTRY_set_data()
+are seldom used in practice because B<X509_NAME_ENTRY> structures
+are almost always part of B<X509_NAME> structures and the
+corresponding B<X509_NAME> functions are typically used to
+create and add new entries in a single operation.
+
+The arguments of these functions support similar options to the similarly
+named ones of the corresponding B<X509_NAME> functions such as
+X509_NAME_add_entry_by_txt(). So for example B<type> can be set to
+B<MBSTRING_ASC> but in the case of X509_set_data() the field name must be
+set first so the relevant field information can be looked up internally.
+
+=head1 RETURN VALUES
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<d2i_X509_NAME(3)|d2i_X509_NAME(3)>,
+L<OBJ_nid2obj(3),OBJ_nid2obj(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/X509_NAME_add_entry_by_txt.pod b/src/lib/libcrypto/doc/X509_NAME_add_entry_by_txt.pod
new file mode 100644
index 0000000000..4472a1c5cf
--- /dev/null
+++ b/src/lib/libcrypto/doc/X509_NAME_add_entry_by_txt.pod
@@ -0,0 +1,110 @@
+=pod
+
+=head1 NAME
+
+X509_NAME_add_entry_by_txt, X509_NAME_add_entry_by_OBJ, X509_NAME_add_entry_by_NID,
+X509_NAME_add_entry, X509_NAME_delete_entry - X509_NAME modification functions
+
+=head1 SYNOPSIS
+
+int X509_NAME_add_entry_by_txt(X509_NAME *name, char *field, int type, unsigned char *bytes, int len, int loc, int set);
+int X509_NAME_add_entry_by_OBJ(X509_NAME *name, ASN1_OBJECT *obj, int type, unsigned char *bytes, int len, int loc, int set);
+int X509_NAME_add_entry_by_NID(X509_NAME *name, int nid, int type, unsigned char *bytes, int len, int loc, int set);
+int X509_NAME_add_entry(X509_NAME *name,X509_NAME_ENTRY *ne, int loc, int set);
+X509_NAME_ENTRY *X509_NAME_delete_entry(X509_NAME *name, int loc);
+
+=head1 DESCRIPTION
+
+X509_NAME_add_entry_by_txt(), X509_NAME_add_entry_by_OBJ() and
+X509_NAME_add_entry_by_NID() add a field whose name is defined
+by a string B<field>, an object B<obj> or a NID B<nid> respectively.
+The field value to be added is in B<bytes> of length B<len>. If
+B<len> is -1 then the field length is calculated internally using
+strlen(bytes).
+
+The type of field is determined by B<type> which can either be a
+definition of the type of B<bytes> (such as B<MBSTRING_ASC>) or a
+standard ASN1 type (such as B<V_ASN1_IA5STRING>). The new entry is
+added to a position determined by B<loc> and B<set>.
+
+X509_NAME_add_entry() adds a copy of B<X509_NAME_ENTRY> structure B<ne>
+to B<name>. The new entry is added to a position determined by B<loc>
+and B<set>. Since a copy of B<ne> is added B<ne> must be freed up after
+the call.
+
+X509_NAME_delete_entry() deletes an entry from B<name> at position
+B<loc>. The deleted entry is returned and must be freed up.
+
+=head1 NOTES
+
+The use of string types such as B<MBSTRING_ASC> or B<MBSTRING_UTF8>
+is strongly recommened for the B<type> parameter. This allows the
+internal code to correctly determine the type of the field and to
+apply length checks according to the relevant standards. This is
+done using ASN1_STRING_set_by_NID().
+
+If instead an ASN1 type is used no checks are performed and the
+supplied data in B<bytes> is used directly.
+
+In X509_NAME_add_entry_by_txt() the B<field> string represents
+the field name using OBJ_txt2obj(field, 0).
+
+The B<loc> and B<set> parameters determine where a new entry should
+be added. For almost all applications B<loc> can be set to -1 and B<set>
+to 0. This adds a new entry to the end of B<name> as a single valued
+RelativeDistinguishedName (RDN).
+
+B<loc> actually determines the index where the new entry is inserted:
+if it is -1 it is appended. 
+
+B<set> determines how the new type is added. If it is zero a
+new RDN is created.
+
+If B<set> is -1 or 1 it is added to the previous or next RDN
+structure respectively. This will then be a multivalued RDN:
+since multivalues RDNs are very seldom used B<set> is almost
+always set to zero.
+
+=head1 EXAMPLES
+
+Create an B<X509_NAME> structure:
+
+"C=UK, O=Disorganized Organization, CN=Joe Bloggs"
+
+ X509_NAME *nm;
+ nm = X509_NAME_new();
+ if (nm == NULL)
+        /* Some error */
+ if (!X509_NAME_add_entry_by_txt(nm, MBSTRING_ASC,
+                        "C", "UK", -1, -1, 0))
+        /* Error */
+ if (!X509_NAME_add_entry_by_txt(nm, MBSTRING_ASC,
+                        "O", "Disorganized Organization", -1, -1, 0))
+        /* Error */
+ if (!X509_NAME_add_entry_by_txt(nm, MBSTRING_ASC,
+                        "CN", "Joe Bloggs", -1, -1, 0))
+        /* Error */
+
+=head1 RETURN VALUES
+
+X509_NAME_add_entry_by_txt(), X509_NAME_add_entry_by_OBJ(),
+X509_NAME_add_entry_by_NID() and X509_NAME_add_entry() return 1 for
+success of 0 if an error occurred.
+
+X509_NAME_delete_entry() returns either the deleted B<X509_NAME_ENTRY>
+structure of B<NULL> if an error occurred.
+
+=head1 BUGS
+
+B<type> can still be set to B<V_ASN1_APP_CHOOSE> to use a
+different algorithm to determine field types. Since this form does
+not understand multicharacter types, performs no length checks and
+can result in invalid field types its use is strongly discouraged.
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<d2i_X509_NAME(3)|d2i_X509_NAME(3)>
+
+=head1 HISTORY
+
+=cut
diff --git a/src/lib/libcrypto/doc/X509_NAME_get_index_by_NID.pod b/src/lib/libcrypto/doc/X509_NAME_get_index_by_NID.pod
new file mode 100644
index 0000000000..333323d734
--- /dev/null
+++ b/src/lib/libcrypto/doc/X509_NAME_get_index_by_NID.pod
@@ -0,0 +1,106 @@
+=pod
+
+=head1 NAME
+
+X509_NAME_get_index_by_NID, X509_NAME_get_index_by_OBJ, X509_NAME_get_entry,
+X509_NAME_entry_count, X509_NAME_get_text_by_NID, X509_NAME_get_text_by_OBJ -
+X509_NAME lookup and enumeration functions
+
+=head1 SYNOPSIS
+
+int X509_NAME_get_index_by_NID(X509_NAME *name,int nid,int lastpos);
+int X509_NAME_get_index_by_OBJ(X509_NAME *name,ASN1_OBJECT *obj, int lastpos);
+
+int X509_NAME_entry_count(X509_NAME *name);
+X509_NAME_ENTRY *X509_NAME_get_entry(X509_NAME *name, int loc);
+
+int X509_NAME_get_text_by_NID(X509_NAME *name, int nid, char *buf,int len);
+int X509_NAME_get_text_by_OBJ(X509_NAME *name, ASN1_OBJECT *obj, char *buf,int len);
+
+=head1 DESCRIPTION
+
+These functions allow an B<X509_NAME> structure to be examined. The
+B<X509_NAME> structure is the same as the B<Name> type defined in
+RFC2459 (and elsewhere) and used for example in certificate subject
+and issuer names.
+
+X509_NAME_get_index_by_NID() and X509_NAME_get_index_by_OBJ() retrieve
+the next index matching B<nid> or B<obj> after B<lastpos>. B<lastpos>
+should initially be set to -1. If there are no more entries -1 is returned.
+
+X509_NAME_entry_count() returns the total number of entries in B<name>.
+
+X509_NAME_get_entry() retrieves the B<X509_NAME_ENTRY> from B<name>
+corresponding to index B<loc>. Acceptable values for B<loc> run from
+0 to (X509_NAME_entry_count(name) - 1). The value returned is an
+internal pointer which must not be freed.
+
+X509_NAME_get_text_by_NID(), X509_NAME_get_text_by_OBJ() retrieve
+the "text" from the first entry in B<name> which matches B<nid> or
+B<obj>, if no such entry exists -1 is returned. At most B<len> bytes
+will be written and the text written to B<buf> will be null
+terminated. The length of the output string written is returned
+excluding the terminating null. If B<buf> is <NULL> then the amount
+of space needed in B<buf> (excluding the final null) is returned. 
+
+=head1 NOTES
+
+X509_NAME_get_text_by_NID() and X509_NAME_get_text_by_OBJ() are
+legacy functions which have various limitations which make them
+of minimal use in practice. They can only find the first matching
+entry and will copy the contents of the field verbatim: this can
+be highly confusing if the target is a muticharacter string type
+like a BMPString or a UTF8String.
+
+For a more general solution X509_NAME_get_index_by_NID() or
+X509_NAME_get_index_by_OBJ() should be used followed by
+X509_NAME_get_entry() on any matching indices and then the
+various B<X509_NAME_ENTRY> utility functions on the result.
+
+=head1 EXAMPLES
+
+Process all entries:
+
+ int i;
+ X509_NAME_ENTRY *e;
+
+ for (i = 0; i < X509_NAME_entry_count(nm); i++)
+        {
+        e = X509_NAME_get_entry(nm, i);
+        /* Do something with e */
+        }
+
+Process all commonName entries:
+
+ int loc;
+ X509_NAME_ENTRY *e;
+
+ loc = -1;
+ for (;;)
+        {
+        lastpos = X509_NAME_get_index_by_NID(nm, NID_commonName, lastpos);
+        if (lastpos == -1)
+                break;
+        e = X509_NAME_get_entry(nm, lastpos);
+        /* Do something with e */
+        }
+
+=head1 RETURN VALUES
+
+X509_NAME_get_index_by_NID() and X509_NAME_get_index_by_OBJ()
+return the index of the next matching entry or -1 if not found.
+
+X509_NAME_entry_count() returns the total number of entries.
+
+X509_NAME_get_entry() returns an B<X509_NAME> pointer to the
+requested entry or B<NULL> if the index is invalid.
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<d2i_X509_NAME(3)|d2i_X509_NAME(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/X509_NAME_print_ex.pod b/src/lib/libcrypto/doc/X509_NAME_print_ex.pod
new file mode 100644
index 0000000000..907c04f684
--- /dev/null
+++ b/src/lib/libcrypto/doc/X509_NAME_print_ex.pod
@@ -0,0 +1,105 @@
+=pod
+
+=head1 NAME
+
+X509_NAME_print_ex, X509_NAME_print_ex_fp, X509_NAME_print,
+X509_NAME_oneline - X509_NAME printing routines.
+
+=head1 SYNOPSIS
+
+ #include <openssl/x509.h>
+
+ int X509_NAME_print_ex(BIO *out, X509_NAME *nm, int indent, unsigned long flags);
+ int X509_NAME_print_ex_fp(FILE *fp, X509_NAME *nm, int indent, unsigned long flags);
+ char * X509_NAME_oneline(X509_NAME *a,char *buf,int size);
+ int X509_NAME_print(BIO *bp, X509_NAME *name, int obase);
+
+=head1 DESCRIPTION
+
+X509_NAME_print_ex() prints a human readable version of B<nm> to BIO B<out>. Each
+line (for multiline formats) is indented by B<indent> spaces. The output format
+can be extensively customised by use of the B<flags> parameter.
+
+X509_NAME_print_ex_fp() is identical to X509_NAME_print_ex() except the output is
+written to FILE pointer B<fp>.
+
+X509_NAME_oneline() prints an ASCII version of B<a> to B<buf>. At most B<size>
+bytes will be written. If B<buf> is B<NULL> then a buffer is dynamically allocated
+and returned, otherwise B<buf> is returned.
+
+X509_NAME_print() prints out B<name> to B<bp> indenting each line by B<obase> 
+characters. Multiple lines are used if the output (including indent) exceeds
+80 characters.
+
+=head1 NOTES
+
+The functions X509_NAME_oneline() and X509_NAME_print() are legacy functions which
+produce a non standard output form, they don't handle multi character fields and
+have various quirks and inconsistencies. Their use is strongly discouraged in new
+applications.
+
+Although there are a large number of possible flags for most purposes
+B<XN_FLAG_ONELINE>, B<XN_FLAG_MULTILINE> or B<XN_FLAG_RFC2253> will suffice.
+As noted on the L<ASN1_STRING_print_ex(3)|ASN1_STRING_print_ex(3)> manual page
+for UTF8 terminals the B<ASN1_STRFLAGS_ESC_MSB> should be unset: so for example
+B<XN_FLAG_ONELINE & ~ASN1_STRFLAGS_ESC_MSB> would be used.
+
+The complete set of the flags supported by X509_NAME_print_ex() is listed below.
+
+Several options can be ored together.
+
+The options B<XN_FLAG_SEP_COMMA_PLUS>, B<XN_FLAG_SEP_CPLUS_SPC>,
+B<XN_FLAG_SEP_SPLUS_SPC> and B<XN_FLAG_SEP_MULTILINE> determine the field separators
+to use. Two distinct separators are used between distinct RelativeDistinguishedName
+components and separate values in the same RDN for a multi-valued RDN. Multi-valued
+RDNs are currently very rare so the second separator will hardly ever be used.
+
+B<XN_FLAG_SEP_COMMA_PLUS> uses comma and plus as separators. B<XN_FLAG_SEP_CPLUS_SPC>
+uses comma and plus with spaces: this is more readable that plain comma and plus.
+B<XN_FLAG_SEP_SPLUS_SPC> uses spaced semicolon and plus. B<XN_FLAG_SEP_MULTILINE> uses
+spaced newline and plus respectively.
+
+If B<XN_FLAG_DN_REV> is set the whole DN is printed in reversed order.
+
+The fields B<XN_FLAG_FN_SN>, B<XN_FLAG_FN_LN>, B<XN_FLAG_FN_OID>,
+B<XN_FLAG_FN_NONE> determine how a field name is displayed. It will
+use the short name (e.g. CN) the long name (e.g. commonName) always
+use OID numerical form (normally OIDs are only used if the field name is not
+recognised) and no field name respectively.
+
+If B<XN_FLAG_SPC_EQ> is set then spaces will be placed around the '=' character
+separating field names and values.
+
+If B<XN_FLAG_DUMP_UNKNOWN_FIELDS> is set then the encoding of unknown fields is
+printed instead of the values.
+
+If B<XN_FLAG_FN_ALIGN> is set then field names are padded to 20 characters: this
+is only of use for multiline format.
+
+Additionally all the options supported by ASN1_STRING_print_ex() can be used to 
+control how each field value is displayed.
+
+In addition a number options can be set for commonly used formats.
+
+B<XN_FLAG_RFC2253> sets options which produce an output compatible with RFC2253 it
+is equivalent to:
+ B<ASN1_STRFLGS_RFC2253 | XN_FLAG_SEP_COMMA_PLUS | XN_FLAG_DN_REV | XN_FLAG_FN_SN | XN_FLAG_DUMP_UNKNOWN_FIELDS>
+
+
+B<XN_FLAG_ONELINE> is a more readable one line format it is the same as:
+ B<ASN1_STRFLGS_RFC2253 | ASN1_STRFLGS_ESC_QUOTE | XN_FLAG_SEP_CPLUS_SPC | XN_FLAG_SPC_EQ | XN_FLAG_FN_SN>
+
+B<XN_FLAG_MULTILINE> is a multiline format is is the same as:
+ B<ASN1_STRFLGS_ESC_CTRL | ASN1_STRFLGS_ESC_MSB | XN_FLAG_SEP_MULTILINE | XN_FLAG_SPC_EQ | XN_FLAG_FN_LN | XN_FLAG_FN_ALIGN>
+
+B<XN_FLAG_COMPAT> uses a format identical to X509_NAME_print(): in fact it calls X509_NAME_print() internally.
+
+=head1 SEE ALSO
+
+L<ASN1_STRING_print_ex(3)|ASN1_STRING_print_ex(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/X509_new.pod b/src/lib/libcrypto/doc/X509_new.pod
new file mode 100644
index 0000000000..fd5fc65ce1
--- /dev/null
+++ b/src/lib/libcrypto/doc/X509_new.pod
@@ -0,0 +1,37 @@
+=pod
+
+=head1 NAME
+
+X509_new, X509_free - X509 certificate ASN1 allocation functions
+
+=head1 SYNOPSIS
+
+ X509 *X509_new(void);
+ void X509_free(X509 *a);
+
+=head1 DESCRIPTION
+
+The X509 ASN1 allocation routines, allocate and free an
+X509 structure, which represents an X509 certificate.
+
+X509_new() allocates and initializes a X509 structure.
+
+X509_free() frees up the B<X509> structure B<a>.
+
+=head1 RETURN VALUES
+
+If the allocation fails, X509_new() returns B<NULL> and sets an error
+code that can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
+Otherwise it returns a pointer to the newly allocated structure.
+
+X509_free() returns no value.
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<d2i_X509(3)|d2i_X509(3)>
+
+=head1 HISTORY
+
+X509_new() and X509_free() are available in all versions of SSLeay and OpenSSL.
+
+=cut
diff --git a/src/lib/libcrypto/doc/d2i_ASN1_OBJECT.pod b/src/lib/libcrypto/doc/d2i_ASN1_OBJECT.pod
new file mode 100644
index 0000000000..45bb18492c
--- /dev/null
+++ b/src/lib/libcrypto/doc/d2i_ASN1_OBJECT.pod
@@ -0,0 +1,29 @@
+=pod
+
+=head1 NAME
+
+d2i_ASN1_OBJECT, i2d_ASN1_OBJECT - ASN1 OBJECT IDENTIFIER functions
+
+=head1 SYNOPSIS
+
+ #include <openssl/objects.h>
+
+ ASN1_OBJECT *d2i_ASN1_OBJECT(ASN1_OBJECT **a, unsigned char **pp, long length);
+ int i2d_ASN1_OBJECT(ASN1_OBJECT *a, unsigned char **pp);
+
+=head1 DESCRIPTION
+
+These functions decode and encode an ASN1 OBJECT IDENTIFIER.
+
+Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
+
+=head1 SEE ALSO
+
+L<d2i_X509(3)|d2i_X509(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/d2i_DSAPublicKey.pod b/src/lib/libcrypto/doc/d2i_DSAPublicKey.pod
new file mode 100644
index 0000000000..6ebd30427b
--- /dev/null
+++ b/src/lib/libcrypto/doc/d2i_DSAPublicKey.pod
@@ -0,0 +1,82 @@
+=pod
+
+=head1 NAME
+
+d2i_DSAPublicKey, i2d_DSAPublicKey, d2i_DSAPrivateKey, i2d_DSAPrivateKey,
+d2i_DSA_PUBKEY, i2d_DSA_PUBKEY, d2i_DSA_SIG, i2d_DSA_SIG - DSA key encoding
+and parsing functions.
+
+=head1 SYNOPSIS
+
+ #include <openssl/dsa.h>
+
+ DSA * d2i_DSAPublicKey(DSA **a, const unsigned char **pp, long length);
+
+ int i2d_DSAPublicKey(const DSA *a, unsigned char **pp);
+
+ DSA * d2i_DSA_PUBKEY(DSA **a, const unsigned char **pp, long length);
+
+ int i2d_DSA_PUBKEY(const DSA *a, unsigned char **pp);
+
+ DSA * d2i_DSAPrivateKey(DSA **a, const unsigned char **pp, long length);
+
+ int i2d_DSAPrivateKey(const DSA *a, unsigned char **pp);
+
+ DSA * d2i_DSAparams(DSA **a, const unsigned char **pp, long length);
+
+ int i2d_DSAparams(const DSA *a, unsigned char **pp);
+
+ DSA * d2i_DSA_SIG(DSA_SIG **a, const unsigned char **pp, long length);
+
+ int i2d_DSA_SIG(const DSA_SIG *a, unsigned char **pp);
+
+=head1 DESCRIPTION
+
+d2i_DSAPublicKey() and i2d_DSAPublicKey() decode and encode the DSA public key
+components structure.
+
+d2i_DSA_PUKEY() and i2d_DSA_PUKEY() decode and encode an DSA public key using a
+SubjectPublicKeyInfo (certificate public key) structure.
+
+d2i_DSAPrivateKey(), i2d_DSAPrivateKey() decode and encode the DSA private key
+components.
+
+d2i_DSAparams(), i2d_DSAparams() decode and encode the DSA parameters using
+a B<Dss-Parms> structure as defined in RFC2459.
+
+d2i_DSA_SIG(), i2d_DSA_SIG() decode and encode a DSA signature using a
+B<Dss-Sig-Value> structure as defined in RFC2459.
+
+The usage of all of these functions is similar to the d2i_X509() and
+i2d_X509() described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
+
+=head1 NOTES
+
+The B<DSA> structure passed to the private key encoding functions should have
+all the private key components present.
+
+The data encoded by the private key functions is unencrypted and therefore 
+offers no private key security.
+
+The B<DSA_PUBKEY> functions should be used in preference to the B<DSAPublicKey>
+functions when encoding public keys because they use a standard format.
+
+The B<DSAPublicKey> functions use an non standard format the actual data encoded
+depends on the value of the B<write_params> field of the B<a> key parameter.
+If B<write_params> is zero then only the B<pub_key> field is encoded as an
+B<INTEGER>. If B<write_params> is 1 then a B<SEQUENCE> consisting of the
+B<p>, B<q>, B<g> and B<pub_key> respectively fields are encoded.
+
+The B<DSAPrivateKey> functions also use a non standard structure consiting
+consisting of a SEQUENCE containing the B<p>, B<q>, B<g> and B<pub_key> and
+B<priv_key> fields respectively.
+
+=head1 SEE ALSO
+
+L<d2i_X509(3)|d2i_X509(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/d2i_X509.pod b/src/lib/libcrypto/doc/d2i_X509.pod
new file mode 100644
index 0000000000..5e3c3d0985
--- /dev/null
+++ b/src/lib/libcrypto/doc/d2i_X509.pod
@@ -0,0 +1,231 @@
+=pod
+
+=head1 NAME
+
+d2i_X509, i2d_X509, d2i_X509_bio, d2i_X509_fp, i2d_X509_bio,
+i2d_X509_fp - X509 encode and decode functions
+
+=head1 SYNOPSIS
+
+ #include <openssl/x509.h>
+
+ X509 *d2i_X509(X509 **px, unsigned char **in, int len);
+ int i2d_X509(X509 *x, unsigned char **out);
+
+ X509 *d2i_X509_bio(BIO *bp, X509 **x);
+ X509 *d2i_X509_fp(FILE *fp, X509 **x);
+
+ int i2d_X509_bio(X509 *x, BIO *bp);
+ int i2d_X509_fp(X509 *x, FILE *fp);
+
+=head1 DESCRIPTION
+
+The X509 encode and decode routines encode and parse an
+B<X509> structure, which represents an X509 certificate.
+
+d2i_X509() attempts to decode B<len> bytes at B<*out>. If 
+successful a pointer to the B<X509> structure is returned. If an error
+occurred then B<NULL> is returned. If B<px> is not B<NULL> then the
+returned structure is written to B<*px>. If B<*px> is not B<NULL>
+then it is assumed that B<*px> contains a valid B<X509>
+structure and an attempt is made to reuse it. If the call is
+successful B<*out> is incremented to the byte following the
+parsed data.
+
+i2d_X509() encodes the structure pointed to by B<x> into DER format.
+If B<out> is not B<NULL> is writes the DER encoded data to the buffer
+at B<*out>, and increments it to point after the data just written.
+If the return value is negative an error occurred, otherwise it
+returns the length of the encoded data. 
+
+For OpenSSL 0.9.7 and later if B<*out> is B<NULL> memory will be
+allocated for a buffer and the encoded data written to it. In this
+case B<*out> is not incremented and it points to the start of the
+data just written.
+
+d2i_X509_bio() is similar to d2i_X509() except it attempts
+to parse data from BIO B<bp>.
+
+d2i_X509_fp() is similar to d2i_X509() except it attempts
+to parse data from FILE pointer B<fp>.
+
+i2d_X509_bio() is similar to i2d_X509() except it writes
+the encoding of the structure B<x> to BIO B<bp> and it
+returns 1 for success and 0 for failure.
+
+i2d_X509_fp() is similar to i2d_X509() except it writes
+the encoding of the structure B<x> to BIO B<bp> and it
+returns 1 for success and 0 for failure.
+
+=head1 NOTES
+
+The letters B<i> and B<d> in for example B<i2d_X509> stand for
+"internal" (that is an internal C structure) and "DER". So that
+B<i2d_X509> converts from internal to DER.
+
+The functions can also understand B<BER> forms.
+
+The actual X509 structure passed to i2d_X509() must be a valid
+populated B<X509> structure it can B<not> simply be fed with an
+empty structure such as that returned by X509_new().
+
+The encoded data is in binary form and may contain embedded zeroes.
+Therefore any FILE pointers or BIOs should be opened in binary mode.
+Functions such as B<strlen()> will B<not> return the correct length
+of the encoded structure.
+
+The ways that B<*in> and B<*out> are incremented after the operation
+can trap the unwary. See the B<WARNINGS> section for some common
+errors.
+
+The reason for the auto increment behaviour is to reflect a typical
+usage of ASN1 functions: after one structure is encoded or decoded
+another will processed after it.
+
+=head1 EXAMPLES
+
+Allocate and encode the DER encoding of an X509 structure:
+
+ int len;
+ unsigned char *buf, *p;
+
+ len = i2d_X509(x, NULL);
+
+ buf = OPENSSL_malloc(len);
+
+ if (buf == NULL)
+        /* error */
+
+ p = buf;
+
+ i2d_X509(x, &p);
+
+If you are using OpenSSL 0.9.7 or later then this can be
+simplified to:
+
+
+ int len;
+ unsigned char *buf;
+
+ buf = NULL;
+
+ len = i2d_X509(x, &buf);
+
+ if (len < 0)
+        /* error */
+
+Attempt to decode a buffer:
+
+ X509 *x;
+
+ unsigned char *buf, *p;
+
+ int len;
+
+ /* Something to setup buf and len */
+
+ p = buf;
+
+ x = d2i_X509(NULL, &p, len);
+
+ if (x == NULL)
+    /* Some error */
+
+Alternative technique:
+
+ X509 *x;
+
+ unsigned char *buf, *p;
+
+ int len;
+
+ /* Something to setup buf and len */
+
+ p = buf;
+
+ x = NULL;
+
+ if(!d2i_X509(&x, &p, len))
+    /* Some error */
+
+
+=head1 WARNINGS
+
+The use of temporary variable is mandatory. A common
+mistake is to attempt to use a buffer directly as follows:
+
+ int len;
+ unsigned char *buf;
+
+ len = i2d_X509(x, NULL);
+
+ buf = OPENSSL_malloc(len);
+
+ if (buf == NULL)
+        /* error */
+
+ i2d_X509(x, &buf);
+
+ /* Other stuff ... */
+
+ OPENSSL_free(buf);
+
+This code will result in B<buf> apparently containing garbage because
+it was incremented after the call to point after the data just written.
+Also B<buf> will no longer contain the pointer allocated by B<OPENSSL_malloc()>
+and the subsequent call to B<OPENSSL_free()> may well crash.
+
+The auto allocation feature (setting buf to NULL) only works on OpenSSL
+0.9.7 and later. Attempts to use it on earlier versions will typically
+cause a segmentation violation.
+
+Another trap to avoid is misuse of the B<xp> argument to B<d2i_X509()>:
+
+ X509 *x;
+
+ if (!d2i_X509(&x, &p, len))
+        /* Some error */
+
+This will probably crash somewhere in B<d2i_X509()>. The reason for this
+is that the variable B<x> is uninitialized and an attempt will be made to
+interpret its (invalid) value as an B<X509> structure, typically causing
+a segmentation violation. If B<x> is set to NULL first then this will not
+happen.
+
+=head1 BUGS
+
+In some versions of OpenSSL the "reuse" behaviour of d2i_X509() when 
+B<*px> is valid is broken and some parts of the reused structure may
+persist if they are not present in the new one. As a result the use
+of this "reuse" behaviour is strongly discouraged.
+
+i2d_X509() will not return an error in many versions of OpenSSL,
+if mandatory fields are not initialized due to a programming error
+then the encoded structure may contain invalid data or omit the
+fields entirely and will not be parsed by d2i_X509(). This may be
+fixed in future so code should not assume that i2d_X509() will
+always succeed.
+
+=head1 RETURN VALUES
+
+d2i_X509(), d2i_X509_bio() and d2i_X509_fp() return a valid B<X509> structure
+or B<NULL> if an error occurs. The error code that can be obtained by
+L<ERR_get_error(3)|ERR_get_error(3)>. 
+
+i2d_X509(), i2d_X509_bio() and i2d_X509_fp() return a the number of bytes
+successfully encoded or a negative value if an error occurs. The error code
+can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>. 
+
+i2d_X509_bio() and i2d_X509_fp() returns 1 for success and 0 if an error 
+occurs The error code can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>. 
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>
+
+=head1 HISTORY
+
+d2i_X509, i2d_X509, d2i_X509_bio, d2i_X509_fp, i2d_X509_bio and i2d_X509_fp
+are available in all versions of SSLeay and OpenSSL.
+
+=cut
diff --git a/src/lib/libcrypto/doc/d2i_X509_ALGOR.pod b/src/lib/libcrypto/doc/d2i_X509_ALGOR.pod
new file mode 100644
index 0000000000..9e5cd92ca7
--- /dev/null
+++ b/src/lib/libcrypto/doc/d2i_X509_ALGOR.pod
@@ -0,0 +1,30 @@
+=pod
+
+=head1 NAME
+
+d2i_X509_ALGOR, i2d_X509_ALGOR - AlgorithmIdentifier functions.
+
+=head1 SYNOPSIS
+
+ #include <openssl/x509.h>
+
+ X509_ALGOR *d2i_X509_ALGOR(X509_ALGOR **a, unsigned char **pp, long length);
+ int i2d_X509_ALGOR(X509_ALGOR *a, unsigned char **pp);
+
+=head1 DESCRIPTION
+
+These functions decode and encode an B<X509_ALGOR> structure which is
+equivalent to the B<AlgorithmIdentifier> structure.
+
+Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
+
+=head1 SEE ALSO
+
+L<d2i_X509(3)|d2i_X509(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/d2i_X509_CRL.pod b/src/lib/libcrypto/doc/d2i_X509_CRL.pod
new file mode 100644
index 0000000000..06c5b23c09
--- /dev/null
+++ b/src/lib/libcrypto/doc/d2i_X509_CRL.pod
@@ -0,0 +1,37 @@
+=pod
+
+=head1 NAME
+
+d2i_X509_CRL, i2d_X509_CRL, d2i_X509_CRL_bio, d2i_509_CRL_fp,
+i2d_X509_CRL_bio, i2d_X509_CRL_fp - PKCS#10 certificate request functions.
+
+=head1 SYNOPSIS
+
+ #include <openssl/x509.h>
+
+ X509_CRL *d2i_X509_CRL(X509_CRL **a, unsigned char **pp, long length);
+ int i2d_X509_CRL(X509_CRL *a, unsigned char **pp);
+
+ X509_CRL *d2i_X509_CRL_bio(BIO *bp, X509_CRL **x);
+ X509_CRL *d2i_X509_CRL_fp(FILE *fp, X509_CRL **x);
+
+ int i2d_X509_CRL_bio(X509_CRL *x, BIO *bp);
+ int i2d_X509_CRL_fp(X509_CRL *x, FILE *fp);
+
+=head1 DESCRIPTION
+
+These functions decode and encode an X509 CRL (certificate revocation
+list).
+
+Othewise the functions behave in a similar way to d2i_X509() and i2d_X509()
+described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
+
+=head1 SEE ALSO
+
+L<d2i_X509(3)|d2i_X509(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/d2i_X509_NAME.pod b/src/lib/libcrypto/doc/d2i_X509_NAME.pod
new file mode 100644
index 0000000000..343ffe1519
--- /dev/null
+++ b/src/lib/libcrypto/doc/d2i_X509_NAME.pod
@@ -0,0 +1,31 @@
+=pod
+
+=head1 NAME
+
+d2i_X509_NAME, i2d_X509_NAME - X509_NAME encoding functions
+
+=head1 SYNOPSIS
+
+ #include <openssl/x509.h>
+
+ X509_NAME *d2i_X509_NAME(X509_NAME **a, unsigned char **pp, long length);
+ int i2d_X509_NAME(X509_NAME *a, unsigned char **pp);
+
+=head1 DESCRIPTION
+
+These functions decode and encode an B<X509_NAME> structure which is the
+the same as the B<Name> type defined in RFC2459 (and elsewhere) and used
+for example in certificate subject and issuer names.
+
+Othewise the functions behave in a similar way to d2i_X509() and i2d_X509()
+described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
+
+=head1 SEE ALSO
+
+L<d2i_X509(3)|d2i_X509(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/d2i_X509_REQ.pod b/src/lib/libcrypto/doc/d2i_X509_REQ.pod
new file mode 100644
index 0000000000..be4ad68257
--- /dev/null
+++ b/src/lib/libcrypto/doc/d2i_X509_REQ.pod
@@ -0,0 +1,36 @@
+=pod
+
+=head1 NAME
+
+d2i_X509_REQ, i2d_X509_REQ, d2i_X509_REQ_bio, d2i_X509_REQ_fp,
+i2d_X509_REQ_bio, i2d_X509_REQ_fp - PKCS#10 certificate request functions.
+
+=head1 SYNOPSIS
+
+ #include <openssl/x509.h>
+
+ X509_REQ *d2i_X509_REQ(X509_REQ **a, unsigned char **pp, long length);
+ int i2d_X509_REQ(X509_REQ *a, unsigned char **pp);
+
+ X509_REQ *d2i_X509_REQ_bio(BIO *bp, X509_REQ **x);
+ X509_REQ *d2i_X509_REQ_fp(FILE *fp, X509_REQ **x);
+
+ int i2d_X509_REQ_bio(X509_REQ *x, BIO *bp);
+ int i2d_X509_REQ_fp(X509_REQ *x, FILE *fp);
+
+=head1 DESCRIPTION
+
+These functions decode and encode a PKCS#10 certificate request.
+
+Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
+
+=head1 SEE ALSO
+
+L<d2i_X509(3)|d2i_X509(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/d2i_X509_SIG.pod b/src/lib/libcrypto/doc/d2i_X509_SIG.pod
new file mode 100644
index 0000000000..e48fd79a51
--- /dev/null
+++ b/src/lib/libcrypto/doc/d2i_X509_SIG.pod
@@ -0,0 +1,30 @@
+=pod
+
+=head1 NAME
+
+d2i_X509_SIG, i2d_X509_SIG - DigestInfo functions.
+
+=head1 SYNOPSIS
+
+ #include <openssl/x509.h>
+
+ X509_SIG *d2i_X509_SIG(X509_SIG **a, unsigned char **pp, long length);
+ int i2d_X509_SIG(X509_SIG *a, unsigned char **pp);
+
+=head1 DESCRIPTION
+
+These functions decode and encode an X509_SIG structure which is
+equivalent to the B<DigestInfo> structure defined in PKCS#1 and PKCS#7.
+
+Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+described in the L<d2i_X509(3)|d2i_X509(3)> manual page.
+
+=head1 SEE ALSO
+
+L<d2i_X509(3)|d2i_X509(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libcrypto/doc/engine.pod b/src/lib/libcrypto/doc/engine.pod
index 61e0264bb7..c77dad5562 100644
--- a/src/lib/libcrypto/doc/engine.pod
+++ b/src/lib/libcrypto/doc/engine.pod
@@ -187,7 +187,7 @@ tell which one you are dealing with at any given point in time (after all
 they are both simply (ENGINE *) pointers, the difference is in the way they
 are used).
 
-=head3 Structural references
+I<Structural references>
 
 This basic type of reference is typically used for creating new ENGINEs
 dynamically, iterating across OpenSSL's internal linked-list of loaded
@@ -224,7 +224,7 @@ To clarify a particular function's handling of references, one should
 always consult that function's documentation "man" page, or failing that
 the openssl/engine.h header file includes some hints.
 
-=head3 Functional references
+I<Functional references>
 
 As mentioned, functional references exist when the cryptographic
 functionality of an ENGINE is required to be available. A functional
@@ -386,7 +386,7 @@ things, so we will simply illustrate the consequences as they apply to a
 couple of simple cases and leave developers to consider these and the
 source code to openssl's builtin utilities as guides.
 
-=head3 Using a specific ENGINE implementation
+I<Using a specific ENGINE implementation>
 
 Here we'll assume an application has been configured by its user or admin
 to want to use the "ACME" ENGINE if it is available in the version of
@@ -418,7 +418,7 @@ illustrates how to approach this;
  /* Release the structural reference from ENGINE_by_id() */
  ENGINE_free(e);
 
-=head3 Automatically using builtin ENGINE implementations
+I<Automatically using builtin ENGINE implementations>
 
 Here we'll assume we want to load and register all ENGINE implementations
 bundled with OpenSSL, such that for any cryptographic algorithm required by
@@ -469,7 +469,7 @@ in same cases both. ENGINE implementations should provide indications of
 this in the descriptions attached to builtin control commands and/or in
 external product documentation.
 
-=head3 Issuing control commands to an ENGINE
+I<Issuing control commands to an ENGINE>
 
 Let's illustrate by example; a function for which the caller supplies the
 name of the ENGINE it wishes to use, a table of string-pairs for use before
@@ -526,7 +526,7 @@ return success without doing anything. In this case we assume the user is
 only supplying commands specific to the given ENGINE so we set this to
 FALSE.
 
-=head3 Discovering supported control commands
+I<Discovering supported control commands>
 
 It is possible to discover at run-time the names, numerical-ids, descriptions
 and input parameters of the control commands supported from a structural