Tidy up CRL handling by checking for critical extensions when it is

[openssl.git] / CHANGES

diff --git a/CHANGES b/CHANGES
index 054c6a7a7f0b2d6098e34e1e86f442eadcbadf57..93db3118e1e2a1fb84b6444d0dbb159a08d9da64 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -4,6 +4,35 @@
 
  Changes between 0.9.8d and 0.9.9  [xx XXX xxxx]
 
+  *) Add an X509_CRL_METHOD structure to allow CRL processing to be redirected
+     to external functions. This can be used to increase CRL handling 
+     efficiency especially when CRLs are very large by (for example) storing
+     the CRL revoked certificates in a database.
+     [Steve Henson]
+
+  *) Overhaul of by_dir code. Add support for dynamic loading of CRLs so
+     new CRLs added to a directory can be used. New command line option
+     -verify_return_error to s_client and s_server. This causes real errors
+     to be returned by the verify callback instead of carrying on no matter
+     what. This reflects the way a "real world" verify callback would behave.
+     [Steve Henson]
+
+  *) GOST engine, supporting several GOST algorithms and public key formats.
+     Kindly donated by Cryptocom.
+     [Cryptocom]
+
+  *) Partial support for Issuing Distribution Point CRL extension. CRLs
+     partitioned by DP are handled but no indirect CRL or reason partitioning
+     (yet). Complete overhaul of CRL handling: now the most suitable CRL is
+     selected via a scoring technique which handles IDP and AKID in CRLs.
+     [Steve Henson]
+
+  *) New X509_STORE_CTX callbacks lookup_crls() and lookup_certs() which
+     will ultimately be used for all verify operations: this will remove the
+     X509_STORE dependency on certificate verification and allow alternative
+     lookup methods.  X509_STORE based implementations of these two callbacks.
+     [Steve Henson]
+
   *) Allow multiple CRLs to exist in an X509_STORE with matching issuer names.
      Modify get_crl() to find a valid (unexpired) CRL if possible.
      [Steve Henson]
@@ -381,7 +410,8 @@
 
   *) Since 0.9.8b, ciphersuite strings naming explicit ciphersuites
      match only those.  Before that, "AES256-SHA" would be interpreted
-     as a pattern and match "AES128-SHA" too since we currently only
+     as a pattern and match "AES128-SHA" too (since AES128-SHA got
+     the same strength classification in 0.9.7h) as we currently only
      have a single AES bit in the ciphersuite description bitmap.
      That change, however, also applied to ciphersuite strings such as
      "RC4-MD5" that intentionally matched multiple ciphersuites --
@@ -1366,6 +1396,17 @@
      differing sizes.
      [Richard Levitte]
 
+ Changes between 0.9.7k and 0.9.7l  [xx XXX xxxx]
+
+  *) Change ciphersuite string processing so that an explicit
+     ciphersuite selects this one ciphersuite (so that "AES256-SHA"
+     will no longer include "AES128-SHA"), and any other similar
+     ciphersuite (same bitmap) from *other* protocol versions (so that
+     "RC4-MD5" will still include both the SSL 2.0 ciphersuite and the
+     SSL 3.0/TLS 1.0 ciphersuite).  This is a backport combining
+     changes from 0.9.8b and 0.9.8d.
+     [Bodo Moeller]
+
  Changes between 0.9.7j and 0.9.7k  [05 Sep 2006]
 
   *) Avoid PKCS #1 v1.5 signature attack discovered by Daniel Bleichenbacher