Replace HTML files by redirection to the official spec hosting
Use HTML redirects since we can't do HTTP redirects on GitHub pages.
Signed-off-by: Gilles Peskine <Gilles.Peskine@arm.com>
diff --git a/docs/1.0.1/html/overview/conventions.html b/docs/1.0.1/html/overview/conventions.html
index 76beba2..7523c89 100644
--- a/docs/1.0.1/html/overview/conventions.html
+++ b/docs/1.0.1/html/overview/conventions.html
@@ -1,372 +1 @@
-
-<!DOCTYPE html>
-
-<html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <meta charset="utf-8" />
- <title>5. Library conventions — PSA Crypto API 1.0.1 documentation</title>
- <link rel="stylesheet" href="../_static/alabaster.css" type="text/css" />
- <link rel="stylesheet" href="../_static/pygments.css" type="text/css" />
- <script type="text/javascript" id="documentation_options" data-url_root="../" src="../_static/documentation_options.js"></script>
- <script type="text/javascript" src="../_static/jquery.js"></script>
- <script type="text/javascript" src="../_static/underscore.js"></script>
- <script type="text/javascript" src="../_static/doctools.js"></script>
- <script type="text/javascript" src="../_static/language_data.js"></script>
- <link rel="author" title="About these documents" href="../about.html" />
- <link rel="index" title="Index" href="../genindex.html" />
- <link rel="search" title="Search" href="../search.html" />
- <link rel="next" title="6. Implementation considerations" href="implementation.html" />
- <link rel="prev" title="4. Sample architectures" href="sample-arch.html" />
-
- <link rel="stylesheet" href="../_static/custom.css" type="text/css" />
-
-
- <meta name="viewport" content="width=device-width, initial-scale=0.9, maximum-scale=0.9" />
-
- </head><body>
-
-
- <div class="document">
- <div class="documentwrapper">
- <div class="bodywrapper">
-
-
- <div class="body" role="main">
-
- <div class="section" id="library-conventions">
-<h1>5. Library conventions</h1>
-<div class="section" id="error-handling">
-<h2>5.1. Error handling</h2>
-<div class="section" id="return-status">
-<h3>5.1.1. Return status</h3>
-<p>Almost all functions return a status indication of type <a class="reference internal" href="../api/library/status.html#c.psa_status_t" title="psa_status_t"><code class="xref any c c-type docutils literal notranslate"><span class="pre">psa_status_t</span></code></a>. This
-is an enumeration of integer values, with <code class="docutils literal notranslate"><span class="pre">0</span></code> (<a class="reference internal" href="../api/library/status.html#c.PSA_SUCCESS" title="PSA_SUCCESS"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_SUCCESS</span></code></a>) indicating
-successful operation and other values indicating errors. The exceptions are
-functions which only access objects that are intended to be implemented as
-simple data structures. Such functions cannot fail and either return
-<code class="docutils literal notranslate"><span class="pre">void</span></code> or a data value.</p>
-<p>Unless specified otherwise, if multiple error conditions apply, an
-implementation is free to return any of the applicable error codes. The choice
-of error code is considered an implementation quality issue. Different
-implementations can make different choices, for example to favor code size over
-ease of debugging or vice versa.</p>
-<p>If the behavior is undefined, for example, if a function receives an invalid
-pointer as a parameter, this specification makes no guarantee that the function
-will return an error. Implementations are encouraged to return an error or halt
-the application in a manner that is appropriate for the platform if the
-undefined behavior condition can be detected. However, application developers need to be aware that undefined behavior conditions cannot be detected in general.</p>
-</div>
-<div class="section" id="behavior-on-error">
-<h3>5.1.2. Behavior on error</h3>
-<p>All function calls must be implemented atomically:</p>
-<ul class="simple">
-<li><p>When a function returns a type other than <a class="reference internal" href="../api/library/status.html#c.psa_status_t" title="psa_status_t"><code class="xref any c c-type docutils literal notranslate"><span class="pre">psa_status_t</span></code></a>, the requested
-action has been carried out.</p></li>
-<li><p>When a function returns the status <a class="reference internal" href="../api/library/status.html#c.PSA_SUCCESS" title="PSA_SUCCESS"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_SUCCESS</span></code></a>, the requested action has
-been carried out.</p></li>
-<li><p>When a function returns another status of type <a class="reference internal" href="../api/library/status.html#c.psa_status_t" title="psa_status_t"><code class="xref any c c-type docutils literal notranslate"><span class="pre">psa_status_t</span></code></a>, no action
-has been carried out. The content of the output parameters is undefined, but
-otherwise the state of the system has not changed, except as described below.</p></li>
-</ul>
-<p>In general, functions that modify the system state, for example, creating or
-destroying a key, must leave the system state unchanged if they return an error
-code. There are specific conditions that can result in different behavior:</p>
-<ul class="simple">
-<li><p>The status <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_BAD_STATE" title="PSA_ERROR_BAD_STATE"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_ERROR_BAD_STATE</span></code></a> indicates that a parameter was not in a
-valid state for the requested action. This parameter might have been modified
-by the call and is now in an undefined state. The only valid action on an
-object in an undefined state is to abort it with the appropriate
-<code class="docutils literal notranslate"><span class="pre">psa_abort_xxx()</span></code> function.</p></li>
-<li><p>The status <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_INSUFFICIENT_DATA" title="PSA_ERROR_INSUFFICIENT_DATA"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_ERROR_INSUFFICIENT_DATA</span></code></a> indicates that a key
-derivation object has reached its maximum capacity. The key derivation
-operation might have been modified by the call. Any further attempt to obtain
-output from the key derivation operation will return
-<a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_INSUFFICIENT_DATA" title="PSA_ERROR_INSUFFICIENT_DATA"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_ERROR_INSUFFICIENT_DATA</span></code></a>.</p></li>
-<li><p>The status <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_COMMUNICATION_FAILURE" title="PSA_ERROR_COMMUNICATION_FAILURE"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_ERROR_COMMUNICATION_FAILURE</span></code></a> indicates that the
-communication between the application and the cryptoprocessor has broken
-down. In this case, the cryptoprocessor must either finish the requested
-action successfully, or interrupt the action and roll back the system to its
-original state. Because it is often impossible to report the outcome to the
-application after a communication failure, this specification does not
-provide a way for the application to determine whether the action was
-successful.</p></li>
-<li><p>The statuses <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_STORAGE_FAILURE" title="PSA_ERROR_STORAGE_FAILURE"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_ERROR_STORAGE_FAILURE</span></code></a>, <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_DATA_CORRUPT" title="PSA_ERROR_DATA_CORRUPT"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_ERROR_DATA_CORRUPT</span></code></a>, <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_HARDWARE_FAILURE" title="PSA_ERROR_HARDWARE_FAILURE"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_ERROR_HARDWARE_FAILURE</span></code></a>
-and <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_CORRUPTION_DETECTED" title="PSA_ERROR_CORRUPTION_DETECTED"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_ERROR_CORRUPTION_DETECTED</span></code></a> might indicate data corruption in the
-system state. When a function returns one of these statuses, the system state
-might have changed from its previous state before the function call, even
-though the function call failed.</p></li>
-<li><p>Some system states cannot be rolled back, for example, the internal state of
-the random number generator or the content of access logs.</p></li>
-</ul>
-<p>Unless otherwise documented, the content of output parameters is not defined
-when a function returns a status other than <a class="reference internal" href="../api/library/status.html#c.PSA_SUCCESS" title="PSA_SUCCESS"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_SUCCESS</span></code></a>. It is recommended
-that implementations set output parameters to safe defaults to avoid leaking
-confidential data and limit risk, in case an application does not properly
-handle all errors.</p>
-</div>
-</div>
-<div class="section" id="parameter-conventions">
-<h2>5.2. Parameter conventions</h2>
-<div class="section" id="pointer-conventions">
-<h3>5.2.1. Pointer conventions</h3>
-<p>Unless explicitly stated in the documentation of a function, all pointers must
-be valid pointers to an object of the specified type.</p>
-<p>A parameter is considered a <strong>buffer</strong> if it points to an array of bytes. A
-buffer parameter always has the type <code class="docutils literal notranslate"><span class="pre">uint8_t</span> <span class="pre">*</span></code> or <code class="docutils literal notranslate"><span class="pre">const</span> <span class="pre">uint8_t</span> <span class="pre">*</span></code>, and
-always has an associated parameter indicating the size of the array. Note that a
-parameter of type <code class="docutils literal notranslate"><span class="pre">void</span> <span class="pre">*</span></code> is never considered a buffer.</p>
-<p>All parameters of pointer type must be valid non-null pointers, unless the
-pointer is to a buffer of length <code class="docutils literal notranslate"><span class="pre">0</span></code> or the function’s documentation
-explicitly describes the behavior when the pointer is null. Passing a null
-pointer as a function parameter in other cases is expected to abort the caller
-on implementations where this is the normal behavior for a null pointer
-dereference.</p>
-<p>Pointers to input parameters can be in read-only memory. Output parameters must
-be in writable memory. Output parameters that are not buffers must also be
-readable, and the implementation must be able to write to a non-buffer output
-parameter and read back the same value, as explained in the
-<a class="reference internal" href="#stability-of-parameters"><span class="secref">Stability of parameters</span></a> section.</p>
-</div>
-<div class="section" id="input-buffer-sizes">
-<h3>5.2.2. Input buffer sizes</h3>
-<p>For input buffers, the parameter convention is:</p>
-<dl class="simple">
-<dt><code class="docutils literal notranslate"><span class="pre">const</span> <span class="pre">uint8_t</span> <span class="pre">*foo</span></code></dt><dd><p>Pointer to the first byte of the data. The pointer
-can be invalid if the buffer size is <code class="docutils literal notranslate"><span class="pre">0</span></code>.</p>
-</dd>
-<dt><code class="docutils literal notranslate"><span class="pre">size_t</span> <span class="pre">foo_length</span></code></dt><dd><p>Size of the buffer in bytes.</p>
-</dd>
-</dl>
-<p>The interface never uses input-output buffers.</p>
-</div>
-<div class="section" id="output-buffer-sizes">
-<h3>5.2.3. Output buffer sizes</h3>
-<p>For output buffers, the parameter convention is:</p>
-<dl class="simple">
-<dt><code class="docutils literal notranslate"><span class="pre">uint8_t</span> <span class="pre">*foo</span></code></dt><dd><p>Pointer to the first byte of the data. The pointer can be
-invalid if the buffer size is <code class="docutils literal notranslate"><span class="pre">0</span></code>.</p>
-</dd>
-<dt><code class="docutils literal notranslate"><span class="pre">size_t</span> <span class="pre">foo_size</span></code></dt><dd><p>The size of the buffer in bytes.</p>
-</dd>
-<dt><code class="docutils literal notranslate"><span class="pre">size_t</span> <span class="pre">*foo_length</span></code></dt><dd><p>On successful return, contains the length of the
-output in bytes.</p>
-</dd>
-</dl>
-<p>The content of the data buffer and of <code class="docutils literal notranslate"><span class="pre">*foo_length</span></code> on errors is unspecified,
-unless explicitly mentioned in the function description. They might be unmodified
-or set to a safe default. On successful completion, the content of the buffer
-between the offsets <code class="docutils literal notranslate"><span class="pre">*foo_length</span></code> and <code class="docutils literal notranslate"><span class="pre">foo_size</span></code> is also unspecified.</p>
-<p>Functions return <a class="reference internal" href="../api/library/status.html#c.PSA_ERROR_BUFFER_TOO_SMALL" title="PSA_ERROR_BUFFER_TOO_SMALL"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_ERROR_BUFFER_TOO_SMALL</span></code></a> if the buffer size is
-insufficient to carry out the requested operation. The interface defines macros
-to calculate a sufficient buffer size for each operation that has an output
-buffer. These macros return compile-time constants if their arguments are
-compile-time constants, so they are suitable for static or stack allocation.
-Refer to an individual function’s documentation for the associated output size
-macro.</p>
-<p>Some functions always return exactly as much data as the size of the output
-buffer. In this case, the parameter convention changes to:</p>
-<dl class="simple">
-<dt><code class="docutils literal notranslate"><span class="pre">uint8_t</span> <span class="pre">*foo</span></code></dt><dd><p>Pointer to the first byte of the output. The pointer can be
-invalid if the buffer size is <code class="docutils literal notranslate"><span class="pre">0</span></code>.</p>
-</dd>
-<dt><code class="docutils literal notranslate"><span class="pre">size_t</span> <span class="pre">foo_length</span></code></dt><dd><p>The number of bytes to return in <code class="docutils literal notranslate"><span class="pre">foo</span></code> if
-successful.</p>
-</dd>
-</dl>
-</div>
-<div class="section" id="overlap-between-parameters">
-<h3>5.2.4. Overlap between parameters</h3>
-<p>Output parameters that are not buffers must not overlap with any input buffer or
-with any other output parameter. Otherwise, the behavior is undefined.</p>
-<p>Output buffers can overlap with input buffers. In this event, the implementation
-must return the same result as if the buffers did not overlap. The
-implementation must behave as if it had copied all the inputs into temporary
-memory, as far as the result is concerned. However, it is possible that overlap
-between parameters will affect the performance of a function call. Overlap might
-also affect memory management security if the buffer is located in memory that
-the caller shares with another security context, as described in the
-<a class="reference internal" href="#stability-of-parameters"><span class="secref">Stability of parameters</span></a> section.</p>
-</div>
-<div class="section" id="stability-of-parameters">
-<span id="id1"></span><h3>5.2.5. Stability of parameters</h3>
-<p>In some environments, it is possible for the content of a parameter to change
-while a function is executing. It might also be possible for the content of an
-output parameter to be read before the function terminates. This can happen if
-the application is multithreaded. In some implementations, memory can be shared
-between security contexts, for example, between tasks in a multitasking
-operating system, between a user land task and the kernel, or between the
-Non-secure world and the Secure world of a trusted execution environment.</p>
-<p>This section describes the assumptions that an implementation can make about
-function parameters, and the guarantees that the implementation must provide
-about how it accesses parameters.</p>
-<p>Parameters that are not buffers are assumed to be under the caller’s full
-control. In a shared memory environment, this means that the parameter must be
-in memory that is exclusively accessible by the application. In a multithreaded
-environment, this means that the parameter must not be modified during the
-execution, and the value of an output parameter is undetermined until the
-function returns. The implementation can read an input parameter that is not a
-buffer multiple times and expect to read the same data. The implementation can
-write to an output parameter that is not a buffer and expect to read back the
-value that it last wrote. The implementation has the same permissions on buffers
-that overlap with a buffer in the opposite direction.</p>
-<p>In an environment with multiple threads or with shared memory, the
-implementation carefully accesses non-overlapping buffer parameters in order to
-prevent any security risk resulting from the content of the buffer being
-modified or observed during the execution of the function. In an input buffer
-that does not overlap with an output buffer, the implementation reads each byte
-of the input once, at most. The implementation does not read from an output
-buffer that does not overlap with an input buffer. Additionally, the
-implementation does not write data to a non-overlapping output buffer if this
-data is potentially confidential and the implementation has not yet verified
-that outputting this data is authorized.</p>
-<p>Unless otherwise specified, the implementation must not keep a reference to any
-parameter once a function call has returned.</p>
-</div>
-</div>
-<div class="section" id="key-types-and-algorithms">
-<h2>5.3. Key types and algorithms</h2>
-<p>Types of cryptographic keys and cryptographic algorithms are encoded separately.
-Each is encoded by using an integral type: <a class="reference internal" href="../api/keys/types.html#c.psa_key_type_t" title="psa_key_type_t"><code class="xref any c c-type docutils literal notranslate"><span class="pre">psa_key_type_t</span></code></a> and
-<a class="reference internal" href="../api/ops/algorithms.html#c.psa_algorithm_t" title="psa_algorithm_t"><code class="xref any c c-type docutils literal notranslate"><span class="pre">psa_algorithm_t</span></code></a>, respectively.</p>
-<p>There is some overlap in the information conveyed by key types and algorithms.
-Both types contain enough information, so that the meaning of an algorithm type
-value does not depend on what type of key it is used with, and vice versa.
-However, the particular instance of an algorithm might depend on the key type. For
-example, the algorithm <a class="reference internal" href="../api/ops/aead.html#c.PSA_ALG_GCM" title="PSA_ALG_GCM"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_ALG_GCM</span></code></a> can be instantiated as any AEAD algorithm
-using the GCM mode over a block cipher. The underlying block cipher is
-determined by the key type.</p>
-<p>Key types do not encode the key size. For example, AES-128, AES-192 and AES-256
-share a key type <a class="reference internal" href="../api/keys/types.html#c.PSA_KEY_TYPE_AES" title="PSA_KEY_TYPE_AES"><code class="xref any c c-macro docutils literal notranslate"><span class="pre">PSA_KEY_TYPE_AES</span></code></a>.</p>
-<div class="section" id="structure-of-key-and-algorithm-types">
-<h3>5.3.1. Structure of key and algorithm types</h3>
-<p>Both types use a partial bitmask structure, which allows the analysis and
-building of values from parts. However, the interface defines constants, so that
-applications do not need to depend on the encoding, and an implementation might
-only care about the encoding for code size optimization.</p>
-<p>The encodings follows a few conventions:</p>
-<ul class="simple">
-<li><p>The highest bit is a vendor flag. Current and future versions of this
-specification will only define values where this bit is clear.
-Implementations that wish to define additional implementation-specific values
-must use values where this bit is set, to avoid conflicts with future
-versions of this specification.</p></li>
-<li><p>The next few highest bits indicate the corresponding algorithm category:
-hash, MAC, symmetric cipher, asymmetric encryption, and so on.</p></li>
-<li><p>The following bits identify a family of algorithms in a category-dependent
-manner.</p></li>
-<li><p>In some categories and algorithm families, the lowest-order bits indicate a
-variant in a systematic way. For example, algorithm families that are
-parametrized around a hash function encode the hash in the 8 lowest bits.</p></li>
-</ul>
-</div>
-</div>
-<div class="section" id="concurrent-calls">
-<span id="concurrency"></span><h2>5.4. Concurrent calls</h2>
-<p>In some environments, an application can make calls to the PSA crypto API in
-separate threads. In such an environment, <em>concurrent calls</em> are two or more
-calls to the API whose execution can overlap in time.</p>
-<p>Concurrent calls are performed correctly, as if the calls were executed in
-sequence, provided that they obey the following constraints:</p>
-<ul class="simple">
-<li><p>There is no overlap between an output parameter of one call and an input or
-output parameter of another call. Overlap between input parameters is
-permitted.</p></li>
-<li><p>A call to destroy a key must not overlap with a concurrent call to any of
-the following functions:</p>
-<ul>
-<li><p>Any call where the same key identifier is a parameter to the call.</p></li>
-<li><p>Any call in a multi-part operation, where the same key identifier was
-used as a parameter to a previous step in the multi-part operation.</p></li>
-</ul>
-</li>
-<li><p>Concurrent calls must not use the same operation object.</p></li>
-</ul>
-<p>If any of these constraints are violated, the behavior is undefined.</p>
-<p>If the application modifies an input parameter while a function call is in
-progress, the behavior is undefined.</p>
-<p>Individual implementations can provide additional guarantees.</p>
-</div>
-</div>
-
-
- </div>
-
- </div>
- </div>
- <div class="sphinxsidebar" role="navigation" aria-label="main navigation">
- <div class="sphinxsidebarwrapper"><h3><a href="../index.html"><b>PSA Crypto API</b></a></h3>
-IHI 0086<br/>
-Non-confidential<br/>
-Version 1.0.1
-<span style="color: red; font-weight: bold;"></span>
-<ul>
-<li class="toctree-l1"><a class="reference internal" href="../about.html">About this document</a></li>
-</ul>
-<ul class="current">
-<li class="toctree-l1"><a class="reference internal" href="intro.html">1. Introduction</a></li>
-<li class="toctree-l1"><a class="reference internal" href="goals.html">2. Design goals</a></li>
-<li class="toctree-l1"><a class="reference internal" href="functionality.html">3. Functionality overview</a></li>
-<li class="toctree-l1"><a class="reference internal" href="sample-arch.html">4. Sample architectures</a></li>
-<li class="toctree-l1 current"><a class="current reference internal" href="#">5. Library conventions</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="#error-handling">5.1. Error handling</a><ul>
-<li class="toctree-l3"><a class="reference internal" href="#return-status">5.1.1. Return status</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#behavior-on-error">5.1.2. Behavior on error</a></li>
-</ul>
-</li>
-<li class="toctree-l2"><a class="reference internal" href="#parameter-conventions">5.2. Parameter conventions</a><ul>
-<li class="toctree-l3"><a class="reference internal" href="#pointer-conventions">5.2.1. Pointer conventions</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#input-buffer-sizes">5.2.2. Input buffer sizes</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#output-buffer-sizes">5.2.3. Output buffer sizes</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#overlap-between-parameters">5.2.4. Overlap between parameters</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#stability-of-parameters">5.2.5. Stability of parameters</a></li>
-</ul>
-</li>
-<li class="toctree-l2"><a class="reference internal" href="#key-types-and-algorithms">5.3. Key types and algorithms</a><ul>
-<li class="toctree-l3"><a class="reference internal" href="#structure-of-key-and-algorithm-types">5.3.1. Structure of key and algorithm types</a></li>
-</ul>
-</li>
-<li class="toctree-l2"><a class="reference internal" href="#concurrent-calls">5.4. Concurrent calls</a></li>
-</ul>
-</li>
-<li class="toctree-l1"><a class="reference internal" href="implementation.html">6. Implementation considerations</a></li>
-<li class="toctree-l1"><a class="reference internal" href="usage.html">7. Usage considerations</a></li>
-<li class="toctree-l1"><a class="reference internal" href="../api/library/index.html">8. Library management reference</a></li>
-<li class="toctree-l1"><a class="reference internal" href="../api/keys/index.html">9. Key management reference</a></li>
-<li class="toctree-l1"><a class="reference internal" href="../api/ops/index.html">10. Cryptographic operation reference</a></li>
-</ul>
-<ul>
-<li class="toctree-l1"><a class="reference internal" href="../appendix/example_header.html">Example header file</a></li>
-<li class="toctree-l1"><a class="reference internal" href="../appendix/specdef_values.html">Example macro implementations</a></li>
-<li class="toctree-l1"><a class="reference internal" href="../appendix/history.html">Changes to the API</a></li>
-</ul>
-<ul>
-<li class="toctree-l1"><a class="reference internal" href="../psa_c-identifiers.html">Index of API elements</a></li>
-</ul>
-<div id="searchbox" style="display: none" role="search">
- <h3 id="searchlabel">Quick search</h3>
- <div class="searchformwrapper">
- <form class="search" action="../search.html" method="get">
- <input type="text" name="q" aria-labelledby="searchlabel" />
- <input type="submit" value="Go" />
- </form>
- </div>
-</div>
-<script type="text/javascript">$('#searchbox').show(0);</script>
- </div>
- </div>
- <div class="clearer"></div>
- </div>
- <div class="footer">
- © 2018-2020, Arm Limited or its affiliates. All rights reserved.
-
- |
- Powered by <a href="http://sphinx-doc.org/">Sphinx 2.1.2</a>
- & <a href="https://github.com/bitprophet/alabaster">Alabaster 0.7.12</a>
-
- </div>
-
-
-
-
- </body>
-</html>
\ No newline at end of file
+<meta http-equiv="Refresh" content="0; url='https://arm-software.github.io/psa-api/crypto/1.0/overview/conventions.html'" />