101 files changed, 2872 insertions, 192 deletions

diff --git a/src/lib/libssl/src/doc/HOWTO/certificates.txt b/src/lib/libssl/src/doc/HOWTO/certificates.txt
index 88048645db..d3a62545ad 100644
--- a/src/lib/libssl/src/doc/HOWTO/certificates.txt
+++ b/src/lib/libssl/src/doc/HOWTO/certificates.txt
@@ -1,6 +1,8 @@
 <DRAFT!>
                         HOWTO certificates
 
+1. Introduction
+
 How you handle certificates depend a great deal on what your role is.
 Your role can be one or several of:
 
@@ -13,12 +15,14 @@ Certificate authorities should read ca.txt.
 
 In all the cases shown below, the standard configuration file, as
 compiled into openssl, will be used.  You may find it in /etc/,
-/usr/local/ssr/ or somewhere else.  The name is openssl.cnf, and
+/usr/local/ssl/ or somewhere else.  The name is openssl.cnf, and
 is better described in another HOWTO <config.txt?>.  If you want to
 use a different configuration file, use the argument '-config {file}'
 with the command shown below.
 
 
+2. Relationship with keys
+
 Certificates are related to public key cryptography by containing a
 public key.  To be useful, there must be a corresponding private key
 somewhere.  With OpenSSL, public keys are easily derived from private
@@ -26,22 +30,25 @@ keys, so before you create a certificate or a certificate request, you
 need to create a private key.
 
 Private keys are generated with 'openssl genrsa' if you want a RSA
-private key, or 'openssl gendsa' if you want a DSA private key.  More
-info on how to handle these commands are found in the manual pages for
-those commands or by running them with the argument '-h'.  For the
-sake of the description in this file, let's assume that the private
-key ended up in the file privkey.pem (which is the default in some
-cases).
-
-
-Let's start with the most normal way of getting a certificate.  Most
-often, you want or need to get a certificate from a certificate
-authority.  To handle that, the certificate authority needs a
-certificate request (or, as some certificate authorities like to put
+private key, or 'openssl gendsa' if you want a DSA private key.
+Further information on how to create private keys can be found in
+another HOWTO <keys.txt?>.  The rest of this text assumes you have
+a private key in the file privkey.pem.
+
+
+3. Creating a certificate request
+
+To create a certificate, you need to start with a certificate
+request (or, as some certificate authorities like to put
 it, "certificate signing request", since that's exactly what they do,
 they sign it and give you the result back, thus making it authentic
-according to their policies) from you.  To generate a request, use the
-command 'openssl req' like this:
+according to their policies).  A certificate request can then be sent
+to a certificate authority to get it signed into a certificate, or if
+you have your own certificate authority, you may sign it yourself, or
+if you need a self-signed certificate (because you just want a test
+certificate or because you are setting up your own CA).
+
+The certificate request is created like this:
 
   openssl req -new -key privkey.pem -out cert.csr
 
@@ -55,9 +62,23 @@ When the certificate authority has then done the checks the need to
 do (and probably gotten payment from you), they will hand over your
 new certificate to you.
 
+Section 5 will tell you more on how to handle the certificate you
+received.
+
+
+4. Creating a self-signed certificate
+
+If you don't want to deal with another certificate authority, or just
+want to create a test certificate for yourself, or are setting up a
+certificate authority of your own, you may want to make the requested
+certificate a self-signed one.  This is similar to creating a
+certificate request, but creates a certificate instead of a
+certificate request (1095 is 3 years):
+
+  openssl req -new -x509 -key privkey.pem -out cacert.pem -days 1095
 
-[fill in on how to create a self-signed certificate]
 
+5. What to do with the certificate
 
 If you created everything yourself, or if the certificate authority
 was kind enough, your certificate is a raw DER thing in PEM format.
diff --git a/src/lib/libssl/src/doc/HOWTO/keys.txt b/src/lib/libssl/src/doc/HOWTO/keys.txt
new file mode 100644
index 0000000000..45f42eaaf1
--- /dev/null
+++ b/src/lib/libssl/src/doc/HOWTO/keys.txt
@@ -0,0 +1,73 @@
+<DRAFT!>
+                        HOWTO keys
+
+1. Introduction
+
+Keys are the basis of public key algorithms and PKI.  Keys usually
+come in pairs, with one half being the public key and the other half
+being the private key.  With OpenSSL, the private key contains the
+public key information as well, so a public key doesn't need to be
+generated separately.
+
+Public keys come in several flavors, using different cryptographic
+algorithms.  The most popular ones associated with certificates are
+RSA and DSA, and this HOWTO will show how to generate each of them.
+
+
+2. To generate a RSA key
+
+A RSA key can be used both for encryption and for signing.
+
+Generating a key for the RSA algorithm is quite easy, all you have to
+do is the following:
+
+  openssl genrsa -des3 -out privkey.pem 2048
+
+With this variant, you will be prompted for a protecting password.  If
+you don't want your key to be protected by a password, remove the flag
+'-des3' from the command line above.
+
+    NOTE: if you intend to use the key together with a server
+    certificate, it may be a good thing to avoid protecting it
+    with a password, since that would mean someone would have to
+    type in the password every time the server needs to access
+    the key.
+
+The number 2048 is the size of the key, in bits.  Today, 2048 or
+higher is recommended for RSA keys, as fewer amount of bits is
+consider insecure or to be insecure pretty soon.
+
+
+3. To generate a DSA key
+
+A DSA key can be used both for signing only.  This is important to
+keep in mind to know what kind of purposes a certificate request with
+a DSA key can really be used for.
+
+Generating a key for the DSA algorithm is a two-step process.  First,
+you have to generate parameters from which to generate the key:
+
+  openssl dsaparam -out dsaparam.pem 2048
+
+The number 2048 is the size of the key, in bits.  Today, 2048 or
+higher is recommended for DSA keys, as fewer amount of bits is
+consider insecure or to be insecure pretty soon.
+
+When that is done, you can generate a key using the parameters in
+question (actually, several keys can be generated from the same
+parameters):
+
+  openssl gendsa -des3 -out privkey.pem dsaparam.pem
+
+With this variant, you will be prompted for a protecting password.  If
+you don't want your key to be protected by a password, remove the flag
+'-des3' from the command line above.
+
+    NOTE: if you intend to use the key together with a server
+    certificate, it may be a good thing to avoid protecting it
+    with a password, since that would mean someone would have to
+    type in the password every time the server needs to access
+    the key.
+
+-- 
+Richard Levitte
diff --git a/src/lib/libssl/src/doc/apps/ca.pod b/src/lib/libssl/src/doc/apps/ca.pod
index c2ca8f2400..de66c534b5 100644
--- a/src/lib/libssl/src/doc/apps/ca.pod
+++ b/src/lib/libssl/src/doc/apps/ca.pod
@@ -13,6 +13,10 @@ B<openssl> B<ca>
 [B<-name section>]
 [B<-gencrl>]
 [B<-revoke file>]
+[B<-crl_reason reason>]
+[B<-crl_hold instruction>]
+[B<-crl_compromise time>]
+[B<-crl_CA_compromise time>]
 [B<-subj arg>]
 [B<-crldays days>]
 [B<-crlhours hours>]
@@ -39,6 +43,7 @@ B<openssl> B<ca>
 [B<-msie_hack>]
 [B<-extensions section>]
 [B<-extfile section>]
+[B<-engine id>]
 
 =head1 DESCRIPTION
 
@@ -74,7 +79,7 @@ a single self signed certificate to be signed by the CA.
 =item B<-spkac filename>
 
 a file containing a single Netscape signed public key and challenge
-and additional field values to be signed by the CA. See the B<NOTES>
+and additional field values to be signed by the CA. See the B<SPKAC FORMAT>
 section for information on the required format.
 
 =item B<-infiles>
@@ -191,6 +196,13 @@ an additional configuration file to read certificate extensions from
 (using the default section unless the B<-extensions> option is also
 used).
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =back
 
 =head1 CRL OPTIONS
@@ -214,6 +226,33 @@ the number of hours before the next CRL is due.
 
 a filename containing a certificate to revoke.
 
+=item B<-crl_reason reason>
+
+revocation reason, where B<reason> is one of: B<unspecified>, B<keyCompromise>,
+B<CACompromise>, B<affiliationChanged>, B<superseded>, B<cessationOfOperation>,
+B<certificateHold> or B<removeFromCRL>. The matching of B<reason> is case
+insensitive. Setting any revocation reason will make the CRL v2.
+
+In practive B<removeFromCRL> is not particularly useful because it is only used
+in delta CRLs which are not currently implemented.
+
+=item B<-crl_hold instruction>
+
+This sets the CRL revocation reason code to B<certificateHold> and the hold
+instruction to B<instruction> which must be an OID. Although any OID can be
+used only B<holdInstructionNone> (the use of which is discouraged by RFC2459)
+B<holdInstructionCallIssuer> or B<holdInstructionReject> will normally be used.
+
+=item B<-crl_compromise time>
+
+This sets the revocation reason to B<keyCompromise> and the compromise time to
+B<time>. B<time> should be in GeneralizedTime format that is B<YYYYMMDDHHMMSSZ>.
+
+=item B<-crl_CA_compromise time>
+
+This is the same as B<crl_compromise> except the revocation reason is set to
+B<CACompromise>.
+
 =item B<-subj arg>
 
 supersedes subject name given in the request.
@@ -486,18 +525,6 @@ A sample configuration file with the relevant sections for B<ca>:
  commonName             = supplied
  emailAddress           = optional
 
-=head1 WARNINGS
-
-The B<ca> command is quirky and at times downright unfriendly.
-
-The B<ca> utility was originally meant as an example of how to do things
-in a CA. It was not supposed to be used as a full blown CA itself:
-nevertheless some people are using it for this purpose.
-
-The B<ca> command is effectively a single user command: no locking is
-done on the various files and attempts to run more than one B<ca> command
-on the same database can have unpredictable results.
-
 =head1 FILES
 
 Note: the location of all files can change either by compile time options,
@@ -527,9 +554,6 @@ if corrupted it can be difficult to fix. It is theoretically possible
 to rebuild the index file from all the issued certificates and a current
 CRL: however there is no option to do this.
 
-CRL entry extensions cannot currently be created: only CRL extensions
-can be added.
-
 V2 CRL features like delta CRL support and CRL numbers are not currently
 supported.
 
@@ -565,6 +589,16 @@ create an empty file.
 
 =head1 WARNINGS
 
+The B<ca> command is quirky and at times downright unfriendly.
+
+The B<ca> utility was originally meant as an example of how to do things
+in a CA. It was not supposed to be used as a full blown CA itself:
+nevertheless some people are using it for this purpose.
+
+The B<ca> command is effectively a single user command: no locking is
+done on the various files and attempts to run more than one B<ca> command
+on the same database can have unpredictable results.
+
 The B<copy_extensions> option should be used with caution. If care is
 not taken then it can be a security risk. For example if a certificate
 request contains a basicConstraints extension with CA:TRUE and the
diff --git a/src/lib/libssl/src/doc/apps/ciphers.pod b/src/lib/libssl/src/doc/apps/ciphers.pod
index b7e577b24f..81a2c43893 100644
--- a/src/lib/libssl/src/doc/apps/ciphers.pod
+++ b/src/lib/libssl/src/doc/apps/ciphers.pod
@@ -203,6 +203,10 @@ cipher suites using DH, including anonymous DH.
 
 anonymous DH cipher suites.
 
+=item B<AES>
+
+cipher suites using AES.
+
 =item B<3DES>
 
 cipher suites using triple DES.
@@ -236,7 +240,9 @@ cipher suites using SHA1.
 =head1 CIPHER SUITE NAMES
 
 The following lists give the SSL or TLS cipher suites names from the
-relevant specification and their OpenSSL equivalents.
+relevant specification and their OpenSSL equivalents. It should be noted,
+that several cipher suite names do not include the authentication used,
+e.g. DES-CBC3-SHA. In these cases, RSA authentication is used.
 
 =head2 SSL v3.0 cipher suites.
 
@@ -306,6 +312,24 @@ relevant specification and their OpenSSL equivalents.
  TLS_DH_anon_WITH_DES_CBC_SHA            ADH-DES-CBC-SHA
  TLS_DH_anon_WITH_3DES_EDE_CBC_SHA       ADH-DES-CBC3-SHA
 
+=head2 AES ciphersuites from RFC3268, extending TLS v1.0
+
+ TLS_RSA_WITH_AES_128_CBC_SHA            AES128-SHA
+ TLS_RSA_WITH_AES_256_CBC_SHA            AES256-SHA
+
+ TLS_DH_DSS_WITH_AES_128_CBC_SHA         DH-DSS-AES128-SHA
+ TLS_DH_DSS_WITH_AES_256_CBC_SHA         DH-DSS-AES256-SHA
+ TLS_DH_RSA_WITH_AES_128_CBC_SHA         DH-RSA-AES128-SHA
+ TLS_DH_RSA_WITH_AES_256_CBC_SHA         DH-RSA-AES256-SHA
+
+ TLS_DHE_DSS_WITH_AES_128_CBC_SHA        DHE-DSS-AES128-SHA
+ TLS_DHE_DSS_WITH_AES_256_CBC_SHA        DHE-DSS-AES256-SHA
+ TLS_DHE_RSA_WITH_AES_128_CBC_SHA        DHE-RSA-AES128-SHA
+ TLS_DHE_RSA_WITH_AES_256_CBC_SHA        DHE-RSA-AES256-SHA
+
+ TLS_DH_anon_WITH_AES_128_CBC_SHA        ADH-AES128-SHA
+ TLS_DH_anon_WITH_AES_256_CBC_SHA        ADH-AES256-SHA
+
 =head2 Additional Export 1024 and other cipher suites
 
 Note: these ciphers can also be used in SSL v3.
diff --git a/src/lib/libssl/src/doc/apps/dhparam.pod b/src/lib/libssl/src/doc/apps/dhparam.pod
index ff8a6e5e5b..c31db95a47 100644
--- a/src/lib/libssl/src/doc/apps/dhparam.pod
+++ b/src/lib/libssl/src/doc/apps/dhparam.pod
@@ -18,6 +18,7 @@ B<openssl dhparam>
 [B<-2>]
 [B<-5>]
 [B<-rand> I<file(s)>]
+[B<-engine id>]
 [I<numbits>]
 
 =head1 DESCRIPTION
@@ -96,6 +97,13 @@ this option prints out the DH parameters in human readable form.
 this option converts the parameters into C code. The parameters can then
 be loaded by calling the B<get_dh>I<numbits>B<()> function.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =back
 
 =head1 WARNINGS
diff --git a/src/lib/libssl/src/doc/apps/dsa.pod b/src/lib/libssl/src/doc/apps/dsa.pod
index 28e534bb95..ed06b8806d 100644
--- a/src/lib/libssl/src/doc/apps/dsa.pod
+++ b/src/lib/libssl/src/doc/apps/dsa.pod
@@ -21,6 +21,7 @@ B<openssl> B<dsa>
 [B<-modulus>]
 [B<-pubin>]
 [B<-pubout>]
+[B<-engine id>]
 
 =head1 DESCRIPTION
 
@@ -106,6 +107,13 @@ by default a private key is output. With this option a public
 key will be output instead. This option is automatically set if the input is
 a public key.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =back
 
 =head1 NOTES
diff --git a/src/lib/libssl/src/doc/apps/dsaparam.pod b/src/lib/libssl/src/doc/apps/dsaparam.pod
index 50c2f61242..b9b1b93b42 100644
--- a/src/lib/libssl/src/doc/apps/dsaparam.pod
+++ b/src/lib/libssl/src/doc/apps/dsaparam.pod
@@ -16,6 +16,7 @@ B<openssl dsaparam>
 [B<-C>]
 [B<-rand file(s)>]
 [B<-genkey>]
+[B<-engine id>]
 [B<numbits>]
 
 =head1 DESCRIPTION
@@ -82,6 +83,13 @@ this option specifies that a parameter set should be generated of size
 B<numbits>. It must be the last option. If this option is included then
 the input file (if any) is ignored.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =back
 
 =head1 NOTES
diff --git a/src/lib/libssl/src/doc/apps/gendsa.pod b/src/lib/libssl/src/doc/apps/gendsa.pod
index 74318fe7fb..2c56cc7888 100644
--- a/src/lib/libssl/src/doc/apps/gendsa.pod
+++ b/src/lib/libssl/src/doc/apps/gendsa.pod
@@ -12,6 +12,7 @@ B<openssl> B<gendsa>
 [B<-des3>]
 [B<-idea>]
 [B<-rand file(s)>]
+[B<-engine id>]
 [B<paramfile>]
 
 =head1 DESCRIPTION
@@ -37,6 +38,13 @@ Multiple files can be specified separated by a OS-dependent character.
 The separator is B<;> for MS-Windows, B<,> for OpenVMS, and B<:> for
 all others.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =item B<paramfile>
 
 This option specifies the DSA parameter file to use. The parameters in this
diff --git a/src/lib/libssl/src/doc/apps/genrsa.pod b/src/lib/libssl/src/doc/apps/genrsa.pod
index cdcc03c123..25af4d1475 100644
--- a/src/lib/libssl/src/doc/apps/genrsa.pod
+++ b/src/lib/libssl/src/doc/apps/genrsa.pod
@@ -15,6 +15,7 @@ B<openssl> B<genrsa>
 [B<-f4>]
 [B<-3>]
 [B<-rand file(s)>]
+[B<-engine id>]
 [B<numbits>]
 
 =head1 DESCRIPTION
@@ -54,6 +55,13 @@ Multiple files can be specified separated by a OS-dependent character.
 The separator is B<;> for MS-Windows, B<,> for OpenVMS, and B<:> for
 all others.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =item B<numbits>
 
 the size of the private key to generate in bits. This must be the last option
diff --git a/src/lib/libssl/src/doc/apps/ocsp.pod b/src/lib/libssl/src/doc/apps/ocsp.pod
index da201b95e6..4f266058e5 100644
--- a/src/lib/libssl/src/doc/apps/ocsp.pod
+++ b/src/lib/libssl/src/doc/apps/ocsp.pod
@@ -11,6 +11,10 @@ B<openssl> B<ocsp>
 [B<-issuer file>]
 [B<-cert file>]
 [B<-serial n>]
+[B<-signer file>]
+[B<-signkey file>]
+[B<-sign_other file>]
+[B<-no_certs>]
 [B<-req_text>]
 [B<-resp_text>]
 [B<-text>]
@@ -20,27 +24,36 @@ B<openssl> B<ocsp>
 [B<-respin file>]
 [B<-nonce>]
 [B<-no_nonce>]
-[B<-url responder_url>]
+[B<-url URL>]
 [B<-host host:n>]
 [B<-path>]
-[B<-CApath file>]
+[B<-CApath dir>]
 [B<-CAfile file>]
 [B<-VAfile file>]
-[B<-verify_certs file>]
+[B<-validity_period n>]
+[B<-status_age n>]
 [B<-noverify>]
+[B<-verify_other file>]
 [B<-trust_other>]
 [B<-no_intern>]
-[B<-no_sig_verify>]
+[B<-no_signature_verify>]
 [B<-no_cert_verify>]
 [B<-no_chain>]
 [B<-no_cert_checks>]
-[B<-validity_period nsec>]
-[B<-status_age nsec>]
+[B<-port num>]
+[B<-index file>]
+[B<-CA file>]
+[B<-rsigner file>]
+[B<-rkey file>]
+[B<-rother file>]
+[B<-resp_no_certs>]
+[B<-nmin n>]
+[B<-ndays n>]
+[B<-resp_key_id>]
+[B<-nrequest n>]
 
 =head1 DESCRIPTION
 
-B<WARNING: this documentation is preliminary and subject to change.>
-
 The Online Certificate Status Protocol (OCSP) enables applications to
 determine the (revocation) state of an identified certificate (RFC 2560).
 
@@ -83,6 +96,10 @@ the B<signkey> option is not present then the private key is read
 from the same file as the certificate. If neither option is specified then
 the OCSP request is not signed.
 
+=item B<-sign_other filename>
+
+Additional certificates to include in the signed request.
+
 =item B<-nonce>, B<-no_nonce>
 
 Add an OCSP nonce extension to a request or disable OCSP nonce addition.
@@ -120,7 +137,7 @@ or "/" by default.
 file or pathname containing trusted CA certificates. These are used to verify
 the signature on the OCSP response.
 
-=item B<-verify_certs file>
+=item B<-verify_other file>
 
 file containing additional certificates to search when attempting to locate
 the OCSP response signing certificate. Some responders omit the actual signer's
@@ -151,7 +168,7 @@ ignore certificates contained in the OCSP response when searching for the
 signers certificate. With this option the signers certificate must be specified
 with either the B<-verify_certs> or B<-VAfile> options.
 
-=item B<-no_sig_verify>
+=item B<-no_signature_verify>
 
 don't check the signature on the OCSP response. Since this option tolerates invalid
 signatures on OCSP responses it will normally only be used for testing purposes.
diff --git a/src/lib/libssl/src/doc/apps/passwd.pod b/src/lib/libssl/src/doc/apps/passwd.pod
index 07d849c824..f44982549b 100644
--- a/src/lib/libssl/src/doc/apps/passwd.pod
+++ b/src/lib/libssl/src/doc/apps/passwd.pod
@@ -75,7 +75,7 @@ to each password hash.
 
 B<openssl passwd -crypt -salt xx password> prints B<xxj31ZMTZzkVA>.
 
-B<openssl passwd -1 -salt xxxxxxxx password> prints B<$1$xxxxxxxx$8XJIcl6ZXqBMCK0qFevqT1>.
+B<openssl passwd -1 -salt xxxxxxxx password> prints B<$1$xxxxxxxx$UYCIxa628.9qXjpQCjM4a.>.
 
 B<openssl passwd -apr1 -salt xxxxxxxx password> prints B<$apr1$xxxxxxxx$dxHfLAsjHkDRmG83UXe8K0>.
 
diff --git a/src/lib/libssl/src/doc/apps/pkcs7.pod b/src/lib/libssl/src/doc/apps/pkcs7.pod
index 9871c0e0cd..a0a636328b 100644
--- a/src/lib/libssl/src/doc/apps/pkcs7.pod
+++ b/src/lib/libssl/src/doc/apps/pkcs7.pod
@@ -14,6 +14,7 @@ B<openssl> B<pkcs7>
 [B<-print_certs>]
 [B<-text>]
 [B<-noout>]
+[B<-engine id>]
 
 =head1 DESCRIPTION
 
@@ -59,6 +60,13 @@ issuer names.
 don't output the encoded version of the PKCS#7 structure (or certificates
 is B<-print_certs> is set).
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =back
 
 =head1 EXAMPLES
diff --git a/src/lib/libssl/src/doc/apps/pkcs8.pod b/src/lib/libssl/src/doc/apps/pkcs8.pod
index a56b2dd002..68ecd65b10 100644
--- a/src/lib/libssl/src/doc/apps/pkcs8.pod
+++ b/src/lib/libssl/src/doc/apps/pkcs8.pod
@@ -21,6 +21,7 @@ B<openssl> B<pkcs8>
 [B<-nsdb>]
 [B<-v2 alg>]
 [B<-v1 alg>]
+[B<-engine id>]
 
 =head1 DESCRIPTION
 
@@ -122,6 +123,13 @@ B<des>, B<des3> and B<rc2>. It is recommended that B<des3> is used.
 This option specifies a PKCS#5 v1.5 or PKCS#12 algorithm to use. A complete
 list of possible algorithms is included below.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =back
 
 =head1 NOTES
diff --git a/src/lib/libssl/src/doc/apps/req.pod b/src/lib/libssl/src/doc/apps/req.pod
index 10e4e12a5c..e2b5d0d8ec 100644
--- a/src/lib/libssl/src/doc/apps/req.pod
+++ b/src/lib/libssl/src/doc/apps/req.pod
@@ -41,6 +41,7 @@ B<openssl> B<req>
 [B<-nameopt>]
 [B<-batch>]
 [B<-verbose>]
+[B<-engine id>]
 
 =head1 DESCRIPTION
 
@@ -244,6 +245,13 @@ non-interactive mode.
 
 print extra details about the operations being performed.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =back
 
 =head1 CONFIGURATION FILE FORMAT
@@ -406,7 +414,7 @@ be input by calling it "1.organizationName".
 The actual permitted field names are any object identifier short or
 long names. These are compiled into OpenSSL and include the usual
 values such as commonName, countryName, localityName, organizationName,
-organizationUnitName, stateOrPrivinceName. Additionally emailAddress
+organizationUnitName, stateOrProvinceName. Additionally emailAddress
 is include as well as name, surname, givenName initials and dnQualifier.
 
 Additional object identifiers can be defined with the B<oid_file> or
@@ -512,13 +520,13 @@ Sample configuration containing all field values:
 
 The header and footer lines in the B<PEM> format are normally:
 
- -----BEGIN CERTIFICATE REQUEST----
- -----END CERTIFICATE REQUEST----
+ -----BEGIN CERTIFICATE REQUEST-----
+ -----END CERTIFICATE REQUEST-----
 
 some software (some versions of Netscape certificate server) instead needs:
 
- -----BEGIN NEW CERTIFICATE REQUEST----
- -----END NEW CERTIFICATE REQUEST----
+ -----BEGIN NEW CERTIFICATE REQUEST-----
+ -----END NEW CERTIFICATE REQUEST-----
 
 which is produced with the B<-newhdr> option but is otherwise compatible.
 Either form is accepted transparently on input.
diff --git a/src/lib/libssl/src/doc/apps/rsa.pod b/src/lib/libssl/src/doc/apps/rsa.pod
index ef74f1adff..4d7640995e 100644
--- a/src/lib/libssl/src/doc/apps/rsa.pod
+++ b/src/lib/libssl/src/doc/apps/rsa.pod
@@ -24,6 +24,7 @@ B<openssl> B<rsa>
 [B<-check>]
 [B<-pubin>]
 [B<-pubout>]
+[B<-engine id>]
 
 =head1 DESCRIPTION
 
@@ -117,6 +118,13 @@ by default a private key is output: with this option a public
 key will be output instead. This option is automatically set if
 the input is a public key.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
+
 =back
 
 =head1 NOTES
diff --git a/src/lib/libssl/src/doc/apps/s_client.pod b/src/lib/libssl/src/doc/apps/s_client.pod
index 7fca9cbdbd..47dc93cb3f 100644
--- a/src/lib/libssl/src/doc/apps/s_client.pod
+++ b/src/lib/libssl/src/doc/apps/s_client.pod
@@ -33,6 +33,7 @@ B<openssl> B<s_client>
 [B<-no_tls1>]
 [B<-bugs>]
 [B<-cipher cipherlist>]
+[B<-starttls protocol>]
 [B<-engine id>]
 [B<-rand file(s)>]
 
@@ -163,6 +164,12 @@ the server determines which cipher suite is used it should take the first
 supported cipher in the list sent by the client. See the B<ciphers>
 command for more information.
 
+=item B<-starttls protocol>
+
+send the protocol-specific message(s) to switch to TLS for communication.
+B<protocol> is a keyword for the intended protocol.  Currently, the only
+supported keyword is "smtp".
+
 =item B<-engine id>
 
 specifying an engine (by it's unique B<id> string) will cause B<s_client>
diff --git a/src/lib/libssl/src/doc/apps/s_server.pod b/src/lib/libssl/src/doc/apps/s_server.pod
index 4b1e4260ef..1d21921e47 100644
--- a/src/lib/libssl/src/doc/apps/s_server.pod
+++ b/src/lib/libssl/src/doc/apps/s_server.pod
@@ -42,6 +42,7 @@ B<openssl> B<s_server>
 [B<-WWW>]
 [B<-HTTP>]
 [B<-engine id>]
+[B<-id_prefix arg>]
 [B<-rand file(s)>]
 
 =head1 DESCRIPTION
@@ -209,6 +210,13 @@ to attempt to obtain a functional reference to the specified engine,
 thus initialising it if needed. The engine will then be set as the default
 for all available algorithms.
 
+=item B<-id_prefix arg>
+
+generate SSL/TLS session IDs prefixed by B<arg>. This is mostly useful
+for testing any SSL/TLS code (eg. proxies) that wish to deal with multiple
+servers, when each of which might be generating a unique range of session
+IDs (eg. with a certain prefix).
+
 =item B<-rand file(s)>
 
 a file or files containing random data used to seed the random number
diff --git a/src/lib/libssl/src/doc/apps/smime.pod b/src/lib/libssl/src/doc/apps/smime.pod
index fa5d23e8dc..2453dd2738 100644
--- a/src/lib/libssl/src/doc/apps/smime.pod
+++ b/src/lib/libssl/src/doc/apps/smime.pod
@@ -340,8 +340,8 @@ detached signature format. You can use this program to verify the
 signature by line wrapping the base64 encoded structure and surrounding
 it with:
 
- -----BEGIN PKCS7----
- -----END PKCS7----
+ -----BEGIN PKCS7-----
+ -----END PKCS7-----
 
 and using the command, 
 
diff --git a/src/lib/libssl/src/doc/apps/speed.pod b/src/lib/libssl/src/doc/apps/speed.pod
index 8101851ec6..0dcdba873e 100644
--- a/src/lib/libssl/src/doc/apps/speed.pod
+++ b/src/lib/libssl/src/doc/apps/speed.pod
@@ -54,4 +54,6 @@ for all available algorithms.
 If any options are given, B<speed> tests those algorithms, otherwise all of
 the above are tested.
 
+=back
+
 =cut
diff --git a/src/lib/libssl/src/doc/apps/spkac.pod b/src/lib/libssl/src/doc/apps/spkac.pod
index bb84dfbe33..c3f1ff9c64 100644
--- a/src/lib/libssl/src/doc/apps/spkac.pod
+++ b/src/lib/libssl/src/doc/apps/spkac.pod
@@ -17,7 +17,7 @@ B<openssl> B<spkac>
 [B<-spksect section>]
 [B<-noout>]
 [B<-verify>]
-
+[B<-engine id>]
 
 =head1 DESCRIPTION
 
@@ -79,6 +79,12 @@ being created).
 
 verifies the digital signature on the supplied SPKAC.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
 
 =back
 
diff --git a/src/lib/libssl/src/doc/apps/x509.pod b/src/lib/libssl/src/doc/apps/x509.pod
index 4a17e338dd..50343cd685 100644
--- a/src/lib/libssl/src/doc/apps/x509.pod
+++ b/src/lib/libssl/src/doc/apps/x509.pod
@@ -50,6 +50,7 @@ B<openssl> B<x509>
 [B<-clrext>]
 [B<-extfile filename>]
 [B<-extensions section>]
+[B<-engine id>]
 
 =head1 DESCRIPTION
 
@@ -61,8 +62,9 @@ certificate trust settings.
 Since there are a large number of options they will split up into
 various sections.
 
+=head1 OPTIONS
 
-=head1 INPUT, OUTPUT AND GENERAL PURPOSE OPTIONS
+=head2 INPUT, OUTPUT AND GENERAL PURPOSE OPTIONS
 
 =over 4
 
@@ -97,13 +99,19 @@ digest, such as the B<-fingerprint>, B<-signkey> and B<-CA> options. If not
 specified then MD5 is used. If the key being used to sign with is a DSA key then
 this option has no effect: SHA1 is always used with DSA keys.
 
+=item B<-engine id>
+
+specifying an engine (by it's unique B<id> string) will cause B<req>
+to attempt to obtain a functional reference to the specified engine,
+thus initialising it if needed. The engine will then be set as the default
+for all available algorithms.
 
 =back
 
-=head1 DISPLAY OPTIONS
+=head2 DISPLAY OPTIONS
 
 Note: the B<-alias> and B<-purpose> options are also display options
-but are described in the B<TRUST OPTIONS> section.
+but are described in the B<TRUST SETTINGS> section.
 
 =over 4
 
@@ -181,7 +189,7 @@ this outputs the certificate in the form of a C source file.
 
 =back
 
-=head1 TRUST SETTINGS
+=head2 TRUST SETTINGS
 
 Please note these options are currently experimental and may well change.
 
@@ -252,7 +260,7 @@ EXTENSIONS> section.
 
 =back
 
-=head1 SIGNING OPTIONS
+=head2 SIGNING OPTIONS
 
 The B<x509> utility can be used to sign certificates and requests: it
 can thus behave like a "mini CA".
@@ -341,7 +349,7 @@ The default filename consists of the CA certificate file base name with
 ".srl" appended. For example if the CA certificate file is called 
 "mycacert.pem" it expects to find a serial number file called "mycacert.srl".
 
-=item B<-CAcreateserial filename>
+=item B<-CAcreateserial>
 
 with this option the CA serial number file is created if it does not exist:
 it will contain the serial number "02" and the certificate being signed will
@@ -362,7 +370,7 @@ specified then the extensions should either be contained in the unnamed
 
 =back
 
-=head1 NAME OPTIONS
+=head2 NAME OPTIONS
 
 The B<nameopt> command line switch determines how the subject and issuer
 names are displayed. If no B<nameopt> switch is present the default "oneline"
@@ -499,7 +507,7 @@ name.
 
 =back
 
-=head1 TEXT OPTIONS
+=head2 TEXT OPTIONS
 
 As well as customising the name output format, it is also possible to
 customise the actual fields printed using the B<certopt> options when
@@ -636,25 +644,25 @@ certificate extensions:
 Set a certificate to be trusted for SSL client use and change set its alias to
 "Steve's Class 1 CA"
 
- openssl x509 -in cert.pem -addtrust sslclient \
-        -alias "Steve's Class 1 CA" -out trust.pem
+ openssl x509 -in cert.pem -addtrust clientAuth \
+        -setalias "Steve's Class 1 CA" -out trust.pem
 
 =head1 NOTES
 
 The PEM format uses the header and footer lines:
 
- -----BEGIN CERTIFICATE----
- -----END CERTIFICATE----
+ -----BEGIN CERTIFICATE-----
+ -----END CERTIFICATE-----
 
 it will also handle files containing:
 
- -----BEGIN X509 CERTIFICATE----
- -----END X509 CERTIFICATE----
+ -----BEGIN X509 CERTIFICATE-----
+ -----END X509 CERTIFICATE-----
 
 Trusted certificates have the lines
 
- -----BEGIN TRUSTED CERTIFICATE----
- -----END TRUSTED CERTIFICATE----
+ -----BEGIN TRUSTED CERTIFICATE-----
+ -----END TRUSTED CERTIFICATE-----
 
 The conversion to UTF8 format used with the name options assumes that
 T61Strings use the ISO8859-1 character set. This is wrong but Netscape
diff --git a/src/lib/libssl/src/doc/c-indentation.el b/src/lib/libssl/src/doc/c-indentation.el
index 48ca3cf69b..cbf01cb172 100644
--- a/src/lib/libssl/src/doc/c-indentation.el
+++ b/src/lib/libssl/src/doc/c-indentation.el
@@ -13,12 +13,10 @@
 ;
 ; Apparently statement blocks that are not introduced by a statement
 ; such as "if" and that are not the body of a function cannot
-; be handled too well by CC mode with this indentation style.
-; The style defined below does not indent them at all.
-; To insert tabs manually, prefix them with ^Q (the "quoted-insert"
-; command of Emacs).  If you know a solution to this problem
-; or find other problems with this indentation style definition,
-; please send e-mail to bodo@openssl.org.
+; be handled too well by CC mode with this indentation style,
+; so you have to indent them manually (you can use C-q tab).
+; 
+; For suggesting improvements, please send e-mail to bodo@openssl.org.
 
 (c-add-style "eay"
              '((c-basic-offset . 8)
diff --git a/src/lib/libssl/src/doc/crypto/ASN1_OBJECT_new.pod b/src/lib/libssl/src/doc/crypto/ASN1_OBJECT_new.pod
new file mode 100644
index 0000000000..51679bfcd9
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/ASN1_OBJECT_new.pod
@@ -0,0 +1,43 @@
+=pod
+
+=head1 NAME
+
+ASN1_OBJECT_new, ASN1_OBJECT_free, - object allocation functions
+
+=head1 SYNOPSIS
+
+ ASN1_OBJECT *ASN1_OBJECT_new(void);
+ void ASN1_OBJECT_free(ASN1_OBJECT *a);
+
+=head1 DESCRIPTION
+
+The ASN1_OBJECT allocation routines, allocate and free an
+ASN1_OBJECT structure, which represents an ASN1 OBJECT IDENTIFIER.
+
+ASN1_OBJECT_new() allocates and initializes a ASN1_OBJECT structure.
+
+ASN1_OBJECT_free() frees up the B<ASN1_OBJECT> structure B<a>.
+
+=head1 NOTES
+
+Although ASN1_OBJECT_new() allocates a new ASN1_OBJECT structure it
+is almost never used in applications. The ASN1 object utility functions
+such as OBJ_nid2obj() are used instead.
+
+=head1 RETURN VALUES
+
+If the allocation fails, ASN1_OBJECT_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.
+
+ASN1_OBJECT_free() returns no value.
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>, L<d2i_ASN1_OBJECT(3)|d2i_ASN1_OBJECT(3)>
+
+=head1 HISTORY
+
+ASN1_OBJECT_new() and ASN1_OBJECT_free() are available in all versions of SSLeay and OpenSSL.
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/ASN1_STRING_length.pod b/src/lib/libssl/src/doc/crypto/ASN1_STRING_length.pod
new file mode 100644
index 0000000000..c4ec693f17
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/ASN1_STRING_length.pod
@@ -0,0 +1,81 @@
+=pod
+
+=head1 NAME
+
+ASN1_STRING_dup, ASN1_STRING_cmp, ASN1_STRING_set, ASN1_STRING_length,
+ASN1_STRING_length_set, ASN1_STRING_type, ASN1_STRING_data -
+ASN1_STRING utility functions
+
+=head1 SYNOPSIS
+
+ int ASN1_STRING_length(ASN1_STRING *x);
+ unsigned char * ASN1_STRING_data(ASN1_STRING *x);
+
+ ASN1_STRING * ASN1_STRING_dup(ASN1_STRING *a);
+
+ int ASN1_STRING_cmp(ASN1_STRING *a, ASN1_STRING *b);
+
+ int ASN1_STRING_set(ASN1_STRING *str, const void *data, int len);
+
+ int ASN1_STRING_type(ASN1_STRING *x);
+
+ int ASN1_STRING_to_UTF8(unsigned char **out, ASN1_STRING *in);
+
+=head1 DESCRIPTION
+
+These functions allow an B<ASN1_STRING> structure to be manipulated.
+
+ASN1_STRING_length() returns the length of the content of B<x>.
+
+ASN1_STRING_data() returns an internal pointer to the data of B<x>.
+Since this is an internal pointer it should B<not> be freed or
+modified in any way.
+
+ASN1_STRING_dup() returns a copy of the structure B<a>.
+
+ASN1_STRING_cmp() compares B<a> and B<b> returning 0 if the two
+are identical. The string types and content are compared.
+
+ASN1_STRING_set() sets the data of string B<str> to the buffer
+B<data> or length B<len>. The supplied data is copied. If B<len>
+is -1 then the length is determined by strlen(data).
+
+ASN1_STRING_type() returns the type of B<x>, using standard constants
+such as B<V_ASN1_OCTET_STRING>.
+
+ASN1_STRING_to_UTF8() converts the string B<in> to UTF8 format, the
+converted data is allocated in a buffer in B<*out>. The length of
+B<out> is returned or a negative error code. The buffer B<*out>
+should be free using OPENSSL_free().
+
+=head1 NOTES
+
+Almost all ASN1 types in OpenSSL are represented as an B<ASN1_STRING>
+structure. Other types such as B<ASN1_OCTET_STRING> are simply typedefed
+to B<ASN1_STRING> and the functions call the B<ASN1_STRING> equivalents.
+B<ASN1_STRING> is also used for some B<CHOICE> types which consist
+entirely of primitive string types such as B<DirectoryString> and
+B<Time>.
+
+These functions should B<not> be used to examine or modify B<ASN1_INTEGER>
+or B<ASN1_ENUMERATED> types: the relevant B<INTEGER> or B<ENUMERATED>
+utility functions should be used instead.
+
+In general it cannot be assumed that the data returned by ASN1_STRING_data()
+is null terminated or does not contain embedded nulls. The actual format
+of the data will depend on the actual string type itself: for example
+for and IA5String the data will be ASCII, for a BMPString two bytes per
+character in big endian format, UTF8String will be in UTF8 format.
+
+Similar care should be take to ensure the data is in the correct format
+when calling ASN1_STRING_set().
+
+=head1 RETURN VALUES
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>
+
+=head1 HISTORY
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/ASN1_STRING_new.pod b/src/lib/libssl/src/doc/crypto/ASN1_STRING_new.pod
new file mode 100644
index 0000000000..5b1bbb7eb2
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/ASN1_STRING_new.pod
@@ -0,0 +1,44 @@
+=pod
+
+=head1 NAME
+
+ASN1_STRING_new, ASN1_STRING_type_new, ASN1_STRING_free -
+ASN1_STRING allocation functions
+
+=head1 SYNOPSIS
+
+ ASN1_STRING * ASN1_STRING_new(void);
+ ASN1_STRING * ASN1_STRING_type_new(int type);
+ void ASN1_STRING_free(ASN1_STRING *a);
+
+=head1 DESCRIPTION
+
+ASN1_STRING_new() returns an allocated B<ASN1_STRING> structure. Its type
+is undefined.
+
+ASN1_STRING_type_new() returns an allocated B<ASN1_STRING> structure of
+type B<type>.
+
+ASN1_STRING_free() frees up B<a>.
+
+=head1 NOTES
+
+Other string types call the B<ASN1_STRING> functions. For example
+ASN1_OCTET_STRING_new() calls ASN1_STRING_type(V_ASN1_OCTET_STRING).
+
+=head1 RETURN VALUES
+
+ASN1_STRING_new() and ASN1_STRING_type_new() return a valid
+ASN1_STRING structure or B<NULL> if an error occurred.
+
+ASN1_STRING_free() does not return a value.
+
+=head1 SEE ALSO
+
+L<ERR_get_error(3)|ERR_get_error(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/ASN1_STRING_print_ex.pod b/src/lib/libssl/src/doc/crypto/ASN1_STRING_print_ex.pod
new file mode 100644
index 0000000000..fbf9a1f141
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/ASN1_STRING_print_ex.pod
@@ -0,0 +1,96 @@
+=pod
+
+=head1 NAME
+
+ASN1_STRING_print_ex, ASN1_STRING_print_ex_fp - ASN1_STRING output routines.
+
+=head1 SYNOPSIS
+
+ #include <openssl/asn1.h>
+
+ int ASN1_STRING_print_ex(BIO *out, ASN1_STRING *str, unsigned long flags);
+ int ASN1_STRING_print_ex_fp(FILE *fp, ASN1_STRING *str, unsigned long flags);
+ int ASN1_STRING_print(BIO *out, ASN1_STRING *str);
+
+
+=head1 DESCRIPTION
+
+These functions output an B<ASN1_STRING> structure. B<ASN1_STRING> is used to
+represent all the ASN1 string types.
+
+ASN1_STRING_print_ex() outputs B<str> to B<out>, the format is determined by
+the options B<flags>. ASN1_STRING_print_ex_fp() is identical except it outputs
+to B<fp> instead.
+
+ASN1_STRING_print() prints B<str> to B<out> but using a different format to
+ASN1_STRING_print_ex(). It replaces unprintable characters (other than CR, LF)
+with '.'.
+
+=head1 NOTES
+
+ASN1_STRING_print() is a legacy function which should be avoided in new applications.
+
+Although there are a large number of options frequently B<ASN1_STRFLAGS_RFC2253> is 
+suitable, or on UTF8 terminals B<ASN1_STRFLAGS_RFC2253 & ~ASN1_STRFLAGS_ESC_MSB>.
+
+The complete set of supported options for B<flags> is listed below.
+
+Various characters can be escaped. If B<ASN1_STRFLGS_ESC_2253> is set the characters
+determined by RFC2253 are escaped. If B<ASN1_STRFLGS_ESC_CTRL> is set control
+characters are escaped. If B<ASN1_STRFLGS_ESC_MSB> is set characters with the
+MSB set are escaped: this option should B<not> be used if the terminal correctly
+interprets UTF8 sequences.
+
+Escaping takes several forms.
+
+If the character being escaped is a 16 bit character then the form "\WXXXX" is used
+using exactly four characters for the hex representation. If it is 32 bits then
+"\UXXXXXXXX" is used using eight characters of its hex representation. These forms
+will only be used if UTF8 conversion is not set (see below).
+
+Printable characters are normally escaped using the backslash '\' character. If
+B<ASN1_STRFLGS_ESC_QUOTE> is set then the whole string is instead surrounded by
+double quote characters: this is arguably more readable than the backslash
+notation. Other characters use the "\XX" using exactly two characters of the hex
+representation.
+
+If B<ASN1_STRFLGS_UTF8_CONVERT> is set then characters are converted to UTF8
+format first. If the terminal supports the display of UTF8 sequences then this
+option will correctly display multi byte characters.
+
+If B<ASN1_STRFLGS_IGNORE_TYPE> is set then the string type is not interpreted at
+all: everything is assumed to be one byte per character. This is primarily for
+debugging purposes and can result in confusing output in multi character strings.
+
+If B<ASN1_STRFLGS_SHOW_TYPE> is set then the string type itself is printed out
+before its value (for example "BMPSTRING"), this actually uses ASN1_tag2str().
+
+The content of a string instead of being interpreted can be "dumped": this just
+outputs the value of the string using the form #XXXX using hex format for each
+octet.
+
+If B<ASN1_STRFLGS_DUMP_ALL> is set then any type is dumped.
+
+Normally non character string types (such as OCTET STRING) are assumed to be
+one byte per character, if B<ASN1_STRFLAGS_DUMP_UNKNOWN> is set then they will
+be dumped instead.
+
+When a type is dumped normally just the content octets are printed, if 
+B<ASN1_STRFLGS_DUMP_DER> is set then the complete encoding is dumped
+instead (including tag and length octets).
+
+B<ASN1_STRFLGS_RFC2253> includes all the flags required by RFC2253. It is
+equivalent to:
+ ASN1_STRFLGS_ESC_2253 | ASN1_STRFLGS_ESC_CTRL | ASN1_STRFLGS_ESC_MSB |
+ ASN1_STRFLGS_UTF8_CONVERT | ASN1_STRFLGS_DUMP_UNKNOWN ASN1_STRFLGS_DUMP_DER
+
+=head1 SEE ALSO
+
+L<X509_NAME_print_ex(3)|X509_NAME_print_ex(3)>,
+L<ASN1_tag2str(3)|ASN1_tag2str(3)>
+
+=head1 HISTORY
+
+TBA
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/BIO_f_cipher.pod b/src/lib/libssl/src/doc/crypto/BIO_f_cipher.pod
index 4182f2c309..02439cea94 100644
--- a/src/lib/libssl/src/doc/crypto/BIO_f_cipher.pod
+++ b/src/lib/libssl/src/doc/crypto/BIO_f_cipher.pod
@@ -28,7 +28,7 @@ BIO_flush() on an encryption BIO that is being written through is
 used to signal that no more data is to be encrypted: this is used
 to flush and possibly pad the final block through the BIO.
 
-BIO_set_cipher() sets the cipher of BIO <b> to B<cipher> using key B<key>
+BIO_set_cipher() sets the cipher of BIO B<b> to B<cipher> using key B<key>
 and IV B<iv>. B<enc> should be set to 1 for encryption and zero for
 decryption.
 
diff --git a/src/lib/libssl/src/doc/crypto/BIO_s_accept.pod b/src/lib/libssl/src/doc/crypto/BIO_s_accept.pod
index 55e4b730b9..7b63e4621b 100644
--- a/src/lib/libssl/src/doc/crypto/BIO_s_accept.pod
+++ b/src/lib/libssl/src/doc/crypto/BIO_s_accept.pod
@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-BIO_s_accept, BIO_set_nbio, BIO_set_accept_port, BIO_get_accept_port,
+BIO_s_accept, BIO_set_accept_port, BIO_get_accept_port,
 BIO_set_nbio_accept, BIO_set_accept_bios, BIO_set_bind_mode,
 BIO_get_bind_mode, BIO_do_accept - accept BIO
 
diff --git a/src/lib/libssl/src/doc/crypto/BIO_s_bio.pod b/src/lib/libssl/src/doc/crypto/BIO_s_bio.pod
index 95ae802e47..8d0a55a025 100644
--- a/src/lib/libssl/src/doc/crypto/BIO_s_bio.pod
+++ b/src/lib/libssl/src/doc/crypto/BIO_s_bio.pod
@@ -76,7 +76,9 @@ BIO_get_write_buf_size() returns the size of the write buffer.
 BIO_new_bio_pair() combines the calls to BIO_new(), BIO_make_bio_pair() and
 BIO_set_write_buf_size() to create a connected pair of BIOs B<bio1>, B<bio2>
 with write buffer sizes B<writebuf1> and B<writebuf2>. If either size is
-zero then the default size is used.
+zero then the default size is used.  BIO_new_bio_pair() does not check whether
+B<bio1> or B<bio2> do point to some other BIO, the values are overwritten,
+BIO_free() is not called.
 
 BIO_get_write_guarantee() and BIO_ctrl_get_write_guarantee() return the maximum
 length of data that can be currently written to the BIO. Writes larger than this
@@ -118,9 +120,59 @@ the application then waits for data to be available on the underlying transport
 before flushing the write buffer it will never succeed because the request was
 never sent!
 
+=head1 RETURN VALUES
+
+BIO_new_bio_pair() returns 1 on success, with the new BIOs available in
+B<bio1> and B<bio2>, or 0 on failure, with NULL pointers stored into the
+locations for B<bio1> and B<bio2>. Check the error stack for more information.
+
+[XXXXX: More return values need to be added here]
+
 =head1 EXAMPLE
 
-TBA
+The BIO pair can be used to have full control over the network access of an
+application. The application can call select() on the socket as required
+without having to go through the SSL-interface.
+
+ BIO *internal_bio, *network_bio;
+ ...
+ BIO_new_bio_pair(internal_bio, 0, network_bio, 0);
+ SSL_set_bio(ssl, internal_bio, internal_bio);
+ SSL_operations();
+ ...
+
+ application |   TLS-engine
+    |        |
+    +----------> SSL_operations()
+             |     /\    ||
+             |     ||    \/
+             |   BIO-pair (internal_bio)
+    +----------< BIO-pair (network_bio)
+    |        |
+  socket     |
+
+  ...
+  SSL_free(ssl);                /* implicitly frees internal_bio */
+  BIO_free(network_bio);
+  ...
+
+As the BIO pair will only buffer the data and never directly access the
+connection, it behaves non-blocking and will return as soon as the write
+buffer is full or the read buffer is drained. Then the application has to
+flush the write buffer and/or fill the read buffer.
+
+Use the BIO_ctrl_pending(), to find out whether data is buffered in the BIO
+and must be transfered to the network. Use BIO_ctrl_get_read_request() to
+find out, how many bytes must be written into the buffer before the
+SSL_operation() can successfully be continued.
+
+=head1 WARNING
+
+As the data is buffered, SSL_operation() may return with a ERROR_SSL_WANT_READ
+condition, but there is still data in the write buffer. An application must
+not rely on the error value of SSL_operation() but must assure that the
+write buffer is always flushed first. Otherwise a deadlock may occur as
+the peer might be waiting for the data before being able to continue.
 
 =head1 SEE ALSO
 
diff --git a/src/lib/libssl/src/doc/crypto/BN_CTX_new.pod b/src/lib/libssl/src/doc/crypto/BN_CTX_new.pod
index c94d8c610d..ad8d07db89 100644
--- a/src/lib/libssl/src/doc/crypto/BN_CTX_new.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_CTX_new.pod
@@ -42,7 +42,7 @@ BN_CTX_init() and BN_CTX_free() have no return values.
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>, L<BN_add(3)|BN_add(3)>,
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<BN_add(3)|BN_add(3)>,
 L<BN_CTX_start(3)|BN_CTX_start(3)>
 
 =head1 HISTORY
diff --git a/src/lib/libssl/src/doc/crypto/BN_add.pod b/src/lib/libssl/src/doc/crypto/BN_add.pod
index a99fe33808..88c7a799ee 100644
--- a/src/lib/libssl/src/doc/crypto/BN_add.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_add.pod
@@ -111,7 +111,7 @@ The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>, L<BN_CTX_new(3)|BN_CTX_new(3)>,
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<BN_CTX_new(3)|BN_CTX_new(3)>,
 L<BN_add_word(3)|BN_add_word(3)>, L<BN_set_bit(3)|BN_set_bit(3)>
 
 =head1 HISTORY
diff --git a/src/lib/libssl/src/doc/crypto/BN_add_word.pod b/src/lib/libssl/src/doc/crypto/BN_add_word.pod
index 66bedfb924..94244adea4 100644
--- a/src/lib/libssl/src/doc/crypto/BN_add_word.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_add_word.pod
@@ -46,7 +46,7 @@ BN_mod_word() and BN_div_word() return B<a>%B<w>.
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>, L<BN_add(3)|BN_add(3)>
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<BN_add(3)|BN_add(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/BN_bn2bin.pod b/src/lib/libssl/src/doc/crypto/BN_bn2bin.pod
index b62d1af0ff..a4b17ca60a 100644
--- a/src/lib/libssl/src/doc/crypto/BN_bn2bin.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_bn2bin.pod
@@ -80,7 +80,7 @@ The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>, L<BN_zero(3)|BN_zero(3)>,
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<BN_zero(3)|BN_zero(3)>,
 L<ASN1_INTEGER_to_BN(3)|ASN1_INTEGER_to_BN(3)>,
 L<BN_num_bytes(3)|BN_num_bytes(3)>
 
diff --git a/src/lib/libssl/src/doc/crypto/BN_copy.pod b/src/lib/libssl/src/doc/crypto/BN_copy.pod
index 8ad25e7834..388dd7df26 100644
--- a/src/lib/libssl/src/doc/crypto/BN_copy.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_copy.pod
@@ -25,7 +25,7 @@ by L<ERR_get_error(3)|ERR_get_error(3)>.
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/BN_generate_prime.pod b/src/lib/libssl/src/doc/crypto/BN_generate_prime.pod
index 638f6514ee..7dccacbc1e 100644
--- a/src/lib/libssl/src/doc/crypto/BN_generate_prime.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_generate_prime.pod
@@ -70,7 +70,7 @@ If B<do_trial_division == 0>, this test is skipped.
 
 Both BN_is_prime() and BN_is_prime_fasttest() perform a Miller-Rabin
 probabilistic primality test with B<checks> iterations. If
-B<checks == BN_prime_check>, a number of iterations is used that
+B<checks == BN_prime_checks>, a number of iterations is used that
 yields a false positive rate of at most 2^-80 for random input.
 
 If B<callback> is not B<NULL>, B<callback(1, j, cb_arg)> is called
@@ -90,7 +90,7 @@ The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/BN_mod_inverse.pod b/src/lib/libssl/src/doc/crypto/BN_mod_inverse.pod
index 49e62daf9f..3ea3975c74 100644
--- a/src/lib/libssl/src/doc/crypto/BN_mod_inverse.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_mod_inverse.pod
@@ -27,7 +27,7 @@ NULL on error. The error codes can be obtained by L<ERR_get_error(3)|ERR_get_err
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>, L<BN_add(3)|BN_add(3)>
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<BN_add(3)|BN_add(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/BN_mod_mul_montgomery.pod b/src/lib/libssl/src/doc/crypto/BN_mod_mul_montgomery.pod
index ed4af7a214..6b16351b92 100644
--- a/src/lib/libssl/src/doc/crypto/BN_mod_mul_montgomery.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_mod_mul_montgomery.pod
@@ -87,7 +87,7 @@ outside the expected range.
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>, L<BN_add(3)|BN_add(3)>,
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<BN_add(3)|BN_add(3)>,
 L<BN_CTX_new(3)|BN_CTX_new(3)>
 
 =head1 HISTORY
diff --git a/src/lib/libssl/src/doc/crypto/BN_mod_mul_reciprocal.pod b/src/lib/libssl/src/doc/crypto/BN_mod_mul_reciprocal.pod
index a28925f8a9..74a216ddc2 100644
--- a/src/lib/libssl/src/doc/crypto/BN_mod_mul_reciprocal.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_mod_mul_reciprocal.pod
@@ -69,7 +69,7 @@ The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>, L<BN_add(3)|BN_add(3)>,
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<BN_add(3)|BN_add(3)>,
 L<BN_CTX_new(3)|BN_CTX_new(3)>
 
 =head1 HISTORY
diff --git a/src/lib/libssl/src/doc/crypto/BN_new.pod b/src/lib/libssl/src/doc/crypto/BN_new.pod
index c1394ff2a3..3033789c51 100644
--- a/src/lib/libssl/src/doc/crypto/BN_new.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_new.pod
@@ -42,7 +42,7 @@ values.
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/BN_rand.pod b/src/lib/libssl/src/doc/crypto/BN_rand.pod
index 9cec238f9e..81f93c2eb3 100644
--- a/src/lib/libssl/src/doc/crypto/BN_rand.pod
+++ b/src/lib/libssl/src/doc/crypto/BN_rand.pod
@@ -45,7 +45,7 @@ The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
 
 =head1 SEE ALSO
 
-L<bn(3)|bn(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>,
+L<bn(3)|bn(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
 L<RAND_add(3)|RAND_add(3)>, L<RAND_bytes(3)|RAND_bytes(3)>
 
 =head1 HISTORY
diff --git a/src/lib/libssl/src/doc/crypto/DH_generate_key.pod b/src/lib/libssl/src/doc/crypto/DH_generate_key.pod
index 920995b2e5..81f09fdf45 100644
--- a/src/lib/libssl/src/doc/crypto/DH_generate_key.pod
+++ b/src/lib/libssl/src/doc/crypto/DH_generate_key.pod
@@ -40,7 +40,7 @@ The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
 
 =head1 SEE ALSO
 
-L<dh(3)|dh(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>, L<DH_size(3)|DH_size(3)>
+L<dh(3)|dh(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>, L<DH_size(3)|DH_size(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/DH_generate_parameters.pod b/src/lib/libssl/src/doc/crypto/DH_generate_parameters.pod
index a7d0c75f0c..9081e9ea7c 100644
--- a/src/lib/libssl/src/doc/crypto/DH_generate_parameters.pod
+++ b/src/lib/libssl/src/doc/crypto/DH_generate_parameters.pod
@@ -59,7 +59,8 @@ a usable generator.
 
 =head1 SEE ALSO
 
-L<dh(3)|dh(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>, L<DH_free(3)|DH_free(3)>
+L<dh(3)|dh(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
+L<DH_free(3)|DH_free(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/DH_new.pod b/src/lib/libssl/src/doc/crypto/DH_new.pod
index 64624b9d15..60c930093e 100644
--- a/src/lib/libssl/src/doc/crypto/DH_new.pod
+++ b/src/lib/libssl/src/doc/crypto/DH_new.pod
@@ -29,7 +29,7 @@ DH_free() returns no value.
 
 =head1 SEE ALSO
 
-L<dh(3)|dh(3)>, L<err(3)|err(3)>,
+L<dh(3)|dh(3)>, L<ERR_get_error(3)|ERR_get_error(3)>,
 L<DH_generate_parameters(3)|DH_generate_parameters(3)>,
 L<DH_generate_key(3)|DH_generate_key(3)>
 
diff --git a/src/lib/libssl/src/doc/crypto/DSA_SIG_new.pod b/src/lib/libssl/src/doc/crypto/DSA_SIG_new.pod
index 671655554a..3ac6140038 100644
--- a/src/lib/libssl/src/doc/crypto/DSA_SIG_new.pod
+++ b/src/lib/libssl/src/doc/crypto/DSA_SIG_new.pod
@@ -30,7 +30,8 @@ DSA_SIG_free() returns no value.
 
 =head1 SEE ALSO
 
-L<dsa(3)|dsa(3)>, L<err(3)|err(3)>, L<DSA_do_sign(3)|DSA_do_sign(3)>
+L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>,
+L<DSA_do_sign(3)|DSA_do_sign(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/DSA_do_sign.pod b/src/lib/libssl/src/doc/crypto/DSA_do_sign.pod
index a24fd5714e..5dfc733b20 100644
--- a/src/lib/libssl/src/doc/crypto/DSA_do_sign.pod
+++ b/src/lib/libssl/src/doc/crypto/DSA_do_sign.pod
@@ -36,7 +36,7 @@ L<ERR_get_error(3)|ERR_get_error(3)>.
 
 =head1 SEE ALSO
 
-L<dsa(3)|dsa(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>,
+L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
 L<DSA_SIG_new(3)|DSA_SIG_new(3)>,
 L<DSA_sign(3)|DSA_sign(3)>
 
diff --git a/src/lib/libssl/src/doc/crypto/DSA_dup_DH.pod b/src/lib/libssl/src/doc/crypto/DSA_dup_DH.pod
index fdfe125ab0..7f6f0d1115 100644
--- a/src/lib/libssl/src/doc/crypto/DSA_dup_DH.pod
+++ b/src/lib/libssl/src/doc/crypto/DSA_dup_DH.pod
@@ -27,7 +27,7 @@ Be careful to avoid small subgroup attacks when using this.
 
 =head1 SEE ALSO
 
-L<dh(3)|dh(3)>, L<dsa(3)|dsa(3)>, L<err(3)|err(3)>
+L<dh(3)|dh(3)>, L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/DSA_generate_key.pod b/src/lib/libssl/src/doc/crypto/DSA_generate_key.pod
index 52890db5be..af83ccfaa1 100644
--- a/src/lib/libssl/src/doc/crypto/DSA_generate_key.pod
+++ b/src/lib/libssl/src/doc/crypto/DSA_generate_key.pod
@@ -24,7 +24,8 @@ The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
 
 =head1 SEE ALSO
 
-L<dsa(3)|dsa(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>, L<DSA_generate_parameters(3)|DSA_generate_parameters(3)>
+L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
+L<DSA_generate_parameters(3)|DSA_generate_parameters(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/DSA_generate_parameters.pod b/src/lib/libssl/src/doc/crypto/DSA_generate_parameters.pod
index 43f60b0eb9..be7c924ff8 100644
--- a/src/lib/libssl/src/doc/crypto/DSA_generate_parameters.pod
+++ b/src/lib/libssl/src/doc/crypto/DSA_generate_parameters.pod
@@ -90,7 +90,7 @@ Seed lengths E<gt> 20 are not supported.
 
 =head1 SEE ALSO
 
-L<dsa(3)|dsa(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>,
+L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
 L<DSA_free(3)|DSA_free(3)>
 
 =head1 HISTORY
diff --git a/src/lib/libssl/src/doc/crypto/DSA_new.pod b/src/lib/libssl/src/doc/crypto/DSA_new.pod
index 546146d9de..48e9b82a09 100644
--- a/src/lib/libssl/src/doc/crypto/DSA_new.pod
+++ b/src/lib/libssl/src/doc/crypto/DSA_new.pod
@@ -31,7 +31,7 @@ DSA_free() returns no value.
 
 =head1 SEE ALSO
 
-L<dsa(3)|dsa(3)>, L<err(3)|err(3)>,
+L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>,
 L<DSA_generate_parameters(3)|DSA_generate_parameters(3)>,
 L<DSA_generate_key(3)|DSA_generate_key(3)>
 
diff --git a/src/lib/libssl/src/doc/crypto/DSA_sign.pod b/src/lib/libssl/src/doc/crypto/DSA_sign.pod
index f6e60a8ca3..97389e8ec8 100644
--- a/src/lib/libssl/src/doc/crypto/DSA_sign.pod
+++ b/src/lib/libssl/src/doc/crypto/DSA_sign.pod
@@ -55,7 +55,7 @@ Standard, DSS), ANSI X9.30
 
 =head1 SEE ALSO
 
-L<dsa(3)|dsa(3)>, L<err(3)|err(3)>, L<rand(3)|rand(3)>,
+L<dsa(3)|dsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>,
 L<DSA_do_sign(3)|DSA_do_sign(3)>
 
 =head1 HISTORY
diff --git a/src/lib/libssl/src/doc/crypto/ERR_get_error.pod b/src/lib/libssl/src/doc/crypto/ERR_get_error.pod
index 9fdedbcb91..34443045fc 100644
--- a/src/lib/libssl/src/doc/crypto/ERR_get_error.pod
+++ b/src/lib/libssl/src/doc/crypto/ERR_get_error.pod
@@ -5,7 +5,7 @@
 ERR_get_error, ERR_peek_error, ERR_peek_last_error,
 ERR_get_error_line, ERR_peek_error_line, ERR_peek_last_error_line,
 ERR_get_error_line_data, ERR_peek_error_line_data,
-ERR_peek_error_line_data - obtain error code and data
+ERR_peek_last_error_line_data - obtain error code and data
 
 =head1 SYNOPSIS
 
diff --git a/src/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod b/src/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
index 75cceb1ca2..daf57e5895 100644
--- a/src/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
+++ b/src/lib/libssl/src/doc/crypto/EVP_EncryptInit.pod
@@ -419,7 +419,7 @@ Encrypt a string using blowfish:
         EVP_CIPHER_CTX ctx;
         FILE *out;
         EVP_CIPHER_CTX_init(&ctx);
-        EVP_EncryptInit_ex(&ctx, NULL, EVP_bf_cbc(), key, iv);
+        EVP_EncryptInit_ex(&ctx, EVP_bf_cbc(), NULL, key, iv);
 
         if(!EVP_EncryptUpdate(&ctx, outbuf, &outlen, intext, strlen(intext)))
                 {
diff --git a/src/lib/libssl/src/doc/crypto/EVP_PKEY_new.pod b/src/lib/libssl/src/doc/crypto/EVP_PKEY_new.pod
new file mode 100644
index 0000000000..10687e458d
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/EVP_PKEY_set1_RSA.pod b/src/lib/libssl/src/doc/crypto/EVP_PKEY_set1_RSA.pod
new file mode 100644
index 0000000000..2db692e271
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/EVP_SealInit.pod b/src/lib/libssl/src/doc/crypto/EVP_SealInit.pod
index 25ef07f7c7..b5e477e294 100644
--- a/src/lib/libssl/src/doc/crypto/EVP_SealInit.pod
+++ b/src/lib/libssl/src/doc/crypto/EVP_SealInit.pod
@@ -18,22 +18,28 @@ EVP_SealInit, EVP_SealUpdate, EVP_SealFinal - EVP envelope encryption
 =head1 DESCRIPTION
 
 The EVP envelope routines are a high level interface to envelope
-encryption. They generate a random key and then "envelope" it by
-using public key encryption. Data can then be encrypted using this
-key.
+encryption. They generate a random key and IV (if required) then
+"envelope" it by using public key encryption. Data can then be
+encrypted using this key.
 
 EVP_SealInit() initializes a cipher context B<ctx> for encryption
-with cipher B<type> using a random secret key and IV supplied in
-the B<iv> parameter. B<type> is normally supplied by a function such
-as EVP_des_cbc(). The secret key is encrypted using one or more public
-keys, this allows the same encrypted data to be decrypted using any
-of the corresponding private keys. B<ek> is an array of buffers where
-the public key encrypted secret key will be written, each buffer must
-contain enough room for the corresponding encrypted key: that is
+with cipher B<type> using a random secret key and IV. B<type> is normally
+supplied by a function such as EVP_des_cbc(). The secret key is encrypted
+using one or more public keys, this allows the same encrypted data to be
+decrypted using any of the corresponding private keys. B<ek> is an array of
+buffers where the public key encrypted secret key will be written, each buffer
+must contain enough room for the corresponding encrypted key: that is
 B<ek[i]> must have room for B<EVP_PKEY_size(pubk[i])> bytes. The actual
 size of each encrypted secret key is written to the array B<ekl>. B<pubk> is
 an array of B<npubk> public keys.
 
+The B<iv> parameter is a buffer where the generated IV is written to. It must
+contain enough room for the corresponding cipher's IV, as determined by (for
+example) EVP_CIPHER_iv_length(type).
+
+If the cipher does not require an IV then the B<iv> parameter is ignored
+and can be B<NULL>.
+
 EVP_SealUpdate() and EVP_SealFinal() have exactly the same properties
 as the EVP_EncryptUpdate() and EVP_EncryptFinal() routines, as 
 documented on the L<EVP_EncryptInit(3)|EVP_EncryptInit(3)> manual
diff --git a/src/lib/libssl/src/doc/crypto/OBJ_nid2obj.pod b/src/lib/libssl/src/doc/crypto/OBJ_nid2obj.pod
new file mode 100644
index 0000000000..7dcc07923f
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/PKCS12_create.pod b/src/lib/libssl/src/doc/crypto/PKCS12_create.pod
new file mode 100644
index 0000000000..48f3bb8cb8
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/PKCS12_parse.pod b/src/lib/libssl/src/doc/crypto/PKCS12_parse.pod
new file mode 100644
index 0000000000..51344f883a
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/PKCS7_decrypt.pod b/src/lib/libssl/src/doc/crypto/PKCS7_decrypt.pod
new file mode 100644
index 0000000000..b0ca067b89
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/PKCS7_encrypt.pod b/src/lib/libssl/src/doc/crypto/PKCS7_encrypt.pod
new file mode 100644
index 0000000000..1a507b22a2
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/PKCS7_sign.pod b/src/lib/libssl/src/doc/crypto/PKCS7_sign.pod
new file mode 100644
index 0000000000..fc7e649b34
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/PKCS7_verify.pod b/src/lib/libssl/src/doc/crypto/PKCS7_verify.pod
new file mode 100644
index 0000000000..07c9fdad40
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/RAND_bytes.pod b/src/lib/libssl/src/doc/crypto/RAND_bytes.pod
index b6ebd50527..ce6329ce54 100644
--- a/src/lib/libssl/src/doc/crypto/RAND_bytes.pod
+++ b/src/lib/libssl/src/doc/crypto/RAND_bytes.pod
@@ -35,7 +35,8 @@ method.
 
 =head1 SEE ALSO
 
-L<rand(3)|rand(3)>, L<err(3)|err(3)>, L<RAND_add(3)|RAND_add(3)>
+L<rand(3)|rand(3)>, L<ERR_get_error(3)|ERR_get_error(3)>,
+L<RAND_add(3)|RAND_add(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/RSA_check_key.pod b/src/lib/libssl/src/doc/crypto/RSA_check_key.pod
index 3d824a07f5..a5198f3db5 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_check_key.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_check_key.pod
@@ -58,7 +58,7 @@ provide their own verifiers.
 
 =head1 SEE ALSO
 
-L<rsa(3)|rsa(3)>, L<err(3)|err(3)>
+L<rsa(3)|rsa(3)>, L<ERR_get_error(3)|ERR_get_error(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/RSA_generate_key.pod b/src/lib/libssl/src/doc/crypto/RSA_generate_key.pod
index 8714f7179d..52dbb14a53 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_generate_key.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_generate_key.pod
@@ -59,7 +59,8 @@ RSA_generate_key() goes into an infinite loop for illegal input values.
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>, L<RSA_free(3)|RSA_free(3)>
+L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>,
+L<RSA_free(3)|RSA_free(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/RSA_new.pod b/src/lib/libssl/src/doc/crypto/RSA_new.pod
index f0d996c40f..3d15b92824 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_new.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_new.pod
@@ -30,7 +30,8 @@ RSA_free() returns no value.
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<rsa(3)|rsa(3)>, L<RSA_generate_key(3)|RSA_generate_key(3)>,
+L<ERR_get_error(3)|ERR_get_error(3)>, L<rsa(3)|rsa(3)>,
+L<RSA_generate_key(3)|RSA_generate_key(3)>,
 L<RSA_new_method(3)|RSA_new_method(3)>
 
 =head1 HISTORY
diff --git a/src/lib/libssl/src/doc/crypto/RSA_print.pod b/src/lib/libssl/src/doc/crypto/RSA_print.pod
index 67876facc5..e28d107d1c 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_print.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_print.pod
@@ -2,9 +2,9 @@
 
 =head1 NAME
 
-RSA_print, RSA_print_fp, DHparams_print, DHparams_print_fp, DSA_print,
-DSA_print_fp, DHparams_print, DHparams_print_fp - print cryptographic
-parameters
+RSA_print, RSA_print_fp,
+DSAparams_print, DSAparams_print_fp, DSA_print, DSA_print_fp,
+DHparams_print, DHparams_print_fp - print cryptographic parameters
 
 =head1 SYNOPSIS
 
diff --git a/src/lib/libssl/src/doc/crypto/RSA_private_encrypt.pod b/src/lib/libssl/src/doc/crypto/RSA_private_encrypt.pod
index 6861a98a10..746a80c79e 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_private_encrypt.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_private_encrypt.pod
@@ -59,7 +59,8 @@ obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<rsa(3)|rsa(3)>, L<RSA_sign(3)|RSA_sign(3)>, L<RSA_verify(3)|RSA_verify(3)>
+L<ERR_get_error(3)|ERR_get_error(3)>, L<rsa(3)|rsa(3)>,
+L<RSA_sign(3)|RSA_sign(3)>, L<RSA_verify(3)|RSA_verify(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/RSA_public_encrypt.pod b/src/lib/libssl/src/doc/crypto/RSA_public_encrypt.pod
index e20dfcb551..d53e19d2b7 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_public_encrypt.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_public_encrypt.pod
@@ -72,7 +72,8 @@ SSL, PKCS #1 v2.0
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>, L<RSA_size(3)|RSA_size(3)>
+L<ERR_get_error(3)|ERR_get_error(3)>, L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>,
+L<RSA_size(3)|RSA_size(3)>
 
 =head1 HISTORY
 
diff --git a/src/lib/libssl/src/doc/crypto/RSA_set_method.pod b/src/lib/libssl/src/doc/crypto/RSA_set_method.pod
index 0687c2242a..0a305f6b14 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_set_method.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_set_method.pod
@@ -3,13 +3,12 @@
 =head1 NAME
 
 RSA_set_default_method, RSA_get_default_method, RSA_set_method,
-RSA_get_method, RSA_PKCS1_SSLeay,
-RSA_null_method, RSA_flags, RSA_new_method - select RSA method
+RSA_get_method, RSA_PKCS1_SSLeay, RSA_null_method, RSA_flags,
+RSA_new_method - select RSA method
 
 =head1 SYNOPSIS
 
  #include <openssl/rsa.h>
- #include <openssl/engine.h>
 
  void RSA_set_default_method(const RSA_METHOD *meth);
 
@@ -25,7 +24,7 @@ RSA_null_method, RSA_flags, RSA_new_method - select RSA method
 
  int RSA_flags(const RSA *rsa);
 
- RSA *RSA_new_method(ENGINE *engine);
+ RSA *RSA_new_method(RSA_METHOD *method);
 
 =head1 DESCRIPTION
 
@@ -70,6 +69,12 @@ B<engine> will be used for the RSA operations. If B<engine> is NULL, the
 default ENGINE for RSA operations is used, and if no default ENGINE is set,
 the RSA_METHOD controlled by RSA_set_default_method() is used.
 
+RSA_flags() returns the B<flags> that are set for B<rsa>'s current method.
+
+RSA_new_method() allocates and initializes an B<RSA> structure so that
+B<method> will be used for the RSA operations. If B<method> is B<NULL>,
+the default method is used.
+
 =head1 THE RSA_METHOD STRUCTURE
 
  typedef struct rsa_meth_st
diff --git a/src/lib/libssl/src/doc/crypto/RSA_sign.pod b/src/lib/libssl/src/doc/crypto/RSA_sign.pod
index f0bf6eea1b..71688a665e 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_sign.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_sign.pod
@@ -50,8 +50,8 @@ SSL, PKCS #1 v2.0
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<objects(3)|objects(3)>, L<rsa(3)|rsa(3)>,
-L<RSA_private_encrypt(3)|RSA_private_encrypt(3)>,
+L<ERR_get_error(3)|ERR_get_error(3)>, L<objects(3)|objects(3)>,
+L<rsa(3)|rsa(3)>, L<RSA_private_encrypt(3)|RSA_private_encrypt(3)>,
 L<RSA_public_decrypt(3)|RSA_public_decrypt(3)> 
 
 =head1 HISTORY
diff --git a/src/lib/libssl/src/doc/crypto/RSA_sign_ASN1_OCTET_STRING.pod b/src/lib/libssl/src/doc/crypto/RSA_sign_ASN1_OCTET_STRING.pod
index df9ceb339a..e70380bbfc 100644
--- a/src/lib/libssl/src/doc/crypto/RSA_sign_ASN1_OCTET_STRING.pod
+++ b/src/lib/libssl/src/doc/crypto/RSA_sign_ASN1_OCTET_STRING.pod
@@ -47,8 +47,8 @@ These functions serve no recognizable purpose.
 
 =head1 SEE ALSO
 
-L<err(3)|err(3)>, L<objects(3)|objects(3)>, L<rand(3)|rand(3)>,
-L<rsa(3)|rsa(3)>, L<RSA_sign(3)|RSA_sign(3)>,
+L<ERR_get_error(3)|ERR_get_error(3)>, L<objects(3)|objects(3)>,
+L<rand(3)|rand(3)>, L<rsa(3)|rsa(3)>, L<RSA_sign(3)|RSA_sign(3)>,
 L<RSA_verify(3)|RSA_verify(3)>
 
 =head1 HISTORY
diff --git a/src/lib/libssl/src/doc/crypto/SMIME_read_PKCS7.pod b/src/lib/libssl/src/doc/crypto/SMIME_read_PKCS7.pod
new file mode 100644
index 0000000000..ffafa37887
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/SMIME_write_PKCS7.pod b/src/lib/libssl/src/doc/crypto/SMIME_write_PKCS7.pod
new file mode 100644
index 0000000000..2cfad2e049
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/X509_NAME_ENTRY_get_object.pod b/src/lib/libssl/src/doc/crypto/X509_NAME_ENTRY_get_object.pod
new file mode 100644
index 0000000000..d287c18564
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/X509_NAME_add_entry_by_txt.pod b/src/lib/libssl/src/doc/crypto/X509_NAME_add_entry_by_txt.pod
new file mode 100644
index 0000000000..4472a1c5cf
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/X509_NAME_get_index_by_NID.pod b/src/lib/libssl/src/doc/crypto/X509_NAME_get_index_by_NID.pod
new file mode 100644
index 0000000000..333323d734
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/X509_NAME_print_ex.pod b/src/lib/libssl/src/doc/crypto/X509_NAME_print_ex.pod
new file mode 100644
index 0000000000..907c04f684
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/X509_new.pod b/src/lib/libssl/src/doc/crypto/X509_new.pod
new file mode 100644
index 0000000000..fd5fc65ce1
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/crypto.pod b/src/lib/libssl/src/doc/crypto/crypto.pod
index c12eec1409..7a527992bb 100644
--- a/src/lib/libssl/src/doc/crypto/crypto.pod
+++ b/src/lib/libssl/src/doc/crypto/crypto.pod
@@ -62,6 +62,22 @@ L<txt_db(3)|txt_db(3)>
 
 =back
 
+=head1 NOTES
+
+Some of the newer functions follow a naming convention using the numbers
+B<0> and B<1>. For example the functions:
+
+ int X509_CRL_add0_revoked(X509_CRL *crl, X509_REVOKED *rev);
+ int X509_add1_trust_object(X509 *x, ASN1_OBJECT *obj);
+
+The B<0> version uses the supplied structure pointer directly
+in the parent and it will be freed up when the parent is freed.
+In the above example B<crl> would be freed but B<rev> would not.
+
+The B<1> function uses a copy of the supplied structure pointer
+(or in some cases increases its link count) in the parent and
+so both (B<x> and B<obj> above) should be freed up.
+
 =head1 SEE ALSO
 
 L<openssl(1)|openssl(1)>, L<ssl(3)|ssl(3)>
diff --git a/src/lib/libssl/src/doc/crypto/d2i_ASN1_OBJECT.pod b/src/lib/libssl/src/doc/crypto/d2i_ASN1_OBJECT.pod
new file mode 100644
index 0000000000..45bb18492c
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/d2i_DHparams.pod b/src/lib/libssl/src/doc/crypto/d2i_DHparams.pod
index a6d1743d39..1e98aebeca 100644
--- a/src/lib/libssl/src/doc/crypto/d2i_DHparams.pod
+++ b/src/lib/libssl/src/doc/crypto/d2i_DHparams.pod
@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-d2i_DHparams, i2d_DHparams - ...
+d2i_DHparams, i2d_DHparams - PKCS#3 DH parameter functions.
 
 =head1 SYNOPSIS
 
@@ -13,18 +13,18 @@ d2i_DHparams, i2d_DHparams - ...
 
 =head1 DESCRIPTION
 
-...
+These functions decode and encode PKCS#3 DH parameters using the
+DHparameter structure described in PKCS#3.
 
-=head1 RETURN VALUES
-
-...
+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/libssl/src/doc/crypto/d2i_DSAPublicKey.pod b/src/lib/libssl/src/doc/crypto/d2i_DSAPublicKey.pod
new file mode 100644
index 0000000000..6ebd30427b
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/d2i_PKCS8PrivateKey.pod b/src/lib/libssl/src/doc/crypto/d2i_PKCS8PrivateKey.pod
new file mode 100644
index 0000000000..a54b779088
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/d2i_PKCS8PrivateKey.pod
@@ -0,0 +1,56 @@
+=pod
+
+=head1 NAME
+
+d2i_PKCS8PrivateKey_bio, d2i_PKCS8PrivateKey_fp,
+i2d_PKCS8PrivateKey_bio, i2d_PKCS8PrivateKey_fp,
+i2d_PKCS8PrivateKey_nid_bio, i2d_PKCS8PrivateKey_nid_fp - PKCS#8 format private key functions
+
+=head1 SYNOPSIS
+
+ #include <openssl/evp.h>
+
+ EVP_PKEY *d2i_PKCS8PrivateKey_bio(BIO *bp, EVP_PKEY **x, pem_password_cb *cb, void *u);
+ EVP_PKEY *d2i_PKCS8PrivateKey_fp(FILE *fp, EVP_PKEY **x, pem_password_cb *cb, void *u);
+
+ int i2d_PKCS8PrivateKey_bio(BIO *bp, EVP_PKEY *x, const EVP_CIPHER *enc,
+                                  char *kstr, int klen,
+                                  pem_password_cb *cb, void *u);
+
+ int i2d_PKCS8PrivateKey_fp(FILE *fp, EVP_PKEY *x, const EVP_CIPHER *enc,
+                                  char *kstr, int klen,
+                                  pem_password_cb *cb, void *u);
+
+ int i2d_PKCS8PrivateKey_nid_bio(BIO *bp, EVP_PKEY *x, int nid,
+                                  char *kstr, int klen,
+                                  pem_password_cb *cb, void *u);
+
+ int i2d_PKCS8PrivateKey_nid_fp(FILE *fp, EVP_PKEY *x, int nid,
+                                  char *kstr, int klen,
+                                  pem_password_cb *cb, void *u);
+
+=head1 DESCRIPTION
+
+The PKCS#8 functions encode and decode private keys in PKCS#8 format using both
+PKCS#5 v1.5 and PKCS#5 v2.0 password based encryption algorithms.
+
+Other than the use of DER as opposed to PEM these functions are identical to the
+corresponding B<PEM> function as described in the L<pem(3)|pem(3)> manual page.
+
+=head1 NOTES
+
+Before using these functions L<OpenSSL_add_all_algorithms(3)|OpenSSL_add_all_algorithms(3)>
+should be called to initialize the internal algorithm lookup tables otherwise errors about
+unknown algorithms will occur if an attempt is made to decrypt a private key. 
+
+These functions are currently the only way to store encrypted private keys using DER format.
+
+Currently all the functions use BIOs or FILE pointers, there are no functions which
+work directly on memory: this can be readily worked around by converting the buffers
+to memory BIOs, see L<BIO_s_mem(3)|BIO_s_mem(3)> for details.
+
+=head1 SEE ALSO
+
+L<pem(3)|pem(3)>
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/d2i_RSAPublicKey.pod b/src/lib/libssl/src/doc/crypto/d2i_RSAPublicKey.pod
index ff4d0d57db..7c71bcbf3d 100644
--- a/src/lib/libssl/src/doc/crypto/d2i_RSAPublicKey.pod
+++ b/src/lib/libssl/src/doc/crypto/d2i_RSAPublicKey.pod
@@ -2,7 +2,9 @@
 
 =head1 NAME
 
-d2i_RSAPublicKey, i2d_RSAPublicKey, d2i_RSAPrivateKey, i2d_RSAPrivateKey, i2d_Netscape_RSA, d2i_Netscape_RSA - ...
+d2i_RSAPublicKey, i2d_RSAPublicKey, d2i_RSAPrivateKey, i2d_RSAPrivateKey,
+d2i_RSA_PUBKEY, i2d_RSA_PUBKEY, i2d_Netscape_RSA,
+d2i_Netscape_RSA - RSA public and private key encoding functions.
 
 =head1 SYNOPSIS
 
@@ -12,6 +14,10 @@ d2i_RSAPublicKey, i2d_RSAPublicKey, d2i_RSAPrivateKey, i2d_RSAPrivateKey, i2d_Ne
 
  int i2d_RSAPublicKey(RSA *a, unsigned char **pp);
 
+ RSA * d2i_RSA_PUBKEY(RSA **a, unsigned char **pp, long length);
+
+ int i2d_RSA_PUBKEY(RSA *a, unsigned char **pp);
+
  RSA * d2i_RSAPrivateKey(RSA **a, unsigned char **pp, long length);
 
  int i2d_RSAPrivateKey(RSA *a, unsigned char **pp);
@@ -22,18 +28,39 @@ d2i_RSAPublicKey, i2d_RSAPublicKey, d2i_RSAPrivateKey, i2d_RSAPrivateKey, i2d_Ne
 
 =head1 DESCRIPTION
 
-...
+d2i_RSAPublicKey() and i2d_RSAPublicKey() decode and encode a PKCS#1 RSAPublicKey
+structure.
+
+d2i_RSA_PUKEY() and i2d_RSA_PUKEY() decode and encode an RSA public key using a
+SubjectPublicKeyInfo (certificate public key) structure.
+
+d2i_RSAPrivateKey(), i2d_RSAPrivateKey() decode and encode a PKCS#1 RSAPrivateKey
+structure.
+
+d2i_Netscape_RSA(), i2d_Netscape_RSA() decode and encode an RSA private key in
+NET format.
+
+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<RSA> structure passed to the private key encoding functions should have
+all the PKCS#1 private key components present.
 
-=head1 RETURN VALUES
+The data encoded by the private key functions is unencrypted and therefore 
+offers no private key security. 
 
-...
+The NET format functions are present to provide compatibility with certain very
+old software. This format has some severe security weaknesses and should be
+avoided if possible.
 
 =head1 SEE ALSO
 
-...
+L<d2i_X509(3)|d2i_X509(3)>
 
 =head1 HISTORY
 
-...
+TBA
 
 =cut
diff --git a/src/lib/libssl/src/doc/crypto/d2i_X509.pod b/src/lib/libssl/src/doc/crypto/d2i_X509.pod
new file mode 100644
index 0000000000..5e3c3d0985
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/d2i_X509_ALGOR.pod b/src/lib/libssl/src/doc/crypto/d2i_X509_ALGOR.pod
new file mode 100644
index 0000000000..9e5cd92ca7
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/d2i_X509_CRL.pod b/src/lib/libssl/src/doc/crypto/d2i_X509_CRL.pod
new file mode 100644
index 0000000000..06c5b23c09
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/d2i_X509_NAME.pod b/src/lib/libssl/src/doc/crypto/d2i_X509_NAME.pod
new file mode 100644
index 0000000000..343ffe1519
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/d2i_X509_REQ.pod b/src/lib/libssl/src/doc/crypto/d2i_X509_REQ.pod
new file mode 100644
index 0000000000..be4ad68257
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/d2i_X509_SIG.pod b/src/lib/libssl/src/doc/crypto/d2i_X509_SIG.pod
new file mode 100644
index 0000000000..e48fd79a51
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/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/libssl/src/doc/crypto/engine.pod b/src/lib/libssl/src/doc/crypto/engine.pod
index 61e0264bb7..c77dad5562 100644
--- a/src/lib/libssl/src/doc/crypto/engine.pod
+++ b/src/lib/libssl/src/doc/crypto/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
diff --git a/src/lib/libssl/src/doc/openssl-shared.txt b/src/lib/libssl/src/doc/openssl-shared.txt
new file mode 100644
index 0000000000..5cf84a054f
--- /dev/null
+++ b/src/lib/libssl/src/doc/openssl-shared.txt
@@ -0,0 +1,32 @@
+The OpenSSL  shared libraries are often installed in a directory like
+/usr/local/ssl/lib.
+
+If this directory is not in a standard system path for dynamic/shared
+libraries, then you will have problems linking and executing
+applications that use OpenSSL libraries UNLESS:
+
+* you link with static (archive) libraries.  If you are truly
+  paranoid about security, you should use static libraries.
+* you use the GNU libtool code during linking
+  (http://www.gnu.org/software/libtool/libtool.html)
+* you use pkg-config during linking (this requires that
+  PKG_CONFIG_PATH includes the path to the OpenSSL shared
+  library directory), and make use of -R or -rpath.
+  (http://www.freedesktop.org/software/pkgconfig/)
+* you specify the system-wide link path via a command such
+  as crle(1) on Solaris systems.
+* you add the OpenSSL shared library directory to /etc/ld.so.conf
+  and run ldconfig(8) on Linux systems.
+* you define the LD_LIBRARY_PATH, LIBPATH, SHLIB_PATH (HP),
+  DYLD_LIBRARY_PATH (MacOS X) or PATH (Cygwin and DJGPP)
+  environment variable and add the OpenSSL shared library
+  directory to it.
+
+One common tool to check the dynamic dependencies of an executable
+or dynamic library is ldd(1) on most UNIX systems.
+
+See any operating system documentation and manpages about shared
+libraries for your version of UNIX.  The following manpages may be
+helpful: ld(1), ld.so(1), ld.so.1(1) [Solaris], dld.sl(1) [HP],
+ldd(1), crle(1) [Solaris], pldd(1) [Solaris], ldconfig(8) [Linux],
+chatr(1) [HP].
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_add_session.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_add_session.pod
index af326c2f73..82676b26b2 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_add_session.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_add_session.pod
@@ -37,6 +37,14 @@ removed and replaced by the new session. If the session is actually
 identical (the SSL_SESSION object is identical), SSL_CTX_add_session()
 is a no-op, and the return value is 0.
 
+If a server SSL_CTX is configured with the SSL_SESS_CACHE_NO_INTERNAL_STORE
+flag then the internal cache will not be populated automatically by new
+sessions negotiated by the SSL/TLS implementation, even though the internal
+cache will be searched automatically for session-resume requests (the
+latter can be surpressed by SSL_SESS_CACHE_NO_INTERNAL_LOOKUP). So the
+application can use SSL_CTX_add_session() directly to have full control
+over the sessions that can be resumed if desired.
+
 
 =head1 RETURN VALUES
 
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_free.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_free.pod
index 55e592f5f8..51d8676968 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_free.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_free.pod
@@ -20,12 +20,22 @@ It also calls the free()ing procedures for indirectly affected items, if
 applicable: the session cache, the list of ciphers, the list of Client CAs,
 the certificates and keys.
 
+=head1 WARNINGS
+
+If a session-remove callback is set (SSL_CTX_sess_set_remove_cb()), this
+callback will be called for each session being freed from B<ctx>'s
+session cache. This implies, that all corresponding sessions from an
+external session cache are removed as well. If this is not desired, the user
+should explicitly unset the callback by calling
+SSL_CTX_sess_set_remove_cb(B<ctx>, NULL) prior to calling SSL_CTX_free().
+
 =head1 RETURN VALUES
 
 SSL_CTX_free() does not provide diagnostic information.
 
 =head1 SEE ALSO
 
-L<SSL_CTX_new(3)|SSL_CTX_new(3)>, L<ssl(3)|ssl(3)>
+L<SSL_CTX_new(3)|SSL_CTX_new(3)>, L<ssl(3)|ssl(3)>,
+L<SSL_CTX_sess_set_get_cb(3)|SSL_CTX_sess_set_get_cb(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_sess_set_get_cb.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_sess_set_get_cb.pod
index 7c0b2baf6c..b9d54a40a1 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_sess_set_get_cb.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_sess_set_get_cb.pod
@@ -60,10 +60,11 @@ B<sess>. If the callback returns B<0>, the session will be immediately
 removed again.
 
 The remove_session_cb() is called, whenever the SSL engine removes a session
-from the internal cache. This happens if the session is removed because
-it is expired or when a connection was not shutdown cleanly. The
-remove_session_cb() is passed the B<ctx> and the ssl session B<sess>.
-It does not provide any feedback.
+from the internal cache. This happens when the session is removed because
+it is expired or when a connection was not shutdown cleanly. It also happens
+for all sessions in the internal session cache when
+L<SSL_CTX_free(3)|SSL_CTX_free(3)> is called. The remove_session_cb() is passed
+the B<ctx> and the ssl session B<sess>. It does not provide any feedback.
 
 The get_session_cb() is only called on SSL/TLS servers with the session id
 proposed by the client. The get_session_cb() is always called, also when
@@ -80,6 +81,7 @@ L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>.
 L<ssl(3)|ssl(3)>, L<d2i_SSL_SESSION(3)|d2i_SSL_SESSION(3)>,
 L<SSL_CTX_set_session_cache_mode(3)|SSL_CTX_set_session_cache_mode(3)>,
 L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)>,
-L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>
+L<SSL_SESSION_free(3)|SSL_SESSION_free(3)>,
+L<SSL_CTX_free(3)|SSL_CTX_free(3)>
 
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_options.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_options.pod
index f5e2ec3555..766f0c9200 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_options.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_options.pod
@@ -176,7 +176,7 @@ will send his list of preferences to the client and the client chooses.
 =item SSL_OP_NETSCAPE_CA_DN_BUG
 
 If we accept a netscape connection, demand a client cert, have a
-non-self-sighed CA which does not have it's CA in netscape, and the
+non-self-signed CA which does not have its CA in netscape, and the
 browser has a cert, it will crash/hang.  Works for 3.x and 4.xbeta 
 
 =item SSL_OP_NETSCAPE_DEMO_CIPHER_CHANGE_BUG
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_session_cache_mode.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_session_cache_mode.pod
index 9aa6c6b2e3..c5d2f43dff 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_session_cache_mode.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_session_cache_mode.pod
@@ -26,12 +26,14 @@ SSL_CTX object is being maintained, the sessions are unique for each SSL_CTX
 object.
 
 In order to reuse a session, a client must send the session's id to the
-server. It can only send exactly one id.  The server then decides whether it
-agrees in reusing the session or starts the handshake for a new session.
+server. It can only send exactly one id.  The server then either 
+agrees to reuse the session or it starts a full handshake (to create a new
+session).
 
-A server will lookup up the session in its internal session storage. If
-the session is not found in internal storage or internal storage is
-deactivated, the server will try the external storage if available.
+A server will lookup up the session in its internal session storage. If the
+session is not found in internal storage or lookups for the internal storage
+have been deactivated (SSL_SESS_CACHE_NO_INTERNAL_LOOKUP), the server will try
+the external storage if available.
 
 Since a client may try to reuse a session intended for use in a different
 context, the session id context must be set by the server (see
@@ -57,9 +59,10 @@ function. This option is not activated by default.
 =item SSL_SESS_CACHE_SERVER
 
 Server sessions are added to the session cache. When a client proposes a
-session to be reused, the session is looked up in the internal session cache.
-If the session is found, the server will try to reuse the session.
-This is the default.
+session to be reused, the server looks for the corresponding session in (first)
+the internal session cache (unless SSL_SESS_CACHE_NO_INTERNAL_LOOKUP is set),
+then (second) in the external cache if available. If the session is found, the
+server will try to reuse the session.  This is the default.
 
 =item SSL_SESS_CACHE_BOTH
 
@@ -77,12 +80,32 @@ explicitly by the application.
 
 =item SSL_SESS_CACHE_NO_INTERNAL_LOOKUP
 
-By setting this flag sessions are cached in the internal storage but
-they are not looked up automatically. If an external session cache
-is enabled, sessions are looked up in the external cache. As automatic
-lookup only applies for SSL/TLS servers, the flag has no effect on
+By setting this flag, session-resume operations in an SSL/TLS server will not
+automatically look up sessions in the internal cache, even if sessions are
+automatically stored there. If external session caching callbacks are in use,
+this flag guarantees that all lookups are directed to the external cache.
+As automatic lookup only applies for SSL/TLS servers, the flag has no effect on
 clients.
 
+=item SSL_SESS_CACHE_NO_INTERNAL_STORE
+
+Depending on the presence of SSL_SESS_CACHE_CLIENT and/or SSL_SESS_CACHE_SERVER,
+sessions negotiated in an SSL/TLS handshake may be cached for possible reuse.
+Normally a new session is added to the internal cache as well as any external
+session caching (callback) that is configured for the SSL_CTX. This flag will
+prevent sessions being stored in the internal cache (though the application can
+add them manually using L<SSL_CTX_add_session(3)|SSL_CTX_add_session(3)>). Note:
+in any SSL/TLS servers where external caching is configured, any successful
+session lookups in the external cache (ie. for session-resume requests) would
+normally be copied into the local cache before processing continues - this flag
+prevents these additions to the internal cache as well.
+
+=item SSL_SESS_CACHE_NO_INTERNAL
+
+Enable both SSL_SESS_CACHE_NO_INTERNAL_LOOKUP and
+SSL_SESS_CACHE_NO_INTERNAL_STORE at the same time.
+
+
 =back
 
 The default mode is SSL_SESS_CACHE_SERVER.
@@ -98,6 +121,7 @@ SSL_CTX_get_session_cache_mode() returns the currently set cache mode.
 
 L<ssl(3)|ssl(3)>, L<SSL_set_session(3)|SSL_set_session(3)>,
 L<SSL_session_reused(3)|SSL_session_reused(3)>,
+L<SSL_CTX_add_session(3)|SSL_CTX_add_session(3)>,
 L<SSL_CTX_sess_number(3)|SSL_CTX_sess_number(3)>,
 L<SSL_CTX_sess_set_cache_size(3)|SSL_CTX_sess_set_cache_size(3)>,
 L<SSL_CTX_sess_set_get_cb(3)|SSL_CTX_sess_set_get_cb(3)>,
@@ -105,4 +129,9 @@ L<SSL_CTX_set_session_id_context(3)|SSL_CTX_set_session_id_context(3)>,
 L<SSL_CTX_set_timeout(3)|SSL_CTX_set_timeout(3)>,
 L<SSL_CTX_flush_sessions(3)|SSL_CTX_flush_sessions(3)>
 
+=head1 HISTORY
+
+SSL_SESS_CACHE_NO_INTERNAL_STORE and SSL_SESS_CACHE_NO_INTERNAL
+were introduced in OpenSSL 0.9.6h.
+
 =cut
diff --git a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_verify.pod b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_verify.pod
index 5bb21ca535..d15b2a3a1a 100644
--- a/src/lib/libssl/src/doc/ssl/SSL_CTX_set_verify.pod
+++ b/src/lib/libssl/src/doc/ssl/SSL_CTX_set_verify.pod
@@ -235,7 +235,7 @@ L<SSL_get_ex_data_X509_STORE_CTX_idx(3)|SSL_get_ex_data_X509_STORE_CTX_idx(3)>).
      * At this point, err contains the last verification error. We can use
      * it for something special
      */
-    if (!preverify_ok && (err == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT)
+    if (!preverify_ok && (err == X509_V_ERR_UNABLE_TO_GET_ISSUER_CERT))
     {
       X509_NAME_oneline(X509_get_issuer_name(ctx->current_cert), buf, 256);
       printf("issuer= %s\n", buf);
diff --git a/src/lib/libssl/src/doc/ssl/ssl.pod b/src/lib/libssl/src/doc/ssl/ssl.pod
index 1471e0312e..3dc5358ef6 100644
--- a/src/lib/libssl/src/doc/ssl/ssl.pod
+++ b/src/lib/libssl/src/doc/ssl/ssl.pod
@@ -351,7 +351,7 @@ appropriate size (using ???) and return it.
 
 long B<SSL_set_tmp_rsa_callback>(SSL *ssl, RSA *(*cb)(SSL *ssl, int export, int keylength));
 
-The same as L<"SSL_CTX_set_tmp_rsa_callback">, except it operates on an SSL
+The same as B<SSL_CTX_set_tmp_rsa_callback>, except it operates on an SSL
 session instead of a context.
 
 =item void B<SSL_CTX_set_verify>(SSL_CTX *ctx, int mode, int (*cb);(void))
diff --git a/src/lib/libssl/src/doc/standards.txt b/src/lib/libssl/src/doc/standards.txt
index 596d9001e6..edbe2f3a57 100644
--- a/src/lib/libssl/src/doc/standards.txt
+++ b/src/lib/libssl/src/doc/standards.txt
@@ -42,20 +42,9 @@ whole or at least great parts) in OpenSSL.
 2268 A Description of the RC2(r) Encryption Algorithm. R. Rivest.
      January 1998. (Format: TXT=19048 bytes) (Status: INFORMATIONAL)
 
-2314 PKCS 10: Certification Request Syntax Version 1.5. B. Kaliski.
-     March 1998. (Format: TXT=15814 bytes) (Status: INFORMATIONAL)
-
 2315 PKCS 7: Cryptographic Message Syntax Version 1.5. B. Kaliski.
      March 1998. (Format: TXT=69679 bytes) (Status: INFORMATIONAL)
 
-2437 PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski,
-     J. Staddon. October 1998. (Format: TXT=73529 bytes) (Obsoletes
-     RFC2313) (Status: INFORMATIONAL)
-
-2459 Internet X.509 Public Key Infrastructure Certificate and CRL
-     Profile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999.
-     (Format: TXT=278438 bytes) (Status: PROPOSED STANDARD)
-
 PKCS#8: Private-Key Information Syntax Standard
 
 PKCS#12: Personal Information Exchange Syntax Standard, version 1.0.
@@ -65,6 +54,40 @@ PKCS#12: Personal Information Exchange Syntax Standard, version 1.0.
      C. Adams. June 1999. (Format: TXT=43243 bytes) (Status: PROPOSED
      STANDARD)
 
+2712 Addition of Kerberos Cipher Suites to Transport Layer Security
+     (TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT=13763 bytes)
+     (Status: PROPOSED STANDARD)
+
+2898 PKCS #5: Password-Based Cryptography Specification Version 2.0.
+     B. Kaliski. September 2000. (Format: TXT=68692 bytes) (Status:
+     INFORMATIONAL)
+
+2986 PKCS #10: Certification Request Syntax Specification Version 1.7.
+     M. Nystrom, B. Kaliski. November 2000. (Format: TXT=27794 bytes)
+     (Obsoletes RFC2314) (Status: INFORMATIONAL)
+
+3174 US Secure Hash Algorithm 1 (SHA1). D. Eastlake 3rd, P. Jones.
+     September 2001. (Format: TXT=35525 bytes) (Status: INFORMATIONAL)
+
+3268 Advanced Encryption Standard (AES) Ciphersuites for Transport
+     Layer Security (TLS). P. Chown. June 2002. (Format: TXT=13530 bytes)
+     (Status: PROPOSED STANDARD)
+
+3279 Algorithms and Identifiers for the Internet X.509 Public Key
+     Infrastructure Certificate and Certificate Revocation List (CRL)
+     Profile. L. Bassham, W. Polk, R. Housley. April 2002. (Format:
+     TXT=53833 bytes) (Status: PROPOSED STANDARD)
+
+3280 Internet X.509 Public Key Infrastructure Certificate and
+     Certificate Revocation List (CRL) Profile. R. Housley, W. Polk, W.
+     Ford, D. Solo. April 2002. (Format: TXT=295556 bytes) (Obsoletes
+     RFC2459) (Status: PROPOSED STANDARD)
+
+3447 Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography
+     Specifications Version 2.1. J. Jonsson, B. Kaliski. February 2003.
+     (Format: TXT=143173 bytes) (Obsoletes RFC2437) (Status:           
+     INFORMATIONAL)                                         
+
 
 Related:
 --------
@@ -90,23 +113,60 @@ STARTTLS documents.
      Certification and Related Services. B. Kaliski. February 1993.
      (Format: TXT=17537 bytes) (Status: PROPOSED STANDARD)
 
-2256 A Summary of the X.500(96) User Schema for use with LDAPv3. M.
-     Wahl. December 1997. (Format: TXT=32377 bytes) (Status: PROPOSED
-     STANDARD)
+2025 The Simple Public-Key GSS-API Mechanism (SPKM). C. Adams. October
+     1996. (Format: TXT=101692 bytes) (Status: PROPOSED STANDARD)
+
+2510 Internet X.509 Public Key Infrastructure Certificate Management
+     Protocols. C. Adams, S. Farrell. March 1999. (Format: TXT=158178
+     bytes) (Status: PROPOSED STANDARD)
+
+2511 Internet X.509 Certificate Request Message Format. M. Myers, C.
+     Adams, D. Solo, D. Kemp. March 1999. (Format: TXT=48278 bytes)
+     (Status: PROPOSED STANDARD)
+
+2527 Internet X.509 Public Key Infrastructure Certificate Policy and
+     Certification Practices Framework. S. Chokhani, W. Ford. March 1999.
+     (Format: TXT=91860 bytes) (Status: INFORMATIONAL)
 
-2487 SMTP Service Extension for Secure SMTP over TLS. P. Hoffman.
-     January 1999. (Format: TXT=15120 bytes) (Status: PROPOSED STANDARD)
+2538 Storing Certificates in the Domain Name System (DNS). D. Eastlake
+     3rd, O. Gudmundsson. March 1999. (Format: TXT=19857 bytes) (Status:
+     PROPOSED STANDARD)
+
+2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS).
+     D. Eastlake 3rd. March 1999. (Format: TXT=21049 bytes) (Status:
+     PROPOSED STANDARD)
+
+2559 Internet X.509 Public Key Infrastructure Operational Protocols -
+     LDAPv2. S. Boeyen, T. Howes, P. Richard. April 1999. (Format:
+     TXT=22889 bytes) (Updates RFC1778) (Status: PROPOSED STANDARD)
 
 2585 Internet X.509 Public Key Infrastructure Operational Protocols:
      FTP and HTTP. R. Housley, P. Hoffman. May 1999. (Format: TXT=14813
      bytes) (Status: PROPOSED STANDARD)
 
+2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema. S.
+     Boeyen, T. Howes, P. Richard. June 1999. (Format: TXT=15102 bytes)
+     (Status: PROPOSED STANDARD)
+
 2595 Using TLS with IMAP, POP3 and ACAP. C. Newman. June 1999.
      (Format: TXT=32440 bytes) (Status: PROPOSED STANDARD)
 
-2712 Addition of Kerberos Cipher Suites to Transport Layer Security
-     (TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT=13763 bytes)
-     (Status: PROPOSED STANDARD)
+2631 Diffie-Hellman Key Agreement Method. E. Rescorla. June 1999.
+     (Format: TXT=25932 bytes) (Status: PROPOSED STANDARD)
+
+2632 S/MIME Version 3 Certificate Handling. B. Ramsdell, Ed.. June
+     1999. (Format: TXT=27925 bytes) (Status: PROPOSED STANDARD)
+
+2716 PPP EAP TLS Authentication Protocol. B. Aboba, D. Simon. October
+     1999. (Format: TXT=50108 bytes) (Status: EXPERIMENTAL)
+
+2773 Encryption using KEA and SKIPJACK. R. Housley, P. Yee, W. Nace.
+     February 2000. (Format: TXT=20008 bytes) (Updates RFC0959) (Status:
+     EXPERIMENTAL)
+
+2797 Certificate Management Messages over CMS. M. Myers, X. Liu, J.
+     Schaad, J. Weinstein. April 2000. (Format: TXT=103357 bytes) (Status:
+     PROPOSED STANDARD)
 
 2817 Upgrading to TLS Within HTTP/1.1. R. Khare, S. Lawrence. May
      2000. (Format: TXT=27598 bytes) (Updates RFC2616) (Status: PROPOSED
@@ -115,6 +175,77 @@ STARTTLS documents.
 2818 HTTP Over TLS. E. Rescorla. May 2000. (Format: TXT=15170 bytes)
      (Status: INFORMATIONAL)
 
+2876 Use of the KEA and SKIPJACK Algorithms in CMS. J. Pawling. July
+     2000. (Format: TXT=29265 bytes) (Status: INFORMATIONAL)
+
+2984 Use of the CAST-128 Encryption Algorithm in CMS. C. Adams.
+     October 2000. (Format: TXT=11591 bytes) (Status: PROPOSED STANDARD)
+
+2985 PKCS #9: Selected Object Classes and Attribute Types Version 2.0.
+     M. Nystrom, B. Kaliski. November 2000. (Format: TXT=70703 bytes)
+     (Status: INFORMATIONAL)
+
+3029 Internet X.509 Public Key Infrastructure Data Validation and
+     Certification Server Protocols. C. Adams, P. Sylvester, M. Zolotarev,
+     R. Zuccherato. February 2001. (Format: TXT=107347 bytes) (Status:
+     EXPERIMENTAL)
+
+3039 Internet X.509 Public Key Infrastructure Qualified Certificates
+     Profile. S. Santesson, W. Polk, P. Barzin, M. Nystrom. January 2001.
+     (Format: TXT=67619 bytes) (Status: PROPOSED STANDARD)
+
+3058 Use of the IDEA Encryption Algorithm in CMS. S. Teiwes, P.
+     Hartmann, D. Kuenzi. February 2001. (Format: TXT=17257 bytes)
+     (Status: INFORMATIONAL)
+
+3161 Internet X.509 Public Key Infrastructure Time-Stamp Protocol
+     (TSP). C. Adams, P. Cain, D. Pinkas, R. Zuccherato. August 2001.
+     (Format: TXT=54585 bytes) (Status: PROPOSED STANDARD)
+
+3185 Reuse of CMS Content Encryption Keys. S. Farrell, S. Turner.
+     October 2001. (Format: TXT=20404 bytes) (Status: PROPOSED STANDARD)
+
+3207 SMTP Service Extension for Secure SMTP over Transport Layer
+     Security. P. Hoffman. February 2002. (Format: TXT=18679 bytes)
+     (Obsoletes RFC2487) (Status: PROPOSED STANDARD)
+
+3217 Triple-DES and RC2 Key Wrapping. R. Housley. December 2001.
+     (Format: TXT=19855 bytes) (Status: INFORMATIONAL)
+
+3274 Compressed Data Content Type for Cryptographic Message Syntax
+     (CMS). P. Gutmann. June 2002. (Format: TXT=11276 bytes) (Status:
+     PROPOSED STANDARD)
+
+3278 Use of Elliptic Curve Cryptography (ECC) Algorithms in
+     Cryptographic Message Syntax (CMS). S. Blake-Wilson, D. Brown, P.
+     Lambert. April 2002. (Format: TXT=33779 bytes) (Status:
+     INFORMATIONAL)
+
+3281 An Internet Attribute Certificate Profile for Authorization. S.
+     Farrell, R. Housley. April 2002. (Format: TXT=90580 bytes) (Status:
+     PROPOSED STANDARD)
+
+3369 Cryptographic Message Syntax (CMS). R. Housley. August 2002.
+     (Format: TXT=113975 bytes) (Obsoletes RFC2630, RFC3211) (Status:
+     PROPOSED STANDARD)
+
+3370 Cryptographic Message Syntax (CMS) Algorithms. R. Housley. August
+     2002. (Format: TXT=51001 bytes) (Obsoletes RFC2630, RFC3211) (Status:
+     PROPOSED STANDARD)
+
+3377 Lightweight Directory Access Protocol (v3): Technical
+     Specification. J. Hodges, R. Morgan. September 2002. (Format:
+     TXT=9981 bytes) (Updates RFC2251, RFC2252, RFC2253, RFC2254, RFC2255,
+     RFC2256, RFC2829, RFC2830) (Status: PROPOSED STANDARD)
+
+3394 Advanced Encryption Standard (AES) Key Wrap Algorithm. J. Schaad,
+     R. Housley. September 2002. (Format: TXT=73072 bytes) (Status:
+     INFORMATIONAL)
+
+3436 Transport Layer Security over Stream Control Transmission
+     Protocol. A. Jungmaier, E. Rescorla, M. Tuexen. December 2002.
+     (Format: TXT=16333 bytes) (Status: PROPOSED STANDARD)
+
   "Securing FTP with TLS", 01/27/2000, <draft-murray-auth-ftp-ssl-05.txt>  
  
 
@@ -124,7 +255,3 @@ To be implemented:
 These are documents that describe things that are planed to be
 implemented in the hopefully short future.
 
-2712 Addition of Kerberos Cipher Suites to Transport Layer Security
-     (TLS). A. Medvinsky, M. Hur. October 1999. (Format: TXT=13763 bytes)
-     (Status: PROPOSED STANDARD)
-