Move the roadmap into the handbook so end-users can find it.

1 files changed, 106 insertions, 0 deletions

diff --git a/doc/manual/roadmap.rst b/doc/manual/roadmap.rst
new file mode 100644
index 000000000..03461da20
--- /dev/null
+++ b/doc/manual/roadmap.rst
@@ -0,0 +1,106 @@
+
+Development Roadmap
+========================================
+
+Near Term Plans
+----------------------------------------
+
+Here is an outline for the development plans over the next 12-18 months, as of
+November 2017.
+
+TLS Hardening/Testing
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Leverage TLS-Attacker better, for example using custom workflows. Add tests
+using BoringSSL's hacked Go TLS stack. Add interop testing with OpenSSL as part
+of CI. Improve fuzzer coverage.
+
+Expose TLS to C89 and Python
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Exposing TLS to C would allow for many new applications to make use of Botan.
+
+Interface to PSK and SRP databases
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Adding support for databases storing encrypted PSKs and SRP credentials.
+(PSK database support was added in 2.4.0)
+
+ECC Refactoring
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Refactoring how elliptic curve groups are stored, sharing representation and
+allowing better precomputations (eg precomputing base point multiples).
+[Completed in 2.5.0]
+
+Performance Improvements
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The eventual goal would be performance parity with OpenSSL, but initial
+target is probably more like "no worse than 30% slower for any algorithm".
+
+[Major improvements were made in ECC and RSA performance were made
+between 2.4.0 and 2.7.0, measurement and optimization work is ongoing.]
+
+Elliptic Curve Pairings
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+These are useful in many interesting protocols. Initially BN curves are the main
+target (particularly BN-256 for compatability with Go's bn256 module) but likely
+we'll also want BLS curves.
+
+TLS 1.3
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The RFC process seems to be approaching consensus so hopefully there will be a
+final spec soon. The handshake differences are quite substantial, it's an open
+question how to implement that without overly complicating the existing TLS
+v1.0-v1.2 handshake code. There will also be some API extensions required to
+support 0-RTT data.
+
+Initial work is focused on features which are included in TLS v1.3 but also
+available for TLS v1.2 (such as PSS signatures and FFDHE) as well as
+refactorings which will make the eventual implementation of v1.3 simpler.
+Assuming no source of dedicated funding appears, a full v1.3 implementation will
+likely not available until sometime in 2019.
+
+ASN.1 Redesign
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. note::
+
+   This project has been deferred to 3.x as C++14 extended constexpr
+   will likely make it much easier to implement.
+
+The current ASN.1 library (DER_Encoder/BER_Decoder) does make it
+roughly possible to write C++ code matching the ASN.1 structures. But
+it is not flexible enough for all cases and makes many unnecessary
+copies (and thus memory allocations) of the data as it works.
+
+It would be better to have a system that used (a simple subset of) ASN.1 to
+define the types as well as encoding/decoding logic. Then new types could be
+easily defined. This could also obviate the current code for handling OIDs, and
+allow representing the OIDs using the natural OID tree syntax of ASN.1.
+
+Another important feature will be supporting copy-free streaming decoding. That
+is, given a (ptr,len) range the decoding operation either returns an error
+(throws exception) or else the decoded object plus the number of bytes after ptr
+that contain the object, and it does so without making any allocations or
+copies.
+
+It will probably be easier to be consistently allocation free in machine
+generated code, so the two goals of the redesign seem to reinforce each other.
+
+Longer View (Future Major Release)
+----------------------------------------
+
+Eventually (currently estimated for summer 2019), Botan 3.x will be
+released. This schedule allows some substantial time with Botan 2.x and 3.x
+supported simultaneously, to allow for application switch over.
+
+This version will adopt C++17 and use new std types such as string_view,
+optional, and any, along with adopting memory span and guarded integer
+types. Likely C++17 constexpr will also be leveraged.
+
+In this future 3.x release, all deprecated features/APIs of 2.x will be removed.
+However outside of that, breaking API changes should be relatively minimal.