10 files changed, 1572 insertions, 0 deletions

diff --git a/src/lib/libssl/src/doc/apps/ec.pod b/src/lib/libssl/src/doc/apps/ec.pod
new file mode 100644
index 0000000000..1d4a36dbf4
--- /dev/null
+++ b/src/lib/libssl/src/doc/apps/ec.pod
@@ -0,0 +1,190 @@
+=pod
+
+=head1 NAME
+
+ec - EC key processing
+
+=head1 SYNOPSIS
+
+B<openssl> B<ec>
+[B<-inform PEM|DER>]
+[B<-outform PEM|DER>]
+[B<-in filename>]
+[B<-passin arg>]
+[B<-out filename>]
+[B<-passout arg>]
+[B<-des>]
+[B<-des3>]
+[B<-idea>]
+[B<-text>]
+[B<-noout>]
+[B<-param_out>]
+[B<-pubin>]
+[B<-pubout>]
+[B<-conv_form arg>]
+[B<-param_enc arg>]
+[B<-engine id>]
+
+=head1 DESCRIPTION
+
+The B<ec> command processes EC keys. They can be converted between various
+forms and their components printed out. B<Note> OpenSSL uses the 
+private key format specified in 'SEC 1: Elliptic Curve Cryptography'
+(http://www.secg.org/). To convert a OpenSSL EC private key into the
+PKCS#8 private key format use the B<pkcs8> command.
+
+=head1 COMMAND OPTIONS
+
+=over 4
+
+=item B<-inform DER|PEM>
+
+This specifies the input format. The B<DER> option with a private key uses
+an ASN.1 DER encoded SEC1 private key. When used with a public key it
+uses the SubjectPublicKeyInfo structur as specified in RFC 3280.
+The B<PEM> form is the default format: it consists of the B<DER> format base64
+encoded with additional header and footer lines. In the case of a private key
+PKCS#8 format is also accepted.
+
+=item B<-outform DER|PEM>
+
+This specifies the output format, the options have the same meaning as the 
+B<-inform> option.
+
+=item B<-in filename>
+
+This specifies the input filename to read a key from or standard input if this
+option is not specified. If the key is encrypted a pass phrase will be
+prompted for.
+
+=item B<-passin arg>
+
+the input file password source. For more information about the format of B<arg>
+see the B<PASS PHRASE ARGUMENTS> section in L<openssl(1)|openssl(1)>.
+
+=item B<-out filename>
+
+This specifies the output filename to write a key to or standard output by
+is not specified. If any encryption options are set then a pass phrase will be
+prompted for. The output filename should B<not> be the same as the input
+filename.
+
+=item B<-passout arg>
+
+the output file password source. For more information about the format of B<arg>
+see the B<PASS PHRASE ARGUMENTS> section in L<openssl(1)|openssl(1)>.
+
+=item B<-des|-des3|-idea>
+
+These options encrypt the private key with the DES, triple DES, IDEA or 
+any other cipher supported by OpenSSL before outputting it. A pass phrase is
+prompted for.
+If none of these options is specified the key is written in plain text. This
+means that using the B<ec> utility to read in an encrypted key with no
+encryption option can be used to remove the pass phrase from a key, or by
+setting the encryption options it can be use to add or change the pass phrase.
+These options can only be used with PEM format output files.
+
+=item B<-text>
+
+prints out the public, private key components and parameters.
+
+=item B<-noout>
+
+this option prevents output of the encoded version of the key.
+
+=item B<-modulus>
+
+this option prints out the value of the public key component of the key.
+
+=item B<-pubin>
+
+by default a private key is read from the input file: with this option a
+public key is read instead.
+
+=item B<-pubout>
+
+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<-conv_form>
+
+This specifies how the points on the elliptic curve are converted
+into octet strings. Possible values are: B<compressed> (the default
+value), B<uncompressed> and B<hybrid>. For more information regarding
+the point conversion forms please read the X9.62 standard.
+B<Note> Due to patent issues the B<compressed> option is disabled
+by default for binary curves and can be enabled by defining
+the preprocessor macro B<OPENSSL_EC_BIN_PT_COMP> at compile time.
+
+=item B<-param_enc arg>
+
+This specifies how the elliptic curve parameters are encoded.
+Possible value are: B<named_curve>, i.e. the ec parameters are
+specified by a OID, or B<explicit> where the ec parameters are
+explicitly given (see RFC 3279 for the definition of the 
+EC parameters structures). The default value is B<named_curve>.
+B<Note> the B<implicitlyCA> alternative ,as specified in RFC 3279,
+is currently not implemented in OpenSSL.
+
+=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
+
+The PEM private key format uses the header and footer lines:
+
+ -----BEGIN EC PRIVATE KEY-----
+ -----END EC PRIVATE KEY-----
+
+The PEM public key format uses the header and footer lines:
+
+ -----BEGIN PUBLIC KEY-----
+ -----END PUBLIC KEY-----
+
+=head1 EXAMPLES
+
+To encrypt a private key using triple DES:
+
+ openssl ec -in key.pem -des3 -out keyout.pem
+
+To convert a private key from PEM to DER format: 
+
+ openssl ec -in key.pem -outform DER -out keyout.der
+
+To print out the components of a private key to standard output:
+
+ openssl ec -in key.pem -text -noout
+
+To just output the public part of a private key:
+
+ openssl ec -in key.pem -pubout -out pubkey.pem
+
+To change the parameters encoding to B<explicit>:
+
+ openssl ec -in key.pem -param_enc explicit -out keyout.pem
+
+To change the point conversion form to B<compressed>:
+
+ openssl ec -in key.pem -conv_form compressed -out keyout.pem
+
+=head1 SEE ALSO
+
+L<ecparam(1)|ecparam(1)>, L<dsa(1)|dsa(1)>, L<rsa(1)|rsa(1)>
+
+=head1 HISTORY
+
+The ec command was first introduced in OpenSSL 0.9.8.
+
+=head1 AUTHOR
+
+Nils Larsch for the OpenSSL project (http://www.openssl.org).
+
+=cut
diff --git a/src/lib/libssl/src/doc/apps/ecparam.pod b/src/lib/libssl/src/doc/apps/ecparam.pod
new file mode 100644
index 0000000000..1a12105da7
--- /dev/null
+++ b/src/lib/libssl/src/doc/apps/ecparam.pod
@@ -0,0 +1,179 @@
+=pod
+
+=head1 NAME
+
+ecparam - EC parameter manipulation and generation
+
+=head1 SYNOPSIS
+
+B<openssl ecparam>
+[B<-inform DER|PEM>]
+[B<-outform DER|PEM>]
+[B<-in filename>]
+[B<-out filename>]
+[B<-noout>]
+[B<-text>]
+[B<-C>]
+[B<-check>]
+[B<-name arg>]
+[B<-list_curve>]
+[B<-conv_form arg>]
+[B<-param_enc arg>]
+[B<-no_seed>]
+[B<-rand file(s)>]
+[B<-genkey>]
+[B<-engine id>]
+
+=head1 DESCRIPTION
+
+This command is used to manipulate or generate EC parameter files.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<-inform DER|PEM>
+
+This specifies the input format. The B<DER> option uses an ASN.1 DER encoded
+form compatible with RFC 3279 EcpkParameters. The PEM form is the default
+format: it consists of the B<DER> format base64 encoded with additional 
+header and footer lines.
+
+=item B<-outform DER|PEM>
+
+This specifies the output format, the options have the same meaning as the 
+B<-inform> option.
+
+=item B<-in filename>
+
+This specifies the input filename to read parameters from or standard input if
+this option is not specified.
+
+=item B<-out filename>
+
+This specifies the output filename parameters to. Standard output is used
+if this option is not present. The output filename should B<not> be the same
+as the input filename.
+
+=item B<-noout>
+
+This option inhibits the output of the encoded version of the parameters.
+
+=item B<-text>
+
+This option prints out the EC parameters in human readable form.
+
+=item B<-C>
+
+This option converts the EC parameters into C code. The parameters can then
+be loaded by calling the B<get_ec_group_XXX()> function.
+
+=item B<-check>
+
+Validate the elliptic curve parameters.
+
+=item B<-name arg>
+
+Use the EC parameters with the specified 'short' name. Use B<-list_curves>
+to get a list of all currently implemented EC parameters.
+
+=item B<-list_curves>
+
+If this options is specified B<ecparam> will print out a list of all
+currently implemented EC parameters names and exit.
+
+=item B<-conv_form>
+
+This specifies how the points on the elliptic curve are converted
+into octet strings. Possible values are: B<compressed> (the default
+value), B<uncompressed> and B<hybrid>. For more information regarding
+the point conversion forms please read the X9.62 standard.
+B<Note> Due to patent issues the B<compressed> option is disabled
+by default for binary curves and can be enabled by defining
+the preprocessor macro B<OPENSSL_EC_BIN_PT_COMP> at compile time.
+
+=item B<-param_enc arg>
+
+This specifies how the elliptic curve parameters are encoded.
+Possible value are: B<named_curve>, i.e. the ec parameters are
+specified by a OID, or B<explicit> where the ec parameters are
+explicitly given (see RFC 3279 for the definition of the 
+EC parameters structures). The default value is B<named_curve>.
+B<Note> the B<implicitlyCA> alternative ,as specified in RFC 3279,
+is currently not implemented in OpenSSL.
+
+=item B<-no_seed>
+
+This option inhibits that the 'seed' for the parameter generation
+is included in the ECParameters structure (see RFC 3279).
+
+=item B<-genkey>
+
+This option will generate a EC private key using the specified parameters.
+
+=item B<-rand file(s)>
+
+a file or files containing random data used to seed the random number
+generator, or an EGD socket (see L<RAND_egd(3)|RAND_egd(3)>).
+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.
+
+=back
+
+=head1 NOTES
+
+PEM format EC parameters use the header and footer lines:
+
+ -----BEGIN EC PARAMETERS-----
+ -----END EC PARAMETERS-----
+
+OpenSSL is currently not able to generate new groups and therefore
+B<ecparam> can only create EC parameters from known (named) curves. 
+
+=head1 EXAMPLES
+
+To create EC parameters with the group 'prime192v1':
+
+  openssl ecparam -out ec_param.pem -name prime192v1
+
+To create EC parameters with explicit parameters:
+
+  openssl ecparam -out ec_param.pem -name prime192v1 -param_enc explicit
+
+To validate given EC parameters:
+
+  openssl ecparam -in ec_param.pem -check
+
+To create EC parameters and a private key:
+
+  openssl ecparam -out ec_key.pem -name prime192v1 -genkey
+
+To change the point encoding to 'compressed':
+
+  openssl ecparam -in ec_in.pem -out ec_out.pem -conv_form compressed
+
+To print out the EC parameters to standard output:
+
+  openssl ecparam -in ec_param.pem -noout -text
+
+=head1 SEE ALSO
+
+L<ec(1)|ec(1)>, L<dsaparam(1)|dsaparam(1)>
+
+=head1 HISTORY
+
+The ecparam command was first introduced in OpenSSL 0.9.8.
+
+=head1 AUTHOR
+
+Nils Larsch for the OpenSSL project (http://www.openssl.org)
+
+=cut
diff --git a/src/lib/libssl/src/doc/apps/x509v3_config.pod b/src/lib/libssl/src/doc/apps/x509v3_config.pod
new file mode 100644
index 0000000000..38c46e85c4
--- /dev/null
+++ b/src/lib/libssl/src/doc/apps/x509v3_config.pod
@@ -0,0 +1,456 @@
+=pod
+
+=for comment openssl_manual_section:5
+
+=head1 NAME
+
+x509v3_config - X509 V3 certificate extension configuration format
+
+=head1 DESCRIPTION
+
+Several of the OpenSSL utilities can add extensions to a certificate or
+certificate request based on the contents of a configuration file.
+
+Typically the application will contain an option to point to an extension
+section. Each line of the extension section takes the form:
+
+ extension_name=[critical,] extension_options
+
+If B<critical> is present then the extension will be critical.
+
+The format of B<extension_options> depends on the value of B<extension_name>.
+
+There are four main types of extension: I<string> extensions, I<multi-valued>
+extensions, I<raw> and I<arbitrary> extensions.
+
+String extensions simply have a string which contains either the value itself
+or how it is obtained.
+
+For example:
+
+ nsComment="This is a Comment"
+
+Multi-valued extensions have a short form and a long form. The short form
+is a list of names and values:
+
+ basicConstraints=critical,CA:true,pathlen:1
+
+The long form allows the values to be placed in a separate section:
+
+ basicConstraints=critical,@bs_section
+
+ [bs_section]
+
+ CA=true
+ pathlen=1
+
+Both forms are equivalent.
+
+The syntax of raw extensions is governed by the extension code: it can
+for example contain data in multiple sections. The correct syntax to
+use is defined by the extension code itself: check out the certificate
+policies extension for an example.
+
+If an extension type is unsupported then the I<arbitrary> extension syntax
+must be used, see the L<ARBITRART EXTENSIONS|/"ARBITRARY EXTENSIONS"> section for more details.
+
+=head1 STANDARD EXTENSIONS
+
+The following sections describe each supported extension in detail.
+
+=head2 Basic Constraints.
+
+This is a multi valued extension which indicates whether a certificate is
+a CA certificate. The first (mandatory) name is B<CA> followed by B<TRUE> or
+B<FALSE>. If B<CA> is B<TRUE> then an optional B<pathlen> name followed by an
+non-negative value can be included.
+
+For example:
+
+ basicConstraints=CA:TRUE
+
+ basicConstraints=CA:FALSE
+
+ basicConstraints=critical,CA:TRUE, pathlen:0
+
+A CA certificate B<must> include the basicConstraints value with the CA field
+set to TRUE. An end user certificate must either set CA to FALSE or exclude the
+extension entirely. Some software may require the inclusion of basicConstraints
+with CA set to FALSE for end entity certificates.
+
+The pathlen parameter indicates the maximum number of CAs that can appear
+below this one in a chain. So if you have a CA with a pathlen of zero it can
+only be used to sign end user certificates and not further CAs.
+
+
+=head2 Key Usage.
+
+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,
+dataEncipherment, keyAgreement, keyCertSign, cRLSign, encipherOnly
+and decipherOnly.
+
+Examples:
+
+ keyUsage=digitalSignature, nonRepudiation
+
+ keyUsage=critical, keyCertSign
+
+
+=head2 Extended Key Usage.
+
+This extensions consists of a list of usages indicating purposes for which
+the certificate public key can be used for,
+
+These can either be object short names of the dotted numerical form of OIDs.
+While any OID can be used only certain values make sense. In particular the
+following PKIX, NS and MS values are meaningful:
+
+ Value                  Meaning
+ -----                  -------
+ serverAuth             SSL/TLS Web Server Authentication.
+ clientAuth             SSL/TLS Web Client Authentication.
+ codeSigning            Code signing.
+ emailProtection        E-mail Protection (S/MIME).
+ timeStamping           Trusted Timestamping
+ msCodeInd              Microsoft Individual Code Signing (authenticode)
+ msCodeCom              Microsoft Commercial Code Signing (authenticode)
+ msCTLSign              Microsoft Trust List Signing
+ msSGC                  Microsoft Server Gated Crypto
+ msEFS                  Microsoft Encrypted File System
+ nsSGC                  Netscape Server Gated Crypto
+
+Examples:
+
+ extendedKeyUsage=critical,codeSigning,1.2.3.4
+ extendedKeyUsage=nsSGC,msSGC
+
+
+=head2 Subject Key Identifier.
+
+This is really a string extension and can take two possible values. Either
+the word B<hash> which will automatically follow the guidelines in RFC3280
+or a hex string giving the extension value to include. The use of the hex
+string is strongly discouraged.
+
+Example:
+
+ subjectKeyIdentifier=hash
+
+
+=head2 Authority Key Identifier.
+
+The authority key identifier extension permits two options. keyid and issuer:
+both can take the optional value "always".
+
+If the keyid option is present an attempt is made to copy the subject key
+identifier from the parent certificate. If the value "always" is present
+then an error is returned if the option fails.
+
+The issuer option copies the issuer and serial number from the issuer
+certificate. This will only be done if the keyid option fails or
+is not included unless the "always" flag will always include the value.
+
+Example:
+
+ authorityKeyIdentifier=keyid,issuer
+
+
+=head2 Subject Alternative Name.
+
+The subject alternative name extension allows various literal values to be
+included in the configuration file. These include B<email> (an email address)
+B<URI> a uniform resource indicator, B<DNS> (a DNS domain name), B<RID> (a
+registered ID: OBJECT IDENTIFIER), B<IP> (an IP address), B<dirName>
+(a distinguished name) and otherName.
+
+The email option include a special 'copy' value. This will automatically
+include and email addresses contained in the certificate subject name in
+the extension.
+
+The IP address used in the B<IP> options can be in either IPv4 or IPv6 format.
+
+The value of B<dirName> should point to a section containing the distinguished
+name to use as a set of name value pairs. Multi values AVAs can be formed by
+preceeding the name with a B<+> character.
+
+otherName can include arbitrary data associated with an OID: the value
+should be the OID followed by a semicolon and the content in standard
+ASN1_generate_nconf() format.
+
+Examples:
+
+ subjectAltName=email:copy,email:my@other.address,URI:http://my.url.here/
+ subjectAltName=IP:192.168.7.1
+ subjectAltName=IP:13::17
+ subjectAltName=email:my@other.address,RID:1.2.3.4
+ subjectAltName=otherName:1.2.3.4;UTF8:some other identifier
+
+ subjectAltName=dirName:dir_sect
+
+ [dir_sect]
+ C=UK
+ O=My Organization
+ OU=My Unit
+ CN=My Name
+
+
+=head2 Issuer Alternative Name.
+
+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 
+certificate (if possible).
+
+Example:
+
+ issuserAltName = issuer:copy
+
+
+=head2 Authority Info Access.
+
+The authority information access extension gives details about how to access
+certain information relating to the CA. Its syntax is accessOID;location
+where I<location> has the same syntax as subject alternative name (except
+that email:copy is not supported). accessOID can be any valid OID but only
+certain values are meaningful, for example OCSP and caIssuers.
+
+Example:
+
+ authorityInfoAccess = OCSP;URI:http://ocsp.my.host/
+ authorityInfoAccess = caIssuers;URI:http://my.ca/ca.html
+
+
+=head2 CRL distribution points.
+
+This is a multi-valued extension that supports all the literal options of
+subject alternative name. Of the few software packages that currently interpret
+this extension most only interpret the URI option.
+
+Currently each option will set a new DistributionPoint with the fullName
+field set to the given value.
+
+Other fields like cRLissuer and reasons cannot currently be set or displayed:
+at this time no examples were available that used these fields.
+
+Examples:
+
+ crlDistributionPoints=URI:http://myhost.com/myca.crl
+ crlDistributionPoints=URI:http://my.com/my.crl,URI:http://oth.com/my.crl
+
+=head2 Certificate Policies.
+
+This is a I<raw> extension. All the fields of this extension can be set by
+using the appropriate syntax.
+
+If you follow the PKIX recommendations and just using one OID then you just
+include the value of that OID. Multiple OIDs can be set separated by commas,
+for example:
+
+ certificatePolicies= 1.2.4.5, 1.1.3.4
+
+If you wish to include qualifiers then the policy OID and qualifiers need to
+be specified in a separate section: this is done by using the @section syntax
+instead of a literal OID value.
+
+The section referred to must include the policy OID using the name
+policyIdentifier, cPSuri qualifiers can be included using the syntax:
+
+ CPS.nnn=value
+
+userNotice qualifiers can be set using the syntax:
+
+ userNotice.nnn=@notice
+
+The value of the userNotice qualifier is specified in the relevant section.
+This section can include explicitText, organization and noticeNumbers
+options. explicitText and organization are text strings, noticeNumbers is a
+comma separated list of numbers. The organization and noticeNumbers options
+(if included) must BOTH be present. If you use the userNotice option with IE5
+then you need the 'ia5org' option at the top level to modify the encoding:
+otherwise it will not be interpreted properly.
+
+Example:
+
+ certificatePolicies=ia5org,1.2.3.4,1.5.6.7.8,@polsect
+
+ [polsect]
+
+ policyIdentifier = 1.3.5.8
+ CPS.1="http://my.host.name/"
+ CPS.2="http://my.your.name/"
+ userNotice.1=@notice
+
+ [notice]
+
+ explicitText="Explicit Text Here"
+ organization="Organisation Name"
+ noticeNumbers=1,2,3,4
+
+The B<ia5org> option changes the type of the I<organization> field. In RFC2459
+it can only be of type DisplayText. In RFC3280 IA5Strring is also permissible.
+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
+value. At least one component must be present.
+
+Example:
+
+ policyConstraints = requireExplicitPolicy:3
+
+
+=head2 Inhibit Any Policy
+
+This is a string extension whose value must be a non negative integer.
+
+Example:
+
+ inhibitAnyPolicy = 2
+
+
+=head2 Name Constraints
+
+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 
+subnet mask separated by a B</>.
+
+Examples:
+
+ nameConstraints=permitted;IP:192.168.0.0/255.255.0.0
+
+ nameConstraints=permitted;email:.somedomain.com
+
+ nameConstraints=excluded;email:.com
+
+=head1 DEPRECATED EXTENSIONS
+
+The following extensions are non standard, Netscape specific and largely
+obsolete. Their use in new applications is discouraged.
+
+=head2 Netscape String extensions.
+
+Netscape Comment (B<nsComment>) is a string extension containing a comment
+which will be displayed when the certificate is viewed in some browsers.
+
+Example:
+
+ nsComment = "Some Random Comment"
+
+Other supported extensions in this category are: B<nsBaseUrl>,
+B<nsRevocationUrl>, B<nsCaRevocationUrl>, B<nsRenewalUrl>, B<nsCaPolicyUrl>
+and B<nsSslServerName>.
+
+
+=head2 Netscape Certificate Type
+
+This is a multi-valued extensions which consists of a list of flags to be
+included. It was used to indicate the purposes for which a certificate could
+be used. The basicConstraints, keyUsage and extended key usage extensions are
+now used instead.
+
+Acceptable values for nsCertType are: B<client>, B<server>, B<email>,
+B<objsign>, B<reserved>, B<sslCA>, B<emailCA>, B<objCA>.
+
+
+=head1 ARBITRARY EXTENSIONS
+
+If an extension is not supported by the OpenSSL code then it must be encoded
+using the arbitrary extension format. It is also possible to use the arbitrary
+format for supported extensions. Extreme care should be taken to ensure that
+the data is formatted correctly for the given extension type.
+
+There are two ways to encode arbitrary extensions.
+
+The first way is to use the word ASN1 followed by the extension content
+using the same syntax as ASN1_generate_nconf(). For example:
+
+ 1.2.3.4=critical,ASN1:UTF8String:Some random data
+
+ 1.2.3.4=ASN1:SEQUENCE:seq_sect
+
+ [seq_sect]
+
+ field1 = UTF8:field1
+ field2 = UTF8:field2
+
+It is also possible to use the word DER to include the raw encoded data in any
+extension.
+
+ 1.2.3.4=critical,DER:01:02:03:04
+ 1.2.3.4=DER:01020304
+
+The value following DER is a hex dump of the DER encoding of the extension
+Any extension can be placed in this form to override the default behaviour.
+For example:
+
+ basicConstraints=critical,DER:00:01:02:03
+
+=head1 WARNING
+
+There is no guarantee that a specific implementation will process a given
+extension. It may therefore be sometimes possible to use certificates for
+purposes prohibited by their extensions because a specific application does
+not recognize or honour the values of the relevant extensions.
+
+The DER and ASN1 options should be used with caution. It is possible to create
+totally invalid extensions if they are not used carefully.
+
+
+=head1 NOTES
+
+If an extension is multi-value and a field value must contain a comma the long
+form must be used otherwise the comma would be misinterpreted as a field
+separator. For example:
+
+ subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar
+
+will produce an error but the equivalent form:
+
+ subjectAltName=@subject_alt_section
+
+ [subject_alt_section]
+ subjectAltName=URI:ldap://somehost.com/CN=foo,OU=bar
+
+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:
+
+ subjectAltName=@alt_section
+
+ [alt_section]
+
+ email=steve@here
+ email=steve@there
+
+will only recognize the last value. This can be worked around by using the form:
+
+ [alt_section]
+
+ email.1=steve@here
+ email.2=steve@there
+
+=head1 HISTORY
+
+The X509v3 extension code was first added to OpenSSL 0.9.2.
+
+Policy mappings, inhibit any policy and name constraints support was added in
+OpenSSL 0.9.8
+
+The B<directoryName> and B<otherName> option as well as the B<ASN1> option
+for arbitrary extensions was added in OpenSSL 0.9.8
+
+=head1 SEE ALSO
+
+L<req(1)|req(1)>, L<ca(1)|ca(1)>, L<x509(1)|x509(1)>
+
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/ASN1_generate_nconf.pod b/src/lib/libssl/src/doc/crypto/ASN1_generate_nconf.pod
new file mode 100644
index 0000000000..1157cff510
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/ASN1_generate_nconf.pod
@@ -0,0 +1,262 @@
+=pod
+
+=head1 NAME
+
+ASN1_generate_nconf, ASN1_generate_v3 - ASN1 generation functions
+
+=head1 SYNOPSIS
+
+ ASN1_TYPE *ASN1_generate_nconf(char *str, CONF *nconf);
+ ASN1_TYPE *ASN1_generate_v3(char *str, X509V3_CTX *cnf);
+
+=head1 DESCRIPTION
+
+These functions generate the ASN1 encoding of a string
+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
+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.
+
+=head1 GENERATION STRING FORMAT
+
+The actual data encoded is determined by the string B<str> and
+the configuration information. The general format of the string
+is:
+
+=over 2
+
+=item B<[modifier,]type[:value]>
+
+=back
+
+That is zero or more comma separated modifiers followed by a type
+followed by an optional colon and a value. The formats of B<type>,
+B<value> and B<modifier> are explained below.
+
+=head2 SUPPORTED TYPES
+
+The supported types are listed below. Unless otherwise specified
+only the B<ASCII> format is permissible.
+
+=over 2
+
+=item B<BOOLEAN>, B<BOOL>
+
+This encodes a boolean type. The B<value> string is mandatory and
+should be B<TRUE> or B<FALSE>. Additionally B<TRUE>, B<true>, B<Y>,
+B<y>, B<YES>, B<yes>, B<FALSE>, B<false>, B<N>, B<n>, B<NO> and B<no>
+are acceptable. 
+
+=item B<NULL>
+
+Encode the B<NULL> type, the B<value> string must not be present.
+
+=item B<INTEGER>, B<INT>
+
+Encodes an ASN1 B<INTEGER> type. The B<value> string represents
+the value of the integer, it can be preceeded by a minus sign and
+is normally interpreted as a decimal value unless the prefix B<0x>
+is included.
+
+=item B<ENUMERATED>, B<ENUM>
+
+Encodes the ASN1 B<ENUMERATED> type, it is otherwise identical to
+B<INTEGER>.
+
+=item B<OBJECT>, B<OID>
+
+Encodes an ASN1 B<OBJECT IDENTIFIER>, the B<value> string can be
+a short name, a long name or numerical format.
+
+=item B<UTCTIME>, B<UTC>
+
+Encodes an ASN1 B<UTCTime> structure, the value should be in
+the format B<YYMMDDHHMMSSZ>. 
+
+=item B<GENERALIZEDTIME>, B<GENTIME>
+
+Encodes an ASN1 B<GeneralizedTime> structure, the value should be in
+the format B<YYYYMMDDHHMMSSZ>. 
+
+=item B<OCTETSTRING>, B<OCT>
+
+Encodes an ASN1 B<OCTET STRING>. B<value> represents the contents
+of this structure, the format strings B<ASCII> and B<HEX> can be
+used to specify the format of B<value>.
+
+=item B<BITSTRING>, B<BITSTR>
+
+Encodes an ASN1 B<BIT STRING>. B<value> represents the contents
+of this structure, the format strings B<ASCII>, B<HEX> and B<BITLIST>
+can be used to specify the format of B<value>.
+
+If the format is anything other than B<BITLIST> the number of unused
+bits is set to zero.
+
+=item B<UNIVERSALSTRING>, B<UNIV>, B<IA5>, B<IA5STRING>, B<UTF8>,
+B<UTF8String>, B<BMP>, B<BMPSTRING>, B<VISIBLESTRING>,
+B<VISIBLE>, B<PRINTABLESTRING>, B<PRINTABLE>, B<T61>,
+B<T61STRING>, B<TELETEXSTRING>, B<GeneralString>
+
+These encode the corresponding string types. B<value> represents the
+contents of this structure. The format can be B<ASCII> or B<UTF8>.
+
+=item B<SEQUENCE>, B<SEQ>, B<SET>
+
+Formats the result as an ASN1 B<SEQUENCE> or B<SET> type. B<value>
+should be a section name which will contain the contents. The
+field names in the section are ignored and the values are in the
+generated string format. If B<value> is absent then an empty SEQUENCE
+will be encoded.
+
+=back
+
+=head2 MODIFIERS
+
+Modifiers affect the following structure, they can be used to
+add EXPLICIT or IMPLICIT tagging, add wrappers or to change
+the string format of the final type and value. The supported
+formats are documented below.
+
+=over 2
+
+=item B<EXPLICIT>, B<EXP>
+
+Add an explicit tag to the following structure. This string
+should be followed by a colon and the tag value to use as a
+decimal value.
+
+By following the number with B<U>, B<A>, B<P> or B<C> UNIVERSAL,
+APPLICATION, PRIVATE or CONTEXT SPECIFIC tagging can be used,
+the default is CONTEXT SPECIFIC.
+
+=item B<IMPLICIT>, B<IMP>
+
+This is the same as B<EXPLICIT> except IMPLICIT tagging is used
+instead.
+
+=item B<OCTWRAP>, B<SEQWRAP>, B<SETWRAP>, B<BITWRAP>
+
+The following structure is surrounded by an OCTET STRING, a SEQUENCE,
+a SET or a BIT STRING respectively. For a BIT STRING the number of unused
+bits is set to zero.
+
+=item B<FORMAT>
+
+This specifies the format of the ultimate value. It should be followed
+by a colon and one of the strings B<ASCII>, B<UTF8>, B<HEX> or B<BITLIST>.
+
+If no format specifier is included then B<ASCII> is used. If B<UTF8> is
+specified then the value string must be a valid B<UTF8> string. For B<HEX> the
+output must be a set of hex digits. B<BITLIST> (which is only valid for a BIT
+STRING) is a comma separated list of the indices of the set bits, all other
+bits are zero.
+
+=back
+
+=head1 EXAMPLES
+
+A simple IA5String:
+
+ IA5STRING:Hello World
+
+An IA5String explicitly tagged:
+
+ EXPLICIT:0,IA5STRING:Hello World
+
+An IA5String explicitly tagged using APPLICATION tagging:
+
+ EXPLICIT:0A,IA5STRING:Hello World
+
+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:
+
+ asn1 = SEQUENCE:seq_section
+
+ [seq_section]
+
+ field1 = BOOLEAN:TRUE
+ field2 = OID:commonName
+ field3 = UTF8:Third field
+
+This example produces an RSAPrivateKey structure, this is the
+key contained in the file client.pem in all OpenSSL distributions
+(note: the field names such as 'coeff' are ignored and are present just
+for clarity):
+
+ asn1=SEQUENCE:private_key
+ [private_key]
+ version=INTEGER:0
+
+ n=INTEGER:0xBB6FE79432CC6EA2D8F970675A5A87BFBE1AFF0BE63E879F2AFFB93644\
+ D4D2C6D000430DEC66ABF47829E74B8C5108623A1C0EE8BE217B3AD8D36D5EB4FCA1D9
+
+ e=INTEGER:0x010001
+
+ d=INTEGER:0x6F05EAD2F27FFAEC84BEC360C4B928FD5F3A9865D0FCAAD291E2A52F4A\
+ F810DC6373278C006A0ABBA27DC8C63BF97F7E666E27C5284D7D3B1FFFE16B7A87B51D
+
+ p=INTEGER:0xF3929B9435608F8A22C208D86795271D54EBDFB09DDEF539AB083DA912\
+ D4BD57
+
+ q=INTEGER:0xC50016F89DFF2561347ED1186A46E150E28BF2D0F539A1594BBD7FE467\
+ 46EC4F
+
+ exp1=INTEGER:0x9E7D4326C924AFC1DEA40B45650134966D6F9DFA3A7F9D698CD4ABEA\
+ 9C0A39B9
+
+ exp2=INTEGER:0xBA84003BB95355AFB7C50DF140C60513D0BA51D637272E355E397779\
+ E7B2458F
+
+ coeff=INTEGER:0x30B9E4F2AFA5AC679F920FC83F1F2DF1BAF1779CF989447FABC2F5\
+ 628657053A
+
+This example is the corresponding public key in a SubjectPublicKeyInfo
+structure:
+
+ # Start with a SEQUENCE
+ asn1=SEQUENCE:pubkeyinfo
+
+ # pubkeyinfo contains an algorithm identifier and the public key wrapped
+ # in a BIT STRING
+ [pubkeyinfo]
+ algorithm=SEQUENCE:rsa_alg
+ pubkey=BITWRAP,SEQUENCE:rsapubkey
+
+ # algorithm ID for RSA is just an OID and a NULL
+ [rsa_alg]
+ algorithm=OID:rsaEncryption
+ parameter=NULL
+
+ # Actual public key: modulus and exponent
+ [rsapubkey]
+ n=INTEGER:0xBB6FE79432CC6EA2D8F970675A5A87BFBE1AFF0BE63E879F2AFFB93644\
+ D4D2C6D000430DEC66ABF47829E74B8C5108623A1C0EE8BE217B3AD8D36D5EB4FCA1D9
+
+ e=INTEGER:0x010001
+
+=head1 RETURN VALUES
+
+ASN1_generate_nconf() and ASN1_generate_v3() return the encoded
+data as an B<ASN1_TYPE> structure or B<NULL> if an error occurred.
+
+The error codes that 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
+
+ASN1_generate_nconf() and ASN1_generate_v3() were added to OpenSSL 0.9.8
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/BN_BLINDING_new.pod b/src/lib/libssl/src/doc/crypto/BN_BLINDING_new.pod
new file mode 100644
index 0000000000..7b087f7288
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/BN_BLINDING_new.pod
@@ -0,0 +1,109 @@
+=pod
+
+=head1 NAME
+
+BN_BLINDING_new, BN_BLINDING_free, BN_BLINDING_update, BN_BLINDING_convert, 
+BN_BLINDING_invert, BN_BLINDING_convert_ex, BN_BLINDING_invert_ex, 
+BN_BLINDING_get_thread_id, BN_BLINDING_set_thread_id, BN_BLINDING_get_flags,
+BN_BLINDING_set_flags, BN_BLINDING_create_param - blinding related BIGNUM
+functions.
+
+=head1 SYNOPSIS
+
+ #include <openssl/bn.h>
+
+ BN_BLINDING *BN_BLINDING_new(const BIGNUM *A, const BIGNUM *Ai,
+        BIGNUM *mod);
+ void BN_BLINDING_free(BN_BLINDING *b);
+ int BN_BLINDING_update(BN_BLINDING *b,BN_CTX *ctx);
+ int BN_BLINDING_convert(BIGNUM *n, BN_BLINDING *b, BN_CTX *ctx);
+ int BN_BLINDING_invert(BIGNUM *n, BN_BLINDING *b, BN_CTX *ctx);
+ int BN_BLINDING_convert_ex(BIGNUM *n, BIGNUM *r, BN_BLINDING *b,
+        BN_CTX *ctx);
+ int BN_BLINDING_invert_ex(BIGNUM *n, const BIGNUM *r, BN_BLINDING *b,
+        BN_CTX *ctx);
+ unsigned long BN_BLINDING_get_thread_id(const BN_BLINDING *);
+ void BN_BLINDING_set_thread_id(BN_BLINDING *, unsigned long);
+ unsigned long BN_BLINDING_get_flags(const BN_BLINDING *);
+ void BN_BLINDING_set_flags(BN_BLINDING *, unsigned long);
+ BN_BLINDING *BN_BLINDING_create_param(BN_BLINDING *b,
+        const BIGNUM *e, BIGNUM *m, BN_CTX *ctx,
+        int (*bn_mod_exp)(BIGNUM *r, const BIGNUM *a, const BIGNUM *p,
+                          const BIGNUM *m, BN_CTX *ctx, BN_MONT_CTX *m_ctx),
+        BN_MONT_CTX *m_ctx);
+
+=head1 DESCRIPTION
+
+BN_BLINDING_new() allocates a new B<BN_BLINDING> structure and copies
+the B<A> and B<Ai> values into the newly created B<BN_BLINDING> object.
+
+BN_BLINDING_free() frees the B<BN_BLINDING> structure.
+
+BN_BLINDING_update() updates the B<BN_BLINDING> parameters by squaring
+the B<A> and B<Ai> or, after specific number of uses and if the
+necessary parameters are set, by re-creating the blinding parameters.
+
+BN_BLINDING_convert_ex() multiplies B<n> with the blinding factor B<A>.
+If B<r> is not NULL a copy the inverse blinding factor B<Ai> will be
+returned in B<r> (this is useful if a B<RSA> object is shared amoung
+several threads). BN_BLINDING_invert_ex() multiplies B<n> with the
+inverse blinding factor B<Ai>. If B<r> is not NULL it will be used as
+the inverse blinding.
+
+BN_BLINDING_convert() and BN_BLINDING_invert() are wrapper
+functions for BN_BLINDING_convert_ex() and BN_BLINDING_invert_ex()
+with B<r> set to NULL.
+
+BN_BLINDING_set_thread_id() and BN_BLINDING_get_thread_id()
+set and get the "thread id" value of the B<BN_BLINDING> structure,
+a field provided to users of B<BN_BLINDING> structure to help them
+provide proper locking if needed for multi-threaded use. The 
+"thread id" of a newly allocated B<BN_BLINDING> structure is zero.
+
+BN_BLINDING_get_flags() returns the BN_BLINDING flags. Currently
+there are two supported flags: B<BN_BLINDING_NO_UPDATE> and
+B<BN_BLINDING_NO_RECREATE>. B<BN_BLINDING_NO_UPDATE> inhibits the
+automatic update of the B<BN_BLINDING> parameters after each use
+and B<BN_BLINDING_NO_RECREATE> inhibits the automatic re-creation
+of the B<BN_BLINDING> parameters after a fixed number of uses (currently
+32). In newly allocated B<BN_BLINDING> objects no flags are set.
+BN_BLINDING_set_flags() sets the B<BN_BLINDING> parameters flags.
+
+BN_BLINDING_create_param() creates new B<BN_BLINDING> parameters
+using the exponent B<e> and the modulus B<m>. B<bn_mod_exp> and
+B<m_ctx> can be used to pass special functions for exponentiation
+(normally BN_mod_exp_mont() and B<BN_MONT_CTX>).
+
+=head1 RETURN VALUES
+
+BN_BLINDING_new() returns the newly allocated B<BN_BLINDING> structure
+or NULL in case of an error.
+
+BN_BLINDING_update(), BN_BLINDING_convert(), BN_BLINDING_invert(),
+BN_BLINDING_convert_ex() and BN_BLINDING_invert_ex() return 1 on
+success and 0 if an error occured.
+
+BN_BLINDING_get_thread_id() returns the thread id (a B<unsigned long>
+value) or 0 if not set.
+
+BN_BLINDING_get_flags() returns the currently set B<BN_BLINDING> flags
+(a B<unsigned long> value).
+
+BN_BLINDING_create_param() returns the newly created B<BN_BLINDING> 
+parameters or NULL on error.
+
+=head1 SEE ALSO
+
+L<bn(3)|bn(3)>
+
+=head1 HISTORY
+
+BN_BLINDING_convert_ex, BN_BLINDIND_invert_ex, BN_BLINDING_get_thread_id,
+BN_BLINDING_set_thread_id, BN_BLINDING_set_flags, BN_BLINDING_get_flags
+and BN_BLINDING_create_param were first introduced in OpenSSL 0.9.8
+
+=head1 AUTHOR
+
+Nils Larsch for the OpenSSL project (http://www.openssl.org).
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/ERR_set_mark.pod b/src/lib/libssl/src/doc/crypto/ERR_set_mark.pod
new file mode 100644
index 0000000000..d3ca4f2e77
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/ERR_set_mark.pod
@@ -0,0 +1,38 @@
+=pod
+
+=head1 NAME
+
+ERR_set_mark, ERR_pop_to_mark - set marks and pop errors until mark
+
+=head1 SYNOPSIS
+
+ #include <openssl/err.h>
+
+ int ERR_set_mark(void);
+
+ int ERR_pop_to_mark(void);
+
+=head1 DESCRIPTION
+
+ERR_set_mark() sets a mark on the current topmost error record if there
+is one.
+
+ERR_pop_to_mark() will pop the top of the error stack until a mark is found.
+The mark is then removed.  If there is no mark, the whole stack is removed.
+
+=head1 RETURN VALUES
+
+ERR_set_mark() returns 0 if the error stack is empty, otherwise 1.
+
+ERR_pop_to_mark() returns 0 if there was no mark in the error stack, which
+implies that the stack became empty, otherwise 1.
+
+=head1 SEE ALSO
+
+L<err(3)|err(3)>
+
+=head1 HISTORY
+
+ERR_set_mark() and ERR_pop_to_mark() were added in OpenSSL 0.9.8.
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/OPENSSL_Applink.pod b/src/lib/libssl/src/doc/crypto/OPENSSL_Applink.pod
new file mode 100644
index 0000000000..e54de12cc8
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/OPENSSL_Applink.pod
@@ -0,0 +1,21 @@
+=pod
+
+=head1 NAME
+
+OPENSSL_Applink - glue between OpenSSL BIO and Win32 compiler run-time
+
+=head1 SYNOPSIS
+
+ __declspec(dllexport) void **OPENSSL_Applink();
+
+=head1 DESCRIPTION
+
+OPENSSL_Applink is application-side interface which provides a glue
+between OpenSSL BIO layer and Win32 compiler run-time environment.
+Even though it appears at application side, it's essentially OpenSSL
+private interface. For this reason application developers are not
+expected to implement it, but to compile provided module with
+compiler of their choice and link it into the target application.
+The referred module is available as <openssl>/ms/applink.c.
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/OPENSSL_ia32cap.pod b/src/lib/libssl/src/doc/crypto/OPENSSL_ia32cap.pod
new file mode 100644
index 0000000000..2e659d34a5
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/OPENSSL_ia32cap.pod
@@ -0,0 +1,43 @@
+=pod
+
+=head1 NAME
+
+OPENSSL_ia32cap - finding the IA-32 processor capabilities
+
+=head1 SYNOPSIS
+
+ unsigned long *OPENSSL_ia32cap_loc(void);
+ #define OPENSSL_ia32cap (*(OPENSSL_ia32cap_loc()))
+
+=head1 DESCRIPTION
+
+Value returned by OPENSSL_ia32cap_loc() is address of a variable
+containing IA-32 processor capabilities bit vector as it appears in EDX
+register after executing CPUID instruction with EAX=1 input value (see
+Intel Application Note #241618). Naturally it's meaningful on IA-32[E]
+platforms only. The variable is normally set up automatically upon
+toolkit initialization, but can be manipulated afterwards to modify
+crypto library behaviour. For the moment of this writing six bits are
+significant, namely:
+
+1. bit #28 denoting Hyperthreading, which is used to distiguish
+   cores with shared cache;
+2. bit #26 denoting SSE2 support;
+3. bit #25 denoting SSE support;
+4. bit #23 denoting MMX support;
+5. bit #20, reserved by Intel, is used to choose between RC4 code
+   pathes;
+6. bit #4 denoting presence of Time-Stamp Counter.
+
+For example, clearing bit #26 at run-time disables high-performance
+SSE2 code present in the crypto library. You might have to do this if
+target OpenSSL application is executed on SSE2 capable CPU, but under
+control of OS which does not support SSE2 extentions. Even though you
+can manipulate the value programmatically, you most likely will find it
+more appropriate to set up an environment variable with the same name
+prior starting target application, e.g. on Intel P4 processor 'env
+OPENSSL_ia32cap=0x12900010 apps/openssl', to achieve same effect
+without modifying the application source code. Alternatively you can
+reconfigure the toolkit with no-sse2 option and recompile.
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/ecdsa.pod b/src/lib/libssl/src/doc/crypto/ecdsa.pod
new file mode 100644
index 0000000000..49b10f2249
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/ecdsa.pod
@@ -0,0 +1,210 @@
+=pod
+
+=head1 NAME
+
+ecdsa - Elliptic Curve Digital Signature Algorithm
+
+=head1 SYNOPSIS
+
+ #include <openssl/ecdsa.h>
+
+ ECDSA_SIG*     ECDSA_SIG_new(void);
+ void           ECDSA_SIG_free(ECDSA_SIG *sig);
+ int            i2d_ECDSA_SIG(const ECDSA_SIG *sig, unsigned char **pp);
+ ECDSA_SIG*     d2i_ECDSA_SIG(ECDSA_SIG **sig, const unsigned char **pp, 
+                long len);
+
+ ECDSA_SIG*     ECDSA_do_sign(const unsigned char *dgst, int dgst_len,
+                        EC_KEY *eckey);
+ ECDSA_SIG*     ECDSA_do_sign_ex(const unsigned char *dgst, int dgstlen, 
+                        const BIGNUM *kinv, const BIGNUM *rp,
+                        EC_KEY *eckey);
+ int            ECDSA_do_verify(const unsigned char *dgst, int dgst_len,
+                        const ECDSA_SIG *sig, EC_KEY* eckey);
+ int            ECDSA_sign_setup(EC_KEY *eckey, BN_CTX *ctx,
+                        BIGNUM **kinv, BIGNUM **rp);
+ int            ECDSA_sign(int type, const unsigned char *dgst,
+                        int dgstlen, unsigned char *sig,
+                        unsigned int *siglen, EC_KEY *eckey);
+ int            ECDSA_sign_ex(int type, const unsigned char *dgst,
+                        int dgstlen, unsigned char *sig,
+                        unsigned int *siglen, const BIGNUM *kinv, 
+                        const BIGNUM *rp, EC_KEY *eckey);
+ int            ECDSA_verify(int type, const unsigned char *dgst,
+                        int dgstlen, const unsigned char *sig,
+                        int siglen, EC_KEY *eckey);
+ int            ECDSA_size(const EC_KEY *eckey);
+
+ const ECDSA_METHOD*    ECDSA_OpenSSL(void);
+ void           ECDSA_set_default_method(const ECDSA_METHOD *meth);
+ const ECDSA_METHOD*    ECDSA_get_default_method(void);
+ int            ECDSA_set_method(EC_KEY *eckey,const ECDSA_METHOD *meth);
+
+ int            ECDSA_get_ex_new_index(long argl, void *argp,
+                        CRYPTO_EX_new *new_func,
+                        CRYPTO_EX_dup *dup_func,
+                        CRYPTO_EX_free *free_func);
+ int            ECDSA_set_ex_data(EC_KEY *d, int idx, void *arg);
+ void*          ECDSA_get_ex_data(EC_KEY *d, int idx);
+
+=head1 DESCRIPTION
+
+The B<ECDSA_SIG> structure consists of two BIGNUMs for the
+r and s value of a ECDSA signature (see X9.62 or FIPS 186-2).
+
+ struct
+        {
+        BIGNUM *r;
+        BIGNUM *s;
+ } ECDSA_SIG;
+
+ECDSA_SIG_new() allocates a new B<ECDSA_SIG> structure (note: this
+function also allocates the BIGNUMs) and initialize it.
+
+ECDSA_SIG_free() frees the B<ECDSA_SIG> structure B<sig>.
+
+i2d_ECDSA_SIG() creates the DER encoding of the ECDSA signature
+B<sig> and writes the encoded signature to B<*pp> (note: if B<pp>
+is NULL B<i2d_ECDSA_SIG> returns the expected length in bytes of 
+the DER encoded signature). B<i2d_ECDSA_SIG> returns the length
+of the DER encoded signature (or 0 on error).
+
+d2i_ECDSA_SIG() decodes a DER encoded ECDSA signature and returns
+the decoded signature in a newly allocated B<ECDSA_SIG> structure.
+B<*sig> points to the buffer containing the DER encoded signature
+of size B<len>.
+
+ECDSA_size() returns the maximum length of a DER encoded
+ECDSA signature created with the private EC key B<eckey>.
+
+ECDSA_sign_setup() may be used to precompute parts of the
+signing operation. B<eckey> is the private EC key and B<ctx>
+is a pointer to B<BN_CTX> structure (or NULL). The precomputed
+values or returned in B<kinv> and B<rp> and can be used in a
+later call to B<ECDSA_sign_ex> or B<ECDSA_do_sign_ex>.
+
+ECDSA_sign() is wrapper function for ECDSA_sign_ex with B<kinv>
+and B<rp> set to NULL.
+
+ECDSA_sign_ex() computes a digital signature of the B<dgstlen> bytes
+hash value B<dgst> using the private EC key B<eckey> and the optional
+pre-computed values B<kinv> and B<rp>. The DER encoded signatures is
+stored in B<sig> and it's length is returned in B<sig_len>. Note: B<sig>
+must point to B<ECDSA_size> bytes of memory. The parameter B<type>
+is ignored.
+
+ECDSA_verify() verifies that the signature in B<sig> of size
+B<siglen> is a valid ECDSA signature of the hash value
+value B<dgst> of size B<dgstlen> using the public key B<eckey>.
+The parameter B<type> is ignored.
+
+ECDSA_do_sign() is wrapper function for ECDSA_do_sign_ex with B<kinv>
+and B<rp> set to NULL.
+
+ECDSA_do_sign_ex() computes a digital signature of the B<dgst_len>
+bytes hash value B<dgst> using the private key B<eckey> and the
+optional pre-computed values B<kinv> and B<rp>. The signature is
+returned in a newly allocated B<ECDSA_SIG> structure (or NULL on error).
+
+ECDSA_do_verify() verifies that the signature B<sig> is a valid
+ECDSA signature of the hash value B<dgst> of size B<dgst_len>
+using the public key B<eckey>.
+
+=head1 RETURN VALUES
+
+ECDSA_size() returns the maximum length signature or 0 on error.
+
+ECDSA_sign_setup() and ECDSA_sign() return 1 if successful or -1
+on error.
+
+ECDSA_verify() and ECDSA_do_verify() return 1 for a valid
+signature, 0 for an invalid signature and -1 on error.
+The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
+
+=head1 EXAMPLES
+
+Creating a ECDSA signature of given SHA-1 hash value using the
+named curve secp192k1.
+
+First step: create a EC_KEY object (note: this part is B<not> ECDSA
+specific)
+
+ int        ret;
+ ECDSA_SIG *sig;
+ EC_KEY    *eckey = EC_KEY_new();
+ if (eckey == NULL)
+        {
+        /* error */
+        }
+ key->group = EC_GROUP_new_by_nid(NID_secp192k1);
+ if (key->group == NULL)
+        {
+        /* error */
+        }
+ if (!EC_KEY_generate_key(eckey))
+        {
+        /* error */
+        }
+
+Second step: compute the ECDSA signature of a SHA-1 hash value 
+using B<ECDSA_do_sign> 
+
+ sig = ECDSA_do_sign(digest, 20, eckey);
+ if (sig == NULL)
+        {
+        /* error */
+        }
+
+or using B<ECDSA_sign>
+
+ unsigned char *buffer, *pp;
+ int            buf_len;
+ buf_len = ECDSA_size(eckey);
+ buffer  = OPENSSL_malloc(buf_len);
+ pp = buffer;
+ if (!ECDSA_sign(0, dgst, dgstlen, pp, &buf_len, eckey);
+        {
+        /* error */
+        }
+
+Third step: verify the created ECDSA signature using B<ECDSA_do_verify>
+
+ ret = ECDSA_do_verify(digest, 20, sig, eckey);
+
+or using B<ECDSA_verify>
+
+ ret = ECDSA_verify(0, digest, 20, buffer, buf_len, eckey);
+
+and finally evaluate the return value:
+
+ if (ret == -1)
+        {
+        /* error */
+        }
+ else if (ret == 0)
+        {
+        /* incorrect signature */
+        }
+ else   /* ret == 1 */
+        {
+        /* signature ok */
+        }
+
+=head1 CONFORMING TO
+
+ANSI X9.62, US Federal Information Processing Standard FIPS 186-2
+(Digital Signature Standard, DSS)
+
+=head1 SEE ALSO
+
+L<dsa(3)|dsa(3)>, L<rsa(3)|rsa(3)>
+
+=head1 HISTORY
+
+The ecdsa implementation was first introduced in OpenSSL 0.9.8
+
+=head1 AUTHOR
+
+Nils Larsch for the OpenSSL project (http://www.openssl.org).
+
+=cut
diff --git a/src/lib/libssl/src/doc/crypto/x509.pod b/src/lib/libssl/src/doc/crypto/x509.pod
new file mode 100644
index 0000000000..f9e58e0e41
--- /dev/null
+++ b/src/lib/libssl/src/doc/crypto/x509.pod
@@ -0,0 +1,64 @@
+=pod
+
+=head1 NAME
+
+x509 - X.509 certificate handling
+
+=head1 SYNOPSIS
+
+ #include <openssl/x509.h>
+
+=head1 DESCRIPTION
+
+A X.509 certificate is a structured grouping of information about
+an individual, a device, or anything one can imagine.  A X.509 CRL
+(certificate revocation list) is a tool to help determine if a
+certificate is still valid.  The exact definition of those can be
+found in the X.509 document from ITU-T, or in RFC3280 from PKIX.
+In OpenSSL, the type X509 is used to express such a certificate, and
+the type X509_CRL is used to express a CRL.
+
+A related structure is a certificate request, defined in PKCS#10 from
+RSA Security, Inc, also reflected in RFC2896.  In OpenSSL, the type
+X509_REQ is used to express such a certificate request.
+
+To handle some complex parts of a certificate, there are the types
+X509_NAME (to express a certificate name), X509_ATTRIBUTE (to express
+a certificate attributes), X509_EXTENSION (to express a certificate
+extension) and a few more.
+
+Finally, there's the supertype X509_INFO, which can contain a CRL, a
+certificate and a corresponding private key.
+
+B<X509_>I<...>, B<d2i_X509_>I<...> and B<i2d_X509_>I<...> handle X.509
+certificates, with some exceptions, shown below.
+
+B<X509_CRL_>I<...>, B<d2i_X509_CRL_>I<...> and B<i2d_X509_CRL_>I<...>
+handle X.509 CRLs.
+
+B<X509_REQ_>I<...>, B<d2i_X509_REQ_>I<...> and B<i2d_X509_REQ_>I<...>
+handle PKCS#10 certificate requests.
+
+B<X509_NAME_>I<...> handle certificate names.
+
+B<X509_ATTRIBUTE_>I<...> handle certificate attributes.
+
+B<X509_EXTENSION_>I<...> handle certificate extensions.
+
+=head1 SEE ALSO
+
+L<X509_NAME_ENTRY_get_object(3)|X509_NAME_ENTRY_get_object(3)>,
+L<X509_NAME_add_entry_by_txt(3)|X509_NAME_add_entry_by_txt(3)>,
+L<X509_NAME_add_entry_by_NID(3)|X509_NAME_add_entry_by_NID(3)>,
+L<X509_NAME_print_ex(3)|X509_NAME_print_ex(3)>,
+L<X509_NAME_new(3)|X509_NAME_new(3)>,
+L<d2i_X509(3)|d2i_X509(3)>,
+L<d2i_X509_ALGOR(3)|d2i_X509_ALGOR(3)>,
+L<d2i_X509_CRL(3)|d2i_X509_CRL(3)>,
+L<d2i_X509_NAME(3)|d2i_X509_NAME(3)>,
+L<d2i_X509_REQ(3)|d2i_X509_REQ(3)>,
+L<d2i_X509_SIG(3)|d2i_X509_SIG(3)>,
+L<crypto(3)|crypto(3)>,
+L<x509v3(3)|x509v3(3)>
+
+=cut