[openssl-commits] [openssl] master update

Rich Salz rsalz at openssl.org
Sun May 3 12:55:52 UTC 2015


The branch master has been updated
       via  5812e6f17571345d9e8449459572e540379002d5 (commit)
       via  4c583c36596cd86feebd983b0313733fe9870500 (commit)
       via  186bb90705f848806783de512b3df6872552b304 (commit)
       via  8332f91cc0db4955259bca9f9138b5eff94d6e8c (commit)
      from  b6eb9827a6866981c08cc9613ca8b4a648894fb1 (commit)


- Log -----------------------------------------------------------------
commit 5812e6f17571345d9e8449459572e540379002d5
Author: Alok Menghrajani <alok at squareup.com>
Date:   Mon Apr 13 09:48:06 2015 -0700

    Fixes some typos in doc/ssl/
    
    This is the last of Alok's PR260
    Reviewed-by: Tim Hudson <tjh at openssl.org>

commit 4c583c36596cd86feebd983b0313733fe9870500
Author: Alok Menghrajani <alok at squareup.com>
Date:   Mon Apr 13 09:29:52 2015 -0700

    Fixes some typos in doc/apps/
    
    Signed-off-by: Rich Salz <rsalz at akamai.com>
    Reviewed-by: Tim Hudson <tjh at openssl.org>

commit 186bb90705f848806783de512b3df6872552b304
Author: Alok Menghrajani <alok at squareup.com>
Date:   Mon Apr 13 11:05:13 2015 -0700

    RT3802: Fixes typos in doc/crypto/
    
    Signed-off-by: Rich Salz <rsalz at akamai.com>
    Reviewed-by: Tim Hudson <tjh at openssl.org>

commit 8332f91cc0db4955259bca9f9138b5eff94d6e8c
Author: Rich Salz <rsalz at akamai.com>
Date:   Sat May 2 18:42:29 2015 -0400

    fix various typo's
    
     https://github.com/openssl/openssl/pull/176 (CHANGES)
     https://rt.openssl.org/Ticket/Display.html?id=3545 (objects.txt)
     https://rt.openssl.org/Ticket/Display.html?id=3796 (verify.pod)
    
    Reviewed-by: Tim Hudson <tjh at openssl.org>

-----------------------------------------------------------------------

Summary of changes:
 CHANGES                                      |  2 +-
 crypto/objects/obj_dat.h                     |  4 ++--
 crypto/objects/objects.txt                   |  2 +-
 doc/apps/c_rehash.pod                        |  2 +-
 doc/apps/ca.pod                              |  2 +-
 doc/apps/ciphers.pod                         |  6 ++---
 doc/apps/cms.pod                             |  4 ++--
 doc/apps/dgst.pod                            |  2 +-
 doc/apps/enc.pod                             |  4 ++--
 doc/apps/genpkey.pod                         |  6 ++---
 doc/apps/openssl.pod                         | 22 ++++++++---------
 doc/apps/req.pod                             |  4 ++--
 doc/apps/s_client.pod                        |  2 +-
 doc/apps/ts.pod                              | 36 ++++++++++++++--------------
 doc/apps/verify.pod                          |  4 ++--
 doc/apps/x509v3_config.pod                   | 10 ++++----
 doc/crypto/ASN1_TIME_set.pod                 |  2 +-
 doc/crypto/ASN1_TYPE_get.pod                 |  2 +-
 doc/crypto/ASN1_generate_nconf.pod           |  4 ++--
 doc/crypto/BIO_f_cipher.pod                  |  2 +-
 doc/crypto/BIO_s_bio.pod                     |  2 +-
 doc/crypto/BIO_s_connect.pod                 |  4 ++--
 doc/crypto/CONF_modules_load_file.pod        |  4 ++--
 doc/crypto/EC_GROUP_copy.pod                 |  6 ++---
 doc/crypto/EC_GROUP_new.pod                  |  6 ++---
 doc/crypto/EC_KEY_new.pod                    |  4 ++--
 doc/crypto/EVP_BytesToKey.pod                |  4 ++--
 doc/crypto/EVP_DigestInit.pod                |  2 +-
 doc/crypto/EVP_DigestSignInit.pod            |  2 +-
 doc/crypto/EVP_PKEY_CTX_ctrl.pod             |  2 +-
 doc/crypto/EVP_PKEY_CTX_new.pod              |  2 +-
 doc/crypto/EVP_PKEY_keygen.pod               |  6 ++---
 doc/crypto/OBJ_nid2obj.pod                   |  4 ++--
 doc/crypto/PKCS12_create.pod                 |  4 ++--
 doc/crypto/PKCS5_PBKDF2_HMAC.pod             |  2 +-
 doc/crypto/PKCS7_sign.pod                    |  2 +-
 doc/crypto/PKCS7_sign_add_signer.pod         |  2 +-
 doc/crypto/PKCS7_verify.pod                  |  2 +-
 doc/crypto/SMIME_write_PKCS7.pod             |  2 +-
 doc/crypto/X509_NAME_get_index_by_NID.pod    |  2 +-
 doc/crypto/X509_STORE_CTX_get_error.pod      |  2 +-
 doc/crypto/X509_STORE_CTX_new.pod            |  6 ++---
 doc/crypto/X509_VERIFY_PARAM_set_flags.pod   | 10 ++++----
 doc/crypto/X509_check_host.pod               |  2 +-
 doc/crypto/X509_verify_cert.pod              |  2 +-
 doc/crypto/d2i_ASN1_OBJECT.pod               |  2 +-
 doc/crypto/d2i_DHparams.pod                  |  2 +-
 doc/crypto/d2i_DSAPublicKey.pod              |  2 +-
 doc/crypto/d2i_X509_ALGOR.pod                |  2 +-
 doc/crypto/d2i_X509_CRL.pod                  |  2 +-
 doc/crypto/d2i_X509_NAME.pod                 |  2 +-
 doc/crypto/d2i_X509_REQ.pod                  |  2 +-
 doc/crypto/d2i_X509_SIG.pod                  |  2 +-
 doc/crypto/ec.pod                            |  2 +-
 doc/crypto/engine.pod                        |  2 +-
 doc/crypto/err.pod                           |  2 +-
 doc/fingerprints.txt                         |  2 +-
 doc/ssl/SSL_CTX_set_cert_cb.pod              |  2 +-
 doc/ssl/SSL_CTX_set_security_level.pod       |  2 +-
 doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod | 26 ++++++++++----------
 include/openssl/obj_mac.h                    |  2 +-
 61 files changed, 132 insertions(+), 132 deletions(-)

diff --git a/CHANGES b/CHANGES
index b6342bd..de00a8a 100644
--- a/CHANGES
+++ b/CHANGES
@@ -7606,7 +7606,7 @@ des-cbc           3624.96k     5258.21k     5530.91k     5624.30k     5628.26k
      [Bodo Moeller; problems reported by Anders Gertz <gertz at epact.se>]     
 
   *) Correct util/mkdef.pl to be selective about disabled algorithms.
-     Previously, it would create entries for disableed algorithms no
+     Previously, it would create entries for disabled algorithms no
      matter what.
      [Richard Levitte]
 
diff --git a/crypto/objects/obj_dat.h b/crypto/objects/obj_dat.h
index bf5496e..c8102a0 100644
--- a/crypto/objects/obj_dat.h
+++ b/crypto/objects/obj_dat.h
@@ -2164,7 +2164,7 @@ static const ASN1_OBJECT nid_objs[NUM_NID]={
 	&(lvalues[5107]),0},
 {"subjectDirectoryAttributes","X509v3 Subject Directory Attributes",
 	NID_subject_directory_attributes,3,&(lvalues[5115]),0},
-{"issuingDistributionPoint","X509v3 Issuing Distrubution Point",
+{"issuingDistributionPoint","X509v3 Issuing Distribution Point",
 	NID_issuing_distribution_point,3,&(lvalues[5118]),0},
 {"certificateIssuer","X509v3 Certificate Issuer",
 	NID_certificate_issuer,3,&(lvalues[5121]),0},
@@ -3654,7 +3654,7 @@ static const unsigned int ln_objs[NUM_LN]={
 857,	/* "X509v3 Freshest CRL" */
 748,	/* "X509v3 Inhibit Any Policy" */
 86,	/* "X509v3 Issuer Alternative Name" */
-770,	/* "X509v3 Issuing Distrubution Point" */
+770,	/* "X509v3 Issuing Distribution Point" */
 83,	/* "X509v3 Key Usage" */
 666,	/* "X509v3 Name Constraints" */
 403,	/* "X509v3 No Revocation Available" */
diff --git a/crypto/objects/objects.txt b/crypto/objects/objects.txt
index 2bcaf83..2fc85b4 100644
--- a/crypto/objects/objects.txt
+++ b/crypto/objects/objects.txt
@@ -748,7 +748,7 @@ id-ce 24		: invalidityDate	: Invalidity Date
 !Cname delta-crl
 id-ce 27		: deltaCRL		: X509v3 Delta CRL Indicator
 !Cname issuing-distribution-point
-id-ce 28		: issuingDistributionPoint : X509v3 Issuing Distrubution Point
+id-ce 28		: issuingDistributionPoint : X509v3 Issuing Distribution Point
 !Cname certificate-issuer
 id-ce 29		: certificateIssuer	: X509v3 Certificate Issuer
 !Cname name-constraints
diff --git a/doc/apps/c_rehash.pod b/doc/apps/c_rehash.pod
index ccce29e..c3d98b6 100644
--- a/doc/apps/c_rehash.pod
+++ b/doc/apps/c_rehash.pod
@@ -28,7 +28,7 @@ directories to be set up like this in order to find certificates.
 
 If any directories are named on the command line, then those are
 processed in turn. If not, then the B<SSL_CERT_DIR> environment variable
-is consulted; this shold be a colon-separated list of directories,
+is consulted; this should be a colon-separated list of directories,
 like the Unix B<PATH> variable.
 If that is not set then the default directory (installation-specific
 but often B</usr/local/ssl/certs>) is processed.
diff --git a/doc/apps/ca.pod b/doc/apps/ca.pod
index 997fa20..1d18070 100644
--- a/doc/apps/ca.pod
+++ b/doc/apps/ca.pod
@@ -245,7 +245,7 @@ configuration file, must be valid UTF8 strings.
 
 =item B<-multivalue-rdn>
 
-This option causes the -subj argument to be interpretedt with full
+This option causes the -subj argument to be interpreted with full
 support for multivalued RDNs. Example:
 
 I</DC=org/DC=OpenSSL/DC=users/UID=123456+CN=John Doe>
diff --git a/doc/apps/ciphers.pod b/doc/apps/ciphers.pod
index 6d39c54..84d8260 100644
--- a/doc/apps/ciphers.pod
+++ b/doc/apps/ciphers.pod
@@ -303,7 +303,7 @@ ciphersuites using SHA256 or SHA384.
 
 =item B<aGOST> 
 
-cipher suites using GOST R 34.10 (either 2001 or 94) for authenticaction
+cipher suites using GOST R 34.10 (either 2001 or 94) for authentication
 (needs an engine supporting GOST algorithms). 
 
 =item B<aGOST01>
@@ -585,7 +585,7 @@ Note: these ciphers can also be used in SSL v3.
  TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256    ECDH-RSA-CAMELLIA128-SHA256
  TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384    ECDH-RSA-CAMELLIA256-SHA384
 
-=head2 Pre shared keying (PSK) cipheruites
+=head2 Pre shared keying (PSK) ciphersuites
 
  TLS_PSK_WITH_RC4_128_SHA                  PSK-RC4-SHA
  TLS_PSK_WITH_3DES_EDE_CBC_SHA             PSK-3DES-EDE-CBC-SHA
@@ -621,7 +621,7 @@ Include all RC4 ciphers but leave out those without authentication:
 
  openssl ciphers -v 'RC4:!COMPLEMENTOFDEFAULT'
 
-Include all chiphers with RSA authentication but leave out ciphers without
+Include all ciphers with RSA authentication but leave out ciphers without
 encryption.
 
  openssl ciphers -v 'RSA:!COMPLEMENTOFALL'
diff --git a/doc/apps/cms.pod b/doc/apps/cms.pod
index af1240a..9001371 100644
--- a/doc/apps/cms.pod
+++ b/doc/apps/cms.pod
@@ -376,7 +376,7 @@ identifier extension. Supported by B<-sign> and B<-encrypt> options.
 =item B<-receipt_request_all -receipt_request_first>
 
 for B<-sign> option include a signed receipt request. Indicate requests should
-be provided by all receipient or first tier recipients (those mailed directly
+be provided by all recipient or first tier recipients (those mailed directly
 and not from a mailing list). Ignored it B<-receipt_request_from> is included.
 
 =item B<-receipt_request_from emailaddress>
@@ -398,7 +398,7 @@ requests.
 
 specify symmetric key to use. The key must be supplied in hex format and be
 consistent with the algorithm used. Supported by the B<-EncryptedData_encrypt>
-B<-EncrryptedData_decrypt>, B<-encrypt> and B<-decrypt> options. When used
+B<-EncryptedData_decrypt>, B<-encrypt> and B<-decrypt> options. When used
 with B<-encrypt> or B<-decrypt> the supplied key is used to wrap or unwrap the
 content encryption key using an AES key in the B<KEKRecipientInfo> type.
 
diff --git a/doc/apps/dgst.pod b/doc/apps/dgst.pod
index 8f974ed..236e1b7 100644
--- a/doc/apps/dgst.pod
+++ b/doc/apps/dgst.pod
@@ -137,7 +137,7 @@ Following options are supported by both by B<HMAC> and B<gost-mac>:
 
 =item B<key:string>
 
-Specifies MAC key as alphnumeric string (use if key contain printable
+Specifies MAC key as alphanumeric string (use if key contain printable
 characters only). String length must conform to any restrictions of
 the MAC algorithm for example exactly 32 chars for gost-mac.
 
diff --git a/doc/apps/enc.pod b/doc/apps/enc.pod
index 41791ad..8f4ef99 100644
--- a/doc/apps/enc.pod
+++ b/doc/apps/enc.pod
@@ -170,7 +170,7 @@ configuration file is read and any ENGINEs loaded.
 Engines which provide entirely new encryption algorithms (such as ccgost
 engine which provides gost89 algorithm) should be configured in the
 configuration file. Engines, specified in the command line using -engine
-options can only be used for hadrware-assisted implementations of
+options can only be used for hardware-assisted implementations of
 ciphers, which are supported by OpenSSL core or other engine, specified
 in the configuration file.
 
@@ -212,7 +212,7 @@ Note that some of these ciphers can be disabled at compile time
 and some are available only if an appropriate engine is configured
 in the configuration file. The output of the B<enc> command run with
 unsupported options (for example B<openssl enc -help>) includes a
-list of ciphers, supported by your versesion of OpenSSL, including
+list of ciphers, supported by your version of OpenSSL, including
 ones provided by configured engines.
 
 The B<enc> program does not support authenticated encryption modes
diff --git a/doc/apps/genpkey.pod b/doc/apps/genpkey.pod
index 74faba5..0bce0b5 100644
--- a/doc/apps/genpkey.pod
+++ b/doc/apps/genpkey.pod
@@ -87,7 +87,7 @@ parameters along with the PEM or DER structure.
 
 =head1 KEY GENERATION OPTIONS
 
-The options supported by each algorith and indeed each implementation of an
+The options supported by each algorithm and indeed each implementation of an
 algorithm can vary. The options for the OpenSSL implementations are detailed
 below.
 
@@ -154,7 +154,7 @@ such as "P-256".
 
 =item B<ec_param_enc:encoding>
 
-the encoding to use for parameters. The "encoding" paramater must be either
+the encoding to use for parameters. The "encoding" parameter must be either
 "named_curve" or "explicit".
 
 =back
@@ -163,7 +163,7 @@ the encoding to use for parameters. The "encoding" paramater must be either
 
 Gost 2001 support is not enabled by default. To enable this algorithm,
 one should load the ccgost engine in the OpenSSL configuration file.
-See README.gost file in the engines/ccgost directiry of the source
+See README.gost file in the engines/ccgost directory of the source
 distribution for more details.
 
 Use of a parameter file for the GOST R 34.10 algorithm is optional.
diff --git a/doc/apps/openssl.pod b/doc/apps/openssl.pod
index b2e2719..3e651b8 100644
--- a/doc/apps/openssl.pod
+++ b/doc/apps/openssl.pod
@@ -23,12 +23,12 @@ v2/v3) and Transport Layer Security (TLS v1) network protocols and related
 cryptography standards required by them.
 
 The B<openssl> program is a command line tool for using the various
-cryptography functions of OpenSSL's B<crypto> library from the shell. 
-It can be used for 
+cryptography functions of OpenSSL's B<crypto> library from the shell.
+It can be used for
 
  o  Creation and management of private keys, public keys and parameters
  o  Public key cryptographic operations
- o  Creation of X.509 certificates, CSRs and CRLs 
+ o  Creation of X.509 certificates, CSRs and CRLs
  o  Calculation of Message Digests
  o  Encryption and Decryption with Ciphers
  o  SSL/TLS Client and Server Tests
@@ -75,7 +75,7 @@ Parse an ASN.1 sequence.
 
 =item L<B<ca>|ca(1)>
 
-Certificate Authority (CA) Management.  
+Certificate Authority (CA) Management.
 
 =item L<B<ciphers>|ciphers(1)>
 
@@ -104,7 +104,7 @@ Obsoleted by L<B<dhparam>|dhparam(1)>.
 
 =item L<B<dhparam>|dhparam(1)>
 
-Generation and Management of Diffie-Hellman Parameters. Superseded by 
+Generation and Management of Diffie-Hellman Parameters. Superseded by
 L<B<genpkey>|genpkey(1)> and L<B<pkeyparam>|pkeyparam(1)>
 
 
@@ -114,7 +114,7 @@ DSA Data Management.
 
 =item L<B<dsaparam>|dsaparam(1)>
 
-DSA Parameter Generation and Management. Superseded by 
+DSA Parameter Generation and Management. Superseded by
 L<B<genpkey>|genpkey(1)> and L<B<pkeyparam>|pkeyparam(1)>
 
 =item L<B<ec>|ec(1)>
@@ -131,7 +131,7 @@ Encoding with Ciphers.
 
 =item L<B<engine>|engine(1)>
 
-Engine (loadble module) information and manipulation.
+Engine (loadable module) information and manipulation.
 
 =item L<B<errstr>|errstr(1)>
 
@@ -144,7 +144,7 @@ Obsoleted by L<B<dhparam>|dhparam(1)>.
 
 =item L<B<gendsa>|gendsa(1)>
 
-Generation of DSA Private Key from Parameters. Superseded by 
+Generation of DSA Private Key from Parameters. Superseded by
 L<B<genpkey>|genpkey(1)> and L<B<pkey>|pkey(1)>
 
 =item L<B<genpkey>|genpkey(1)>
@@ -279,11 +279,11 @@ MDC2 Digest
 
 RMD-160 Digest
 
-=item B<sha>            
+=item B<sha>
 
 SHA Digest
 
-=item B<sha1>           
+=item B<sha1>
 
 SHA-1 Digest
 
@@ -408,7 +408,7 @@ L<rsautl(1)|rsautl(1)>, L<s_client(1)|s_client(1)>,
 L<s_server(1)|s_server(1)>, L<s_time(1)|s_time(1)>,
 L<smime(1)|smime(1)>, L<spkac(1)|spkac(1)>,
 L<verify(1)|verify(1)>, L<version(1)|version(1)>, L<x509(1)|x509(1)>,
-L<crypto(3)|crypto(3)>, L<ssl(3)|ssl(3)>, L<x509v3_config(5)|x509v3_config(5)> 
+L<crypto(3)|crypto(3)>, L<ssl(3)|ssl(3)>, L<x509v3_config(5)|x509v3_config(5)>
 
 =head1 HISTORY
 
diff --git a/doc/apps/req.pod b/doc/apps/req.pod
index eb840be..9e8e1ab 100644
--- a/doc/apps/req.pod
+++ b/doc/apps/req.pod
@@ -153,7 +153,7 @@ the default key size, specified in the configuration file is used.
 
 All other algorithms support the B<-newkey alg:file> form, where file may be
 an algorithm parameter file, created by the B<genpkey -genparam> command
-or and X.509 certificate for a key with approriate algorithm.
+or and X.509 certificate for a key with appropriate algorithm.
 
 B<param:file> generates a key using the parameter file or certificate B<file>,
 the algorithm is determined by the parameters. B<algname:file> use algorithm
@@ -278,7 +278,7 @@ set multiple options. See the L<x509(1)|x509(1)> manual page for details.
 customise the output format used with B<-text>. The B<option> argument can be
 a single option or multiple options separated by commas. 
 
-See discission of the  B<-certopt> parameter in the L<B<x509>|x509(1)>
+See discussion of the  B<-certopt> parameter in the L<B<x509>|x509(1)>
 command.
 
 
diff --git a/doc/apps/s_client.pod b/doc/apps/s_client.pod
index 92f6e4a..6aaef19 100644
--- a/doc/apps/s_client.pod
+++ b/doc/apps/s_client.pod
@@ -343,7 +343,7 @@ Protocol names are printable ASCII strings, for example "http/1.1" or
 "spdy/3".
 Empty list of protocols is treated specially and will cause the client to
 advertise support for the TLS extension but disconnect just after
-reciving ServerHello with a list of server supported protocols.
+receiving ServerHello with a list of server supported protocols.
 
 =back
 
diff --git a/doc/apps/ts.pod b/doc/apps/ts.pod
index d6aa47d..5aab465 100644
--- a/doc/apps/ts.pod
+++ b/doc/apps/ts.pod
@@ -121,7 +121,7 @@ parameter is specified. (Optional)
 It is possible to specify the message imprint explicitly without the data
 file. The imprint must be specified in a hexadecimal format, two characters
 per byte, the bytes optionally separated by colons (e.g. 1A:F6:01:... or
-1AF601...). The number of bytes must match the message digest algorithm 
+1AF601...). The number of bytes must match the message digest algorithm
 in use. (Optional)
 
 =item B<-md2>|B<-md4>|B<-md5>|B<-sha>|B<-sha1>|B<-mdc2>|B<-ripemd160>|B<...>
@@ -189,7 +189,7 @@ OPTIONS> for configurable variables. (Optional)
 
 =item B<-section> tsa_section
 
-The name of the config file section conatining the settings for the
+The name of the config file section containing the settings for the
 response generation. If not specified the default TSA section is
 used, see B<CONFIGURATION FILE OPTIONS> for details. (Optional)
 
@@ -283,7 +283,7 @@ data file. The B<-verify> command does not use the configuration file.
 =item B<-data> file_to_hash
 
 The response or token must be verified against file_to_hash. The file
-is hashed with the message digest algorithm specified in the token. 
+is hashed with the message digest algorithm specified in the token.
 The B<-digest> and B<-queryfile> options must not be specified with this one.
 (Optional)
 
@@ -311,16 +311,16 @@ of a time stamp response (TimeStampResp). (Optional)
 
 =item B<-CApath> trusted_cert_path
 
-The name of the directory containing the trused CA certificates of the
+The name of the directory containing the trusted CA certificates of the
 client. See the similar option of L<verify(1)|verify(1)> for additional
 details. Either this option or B<-CAfile> must be specified. (Optional)
 
 
 =item B<-CAfile> trusted_certs.pem
 
-The name of the file containing a set of trusted self-signed CA 
-certificates in PEM format. See the similar option of 
-L<verify(1)|verify(1)> for additional details. Either this option 
+The name of the file containing a set of trusted self-signed CA
+certificates in PEM format. See the similar option of
+L<verify(1)|verify(1)> for additional details. Either this option
 or B<-CApath> must be specified.
 (Optional)
 
@@ -348,7 +348,7 @@ switch always overrides the settings in the config file.
 
 =over 4
 
-=item B<tsa> section, B<default_tsa>	
+=item B<tsa> section, B<default_tsa>
 
 This is the main section and it specifies the name of another section
 that contains all the options for the B<-reply> command. This default
@@ -375,8 +375,8 @@ generation a new file is created with serial number 1. (Mandatory)
 
 =item B<crypto_device>
 
-Specifies the OpenSSL engine that will be set as the default for 
-all available algorithms. The default value is builtin, you can specify 
+Specifies the OpenSSL engine that will be set as the default for
+all available algorithms. The default value is builtin, you can specify
 any other engines supported by OpenSSL (e.g. use chil for the NCipher HSM).
 (Optional)
 
@@ -419,7 +419,7 @@ the components is missing zero is assumed for that field. (Optional)
 
 =item B<clock_precision_digits>
 
-Specifies the maximum number of digits, which represent the fraction of 
+Specifies the maximum number of digits, which represent the fraction of
 seconds, that  need to be included in the time field. The trailing zeroes
 must be removed from the time, so there might actually be fewer digits,
 or no fraction of seconds at all. Supported only on UNIX platforms.
@@ -458,12 +458,12 @@ overridden by the B<-config> command line option.
 =head1 EXAMPLES
 
 All the examples below presume that B<OPENSSL_CONF> is set to a proper
-configuration file, e.g. the example configuration file 
+configuration file, e.g. the example configuration file
 openssl/apps/openssl.cnf will do.
 
 =head2 Time Stamp Request
 
-To create a time stamp request for design1.txt with SHA-1 
+To create a time stamp request for design1.txt with SHA-1
 without nonce and policy and no certificate is required in the response:
 
   openssl ts -query -data design1.txt -no_nonce \
@@ -479,7 +479,7 @@ To print the content of the previous request in human readable format:
 
   openssl ts -query -in design1.tsq -text
 
-To create a time stamp request which includes the MD-5 digest 
+To create a time stamp request which includes the MD-5 digest
 of design2.txt, requests the signer certificate and nonce,
 specifies a policy id (assuming the tsa_policy1 name is defined in the
 OID section of the config file):
@@ -559,8 +559,8 @@ Zoltan Glozik <zglozik at opentsa.org>. Known issues:
 =over 4
 
 =item * No support for time stamps over SMTP, though it is quite easy
-to implement an automatic e-mail based TSA with L<procmail(1)|procmail(1)> 
-and L<perl(1)|perl(1)>. HTTP server support is provided in the form of 
+to implement an automatic e-mail based TSA with L<procmail(1)|procmail(1)>
+and L<perl(1)|perl(1)>. HTTP server support is provided in the form of
 a separate apache module. HTTP client support is provided by
 L<tsget(1)|tsget(1)>. Pure TCP/IP protocol is not supported.
 
@@ -587,8 +587,8 @@ Zoltan Glozik <zglozik at opentsa.org>, OpenTSA project (http://www.opentsa.org)
 
 =head1 SEE ALSO
 
-L<tsget(1)|tsget(1)>, L<openssl(1)|openssl(1)>, L<req(1)|req(1)>, 
-L<x509(1)|x509(1)>, L<ca(1)|ca(1)>, L<genrsa(1)|genrsa(1)>, 
+L<tsget(1)|tsget(1)>, L<openssl(1)|openssl(1)>, L<req(1)|req(1)>,
+L<x509(1)|x509(1)>, L<ca(1)|ca(1)>, L<genrsa(1)|genrsa(1)>,
 L<config(5)|config(5)>
 
 =cut
diff --git a/doc/apps/verify.pod b/doc/apps/verify.pod
index d422913..9407fae 100644
--- a/doc/apps/verify.pod
+++ b/doc/apps/verify.pod
@@ -11,7 +11,7 @@ B<openssl> B<verify>
 [B<-CApath directory>]
 [B<-attime timestamp>]
 [B<-check_ss_sig>]
-[B<-crlfile file>]
+[B<-CRLfile file>]
 [B<-crl_check>]
 [B<-crl_check_all>]
 [B<-explicit_policy>]
@@ -76,7 +76,7 @@ current system time. B<timestamp> is the number of seconds since
 Verify the signature on the self-signed root CA. This is disabled by default
 because it doesn't add any security.
 
-=item B<-crlfile file>
+=item B<-CRLfile file>
 
 File containing one or more CRL's (in PEM format) to load.
 
diff --git a/doc/apps/x509v3_config.pod b/doc/apps/x509v3_config.pod
index c82cea1..26b327c 100644
--- a/doc/apps/x509v3_config.pod
+++ b/doc/apps/x509v3_config.pod
@@ -88,7 +88,7 @@ only be used to sign end user certificates and not further CAs.
 Key usage is a multi valued extension consisting of a list of names of the
 permitted key usages.
 
-The supporte names are: digitalSignature, nonRepudiation, keyEncipherment,
+The supported names are: digitalSignature, nonRepudiation, keyEncipherment,
 dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly
 and decipherOnly.
 
@@ -202,7 +202,7 @@ Examples:
 The issuer alternative name option supports all the literal options of
 subject alternative name. It does B<not> support the email:copy option because
 that would not make sense. It does support an additional issuer:copy option
-that will copy all the subject alternative name values from the issuer 
+that will copy all the subject alternative name values from the issuer
 certificate (if possible).
 
 Example:
@@ -358,7 +358,7 @@ Some software (for example some versions of MSIE) may require ia5org.
 =head2 Policy Constraints
 
 This is a multi-valued extension which consisting of the names
-B<requireExplicitPolicy> or B<inhibitPolicyMapping> and a non negative intger
+B<requireExplicitPolicy> or B<inhibitPolicyMapping> and a non negative integer
 value. At least one component must be present.
 
 Example:
@@ -380,7 +380,7 @@ Example:
 The name constraints extension is a multi-valued extension. The name should
 begin with the word B<permitted> or B<excluded> followed by a B<;>. The rest of
 the name and the value follows the syntax of subjectAltName except email:copy
-is not supported and the B<IP> form should consist of an IP addresses and 
+is not supported and the B<IP> form should consist of an IP addresses and
 subnet mask separated by a B</>.
 
 Examples:
@@ -491,7 +491,7 @@ will produce an error but the equivalent form:
  [subject_alt_section]
  subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar
 
-is valid. 
+is valid.
 
 Due to the behaviour of the OpenSSL B<conf> library the same field name
 can only occur once in a section. This means that:
diff --git a/doc/crypto/ASN1_TIME_set.pod b/doc/crypto/ASN1_TIME_set.pod
index ae2b53d..d633265 100644
--- a/doc/crypto/ASN1_TIME_set.pod
+++ b/doc/crypto/ASN1_TIME_set.pod
@@ -123,7 +123,7 @@ otherwise.
 ASN1_TIME_print() returns 1 if the time is successfully printed out and 0 if
 an error occurred (I/O error or invalid time format).
 
-ASN1_TIME_diff() returns 1 for sucess and 0 for failure. It can fail if the
+ASN1_TIME_diff() returns 1 for success and 0 for failure. It can fail if the
 pass ASN1_TIME structure has invalid syntax for example.
 
 =cut
diff --git a/doc/crypto/ASN1_TYPE_get.pod b/doc/crypto/ASN1_TYPE_get.pod
index 79f2e38..3fc9d2a 100644
--- a/doc/crypto/ASN1_TYPE_get.pod
+++ b/doc/crypto/ASN1_TYPE_get.pod
@@ -78,7 +78,7 @@ ASN1_TYPE_get() returns the type of the ASN1_TYPE argument.
 
 ASN1_TYPE_set() does not return a value.
 
-ASN1_TYPE_set1() returns 1 for sucess and 0 for failure.
+ASN1_TYPE_set1() returns 1 for success and 0 for failure.
 
 ASN1_TYPE_cmp() returns 0 if the types are identical and non-zero otherwise.
 
diff --git a/doc/crypto/ASN1_generate_nconf.pod b/doc/crypto/ASN1_generate_nconf.pod
index bfa0a04..5dc1091 100644
--- a/doc/crypto/ASN1_generate_nconf.pod
+++ b/doc/crypto/ASN1_generate_nconf.pod
@@ -19,7 +19,7 @@ in an B<ASN1_TYPE> structure.
 B<str> contains the string to encode B<nconf> or B<cnf> contains
 the optional configuration information where additional strings
 will be read from. B<nconf> will typically come from a config
-file wherease B<cnf> is obtained from an B<X509V3_CTX> structure
+file whereas B<cnf> is obtained from an B<X509V3_CTX> structure
 which will typically be used by X509 v3 certificate extension
 functions. B<cnf> or B<nconf> can be set to B<NULL> if no additional
 configuration will be used.
@@ -181,7 +181,7 @@ A BITSTRING with bits 1 and 5 set and all others zero:
  FORMAT:BITLIST,BITSTRING:1,5
 
 A more complex example using a config file to produce a
-SEQUENCE consiting of a BOOL an OID and a UTF8String:
+SEQUENCE consisting of a BOOL an OID and a UTF8String:
 
  asn1 = SEQUENCE:seq_section
 
diff --git a/doc/crypto/BIO_f_cipher.pod b/doc/crypto/BIO_f_cipher.pod
index 02439ce..fd8762a 100644
--- a/doc/crypto/BIO_f_cipher.pod
+++ b/doc/crypto/BIO_f_cipher.pod
@@ -48,7 +48,7 @@ When encrypting BIO_flush() B<must> be called to flush the final block
 through the BIO. If it is not then the final block will fail a subsequent
 decrypt.
 
-When decrypting an error on the final block is signalled by a zero
+When decrypting an error on the final block is signaled by a zero
 return value from the read operation. A successful decrypt followed
 by EOF will also return zero for the final read. BIO_get_cipher_status()
 should be called to determine if the decrypt was successful.
diff --git a/doc/crypto/BIO_s_bio.pod b/doc/crypto/BIO_s_bio.pod
index 8d0a55a..0f15990 100644
--- a/doc/crypto/BIO_s_bio.pod
+++ b/doc/crypto/BIO_s_bio.pod
@@ -162,7 +162,7 @@ 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
+and must be transferred 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.
 
diff --git a/doc/crypto/BIO_s_connect.pod b/doc/crypto/BIO_s_connect.pod
index 18ece4c..4efd567 100644
--- a/doc/crypto/BIO_s_connect.pod
+++ b/doc/crypto/BIO_s_connect.pod
@@ -64,8 +64,8 @@ form "hostname/any/other/path" or "hostname:port/any/other/path".
 BIO_set_conn_port() sets the port to B<port>. B<port> can be the
 numerical form or a string such as "http". A string will be looked
 up first using getservbyname() on the host platform but if that
-fails a standard table of port names will be used. Currently the
-list is http, telnet, socks, https, ssl, ftp, gopher and wais.
+fails a standard table of port names will be used. This internal
+list is http, telnet, socks, https, ssl, ftp, and gopher.
 
 BIO_set_conn_ip() sets the IP address to B<ip> using binary form,
 that is four bytes specifying the IP address in big-endian form.
diff --git a/doc/crypto/CONF_modules_load_file.pod b/doc/crypto/CONF_modules_load_file.pod
index cc0b537..731911a 100644
--- a/doc/crypto/CONF_modules_load_file.pod
+++ b/doc/crypto/CONF_modules_load_file.pod
@@ -19,9 +19,9 @@ The function CONF_modules_load_file() configures OpenSSL using file
 B<filename> and application name B<appname>. If B<filename> is NULL
 the standard OpenSSL configuration file is used. If B<appname> is
 NULL the standard OpenSSL application name B<openssl_conf> is used.
-The behaviour can be cutomized using B<flags>.
+The behaviour can be customized using B<flags>.
 
-CONF_modules_load() is idential to CONF_modules_load_file() except it
+CONF_modules_load() is identical to CONF_modules_load_file() except it
 reads configuration information from B<cnf>.
 
 =head1 NOTES
diff --git a/doc/crypto/EC_GROUP_copy.pod b/doc/crypto/EC_GROUP_copy.pod
index d8fb3dd..a13d2ad 100644
--- a/doc/crypto/EC_GROUP_copy.pod
+++ b/doc/crypto/EC_GROUP_copy.pod
@@ -58,7 +58,7 @@ EC_GROUP_method_of obtains the EC_METHOD of B<group>.
 EC_GROUP_set_generator sets curve paramaters that must be agreed by all participants using the curve. These
 paramaters include the B<generator>, the B<order> and the B<cofactor>. The B<generator> is a well defined point on the
 curve chosen for cryptographic operations. Integers used for point multiplications will be between 0 and
-n-1 where n is the B<order>. The B<order> multipied by the B<cofactor> gives the number of points on the curve.
+n-1 where n is the B<order>. The B<order> multiplied by the B<cofactor> gives the number of points on the curve.
 
 EC_GROUP_get0_generator returns the generator for the identified B<group>.
 
@@ -82,7 +82,7 @@ previous versions of OpenSSL the value 0 must be used instead. Before OpenSSL
 applications would have to explicitly set the named curve form) in OpenSSL
 1.1.0 and later the named curve form is the default.
 
-The point_coversion_form for a curve controls how EC_POINT data is encoded as ASN1 as defined in X9.62 (ECDSA).
+The point_conversion_form for a curve controls how EC_POINT data is encoded as ASN1 as defined in X9.62 (ECDSA).
 point_conversion_form_t is an enum defined as follows: 
 
  typedef enum {
@@ -143,7 +143,7 @@ or a pentanomial of the form:
 f(x) = x^m + x^k3 + x^k2 + x^k1 + 1 with m > k3 > k2 > k1 >= 1
 
 The function EC_GROUP_get_basis_type returns a NID identifying whether a trinomial or pentanomial is in use for the field. The
-function EC_GROUP_get_trinomial_basis must only be called where f(x) is of the trinomial form, and returns the value of B<k>. Similary
+function EC_GROUP_get_trinomial_basis must only be called where f(x) is of the trinomial form, and returns the value of B<k>. Similarly
 the function EC_GROUP_get_pentanomial_basis must only be called where f(x) is of the pentanomial form, and returns the values of B<k1>,
 B<k2> and B<k3> respectively.
 
diff --git a/doc/crypto/EC_GROUP_new.pod b/doc/crypto/EC_GROUP_new.pod
index 44599e2..73d5219 100644
--- a/doc/crypto/EC_GROUP_new.pod
+++ b/doc/crypto/EC_GROUP_new.pod
@@ -42,14 +42,14 @@ use a trinomial or a pentanomial for this parameter.
 
 A new curve can be constructed by calling EC_GROUP_new, using the implementation provided by B<meth> (see
 L<EC_GFp_simple_method(3)|EC_GFp_simple_method(3)>). It is then necessary to call either EC_GROUP_set_curve_GFp or
-EC_GROUP_set_curve_GF2m as appropriate to create a curve defined over Fp or over F2^m respectively. 
+EC_GROUP_set_curve_GF2m as appropriate to create a curve defined over Fp or over F2^m respectively.
 
 EC_GROUP_set_curve_GFp sets the curve parameters B<p>, B<a> and B<b> for a curve over Fp stored in B<group>.
 EC_group_get_curve_GFp obtains the previously set curve parameters.
 
 EC_GROUP_set_curve_GF2m sets the equivalent curve parameters for a curve over F2^m. In this case B<p> represents
-the irreducible polybnomial - each bit represents a term in the polynomial. Therefore there will either be three
-or five bits set dependant on whether the polynomial is a trinomial or a pentanomial.
+the irreducible polynomial - each bit represents a term in the polynomial. Therefore there will either be three
+or five bits set dependent on whether the polynomial is a trinomial or a pentanomial.
 EC_group_get_curve_GF2m obtains the previously set curve parameters.
 
 The functions EC_GROUP_new_curve_GFp and EC_GROUP_new_curve_GF2m are shortcuts for calling EC_GROUP_new and the
diff --git a/doc/crypto/EC_KEY_new.pod b/doc/crypto/EC_KEY_new.pod
index c737058..fc42cbc 100644
--- a/doc/crypto/EC_KEY_new.pod
+++ b/doc/crypto/EC_KEY_new.pod
@@ -38,7 +38,7 @@ EC_KEY_new, EC_KEY_get_flags, EC_KEY_set_flags, EC_KEY_clear_flags, EC_KEY_new_b
 
 =head1 DESCRIPTION
 
-An EC_KEY represents a public key and (optionaly) an associated private key. A new EC_KEY (with no associated curve) can be constructed by calling EC_KEY_new.
+An EC_KEY represents a public key and (optionally) an associated private key. A new EC_KEY (with no associated curve) can be constructed by calling EC_KEY_new.
 The reference count for the newly created EC_KEY is initially set to 1. A curve can be associated with the EC_KEY by calling
 EC_KEY_set_group.
 
@@ -71,7 +71,7 @@ The functions EC_KEY_get0_group, EC_KEY_set_group, EC_KEY_get0_private_key, EC_K
 The functions EC_KEY_get_conv_form and EC_KEY_set_conv_form get and set the point_conversion_form for the B<key>. For a description
 of point_conversion_forms please refer to L<EC_POINT_new(3)|EC_POINT_new(3)>.
 
-EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitary additional data specific to the
+EC_KEY_insert_key_method_data and EC_KEY_get_key_method_data enable the caller to associate arbitrary additional data specific to the
 elliptic curve scheme being used with the EC_KEY object. This data is treated as a "black box" by the ec library. The data to be stored by EC_KEY_insert_key_method_data is provided in the B<data> parameter, which must have have associated functions for duplicating, freeing and "clear_freeing" the data item. If a subsequent EC_KEY_get_key_method_data call is issued, the functions for duplicating, freeing and "clear_freeing" the data item must be provided again, and they must be the same as they were when the data item was inserted.
 
 EC_KEY_set_flags sets the flags in the B<flags> parameter on the EC_KEY object. Any flags that are already set are left set. The currently defined standard flags are EC_FLAG_NON_FIPS_ALLOW and EC_FLAG_FIPS_CHECKED. In addition there is the flag EC_FLAG_COFACTOR_ECDH which is specific to ECDH and is defined in ecdh.h. EC_KEY_get_flags returns the current flags that are set for this EC_KEY. EC_KEY_clear_flags clears the flags indicated by the B<flags> parameter. All other flags are left in their existing state.
diff --git a/doc/crypto/EVP_BytesToKey.pod b/doc/crypto/EVP_BytesToKey.pod
index cd3aa02..e6df57d 100644
--- a/doc/crypto/EVP_BytesToKey.pod
+++ b/doc/crypto/EVP_BytesToKey.pod
@@ -29,7 +29,7 @@ A typical application of this function is to derive keying material for an
 encryption algorithm from a password in the B<data> parameter.
 
 Increasing the B<count> parameter slows down the algorithm which makes it
-harder for an attacker to peform a brute force attack using a large number
+harder for an attacker to perform a brute force attack using a large number
 of candidate passwords.
 
 If the total key and IV length is less than the digest length and
@@ -46,7 +46,7 @@ enough data is available for the key and IV. D_i is defined as:
 
 	D_i = HASH^count(D_(i-1) || data || salt)
 
-where || denotes concatentaion, D_0 is empty, HASH is the digest
+where || denotes concatenation, D_0 is empty, HASH is the digest
 algorithm in use, HASH^1(data) is simply HASH(data), HASH^2(data)
 is HASH(HASH(data)) and so on.
 
diff --git a/doc/crypto/EVP_DigestInit.pod b/doc/crypto/EVP_DigestInit.pod
index 3fb9b4c..06e6d4f 100644
--- a/doc/crypto/EVP_DigestInit.pod
+++ b/doc/crypto/EVP_DigestInit.pod
@@ -74,7 +74,7 @@ EVP_MD_CTX_create() allocates, initializes and returns a digest context.
 
 EVP_DigestInit_ex() sets up digest context B<ctx> to use a digest
 B<type> from ENGINE B<impl>. B<ctx> must be initialized before calling this
-function. B<type> will typically be supplied by a functionsuch as EVP_sha1().
+function. B<type> will typically be supplied by a function such as EVP_sha1().
 If B<impl> is NULL then the default implementation of digest B<type> is used.
 
 EVP_DigestUpdate() hashes B<cnt> bytes of data at B<d> into the
diff --git a/doc/crypto/EVP_DigestSignInit.pod b/doc/crypto/EVP_DigestSignInit.pod
index 37d960e..5ad1926 100644
--- a/doc/crypto/EVP_DigestSignInit.pod
+++ b/doc/crypto/EVP_DigestSignInit.pod
@@ -26,7 +26,7 @@ be used to set alternative signing options.
 EVP_DigestSignUpdate() hashes B<cnt> bytes of data at B<d> into the
 signature context B<ctx>. This function can be called several times on the
 same B<ctx> to include additional data. This function is currently implemented
-usig a macro.
+using a macro.
 
 EVP_DigestSignFinal() signs the data in B<ctx> places the signature in B<sig>.
 If B<sig> is B<NULL> then the maximum size of the output buffer is written to
diff --git a/doc/crypto/EVP_PKEY_CTX_ctrl.pod b/doc/crypto/EVP_PKEY_CTX_ctrl.pod
index 6866a6f..026c10b 100644
--- a/doc/crypto/EVP_PKEY_CTX_ctrl.pod
+++ b/doc/crypto/EVP_PKEY_CTX_ctrl.pod
@@ -89,7 +89,7 @@ B<PSS> block structure. If this macro is not called a salt length value of -2
 is used by default.
 
 The EVP_PKEY_CTX_set_rsa_rsa_keygen_bits() macro sets the RSA key length for
-RSA key genration to B<bits>. If not specified 1024 bits is used.
+RSA key generation to B<bits>. If not specified 1024 bits is used.
 
 The EVP_PKEY_CTX_set_rsa_keygen_pubexp() macro sets the public exponent value
 for RSA key generation to B<pubexp> currently it should be an odd integer. The
diff --git a/doc/crypto/EVP_PKEY_CTX_new.pod b/doc/crypto/EVP_PKEY_CTX_new.pod
index 17d5e74..d30e007 100644
--- a/doc/crypto/EVP_PKEY_CTX_new.pod
+++ b/doc/crypto/EVP_PKEY_CTX_new.pod
@@ -21,7 +21,7 @@ the algorithm specified in B<pkey> and ENGINE B<e>.
 The EVP_PKEY_CTX_new_id() function allocates public key algorithm context
 using the algorithm specified by B<id> and ENGINE B<e>. It is normally used
 when no B<EVP_PKEY> structure is associated with the operations, for example
-during parameter generation of key genration for some algorithms.
+during parameter generation of key generation for some algorithms.
 
 EVP_PKEY_CTX_dup() duplicates the context B<ctx>.
 
diff --git a/doc/crypto/EVP_PKEY_keygen.pod b/doc/crypto/EVP_PKEY_keygen.pod
index fd431ac..2f0256d 100644
--- a/doc/crypto/EVP_PKEY_keygen.pod
+++ b/doc/crypto/EVP_PKEY_keygen.pod
@@ -26,7 +26,7 @@ EVP_PKEY_keygen_init, EVP_PKEY_keygen, EVP_PKEY_paramgen_init, EVP_PKEY_paramgen
 =head1 DESCRIPTION
 
 The EVP_PKEY_keygen_init() function initializes a public key algorithm
-context using key B<pkey> for a key genration operation.
+context using key B<pkey> for a key generation operation.
 
 The EVP_PKEY_keygen() function performs a key generation operation, the 
 generated key is written to B<ppkey>.
@@ -44,7 +44,7 @@ parameters available is returned. Any non negative value returns the value of
 that parameter. EVP_PKEY_CTX_gen_keygen_info() with a non-negative value for
 B<idx> should only be called within the generation callback.
 
-If the callback returns 0 then the key genration operation is aborted and an
+If the callback returns 0 then the key generation operation is aborted and an
 error occurs. This might occur during a time consuming operation where
 a user clicks on a "cancel" button.
 
@@ -64,7 +64,7 @@ once on the same context if several operations are performed using the same
 parameters.
 
 The meaning of the parameters passed to the callback will depend on the
-algorithm and the specifiic implementation of the algorithm. Some might not
+algorithm and the specific implementation of the algorithm. Some might not
 give any useful information at all during key or parameter generation. Others
 might not even call the callback.
 
diff --git a/doc/crypto/OBJ_nid2obj.pod b/doc/crypto/OBJ_nid2obj.pod
index 648204e..7acb4c4 100644
--- a/doc/crypto/OBJ_nid2obj.pod
+++ b/doc/crypto/OBJ_nid2obj.pod
@@ -46,7 +46,7 @@ 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.
+a long name, a short name or the numerical representation 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
@@ -104,7 +104,7 @@ 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.
 
-Some objects are used to reprsent algorithms which do not have a
+Some objects are used to represent algorithms which do not have a
 corresponding ASN.1 OBJECT IDENTIFIER encoding (for example no OID currently
 exists for a particular algorithm). As a result they B<cannot> be encoded or
 decoded as part of ASN.1 structures. Applications can determine if there
diff --git a/doc/crypto/PKCS12_create.pod b/doc/crypto/PKCS12_create.pod
index de7cab2..88397fe 100644
--- a/doc/crypto/PKCS12_create.pod
+++ b/doc/crypto/PKCS12_create.pod
@@ -16,7 +16,7 @@ PKCS12_create - create a PKCS#12 structure
 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 supplied certificate 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.
 
@@ -56,7 +56,7 @@ used for the corresponding B<friendlyName> or B<localKeyID> in the
 PKCS12 structure.
 
 Either B<pkey>, B<cert> or both can be B<NULL> to indicate that no key or
-certficate is required. In previous versions both had to be present or
+certificate is required. In previous versions both had to be present or
 a fatal error is returned.
 
 B<nid_key> or B<nid_cert> can be set to -1 indicating that no encryption
diff --git a/doc/crypto/PKCS5_PBKDF2_HMAC.pod b/doc/crypto/PKCS5_PBKDF2_HMAC.pod
index 3431ff0..7287993 100644
--- a/doc/crypto/PKCS5_PBKDF2_HMAC.pod
+++ b/doc/crypto/PKCS5_PBKDF2_HMAC.pod
@@ -49,7 +49,7 @@ encryption algorithm from a password in the B<pass>, a salt in B<salt>,
 and an iteration count.
 
 Increasing the B<iter> parameter slows down the algorithm which makes it
-harder for an attacker to peform a brute force attack using a large number
+harder for an attacker to perform a brute force attack using a large number
 of candidate passwords.
 
 =head1 RETURN VALUES
diff --git a/doc/crypto/PKCS7_sign.pod b/doc/crypto/PKCS7_sign.pod
index 64a3514..c788c4b 100644
--- a/doc/crypto/PKCS7_sign.pod
+++ b/doc/crypto/PKCS7_sign.pod
@@ -13,7 +13,7 @@ PKCS7_sign - create a PKCS#7 signedData structure
 =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.
+the certificate to sign with, B<pkey> is the corresponding 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). 
 
diff --git a/doc/crypto/PKCS7_sign_add_signer.pod b/doc/crypto/PKCS7_sign_add_signer.pod
index ebec4d5..f09a0f9 100644
--- a/doc/crypto/PKCS7_sign_add_signer.pod
+++ b/doc/crypto/PKCS7_sign_add_signer.pod
@@ -40,7 +40,7 @@ Any of the following flags (ored together) can be passed in the B<flags>
 parameter.
 
 If B<PKCS7_REUSE_DIGEST> is set then an attempt is made to copy the content
-digest value from the PKCS7 struture: to add a signer to an existing structure.
+digest value from the PKCS7 structure: to add a signer to an existing structure.
 An error occurs if a matching digest value cannot be found to copy. The
 returned PKCS7 structure will be valid and finalized when this flag is set.
 
diff --git a/doc/crypto/PKCS7_verify.pod b/doc/crypto/PKCS7_verify.pod
index f083306..cad304e 100644
--- a/doc/crypto/PKCS7_verify.pod
+++ b/doc/crypto/PKCS7_verify.pod
@@ -16,7 +16,7 @@ PKCS7_verify, PKCS7_get0_signers - verify a PKCS#7 signedData structure
 
 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
+the signer's certificate. B<store> is a trusted certificate 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.
diff --git a/doc/crypto/SMIME_write_PKCS7.pod b/doc/crypto/SMIME_write_PKCS7.pod
index ca6bd02..4a7cd08 100644
--- a/doc/crypto/SMIME_write_PKCS7.pod
+++ b/doc/crypto/SMIME_write_PKCS7.pod
@@ -40,7 +40,7 @@ the data must be read twice: once to compute the signature in PKCS7_sign()
 and once to output the S/MIME message.
 
 If streaming is performed the content is output in BER format using indefinite
-length constructuted encoding except in the case of signed data with detached
+length constructed encoding except in the case of signed data with detached
 content where the content is absent and DER format is used.
 
 =head1 BUGS
diff --git a/doc/crypto/X509_NAME_get_index_by_NID.pod b/doc/crypto/X509_NAME_get_index_by_NID.pod
index c8a8128..84fc180 100644
--- a/doc/crypto/X509_NAME_get_index_by_NID.pod
+++ b/doc/crypto/X509_NAME_get_index_by_NID.pod
@@ -51,7 +51,7 @@ 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
+be highly confusing if the target is a multicharacter string type
 like a BMPString or a UTF8String.
 
 For a more general solution X509_NAME_get_index_by_NID() or
diff --git a/doc/crypto/X509_STORE_CTX_get_error.pod b/doc/crypto/X509_STORE_CTX_get_error.pod
index be00ff1..7748e90 100644
--- a/doc/crypto/X509_STORE_CTX_get_error.pod
+++ b/doc/crypto/X509_STORE_CTX_get_error.pod
@@ -55,7 +55,7 @@ X509_STORE_CTX_get_error() returns B<X509_V_OK> or an error code.
 
 X509_STORE_CTX_get_error_depth() returns a non-negative error depth.
 
-X509_STORE_CTX_get_current_cert() returns the cerificate which caused the
+X509_STORE_CTX_get_current_cert() returns the certificate which caused the
 error or B<NULL> if no certificate is relevant to the error.
 
 X509_verify_cert_error_string() returns a human readable error string for
diff --git a/doc/crypto/X509_STORE_CTX_new.pod b/doc/crypto/X509_STORE_CTX_new.pod
index bad12e4..d8d3346 100644
--- a/doc/crypto/X509_STORE_CTX_new.pod
+++ b/doc/crypto/X509_STORE_CTX_new.pod
@@ -49,7 +49,7 @@ X509_STORE_CTX_trusted_stack() sets the set of trusted certificates of B<ctx>
 to B<sk>. This is an alternative way of specifying trusted certificates 
 instead of using an B<X509_STORE>.
 
-X509_STORE_CTX_set_cert() sets the certificate to be vertified in B<ctx> to
+X509_STORE_CTX_set_cert() sets the certificate to be verified in B<ctx> to
 B<x>.
 
 X509_STORE_CTX_set_chain() sets the additional certificate chain used by B<ctx>
@@ -61,10 +61,10 @@ enabled in the associated B<X509_VERIFY_PARAM> structure. This might be
 used where additional "useful" CRLs are supplied as part of a protocol,
 for example in a PKCS#7 structure.
 
-X509_VERIFY_PARAM *X509_STORE_CTX_get0_param() retrieves an intenal pointer
+X509_VERIFY_PARAM *X509_STORE_CTX_get0_param() retrieves an internal pointer
 to the verification parameters associated with B<ctx>.
 
-X509_STORE_CTX_set0_param() sets the intenal verification parameter pointer
+X509_STORE_CTX_set0_param() sets the internal verification parameter pointer
 to B<param>. After this call B<param> should not be used.
 
 X509_STORE_CTX_set_default() looks up and sets the default verification
diff --git a/doc/crypto/X509_VERIFY_PARAM_set_flags.pod b/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
index d19dc12..066ce0f 100644
--- a/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
+++ b/doc/crypto/X509_VERIFY_PARAM_set_flags.pod
@@ -89,7 +89,7 @@ with the DANE-EE(3) certificate usage, and the internal check will
 be suppressed as appropriate when DANE support is added to OpenSSL.
 
 X509_VERIFY_PARAM_add1_host() adds B<name> as an additional reference
-identifer that can match the peer's certificate.  Any previous names
+identifier that can match the peer's certificate.  Any previous names
 set via X509_VERIFY_PARAM_set1_host() or X509_VERIFY_PARAM_add1_host()
 are retained, no change is made if B<name> is NULL or empty.  When
 multiple names are configured, the peer is considered verified when
@@ -157,13 +157,13 @@ ignored. B<WARNING> setting this option for anything other than debugging
 purposes can be a security risk. Finer control over which extensions are
 supported can be performed in the verification callback.
 
-THe B<X509_V_FLAG_X509_STRICT> flag disables workarounds for some broken
+The B<X509_V_FLAG_X509_STRICT> flag disables workarounds for some broken
 certificates and makes the verification strictly apply B<X509> rules.
 
 B<X509_V_FLAG_ALLOW_PROXY_CERTS> enables proxy certificate verification.
 
 B<X509_V_FLAG_POLICY_CHECK> enables certificate policy checking, by default
-no policy checking is peformed. Additional information is sent to the 
+no policy checking is performed. Additional information is sent to the
 verification callback relating to policy checking.
 
 B<X509_V_FLAG_EXPLICIT_POLICY>, B<X509_V_FLAG_INHIBIT_ANY> and
@@ -181,11 +181,11 @@ By default some additional features such as indirect CRLs and CRLs signed by
 different keys are disabled. If B<X509_V_FLAG_EXTENDED_CRL_SUPPORT> is set
 they are enabled.
 
-If B<X509_V_FLAG_USE_DELTAS> ise set delta CRLs (if present) are used to
+If B<X509_V_FLAG_USE_DELTAS> is set delta CRLs (if present) are used to
 determine certificate status. If not set deltas are ignored.
 
 B<X509_V_FLAG_CHECK_SS_SIGNATURE> enables checking of the root CA self signed
-cerificate signature. By default this check is disabled because it doesn't
+certificate signature. By default this check is disabled because it doesn't
 add any additional security but in some cases applications might want to
 check the signature anyway. A side effect of not checking the root CA
 signature is that disabled or unsupported message digests on the root CA
diff --git a/doc/crypto/X509_check_host.pod b/doc/crypto/X509_check_host.pod
index 0def17a..eab2586 100644
--- a/doc/crypto/X509_check_host.pod
+++ b/doc/crypto/X509_check_host.pod
@@ -91,7 +91,7 @@ expansion; this only applies to B<X509_check_host>.
 
 If set, B<X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS> suppresses support
 for "*" as wildcard pattern in labels that have a prefix or suffix,
-such as: "www*" or "*www"; this only aplies to B<X509_check_host>.
+such as: "www*" or "*www"; this only applies to B<X509_check_host>.
 
 If set, B<X509_CHECK_FLAG_MULTI_LABEL_WILDCARDS> allows a "*" that
 constitutes the complete label of a DNS name (e.g. "*.example.com")
diff --git a/doc/crypto/X509_verify_cert.pod b/doc/crypto/X509_verify_cert.pod
index 5253bdc..e5cfc6f 100644
--- a/doc/crypto/X509_verify_cert.pod
+++ b/doc/crypto/X509_verify_cert.pod
@@ -2,7 +2,7 @@
 
 =head1 NAME
 
-X509_verify_cert - discover and verify X509 certificte chain
+X509_verify_cert - discover and verify X509 certificate chain
 
 =head1 SYNOPSIS
 
diff --git a/doc/crypto/d2i_ASN1_OBJECT.pod b/doc/crypto/d2i_ASN1_OBJECT.pod
index 45bb184..d9a6912 100644
--- a/doc/crypto/d2i_ASN1_OBJECT.pod
+++ b/doc/crypto/d2i_ASN1_OBJECT.pod
@@ -15,7 +15,7 @@ d2i_ASN1_OBJECT, i2d_ASN1_OBJECT - ASN1 OBJECT IDENTIFIER functions
 
 These functions decode and encode an ASN1 OBJECT IDENTIFIER.
 
-Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+Otherwise 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
diff --git a/doc/crypto/d2i_DHparams.pod b/doc/crypto/d2i_DHparams.pod
index 1e98aeb..d8bdf22 100644
--- a/doc/crypto/d2i_DHparams.pod
+++ b/doc/crypto/d2i_DHparams.pod
@@ -16,7 +16,7 @@ d2i_DHparams, i2d_DHparams - PKCS#3 DH parameter functions.
 These functions decode and encode PKCS#3 DH parameters using the
 DHparameter structure described in PKCS#3.
 
-Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+Otherwise 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
diff --git a/doc/crypto/d2i_DSAPublicKey.pod b/doc/crypto/d2i_DSAPublicKey.pod
index e999376..44451cf 100644
--- a/doc/crypto/d2i_DSAPublicKey.pod
+++ b/doc/crypto/d2i_DSAPublicKey.pod
@@ -68,7 +68,7 @@ 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
+The B<DSAPrivateKey> functions also use a non standard structure consisting
 consisting of a SEQUENCE containing the B<p>, B<q>, B<g> and B<pub_key> and
 B<priv_key> fields respectively.
 
diff --git a/doc/crypto/d2i_X509_ALGOR.pod b/doc/crypto/d2i_X509_ALGOR.pod
index 9e5cd92..272a138 100644
--- a/doc/crypto/d2i_X509_ALGOR.pod
+++ b/doc/crypto/d2i_X509_ALGOR.pod
@@ -16,7 +16,7 @@ d2i_X509_ALGOR, i2d_X509_ALGOR - AlgorithmIdentifier functions.
 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()
+Otherwise 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
diff --git a/doc/crypto/d2i_X509_CRL.pod b/doc/crypto/d2i_X509_CRL.pod
index 675d38b..5ace93a 100644
--- a/doc/crypto/d2i_X509_CRL.pod
+++ b/doc/crypto/d2i_X509_CRL.pod
@@ -23,7 +23,7 @@ i2d_X509_CRL_bio, i2d_X509_CRL_fp - PKCS#10 certificate request functions.
 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()
+Otherwise 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
diff --git a/doc/crypto/d2i_X509_NAME.pod b/doc/crypto/d2i_X509_NAME.pod
index 343ffe1..fe0b6c0 100644
--- a/doc/crypto/d2i_X509_NAME.pod
+++ b/doc/crypto/d2i_X509_NAME.pod
@@ -17,7 +17,7 @@ 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()
+Otherwise 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
diff --git a/doc/crypto/d2i_X509_REQ.pod b/doc/crypto/d2i_X509_REQ.pod
index 91c0c19..3a52df4 100644
--- a/doc/crypto/d2i_X509_REQ.pod
+++ b/doc/crypto/d2i_X509_REQ.pod
@@ -22,7 +22,7 @@ i2d_X509_REQ_bio, i2d_X509_REQ_fp - PKCS#10 certificate request functions.
 
 These functions decode and encode a PKCS#10 certificate request.
 
-Othewise these behave in a similar way to d2i_X509() and i2d_X509()
+Otherwise 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
diff --git a/doc/crypto/d2i_X509_SIG.pod b/doc/crypto/d2i_X509_SIG.pod
index e48fd79..38a6f20 100644
--- a/doc/crypto/d2i_X509_SIG.pod
+++ b/doc/crypto/d2i_X509_SIG.pod
@@ -16,7 +16,7 @@ d2i_X509_SIG, i2d_X509_SIG - DigestInfo functions.
 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()
+Otherwise 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
diff --git a/doc/crypto/ec.pod b/doc/crypto/ec.pod
index 7d57ba8..aee0fdf 100644
--- a/doc/crypto/ec.pod
+++ b/doc/crypto/ec.pod
@@ -184,7 +184,7 @@ The creation and destruction of B<EC_GROUP> objects is described in L<EC_GROUP_n
 manipulating B<EC_GROUP> objects are described in L<EC_GROUP_copy(3)|EC_GROUP_copy(3)>.
 
 Functions for creating, destroying and manipulating B<EC_POINT> objects are explained in L<EC_POINT_new(3)|EC_POINT_new(3)>,
-whilst functions for performing mathematical operations and tests on B<EC_POINTs> are coverd in L<EC_POINT_add(3)|EC_POINT_add(3)>.
+whilst functions for performing mathematical operations and tests on B<EC_POINTs> are covered in L<EC_POINT_add(3)|EC_POINT_add(3)>.
 
 For working with private and public keys refer to L<EC_KEY_new(3)|EC_KEY_new(3)>. Implementations are covered in
 L<EC_GFp_simple_method(3)|EC_GFp_simple_method(3)>.
diff --git a/doc/crypto/engine.pod b/doc/crypto/engine.pod
index f5ab1c3..5eb065c 100644
--- a/doc/crypto/engine.pod
+++ b/doc/crypto/engine.pod
@@ -576,7 +576,7 @@ for any higher-level ENGINE functions such as ENGINE_ctrl_cmd_string().
 by applications, administrations, users, etc. These can support arbitrary
 operations via ENGINE_ctrl(), including passing to and/or from the control
 commands data of any arbitrary type. These commands are supported in the
-discovery mechanisms simply to allow applications determinie if an ENGINE
+discovery mechanisms simply to allow applications to determine if an ENGINE
 supports certain specific commands it might want to use (eg. application "foo"
 might query various ENGINEs to see if they implement "FOO_GET_VENDOR_LOGO_GIF" -
 and ENGINE could therefore decide whether or not to support this "foo"-specific
diff --git a/doc/crypto/err.pod b/doc/crypto/err.pod
index 4a5dc69..4b10f59 100644
--- a/doc/crypto/err.pod
+++ b/doc/crypto/err.pod
@@ -46,7 +46,7 @@ err - error codes
 
 =head1 DESCRIPTION
 
-When a call to the OpenSSL library fails, this is usually signalled
+When a call to the OpenSSL library fails, this is usually signaled
 by the return value, and an error code is stored in an error queue
 associated with the current thread. The B<err> library provides
 functions to obtain these error codes and textual error messages.
diff --git a/doc/fingerprints.txt b/doc/fingerprints.txt
index b55d7bb..1863224 100644
--- a/doc/fingerprints.txt
+++ b/doc/fingerprints.txt
@@ -1,4 +1,4 @@
-Fingerprints for Signing Relases
+Fingerprints for Signing Releases
 
 OpenSSL releases are signed with PGP/GnuPG keys.  This file contains
 the fingerprints of team members who are "authorized" to sign the
diff --git a/doc/ssl/SSL_CTX_set_cert_cb.pod b/doc/ssl/SSL_CTX_set_cert_cb.pod
index 141d828..1677ff0 100644
--- a/doc/ssl/SSL_CTX_set_cert_cb.pod
+++ b/doc/ssl/SSL_CTX_set_cert_cb.pod
@@ -43,7 +43,7 @@ SSL_add1_chain_cert().
 It might also call SSL_certs_clear() to delete any certificates associated
 with the B<SSL> object.
 
-The certificate callback functionality supercedes the (largely broken)
+The certificate callback functionality supersedes the (largely broken)
 functionality provided by the old client certificate callback interface.
 It is B<always> called even is a certificate is already set so the callback
 can modify or delete the existing certificate.
diff --git a/doc/ssl/SSL_CTX_set_security_level.pod b/doc/ssl/SSL_CTX_set_security_level.pod
index d5d2539..a8a7ecc 100644
--- a/doc/ssl/SSL_CTX_set_security_level.pod
+++ b/doc/ssl/SSL_CTX_set_security_level.pod
@@ -34,7 +34,7 @@ SSL_CTX_set_security_level, SSL_set_security_level, SSL_CTX_get_security_level,
 =head1 DESCRIPTION
 
 The functions SSL_CTX_set_security_level() and SSL_set_security_level() set
-the security level to B<level>. If not set the libary default security level
+the security level to B<level>. If not set the library default security level
 is used.
 
 The functions SSL_CTX_get_security_level() and SSL_get_security_level()
diff --git a/doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod b/doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod
index da0dd0f..af203b8 100644
--- a/doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod
+++ b/doc/ssl/SSL_CTX_set_tlsext_ticket_key_cb.pod
@@ -15,7 +15,7 @@ SSL_CTX_set_tlsext_ticket_key_cb - set a callback for session ticket processing
 
 =head1 DESCRIPTION
 
-SSL_CTX_set_tlsext_ticket_key_cb() sets a callback fuction I<cb> for handling 
+SSL_CTX_set_tlsext_ticket_key_cb() sets a callback function I<cb> for handling
 session tickets for the ssl context I<sslctx>. Session tickets, defined in 
 RFC5077 provide an enhanced session resumption capability where the server
 implementation is not required to maintain per session state. It only applies
@@ -40,13 +40,13 @@ The server, through the callback function, either agrees to reuse the session
 ticket information or it starts a full TLS handshake to create a new session
 ticket.
 
-Before the callback function is started I<ctx> and I<hctx> have been 
+Before the callback function is started I<ctx> and I<hctx> have been
 initialised with EVP_CIPHER_CTX_init and HMAC_CTX_init respectively.
 
 For new sessions tickets, when the client doesn't present a session ticket, or
-an attempted retreival of the ticket failed, or a renew option was indicated,
+an attempted retrieval of the ticket failed, or a renew option was indicated,
 the callback function will be called with I<enc> equal to 1. The OpenSSL
-library expects that the function will set an arbitary I<name>, initialize
+library expects that the function will set an arbitrary I<name>, initialize
 I<iv>, and set the cipher context I<ctx> and the hash context I<hctx>.
 
 The I<name> is 16 characters long and is used as a key identifier.
@@ -54,22 +54,22 @@ The I<name> is 16 characters long and is used as a key identifier.
 The I<iv> length is the length of the IV of the corresponding cipher. The
 maximum IV length is L<EVP_MAX_IV_LENGTH> bytes defined in B<evp.h>.
 
-The initialization vector I<iv> should be a random value. The cipher context 
-I<ctx> should use the initialisation vector I<iv>. The cipher context can be 
+The initialization vector I<iv> should be a random value. The cipher context
+I<ctx> should use the initialisation vector I<iv>. The cipher context can be
 set using L<EVP_EncryptInit_ex>. The hmac context can be set using L<HMAC_Init_ex>.
 
 When the client presents a session ticket, the callback function with be called 
-with I<enc> set to 0 indicating that the I<cb> function should retreive a set
+with I<enc> set to 0 indicating that the I<cb> function should retrieve a set
 of parameters. In this case I<name> and I<iv> have already been parsed out of
 the session ticket. The OpenSSL library expects that the I<name> will be used
 to retrieve a cryptographic parameters and that the cryptographic context
-I<ctx> will be set with the retreived parameters and the initialization vector
+I<ctx> will be set with the retrieved parameters and the initialization vector
 I<iv>. using a function like L<EVP_DecryptInit_ex>. The I<hctx> needs to be set
 using L<HMAC_Init_ex>.
 
 If the I<name> is still valid but a renewal of the ticket is required the
 callback function should return 2. The library will call the callback again
-with an arguement of enc equal to 1 to set the new ticket.
+with an argument of enc equal to 1 to set the new ticket.
 
 The return value of the I<cb> function is used by OpenSSL to determine what
 further processing will occur. The following return values have meaning:
@@ -92,7 +92,7 @@ continue on those parameters.
 =item Z<>0
 
 This indicates that it was not possible to set/retrieve a session ticket and 
-the SSL/TLS session will continue by by negiotationing a set of cryptographic
+the SSL/TLS session will continue by by negotiating a set of cryptographic
 parameters or using the alternate SSL/TLS resumption mechanism, session ids.
 
 If called with enc equal to 0 the library will call the I<cb> again to get
@@ -107,10 +107,10 @@ This indicates an error.
 =head1 NOTES
 
 Session resumption shortcuts the TLS so that the client certificate
-negiotation don't occur. It makes up for this by storing client certificate
+negotiation don't occur. It makes up for this by storing client certificate
 an all other negotiated state information encrypted within the ticket. In a
 resumed session the applications will have all this state information available
-exactly as if a full negiotation had occured.
+exactly as if a full negotiation had occurred.
 
 If an attacker can obtain the key used to encrypt a session ticket, they can
 obtain the master secret for any ticket using that key and decrypt any traffic
@@ -125,7 +125,7 @@ enable an attacker to obtain the session keys.
 
 =head1 EXAMPLES
 
-Reference Implemention:
+Reference Implementation:
   SSL_CTX_set_tlsext_ticket_key_cb(SSL,ssl_tlsext_ticket_key_cb);
   ....
 
diff --git a/include/openssl/obj_mac.h b/include/openssl/obj_mac.h
index 9d37396..e750a85 100644
--- a/include/openssl/obj_mac.h
+++ b/include/openssl/obj_mac.h
@@ -2354,7 +2354,7 @@
 #define OBJ_delta_crl           OBJ_id_ce,27L
 
 #define SN_issuing_distribution_point           "issuingDistributionPoint"
-#define LN_issuing_distribution_point           "X509v3 Issuing Distrubution Point"
+#define LN_issuing_distribution_point           "X509v3 Issuing Distribution Point"
 #define NID_issuing_distribution_point          770
 #define OBJ_issuing_distribution_point          OBJ_id_ce,28L
 


More information about the openssl-commits mailing list