Update pre10

doc/man1/crl.pod

@@ -120,7 +120,7 @@ Convert a CRL file from PEM to DER:
 
 Output the text form of a DER encoded certificate:
 
- openssl crl -in crl.der -text -noout
+ openssl crl -in crl.der -inform DER -text -noout
 
 =head1 BUGS
 

doc/man1/s_time.pod

@@ -135,16 +135,16 @@ option enables various workarounds.
 This allows the TLSv1.2 and below cipher list sent by the client to be modified.
 This list will be combined with any TLSv1.3 ciphersuites that have been
 configured. Although the server determines which cipher suite is used it should
-take the first supported cipher in the list sent by the client. See the
-L<ciphers(1)> command for more information.
+take the first supported cipher in the list sent by the client. See
+L<ciphers(1)> for more information.
 
 =item B<-ciphersuites val>
 
 This allows the TLSv1.3 ciphersuites sent by the client to be modified. This
 list will be combined with any TLSv1.2 and below ciphersuites that have been
 configured. Although the server determines which cipher suite is used it should
-take the first supported cipher in the list sent by the client. See the
-B<ciphers> command for more information. The format for this list is a simple
+take the first supported cipher in the list sent by the client. See
+L<ciphers(1)> for more information. The format for this list is a simple
 colon (":") separated list of TLSv1.3 ciphersuite names.
 
 =item B<-time length>

doc/man1/sess_id.pod

@@ -99,7 +99,7 @@ Theses are described below in more detail.
 
 =item B<Protocol>
 
-This is the protocol in use TLSv1.2, TLSv1.1, TLSv1 or SSLv3.
+This is the protocol in use TLSv1.3, TLSv1.2, TLSv1.1, TLSv1 or SSLv3.
 
 =item B<Cipher>
 

doc/man3/EVP_DigestInit.pod

@@ -11,7 +11,8 @@ EVP_MD_block_size, EVP_MD_CTX_md, EVP_MD_CTX_size,
 EVP_MD_CTX_block_size, EVP_MD_CTX_type, EVP_MD_CTX_md_data,
 EVP_md_null,
 EVP_get_digestbyname, EVP_get_digestbynid,
-EVP_get_digestbyobj - EVP digest routines
+EVP_get_digestbyobj,
+EVP_MD_CTX_set_pkey_ctx - EVP digest routines
 
 =head1 SYNOPSIS
 
@@ -54,6 +55,8 @@ EVP_get_digestbyobj - EVP digest routines
  const EVP_MD *EVP_get_digestbynid(int type);
  const EVP_MD *EVP_get_digestbyobj(const ASN1_OBJECT *o);
 
+ void EVP_MD_CTX_set_pkey_ctx(EVP_MD_CTX *ctx, EVP_PKEY_CTX *pctx);
+
 =head1 DESCRIPTION
 
 The EVP digest routines are a high level interface to message digests,
@@ -179,6 +182,15 @@ EVP_get_digestbyobj()
 Returns an B<EVP_MD> structure when passed a digest name, a digest B<NID> or an
 B<ASN1_OBJECT> structure respectively.
 
+=item EVP_MD_CTX_set_pkey_ctx()
+
+Assigns an B<EVP_PKEY_CTX> to B<EVP_MD_CTX>. This is usually used to provide
+a customzied B<EVP_PKEY_CTX> to L<EVP_DigestSignInit(3)> or
+L<EVP_DigestVerifyInit(3)>. The B<pctx> passed to this function should be freed
+by the caller. A NULL B<pctx> pointer is also allowed to clear the B<EVP_PKEY_CTX>
+assigned to B<ctx>. In such case, freeing the cleared B<EVP_PKEY_CTX> or not
+depends on how the B<EVP_PKEY_CTX> is created.
+
 =back
 
 =head1 FLAGS
@@ -256,6 +268,10 @@ EVP_get_digestbyobj()
 
 Returns either an B<EVP_MD> structure or NULL if an error occurs.
 
+=item EVP_MD_CTX_set_pkey_ctx()
+
+This function has no return value.
+
 =back
 
 =head1 NOTES
@@ -278,7 +294,7 @@ EVP_MD_CTX_copy_ex() because they can efficiently reuse a digest context
 instead of initializing and cleaning it up on each call and allow non default
 implementations of digests to be specified.
 
-If digest contexts are not cleaned up after use
+If digest contexts are not cleaned up after use,
 memory leaks will occur.
 
 EVP_MD_CTX_size(), EVP_MD_CTX_block_size(), EVP_MD_CTX_type(),
@@ -360,6 +376,8 @@ later, so now EVP_sha1() can be used with RSA and DSA.
 
 EVP_dss1() was removed in OpenSSL 1.1.0.
 
+EVP_MD_CTX_set_pkey_ctx() was added in 1.1.1.
+
 =head1 COPYRIGHT
 
 Copyright 2000-2018 The OpenSSL Project Authors. All Rights Reserved.

doc/man3/EVP_DigestSignInit.pod

@@ -24,14 +24,23 @@ The EVP signature routines are a high level interface to digital signatures.
 
 EVP_DigestSignInit() sets up signing context B<ctx> to use digest B<type> from
 ENGINE B<e> and private key B<pkey>. B<ctx> must be created with
-EVP_MD_CTX_new() before calling this function. If B<pctx> is not NULL the
+EVP_MD_CTX_new() before calling this function. If B<pctx> is not NULL, the
 EVP_PKEY_CTX of the signing operation will be written to B<*pctx>: this can
-be used to set alternative signing options. The digest B<type> may be NULL if
-the signing algorithm supports it.
+be used to set alternative signing options. Note that any existing value in
+B<*pctx> is overwritten. The EVP_PKEY_CTX value returned must not be freed
+directly by the application if B<ctx> is not assigned an EVP_PKEY_CTX value before
+being passed to EVP_DigestSignInit() (which means the EVP_PKEY_CTX is created
+inside EVP_DigestSignInit() and it will be freed automatically when the
+EVP_MD_CTX is freed).
+
+The digest B<type> may be NULL if the signing algorithm supports it.
+
+No B<EVP_PKEY_CTX> will be created by EVP_DigsetSignInit() if the passed B<ctx>
+has already been assigned one via L<EVP_MD_CTX_set_ctx(3)>. See also L<SM2(7)>.
 
 Only EVP_PKEY types that support signing can be used with these functions. This
 includes MAC algorithms where the MAC generation is considered as a form of
-"signing." Built-in EVP_PKEY types supported by these functions are CMAC,
+"signing". Built-in EVP_PKEY types supported by these functions are CMAC,
 Poly1305, DSA, ECDSA, HMAC, RSA, SipHash, Ed25519 and Ed448.
 
 Not all digests can be used for all key types. The following combinations apply.
@@ -80,10 +89,10 @@ 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
 using a macro.
 
-EVP_DigestSignFinal() signs the data in B<ctx> places the signature in B<sig>.
+EVP_DigestSignFinal() signs the data in B<ctx> and places the signature in B<sig>.
 If B<sig> is B<NULL> then the maximum size of the output buffer is written to
 the B<siglen> parameter. If B<sig> is not B<NULL> then before the call the
-B<siglen> parameter should contain the length of the B<sig> buffer, if the
+B<siglen> parameter should contain the length of the B<sig> buffer. If the
 call is successful the signature is written to B<sig> and the amount of data
 written to B<siglen>.
 
@@ -95,7 +104,7 @@ EVP_DigestSignFinal().
 
 EVP_DigestSignInit(), EVP_DigestSignUpdate(), EVP_DigestSignaFinal() and
 EVP_DigestSign() return 1 for success and 0 or a negative value for failure. In
-particular a return value of -2 indicates the operation is not supported by the
+particular, a return value of -2 indicates the operation is not supported by the
 public key algorithm.
 
 The error codes can be obtained from L<ERR_get_error(3)>.
@@ -123,7 +132,7 @@ The call to EVP_DigestSignFinal() internally finalizes a copy of the digest
 context. This means that calls to EVP_DigestSignUpdate() and
 EVP_DigestSignFinal() can be called later to digest and sign additional data.
 
-Since only a copy of the digest context is ever finalized the context must
+Since only a copy of the digest context is ever finalized, the context must
 be cleaned up after use by calling EVP_MD_CTX_free() or a memory leak
 will occur.
 

doc/man3/EVP_DigestVerifyInit.pod

@@ -23,9 +23,17 @@ The EVP signature routines are a high level interface to digital signatures.
 
 EVP_DigestVerifyInit() sets up verification context B<ctx> to use digest
 B<type> from ENGINE B<e> and public key B<pkey>. B<ctx> must be created
-with EVP_MD_CTX_new() before calling this function. If B<pctx> is not NULL the
+with EVP_MD_CTX_new() before calling this function. If B<pctx> is not NULL, the
 EVP_PKEY_CTX of the verification operation will be written to B<*pctx>: this
-can be used to set alternative verification options.
+can be used to set alternative verification options. Note that any existing
+value in B<*pctx> is overwritten. The EVP_PKEY_CTX value returned must not be freed
+directly by the application if B<ctx> is not assigned an EVP_PKEY_CTX value before
+being passed to EVP_DigestSignInit() (which means the EVP_PKEY_CTX is created
+inside EVP_DigestSignInit() and it will be freed automatically when the
+EVP_MD_CTX is freed).
+
+No B<EVP_PKEY_CTX> will be created by EVP_DigsetSignInit() if the passed B<ctx>
+has already been assigned one via L<EVP_MD_CTX_set_ctx(3)>. See also L<SM2(7)>.
 
 EVP_DigestVerifyUpdate() hashes B<cnt> bytes of data at B<d> into the
 verification context B<ctx>. This function can be called several times on the
@@ -75,7 +83,7 @@ The call to EVP_DigestVerifyFinal() internally finalizes a copy of the digest
 context. This means that EVP_VerifyUpdate() and EVP_VerifyFinal() can
 be called later to digest and verify additional data.
 
-Since only a copy of the digest context is ever finalized the context must
+Since only a copy of the digest context is ever finalized, the context must
 be cleaned up after use by calling EVP_MD_CTX_free() or a memory leak
 will occur.
 

doc/man3/EVP_PKEY_CTX_ctrl.pod

@@ -17,7 +17,9 @@ EVP_PKEY_CTX_set_dh_paramgen_generator,
 EVP_PKEY_CTX_set_dh_pad,
 EVP_PKEY_CTX_set_dh_nid,
 EVP_PKEY_CTX_set_ec_paramgen_curve_nid,
-EVP_PKEY_CTX_set_ec_param_enc - algorithm specific control operations
+EVP_PKEY_CTX_set_ec_param_enc,
+EVP_PKEY_CTX_set1_id, EVP_PKEY_CTX_get1_id, EVP_PKEY_CTX_get1_id_len
+- algorithm specific control operations
 
 =head1 SYNOPSIS
 
@@ -53,6 +55,10 @@ EVP_PKEY_CTX_set_ec_param_enc - algorithm specific control operations
  int EVP_PKEY_CTX_set_ec_paramgen_curve_nid(EVP_PKEY_CTX *ctx, int nid);
  int EVP_PKEY_CTX_set_ec_param_enc(EVP_PKEY_CTX *ctx, int param_enc);
 
+ int EVP_PKEY_CTX_set1_id(EVP_PKEY_CTX *ctx, void *id, size_t id_len);
+ int EVP_PKEY_CTX_get1_id(EVP_PKEY_CTX *ctx, void *id);
+ int EVP_PKEY_CTX_get1_id_len(EVP_PKEY_CTX *ctx, size_t *id_len);
+
 =head1 DESCRIPTION
 
 The function EVP_PKEY_CTX_ctrl() sends a control operation to the context
@@ -160,6 +166,17 @@ For maximum compatibility the named curve form should be used. Note: the
 B<OPENSSL_EC_NAMED_CURVE> value was only added to OpenSSL 1.1.0; previous
 versions should use 0 instead.
 
+The EVP_PKEY_CTX_set1_id(), EVP_PKEY_CTX_get1_id() and EVP_PKEY_CTX_get1_id_len()
+macros are used to manipulate the special identifier field for specific signature
+algorithms such as SM2. The EVP_PKEY_CTX_set1_id() sets an ID pointed by B<id> with
+the length B<id_len> to the library. The library takes a copy of the id so that
+the caller can safely free the original memory pointed to by B<id>. The
+EVP_PKEY_CTX_get1_id_len() macro returns the length of the ID set via a previous
+call to EVP_PKEY_CTX_set1_id(). The length is usually used to allocate adequate
+memory for further calls to EVP_PKEY_CTX_get1_id(). The EVP_PKEY_CTX_get1_id()
+macro returns the previously set ID value to caller in B<id>. The caller should
+allocate adequate memory space for the B<id> before calling EVP_PKEY_CTX_get1_id().
+
 =head1 RETURN VALUES
 
 EVP_PKEY_CTX_ctrl() and its macros return a positive value for success and 0
@@ -179,7 +196,8 @@ L<EVP_PKEY_keygen(3)>
 
 =head1 HISTORY
 
-These functions were first added to OpenSSL 1.0.0.
+EVP_PKEY_CTX_set1_id(), EVP_PKEY_CTX_get1_id() and EVP_PKEY_CTX_get1_id_len()
+macros were added in 1.1.1, other functions were first added to OpenSSL 1.0.0.
 
 =head1 COPYRIGHT
 

doc/man3/EVP_PKEY_meth_new.pod

@@ -10,12 +10,14 @@ EVP_PKEY_meth_set_verify, EVP_PKEY_meth_set_verify_recover, EVP_PKEY_meth_set_si
 EVP_PKEY_meth_set_verifyctx, EVP_PKEY_meth_set_encrypt, EVP_PKEY_meth_set_decrypt,
 EVP_PKEY_meth_set_derive, EVP_PKEY_meth_set_ctrl, EVP_PKEY_meth_set_check,
 EVP_PKEY_meth_set_public_check, EVP_PKEY_meth_set_param_check,
+EVP_PKEY_meth_set_digest_custom,
 EVP_PKEY_meth_get_init, EVP_PKEY_meth_get_copy, EVP_PKEY_meth_get_cleanup,
 EVP_PKEY_meth_get_paramgen, EVP_PKEY_meth_get_keygen, EVP_PKEY_meth_get_sign,
 EVP_PKEY_meth_get_verify, EVP_PKEY_meth_get_verify_recover, EVP_PKEY_meth_get_signctx,
 EVP_PKEY_meth_get_verifyctx, EVP_PKEY_meth_get_encrypt, EVP_PKEY_meth_get_decrypt,
 EVP_PKEY_meth_get_derive, EVP_PKEY_meth_get_ctrl, EVP_PKEY_meth_get_check,
 EVP_PKEY_meth_get_public_check, EVP_PKEY_meth_get_param_check,
+EVP_PKEY_meth_get_digest_custom,
 EVP_PKEY_meth_remove
 - manipulating EVP_PKEY_METHOD structure
 
@@ -116,6 +118,9 @@ EVP_PKEY_meth_remove
                                      int (*check) (EVP_PKEY *pkey));
  void EVP_PKEY_meth_set_param_check(EVP_PKEY_METHOD *pmeth,
                                     int (*check) (EVP_PKEY *pkey));
+ void EVP_PKEY_meth_set_digest_custom(EVP_PKEY_METHOD *pmeth,
+                                     int (*digest_custom) (EVP_PKEY_CTX *ctx,
+                                                           EVP_MD_CTX *mctx));
 
  void EVP_PKEY_meth_get_init(const EVP_PKEY_METHOD *pmeth,
                              int (**pinit) (EVP_PKEY_CTX *ctx));
@@ -201,6 +206,9 @@ EVP_PKEY_meth_remove
                                      int (**pcheck) (EVP_PKEY *pkey));
  void EVP_PKEY_meth_get_param_check(const EVP_PKEY_METHOD *pmeth,
                                     int (**pcheck) (EVP_PKEY *pkey));
+ void EVP_PKEY_meth_get_digest_custom(EVP_PKEY_METHOD *pmeth,
+                                     int (**pdigest_custom) (EVP_PKEY_CTX *ctx,
+                                                             EVP_MD_CTX *mctx));
 
 =head1 DESCRIPTION
 
@@ -334,6 +342,15 @@ key-pair, the public component and parameters respectively for a given B<pkey>.
 They could be called by L<EVP_PKEY_check(3)>, L<EVP_PKEY_public_check(3)> and
 L<EVP_PKEY_param_check(3)> respectively.
 
+ int (*digest_custom) (EVP_PKEY_CTX *ctx, EVP_MD_CTX *mctx);
+
+The digest_custom() method is used to generate customized digest content before
+the real message is passed to functions like L<EVP_DigestSignUpdate(3)> or
+L<EVP_DigestVerifyInit(3)>. This is usually required by some public key
+signature algorithms like SM2 which requires a hashed prefix to the message to
+be signed. The digest_custom() function will be called by L<EVP_DigestSignInit(3)>
+and L<EVP_DigestVerifyInit(3)>.
+
 =head2 Functions
 
 EVP_PKEY_meth_new() creates and returns a new B<EVP_PKEY_METHOD> object,

doc/man3/EVP_sm3.pod

@@ -9,7 +9,7 @@ EVP_sm3
 
  #include <openssl/evp.h>
 
- const EVP_MD *EVP_sm3(void)
+ const EVP_MD *EVP_sm3(void);
 
 =head1 DESCRIPTION
 
@@ -42,7 +42,7 @@ L<EVP_DigestInit(3)>
 
 =head1 COPYRIGHT
 
-Copyright 2017 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2017-2018 The OpenSSL Project Authors. All Rights Reserved.
 Copyright 2017 Ribose Inc. All Rights Reserved.
 
 Licensed under the OpenSSL license (the "License").  You may not use

doc/man3/EVP_sm4_cbc.pod

@@ -13,11 +13,11 @@ EVP_sm4_ctr
 
  #include <openssl/evp.h>
 
- const EVP_CIPHER *EVP_sm4_cbc(void)
- const EVP_CIPHER *EVP_sm4_ecb(void)
- const EVP_CIPHER *EVP_sm4_cfb(void)
- const EVP_CIPHER *EVP_sm4_ofb(void)
- const EVP_CIPHER *EVP_sm4_ctr(void)
+ const EVP_CIPHER *EVP_sm4_cbc(void);
+ const EVP_CIPHER *EVP_sm4_ecb(void);
+ const EVP_CIPHER *EVP_sm4_cfb(void);
+ const EVP_CIPHER *EVP_sm4_ofb(void);
+ const EVP_CIPHER *EVP_sm4_ctr(void);
 
 =head1 DESCRIPTION
 
@@ -52,7 +52,7 @@ L<EVP_CIPHER_meth_new(3)>
 
 =head1 COPYRIGHT
 
-Copyright 2017 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2017-2018 The OpenSSL Project Authors. All Rights Reserved.
 Copyright 2017 Ribose Inc. All Rights Reserved.
 
 Licensed under the OpenSSL license (the "License").  You may not use

doc/man3/OBJ_nid2obj.pod

@@ -84,7 +84,8 @@ OBJ_dup() returns a copy of B<o>.
 
 OBJ_create() adds a new object to the internal table. B<oid> is the
 numerical form of the object, B<sn> the short name and B<ln> the
-long name. A new NID is returned for the created object.
+long name. A new NID is returned for the created object in case of
+success and NID_undef in case of failure.
 
 OBJ_length() returns the size of the content octets of B<obj>.
 

doc/man3/OCSP_resp_find_status.pod

@@ -7,6 +7,9 @@ OCSP_resp_get0_signer,
 OCSP_resp_get0_id,
 OCSP_resp_get1_id,
 OCSP_resp_get0_produced_at,
+OCSP_resp_get0_signature,
+OCSP_resp_get0_tbs_sigalg,
+OCSP_resp_get0_respdata,
 OCSP_resp_find_status, OCSP_resp_count, OCSP_resp_get0, OCSP_resp_find,
 OCSP_single_get0_status, OCSP_check_validity,
 OCSP_basic_verify
@@ -33,6 +36,9 @@ OCSP_basic_verify
  const ASN1_GENERALIZEDTIME *OCSP_resp_get0_produced_at(
                              const OCSP_BASICRESP* single);
 
+ const ASN1_OCTET_STRING *OCSP_resp_get0_signature(const OCSP_BASICRESP *bs);
+ const X509_ALGOR *OCSP_resp_get0_tbs_sigalg(const OCSP_BASICRESP *bs);
+ const OCSP_RESPDATA *OCSP_resp_get0_respdata(const OCSP_BASICRESP *bs);
  const STACK_OF(X509) *OCSP_resp_get0_certs(const OCSP_BASICRESP *bs);
 
  int OCSP_resp_get0_signer(OCSP_BASICRESP *bs, X509 **signer,
@@ -82,6 +88,12 @@ B<*revtime>, B<*thisupd> and B<*nextupd>.
 OCSP_resp_get0_produced_at() extracts the B<producedAt> field from the
 single response B<bs>.
 
+OCSP_resp_get0_signature() returns the signature from B<bs>.
+
+OCSP_resp_get0_tbs_sigalg() returns the B<signatureAlgorithm> from B<bs>.
+
+OCSP_resp_get0_respdata() returns the B<tbsResponseData> from B<bs>.
+
 OCSP_resp_get0_certs() returns any certificates included in B<bs>.
 
 OCSP_resp_get0_signer() attempts to retrieve the certificate that directly

doc/man3/SSL_CONF_cmd.pod

@@ -33,25 +33,36 @@ prefix for command line commands is B<-> and that is reflected below.
 
 =item B<-sigalgs>
 
-This sets the supported signature algorithms for TLS v1.2. For clients this
+This sets the supported signature algorithms for TLSv1.2 and TLSv1.3.
+For clients this
 value is used directly for the supported signature algorithms extension. For
 servers it is used to determine which signature algorithms to support.
 
 The B<value> argument should be a colon separated list of signature algorithms
-in order of decreasing preference of the form B<algorithm+hash>. B<algorithm>
+in order of decreasing preference of the form B<algorithm+hash> or
+B<signature_scheme>. B<algorithm>
 is one of B<RSA>, B<DSA> or B<ECDSA> and B<hash> is a supported algorithm
 OID short name such as B<SHA1>, B<SHA224>, B<SHA256>, B<SHA384> of B<SHA512>.
 Note: algorithm and hash names are case sensitive.
+B<signature_scheme> is one of the signature schemes defined in TLSv1.3,
+specified using the IETF name, e.g., B<ecdsa_secp256r1_sha256>, B<ed25519>,
+or B<rsa_pss_pss_sha256>.
 
 If this option is not set then all signature algorithms supported by the
 OpenSSL library are permissible.
 
+Note: algorithms which specify a PKCS#1 v1.5 signature scheme (either by
+using B<RSA> as the B<algorithm> or by using one of the B<rsa_pkcs1_*>
+identifiers) are ignored in TLSv1.3 and will not be negotiated.
+
 =item B<-client_sigalgs>
 
 This sets the supported signature algorithms associated with client
-authentication for TLS v1.2. For servers the value is used in the supported
-signature algorithms field of a certificate request. For clients it is
-used to determine which signature algorithm to with the client certificate.
+authentication for TLSv1.2 and TLSv1.3.
+For servers the value is used in the
+B<signature_algorithms> field of a B<CertificateRequest> message.
+For clients it is
+used to determine which signature algorithm to use with the client certificate.
 If a server does not request a certificate this option has no effect.
 
 The syntax of B<value> is identical to B<-sigalgs>. If not set then
@@ -61,22 +72,21 @@ the value set for B<-sigalgs> will be used instead.
 
 This sets the supported groups. For clients, the groups are
 sent using the supported groups extension. For servers, it is used
-to determine which group to use. This setting affects groups used for both
-signatures and key exchange, if applicable. It also affects the preferred
-key_share sent by a client in a TLSv1.3 compatible connection.
+to determine which group to use. This setting affects groups used for
+signatures (in TLSv1.2 and earlier) and key exchange. The first group listed
+will also be used for the B<key_share> sent by a client in a TLSv1.3
+B<ClientHello>.
 
 The B<value> argument is a colon separated list of groups. The group can be
 either the B<NIST> name (e.g. B<P-256>), some other commonly used name where
 applicable (e.g. B<X25519>) or an OpenSSL OID name (e.g B<prime256v1>). Group
 names are case sensitive. The list should be in order of preference with the
-most preferred group first. The first listed group will be the one used for a
-key_share by a TLSv1.3 client.
+most preferred group first.
 
 =item B<-curves>
 
 This is a synonym for the "-groups" command.
 
-
 =item B<-named_curve>
 
 This sets the temporary curve used for ephemeral ECDH modes. Only used by
@@ -99,6 +109,7 @@ associated with B<cctx>.
 Sets the available ciphersuites for TLSv1.3 to value. This is a simple colon
 (":") separated list of TLSv1.3 ciphersuite names in order of preference. This
 list will be combined any configured TLSv1.2 and below ciphersuites.
+See L<ciphers(1)> for more information.
 
 
 =item B<-cert>
@@ -124,7 +135,7 @@ operations are permitted.
 
 =item B<-record_padding>
 
-Attempts to pad TLS 1.3 records so that they are a multiple of B<value> in
+Attempts to pad TLSv1.3 records so that they are a multiple of B<value> in
 length on send. A B<value> of 0 or 1 turns off padding. Otherwise, the
 B<value> must be >1 or <=16384.
 
@@ -137,9 +148,9 @@ B<SSL_OP_NO_RENEGOTIATION>.
 
 Sets the minimum and maximum supported protocol.
 Currently supported protocol values are B<SSLv3>, B<TLSv1>,
-B<TLSv1.1>, B<TLSv1.2> for TLS and B<DTLSv1>, B<DTLSv1.2> for DTLS,
+B<TLSv1.1>, B<TLSv1.2>, B<TLSv1.3> for TLS and B<DTLSv1>, B<DTLSv1.2> for DTLS,
 and B<None> for no limit.
-If the either bound is not specified then only the other bound applies,
+If either bound is not specified then only the other bound applies,
 if specified.
 To restrict the supported protocol versions use these commands rather
 than the deprecated alternative commands below.
@@ -249,6 +260,7 @@ structure is associated with B<cctx>.
 Sets the available ciphersuites for TLSv1.3 to B<value>. This is a simple colon
 (":") separated list of TLSv1.3 ciphersuite names in order of preference. This
 list will be combined any configured TLSv1.2 and below ciphersuites.
+See L<ciphers(1)> for more information.
 
 =item B<Certificate>
 
@@ -292,7 +304,7 @@ operations are permitted.
 
 =item B<RecordPadding>
 
-Attempts to pad TLS 1.3 records so that they are a multiple of B<value> in
+Attempts to pad TLSv1.3 records so that they are a multiple of B<value> in
 length on send. A B<value> of 0 or 1 turns off padding. Otherwise, the
 B<value> must be >1 or <=16384.
 
@@ -303,25 +315,37 @@ B<SSL_OP_NO_RENEGOTIATION>.
 
 =item B<SignatureAlgorithms>
 
-This sets the supported signature algorithms for TLS v1.2. For clients this
+This sets the supported signature algorithms for TLSv1.2 and TLSv1.3.
+For clients this
 value is used directly for the supported signature algorithms extension. For
 servers it is used to determine which signature algorithms to support.
 
 The B<value> argument should be a colon separated list of signature algorithms
-in order of decreasing preference of the form B<algorithm+hash>. B<algorithm>
+in order of decreasing preference of the form B<algorithm+hash> or
+B<signature_scheme>. B<algorithm>
 is one of B<RSA>, B<DSA> or B<ECDSA> and B<hash> is a supported algorithm
 OID short name such as B<SHA1>, B<SHA224>, B<SHA256>, B<SHA384> of B<SHA512>.
 Note: algorithm and hash names are case sensitive.
+B<signature_scheme> is one of the signature schemes defined in TLSv1.3,
+specified using the IETF name, e.g., B<ecdsa_secp256r1_sha256>, B<ed25519>,
+or B<rsa_pss_pss_sha256>.
 
 If this option is not set then all signature algorithms supported by the
 OpenSSL library are permissible.
 
+Note: algorithms which specify a PKCS#1 v1.5 signature scheme (either by
+using B<RSA> as the B<algorithm> or by using one of the B<rsa_pkcs1_*>
+identifiers) are ignored in TLSv1.3 and will not be negotiated.
+
 =item B<ClientSignatureAlgorithms>
 
 This sets the supported signature algorithms associated with client
-authentication for TLS v1.2. For servers the value is used in the supported
-signature algorithms field of a certificate request. For clients it is
-used to determine which signature algorithm to with the client certificate.
+authentication for TLSv1.2 and TLSv1.3.
+For servers the value is used in the
+B<signature_algorithms> field of a B<CertificateRequest> message.
+For clients it is
+used to determine which signature algorithm to use with the client certificate.
+If a server does not request a certificate this option has no effect.
 
 The syntax of B<value> is identical to B<SignatureAlgorithms>. If not set then
 the value set for B<SignatureAlgorithms> will be used instead.
@@ -330,16 +354,16 @@ the value set for B<SignatureAlgorithms> will be used instead.
 
 This sets the supported groups. For clients, the groups are
 sent using the supported groups extension. For servers, it is used
-to determine which group to use. This setting affects groups used for both
-signatures and key exchange, if applicable. It also affects the preferred
-key_share sent by a client in a TLSv1.3 compatible connection.
+to determine which group to use. This setting affects groups used for
+signatures (in TLSv1.2 and earlier) and key exchange. The first group listed
+will also be used for the B<key_share> sent by a client in a TLSv1.3
+B<ClientHello>.
 
 The B<value> argument is a colon separated list of groups. The group can be
 either the B<NIST> name (e.g. B<P-256>), some other commonly used name where
 applicable (e.g. B<X25519>) or an OpenSSL OID name (e.g B<prime256v1>). Group
 names are case sensitive. The list should be in order of preference with the
-most preferred group first. The first listed group will be the one used for a
-key_share by a TLSv1.3 client.
+most preferred group first.
 
 =item B<Curves>
 
@@ -350,7 +374,7 @@ This is a synonym for the "Groups" command.
 This sets the minimum supported SSL, TLS or DTLS version.
 
 Currently supported protocol values are B<SSLv3>, B<TLSv1>, B<TLSv1.1>,
-B<TLSv1.2>, B<DTLSv1> and B<DTLSv1.2>.
+B<TLSv1.2>, B<TLSv1.3>, B<DTLSv1> and B<DTLSv1.2>.
 The value B<None> will disable the limit.
 
 =item B<MaxProtocol>
@@ -358,7 +382,7 @@ The value B<None> will disable the limit.
 This sets the maximum supported SSL, TLS or DTLS version.
 
 Currently supported protocol values are B<SSLv3>, B<TLSv1>, B<TLSv1.1>,
-B<TLSv1.2>, B<DTLSv1> and B<DTLSv1.2>.
+B<TLSv1.2>, B<TLSv1.3>, B<DTLSv1> and B<DTLSv1.2>.
 The value B<None> will disable the limit.
 
 =item B<Protocol>
@@ -377,7 +401,7 @@ Only enabling some protocol versions does not disable the other protocol
 versions.
 
 Currently supported protocol values are B<SSLv3>, B<TLSv1>, B<TLSv1.1>,
-B<TLSv1.2>, B<DTLSv1> and B<DTLSv1.2>.
+B<TLSv1.2>, B<TLSv1.3>, B<DTLSv1> and B<DTLSv1.2>.
 The special value B<ALL> refers to all supported versions.
 
 This can't enable protocols that are disabled using B<MinProtocol>

doc/man3/SSL_CTX_new.pod

@@ -92,7 +92,7 @@ B<method> can be of the following types:
 These are the general-purpose I<version-flexible> SSL/TLS methods.
 The actual protocol version used will be negotiated to the highest version
 mutually supported by the client and the server.
-The supported protocols are SSLv3, TLSv1, TLSv1.1 and TLSv1.2.
+The supported protocols are SSLv3, TLSv1, TLSv1.1, TLSv1.2 and TLSv1.3.
 Applications should use these methods, and avoid the version-specific
 methods described below.
 
@@ -153,11 +153,12 @@ L<SSL_set_min_proto_version(3)>, L<SSL_CTX_set_max_proto_version(3)> and
 L<SSL_set_max_proto_version(3)> functions.
 Using these functions it is possible to choose e.g. TLS_server_method()
 and be able to negotiate with all possible clients, but to only
-allow newer protocols like TLS 1.0, TLS 1.1 or TLS 1.2.
+allow newer protocols like TLS 1.0, TLS 1.1, TLS 1.2 or TLS 1.3.
 
 The list of protocols available can also be limited using the
 B<SSL_OP_NO_SSLv3>, B<SSL_OP_NO_TLSv1>, B<SSL_OP_NO_TLSv1_1>,
-B<SSL_OP_NO_TLSv1_3> and B<SSL_OP_NO_TLSv1_2> options of the
+B<SSL_OP_NO_TLSv1_3>, B<SSL_OP_NO_TLSv1_2> and B<SSL_OP_NO_TLSv1_3>
+options of the
 L<SSL_CTX_set_options(3)> or L<SSL_set_options(3)> functions, but this approach
 is not recommended. Clients should avoid creating "holes" in the set of
 protocols they support. When disabling a protocol, make sure that you also

doc/man3/SSL_CTX_set0_CA_list.pod

@@ -3,7 +3,7 @@
 =head1 NAME
 
 SSL_set0_CA_list, SSL_CTX_set0_CA_list, SSL_get0_CA_list,
-SSL_CTX_get0_CA_list, SSL_add1_CA_list, SSL_CTX_add1_CA_list,
+SSL_CTX_get0_CA_list, SSL_add1_to_CA_list, SSL_CTX_add1_to_CA_list,
 SSL_get0_peer_CA_list - get or set CA list
 
 =head1 SYNOPSIS
@@ -14,8 +14,8 @@ SSL_get0_peer_CA_list - get or set CA list
  void SSL_set0_CA_list(SSL *s, STACK_OF(X509_NAME) *name_list);
  const STACK_OF(X509_NAME) *SSL_CTX_get0_CA_list(const SSL_CTX *ctx);
  const STACK_OF(X509_NAME) *SSL_get0_CA_list(const SSL *s);
- int SSL_CTX_add1_CA_list(SSL_CTX *ctx, const X509 *x);
- int SSL_add1_CA_list(SSL *ssl, const X509 *x);
+ int SSL_CTX_add1_to_CA_list(SSL_CTX *ctx, const X509 *x);
+ int SSL_add1_to_CA_list(SSL *ssl, const X509 *x);
 
  const STACK_OF(X509_NAME) *SSL_get0_peer_CA_list(const SSL *s);
 
@@ -35,10 +35,10 @@ B<ctx>.
 SSL_CTX_get0_CA_list() retrieves any previously set list of CAs set for
 B<s> or if none are set the list from the parent B<SSL_CTX> is retrieved.
 
-SSL_CTX_add1_CA_list() appends the CA subject name extracted from B<x> to the
+SSL_CTX_add1_to_CA_list() appends the CA subject name extracted from B<x> to the
 list of CAs sent to peer for B<ctx>.
 
-SSL_add1_CA_list() appends the CA subject name extracted from B<x> to the
+SSL_add1_to_CA_list() appends the CA subject name extracted from B<x> to the
 list of CAs sent to the peer for B<s>, overriding the setting in the parent
 B<SSL_CTX>.
 
@@ -66,7 +66,7 @@ SSL_CTX_set0_CA_list() and SSL_set0_CA_list() do not return a value.
 SSL_CTX_get0_CA_list() and SSL_get0_CA_list() return a stack of CA names
 or B<NULL> is no CA names are set.
 
-SSL_CTX_add1_CA_list() and SSL_add1_CA_list() return 1 for success and 0
+SSL_CTX_add1_to_CA_list() and SSL_add1_to_CA_list() return 1 for success and 0
 for failure.
 
 SSL_get0_peer_CA_list() returns a stack of CA names sent by the peer or

doc/man3/SSL_CTX_set_cert_cb.pod

@@ -51,9 +51,9 @@ can modify or delete the existing certificate.
 
 A more advanced callback might examine the handshake parameters and set
 whatever chain is appropriate. For example a legacy client supporting only
-TLS v1.0 might receive a certificate chain signed using SHA1 whereas a
-TLS v1.2 client which advertises support for SHA256 could receive a chain
-using SHA256.
+TLSv1.0 might receive a certificate chain signed using SHA1 whereas a
+TLSv1.2 or later client which advertises support for SHA256 could receive a
+chain using SHA256.
 
 Normal server sanity checks are performed on any certificates set
 by the callback. So if an EC chain is set for a curve the client does not

doc/man3/SSL_CTX_set_psk_client_callback.pod

@@ -132,6 +132,14 @@ Note that parameter B<hint> given to the callback may be B<NULL>.
 A connection established via a TLSv1.3 PSK will appear as if session resumption
 has occurred so that L<SSL_session_reused(3)> will return true.
 
+There are no known security issues with sharing the same PSK between TLSv1.2 (or
+below) and TLSv1.3. However the RFC has this note of caution:
+
+"While there is no known way in which the same PSK might produce related output
+in both versions, only limited analysis has been done.  Implementations can
+ensure safety from cross-protocol related output by not reusing PSKs between
+TLS 1.3 and TLS 1.2."
+
 =head1 RETURN VALUES
 
 Return values from the B<SSL_psk_client_cb_func> callback are interpreted as

doc/man3/SSL_CTX_set_verify.pod

@@ -186,7 +186,7 @@ Its return value is identical to B<preverify_ok>, so that any verification
 failure will lead to a termination of the TLS/SSL handshake with an
 alert message, if SSL_VERIFY_PEER is set.
 
-After calling SSL_force_post_handshake_auth(), the client will need to add a
+After calling SSL_set_post_handshake_auth(), the client will need to add a
 certificate or certificate callback to its configuration before it can
 successfully authenticate. This must be called before SSL_connect().
 

doc/man3/SSL_CTX_use_psk_identity_hint.pod

@@ -123,6 +123,16 @@ completely.
 The B<SSL_psk_find_session_cb_func> callback should return 1 on success or 0 on
 failure. In the event of failure the connection setup fails.
 
+=head1 NOTES
+
+There are no known security issues with sharing the same PSK between TLSv1.2 (or
+below) and TLSv1.3. However the RFC has this note of caution:
+
+"While there is no known way in which the same PSK might produce related output
+in both versions, only limited analysis has been done.  Implementations can
+ensure safety from cross-protocol related output by not reusing PSKs between
+TLS 1.3 and TLS 1.2."
+
 =head1 SEE ALSO
 
 L<SSL_CTX_set_psk_use_session_callback(3)>,

doc/man3/SSL_SESSION_get_protocol_version.pod

@@ -27,7 +27,7 @@ up a session based PSK (see L<SSL_CTX_set_psk_use_session_callback(3)>).
 
 SSL_SESSION_get_protocol_version() returns a number indicating the protocol
 version used for the session; this number matches the constants I<e.g.>
-B<TLS1_VERSION> or B<TLS1_2_VERSION>.
+B<TLS1_VERSION>, B<TLS1_2_VERSION> or B<TLS1_3_VERSION>.
 
 Note that the SSL_SESSION_get_protocol_version() function
 does B<not> perform a null check on the provided session B<s> pointer.

doc/man3/SSL_check_chain.pod

@@ -72,9 +72,9 @@ The validity of a chain is determined by checking if it matches a supported
 signature algorithm, supported curves and in the case of client authentication
 certificate types and issuer names.
 
-Since the supported signature algorithms extension is only used in TLS 1.2
-and DTLS 1.2 the results for earlier versions of TLS and DTLS may not be
-very useful. Applications may wish to specify a different "legacy" chain
+Since the supported signature algorithms extension is only used in TLS 1.2,
+TLS 1.3 and DTLS 1.2 the results for earlier versions of TLS and DTLS may not
+be very useful. Applications may wish to specify a different "legacy" chain
 for earlier versions of TLS or DTLS.
 
 =head1 SEE ALSO

doc/man3/SSL_get_peer_signature_nid.pod

@@ -20,7 +20,9 @@ by the peer to sign TLS messages. It is implemented as a macro.
 SSL_get_peer_signature_type_nid() sets B<*psigtype_nid> to the signature
 type used by the peer to sign TLS messages. Currently the signature type
 is the NID of the public key type used for signing except for PSS signing
-where it is B<EVP_PKEY_RSA_PSS>.
+where it is B<EVP_PKEY_RSA_PSS>. To differentiate between
+B<rsa_pss_rsae_*> and B<rsa_pss_pss_*> signatures, it's necessary to check
+the type of public key in the peer's certificate.
 
 =head1 RETURN VALUES
 

doc/man3/SSL_get_shared_sigalgs.pod

@@ -54,7 +54,8 @@ signature algorithms: after a client hello (for servers) or a certificate
 request (for clients). They can (for example) be called in the certificate
 callback.
 
-Only TLS 1.2 and DTLS 1.2 currently support signature algorithms. If these
+Only TLS 1.2, TLS 1.3 and DTLS 1.2 currently support signature algorithms.
+If these
 functions are called on an earlier version of TLS or DTLS zero is returned.
 
 The shared signature algorithms returned by SSL_get_shared_sigalgs() are
@@ -66,8 +67,9 @@ rsa(1) then B<*rhash> would be 4, B<*rsign> 1, B<*phash> NID_sha256, B<*psig>
 NID_rsaEncryption and B<*psighash> NID_sha256WithRSAEncryption.
 
 If a signature algorithm is not recognised the corresponding NIDs
-will be set to B<NID_undef>. This may be because the value is not supported
-or is not an appropriate combination (for example MD5 and DSA).
+will be set to B<NID_undef>. This may be because the value is not supported,
+is not an appropriate combination (for example MD5 and DSA) or the
+signature algorithm does not use a hash (for example Ed25519).
 
 =head1 SEE ALSO
 

doc/man3/SSL_get_version.pod

@@ -19,17 +19,20 @@ protocol information of a connection
 
 =head1 DESCRIPTION
 
-SSL_client_version() returns the protocol version used by the client when
-initiating the connection. SSL_get_version() returns the name of the protocol
-used for the connection. SSL_version() returns the protocol version used for the
-connection. They should only be called after the initial handshake has been
-completed. Prior to that the results returned from these functions may be
-unreliable.
+SSL_client_version() returns the numeric protocol version advertised by the
+client in the legacy_version field of the ClientHello when initiating the
+connection. Note that, for TLS, this value will never indicate a version greater
+than TLSv1.2 even if TLSv1.3 is subsequently negotiated. SSL_get_version()
+returns the name of the protocol used for the connection. SSL_version() returns
+the numeric protocol version used for the connection. They should only be called
+after the initial handshake has been completed. Prior to that the results
+returned from these functions may be unreliable.
 
 SSL_is_dtls() returns one if the connection is using DTLS, zero if not.
 
 =head1 RETURN VALUES
 
+
 SSL_get_version() returns one of the following strings:
 
 =over 4
@@ -60,8 +63,8 @@ This indicates an unknown protocol version.
 
 =back
 
-SSL_version() and SSL_client_version() return an integer which could include any of
-the following:
+SSL_version() and SSL_client_version() return an integer which could include any
+of the following:
 
 =over 4
 
@@ -83,7 +86,8 @@ The connection uses the TLSv1.2 protocol.
 
 =item TLS1_3_VERSION
 
-The connection uses the TLSv1.3 protocol.
+The connection uses the TLSv1.3 protocol (never returned for
+SSL_client_version()).
 
 =back
 

doc/man7/Ed25519.pod

@@ -25,7 +25,7 @@ The message to sign or verify must be passed using the one-shot
 EVP_DigestSign() and EVP_DigestVerify() functions.
 
 When calling EVP_DigestSignInit() or EVP_DigestVerifyInit(), the
-digest parameter B<MUST> be set to B<NULL>.
+digest B<type> parameter B<MUST> be set to B<NULL>.
 
 Applications wishing to sign certificates (or other structures such as
 CRLs or certificate requests) using Ed25519 or Ed448 can either use X509_sign()
@@ -49,6 +49,10 @@ Ed25519 or Ed448 public keys can be set directly using
 L<EVP_PKEY_new_raw_public_key(3)> or loaded from a SubjectPublicKeyInfo
 structure in a PEM file using L<PEM_read_bio_PUBKEY(3)> (or similar function).
 
+Ed25519 and Ed448 can be tested within L<speed(1)> application since version 1.1.1.
+Valid algorithm names are B<ed25519>, B<ed448> and B<eddsa>. If B<eddsa> is
+specified, then both Ed25519 and Ed448 are benchmarked.
+
 =head1 EXAMPLE
 
 This example generates an B<ED25519> private key and writes it to standard

doc/man7/SM2.pod

@@ -0,0 +1,79 @@
+=pod
+
+=head1 NAME
+
+SM2 - Chinese SM2 signature and encryption algorithm support
+
+=head1 DESCRIPTION
+
+The B<SM2> algorithm was first defined by the Chinese national standard GM/T
+0003-2012 and was later standardized by ISO as ISO/IEC 14888. B<SM2> is actually
+an elliptic curve based algorithm. The current implementation in OpenSSL supports
+both signature and encryption schemes via the EVP interface.
+
+When doing the B<SM2> signature algorithm, it requires a distinguishing identifier
+to form the message prefix which is hashed before the real message is hashed.
+
+=head1 NOTES
+
+B<SM2> signatures can be generated by using the 'DigestSign' series of APIs, for
+instance, EVP_DigestSignInit(), EVP_DigestSignUpdate() and EVP_DigestSignFinal().
+Ditto for the verification process by calling the 'DigestVerify' series of APIs.
+
+There are several special steps that need to be done before computing an B<SM2>
+signature.
+
+The B<EVP_PKEY> structure will default to using ECDSA for signatures when it is
+created. It should be set to B<EVP_PKEY_SM2> by calling:
+
+ EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2);
+
+Then an ID should be set by calling:
+
+ EVP_PKEY_CTX_set1_id(pctx, id, id_len);
+
+When calling the EVP_DigestSignInit() or EVP_DigestVerifyInit() functions, a
+pre-allocated B<EVP_PKEY_CTX> should be assigned to the B<EVP_MD_CTX>. This is
+done by calling:
+
+ EVP_MD_CTX_set_pkey_ctx(mctx, pctx);
+
+And normally there is no need to pass a B<pctx> parameter to EVP_DigestSignInit()
+or EVP_DigestVerifyInit() in such a scenario.
+
+=head1 EXAMPLE
+
+This example demonstrates the calling sequence for using an B<EVP_PKEY> to verify
+a message with the SM2 signature algorithm and the SM3 hash algorithm:
+
+ #include <openssl/evp.h>
+
+ /* obtain an EVP_PKEY using whatever methods... */
+ EVP_PKEY_set_alias_type(pkey, EVP_PKEY_SM2);
+ mctx = EVP_MD_CTX_new();
+ pctx = EVP_PKEY_CTX_new(pkey, NULL);
+ EVP_PKEY_CTX_set1_id(pctx, id, id_len);
+ EVP_MD_CTX_set_pkey_ctx(mctx, pctx);;
+ EVP_DigestVerifyInit(mctx, NULL, EVP_sm3(), NULL, pkey);
+ EVP_DigestVerifyUpdate(mctx, msg, msg_len);
+ EVP_DigestVerifyFinal(mctx, sig, sig_len)
+
+=head1 SEE ALSO
+
+L<EVP_PKEY_CTX_new(3)>,
+L<EVP_PKEY_set_alias_type(3)>,
+L<EVP_DigestSignInit(3)>,
+L<EVP_DigestVerifyInit(3)>,
+L<EVP_PKEY_CTX_set1_id(3)>,
+L<EVP_MD_CTX_set_pkey_ctx(3)>
+
+=head1 COPYRIGHT
+
+Copyright 2018 The OpenSSL Project Authors. All Rights Reserved.
+
+Licensed under the OpenSSL license (the "License").  You may not use
+this file except in compliance with the License.  You can obtain a copy
+in the file LICENSE in the source distribution or at
+L<https://www.openssl.org/source/license.html>.
+
+=cut

doc/man7/ssl.pod

@@ -128,10 +128,12 @@ See L<SSL_CTX_new(3)> for details.
 =item const SSL_METHOD *B<TLS_client_method>(void);
 
 Constructor for the I<version-flexible> SSL_METHOD structure for clients.
+Must be used to support the TLSv1.3 protocol.
 
 =item const SSL_METHOD *B<TLS_server_method>(void);
 
 Constructor for the I<version-flexible> SSL_METHOD structure for servers.
+Must be used to support the TLSv1.3 protocol.
 
 =item const SSL_METHOD *B<TLSv1_2_method>(void);