Merge pull request #146 from eleuzi01/docs_fix

Document fixes

Author: gilles-peskine-arm

kb/assets/mbedtls-stack.png

@@ -10,7 +10,7 @@ Mbed TLS is designed in the portable C language with embedded environments as a
 
 The aim of this tutorial is to show you how to secure your client and server communication with Mbed TLS. The following major components  are involved:
 
-![Mbed TLS Stack.png](https://mbed-tls-docs-images.s3.amazonaws.com/mbedtls-stack.png)
+![Mbed TLS Stack.png](../assets/mbedtls-stack.png)
 
 From the bottom up:
 

kb/how-to/mbedtls-tutorial.md

@@ -6,64 +6,64 @@ All of the settings described on this page are available in `mbedtls_config.h`,
 
 If you need to reduce your memory footprint even more or have related questions, please submit a query in our [support forum](https://forums.mbed.com/c/mbed-tls.html) or open an issue in our [GitHub repository](https://github.com/Mbed-TLS/mbedtls/issues.html). We welcome ideas you may have to further reduce the size in RAM or ROM storage. Please, let us know if you have suggestions for improvements.
 
-# Binary footprint
+## Binary footprint
 
 The binary footprint is the size of the actual file on disk, in the ROM or the flash.
 
-## Minimizing features
+### Minimizing features
 
 By default, Mbed TLS offers several compatibility options and frequently used functionalities. To reduce the footprint, adapt `mbedtls_config.h` to disable the functions that you do not need.
 
-# Memory footprint
+## Memory footprint
 
 The memory footprint is the size of the memory needed at runtime to store variables, contexts and other runtime information.
 
-## Multiple Precision Integers (MPIs)
+### Multiple Precision Integers (MPIs)
 
-### Reducing the maximum size of MPIs
+#### Reducing the maximum size of MPIs
 
 By default, `MBEDTLS_MPI_MAX_SIZE` is set to 1024 bytes (8192 bits). If you know that you will not use larger MPIs, you can reduce `MBEDTLS_MPI_MAX_SIZE`.
 
-### Reducing the MPI window size
+#### Reducing the MPI window size
 
 By default, `mbedtls_mpi_exp_mod()` uses a sliding window size (`MBEDTLS_MPI_WINDOW_SIZE`) of up to 6. You can reduce this value down to 1, which reduces the memory used to the detriment of performance. This only has an effect if you use RSA, DHM or `mbedtls_mpi_exp_mod()` directly.
 
-## Elliptic curves
+### Elliptic curves
 
-### Disabling unused ECP curves
+#### Disabling unused ECP curves
 
 Disabling large elliptic curves that you do not use in your application saves a lot of memory.
 
-### Reducing the maximum ECP bits
+#### Reducing the maximum ECP bits
 
 By default, the `MBEDTLS_ECP_MAX_BITS` is set to `521` to support 521 bits elliptic curves. If you know that you will only use smaller curves, you can safely reduce this value. However, this only has a minimal effect on the memory used.
 
-### Reducing the ECP window size
+#### Reducing the ECP window size
 
 By default, elliptic curve multiplications use a window size (`MBEDTLS_ECP_WINDOW_SIZE`) of up to 6. You can reduce this value down to 2, which reduces the memory used to the detriment of performance. The larger the elliptic curves, the bigger the impact. See also [How to tune ECC resource usage](how-do-i-tune-elliptic-curves-resource-usage.md).
 
-### Disabling the ECP fixed point optimizations
+#### Disabling the ECP fixed point optimizations
 
 If you disable the ECP fixed point optimizations (`MBEDTLS_ECP_FIXED_POINT_OPTIM`), you lose some performance but use less memory. See also [How to tune ECC resource usage](how-do-i-tune-elliptic-curves-resource-usage.md).
 
-## SSL/TLS
+### SSL/TLS
 
-### Reducing the SSL frame buffer
+#### Reducing the SSL frame buffer
 
 By default, Mbed TLS uses a 16 KB frame buffer to hold data for incoming and outgoing frames. This is a TLS standard requirement. If you control both sides of a connection (server and client), you can reduce the maximum frame size to reduce the buffers needed to store the data. The size of this frame is determined by `MBEDTLS_SSL_MAX_CONTENT_LEN`. You can safely reduce this to a more appropriate size (such as 2 KB) if:
 
 * Both sides support the `max_fragment_length` SSL extension (allowing reduction to under 1 KB for the buffers).
 * You know the maximum size that will ever be sent in a single SSL/TLS frame (whether or not you control both sides of the connection).
 
-## AES
+### AES
 
-### Storing AES tables in ROM
+#### Storing AES tables in ROM
 
 By default, our AES implementation uses tables that are computed the first time AES is used and then stored in RAM. You can store them in ROM by enabling `MBEDTLS_AES_ROM_TABLES`. This is a RAM-ROM trade-off.
 
-## X.509
+### X.509
 
-### Parsing X.509 certificates without copying the raw certificate data
+#### Parsing X.509 certificates without copying the raw certificate data
 
 The X.509 CRT parsing APIs `mbedtls_x509_crt_parse()` and `mbedtls_x509_crt_parse_der()` create an internal copy of the raw certificate data passed to them. While this allows you to free or reuse the input buffer, it means the raw certificate data will be twice in memory at some point.
 
@@ -80,7 +80,7 @@ X.509 certificate context. See the [documentation](https://github.com/Mbed-TLS/m
 
 _Example:_ If your own certificate and/or the trusted CA certificates are hardcoded in ROM, you may use `mbedtls_x509_parse_der_nocopy()` to create X.509 certificate contexts from them without an additional copy in RAM.
 
-### Removing a peer certificate after the handshake
+#### Removing a peer certificate after the handshake
 
 By default, Mbed TLS saves a copy of the peer certificate for the lifetime of an SSL session and makes it available through the public API `mbedtls_ssl_get_peer_cert()`. If the application does not need to inspect the peer certificate, disabling the compile-time option `MBEDTLS_SSL_KEEP_PEER_CERTIFICATE` saves RAM as the SSL module will not keep a copy of the peer certificate after the handshake.
 The API `mbedtls_ssl_get_peer_cert()` to obtain the peer certificate is still present, but always returns `NULL`.