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/goals.html b/docs/1.0.1/html/overview/goals.html
index 02bd580..277450a 100644
--- a/docs/1.0.1/html/overview/goals.html
+++ b/docs/1.0.1/html/overview/goals.html
@@ -1,286 +1 @@
-
-<!DOCTYPE html>
-
-<html xmlns="http://www.w3.org/1999/xhtml">
- <head>
- <meta charset="utf-8" />
- <title>2. Design goals — 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="3. Functionality overview" href="functionality.html" />
- <link rel="prev" title="1. Introduction" href="intro.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="design-goals">
-<span id="id1"></span><h1>2. Design goals</h1>
-<div class="section" id="suitable-for-constrained-devices">
-<h2>2.1. Suitable for constrained devices</h2>
-<p>The interface is suitable for a vast range of devices: from special-purpose
-cryptographic processors that process data with a built-in key, to constrained
-devices running custom application code, such as microcontrollers, and
-multi-application devices, such as servers. Consequentially, the interface is
-scalable and modular.</p>
-<ul class="simple">
-<li><p><em>Scalable</em>: devices only need to implement the functionality that they will
-use.</p></li>
-<li><p><em>Modular</em>: larger devices implement larger subsets of the same interface,
-rather than different interfaces.</p></li>
-</ul>
-<p>In this interface, all operations on unbounded amounts of data
-allow <em>multi-part</em> processing, as long as the calculations on the data are
-performed in a streaming manner. This means that the application does not need
-to store the whole message in memory at one time. As a result, this
-specification is suitable for very constrained devices, including those where
-memory is very limited.</p>
-<p>Memory outside the keystore boundary is managed by the application. An
-implementation of the interface is not required to retain any state between
-function calls, apart from the content of the keystore and other data that must
-be kept inside the keystore security boundary.</p>
-<p>The interface does not expose the representation of keys and intermediate data,
-except when required for interchange. This allows each implementation to choose
-optimal data representations. Implementations with multiple components are also
-free to choose which memory area to use for internal data.</p>
-</div>
-<div class="section" id="a-keystore-interface">
-<h2>2.2. A keystore interface</h2>
-<p>The specification allows cryptographic operations to be performed on a key to
-which the application does not have direct access. Except where required for
-interchange, applications access all keys indirectly, by an identifier. The key
-material corresponding to that identifier can reside inside a security boundary
-that prevents it from being extracted, except as permitted by a policy that is
-defined when the key is created.</p>
-</div>
-<div class="section" id="optional-isolation">
-<span id="isolation"></span><h2>2.3. Optional isolation</h2>
-<p>Implementations can isolate the cryptoprocessor from the calling application,
-and can further isolate multiple calling applications. The interface allows the
-implementation to be separated between a frontend and a backend. In an isolated
-implementation, the frontend is the part of the implementation that is located
-in the same isolation boundary as the application, which the application
-accesses by function calls. The backend is the part of the implementation that
-is located in a different environment, which is protected from the frontend.
-Various technologies can provide protection, for example:</p>
-<ul class="simple">
-<li><p>Process isolation in an operating system.</p></li>
-<li><p>Partition isolation, either with a virtual machine or a partition manager.</p></li>
-<li><p>Physical separation between devices.</p></li>
-</ul>
-<p>Communication between the frontend and backend is beyond the scope of this
-specification.</p>
-<p>In an isolated implementation, the backend can serve more than one
-implementation instance. In this case, a single backend communicates with
-multiple instances of the frontend. The backend must enforce <strong>caller
-isolation</strong>: it must ensure that assets of one frontend are not visible to any
-other frontend. The mechanism for identifying callers is beyond the scope of this
-specification. An implementation that provides caller isolation must document
-the identification mechanism. An implementation that provides isolation must
-document any implementation-specific extension of the API that enables frontend
-instances to share data in any form.</p>
-<p>In summary, there are three types of implementation:</p>
-<ul class="simple">
-<li><p>No isolation: there is no security boundary between the application and the
-cryptoprocessor. For example, a statically or dynamically linked library is
-an implementation with no isolation.</p></li>
-<li><p>Cryptoprocessor isolation: there is a security boundary between the
-application and the cryptoprocessor, but the cryptoprocessor does not
-communicate with other applications. For example, a cryptoprocessor chip that
-is a companion to an application processor is an implementation with
-cryptoprocessor isolation.</p></li>
-<li><p>Caller isolation: there are multiple application instances, with a security
-boundary between the application instances among themselves, as well as
-between the cryptoprocessor and the application instances. For example, a
-cryptography service in a multiprocess environment is an implementation with
-caller and cryptoprocessor isolation.</p></li>
-</ul>
-</div>
-<div class="section" id="choice-of-algorithms">
-<h2>2.4. Choice of algorithms</h2>
-<p>The specification defines a low-level cryptographic interface, where the caller
-explicitly chooses which algorithm and which security parameters they use. This
-is necessary to implement protocols that are inescapable in various use cases.
-The design of the interface enables applications to implement widely-used
-protocols and data exchange formats, as well as custom ones.</p>
-<p>As a consequence, all cryptographic functionality operates according to the
-precise algorithm specified by the caller. However, this does not apply to
-device-internal functionality, which does not involve any form of
-interoperability, such as random number generation. The specification does not
-include generic higher-level interfaces, where the implementation chooses the
-best algorithm for a purpose. However, higher-level libraries can be built on
-top of the PSA Crypto API.</p>
-<p>Another consequence is that the specification permits the use of algorithms, key
-sizes and other parameters that, while known to be insecure, might be necessary to
-support legacy protocols or legacy data. Where major weaknesses are known, the
-algorithm descriptions give applicable warnings. However, the lack of a warning
-both does not and cannot indicate that an algorithm is secure in all circumstances.
-Application developers need to research the security of the protocols and
-algorithms that they plan to use to determine if these meet their requirements.</p>
-<p>The interface facilitates algorithm agility. As a consequence, cryptographic
-primitives are presented through generic functions with a parameter indicating
-the specific choice of algorithm. For example, there is a single function to
-calculate a message digest, which takes a parameter that identifies the specific
-hash algorithm.</p>
-</div>
-<div class="section" id="ease-of-use">
-<h2>2.5. Ease of use</h2>
-<p>The interface is designed to be as user-friendly as possible, given the
-aforementioned constraints on suitability for various types of devices and on
-the freedom to choose algorithms.</p>
-<p>In particular, the code flows are designed to reduce the risk of dangerous
-misuse. The interface is designed in part to make it harder to misuse. Where
-possible, it is designed so that
-typical mistakes result in test failures, rather than subtle security issues.
-Implementations avoid leaking data when a function is called with invalid
-parameters, to the extent allowed by the C language and by implementation size
-constraints.</p>
-</div>
-<div class="section" id="example-use-cases">
-<h2>2.6. Example use cases</h2>
-<p>This section lists some of the use cases that were considered during the design
-of this API. This list is not exhaustive, nor are all implementations required to
-support all use cases.</p>
-<div class="section" id="network-security-tls">
-<h3>2.6.1. Network Security (TLS)</h3>
-<p>The API provides all of the cryptographic primitives needed to establish TLS
-connections.</p>
-</div>
-<div class="section" id="secure-storage">
-<h3>2.6.2. Secure Storage</h3>
-<p>The API provides all primitives related to storage encryption, block or
-file-based, with master encryption keys stored inside a key store.</p>
-</div>
-<div class="section" id="network-credentials">
-<h3>2.6.3. Network Credentials</h3>
-<p>The API provides network credential management inside a key store, for example,
-for X.509-based authentication or pre-shared keys on enterprise networks.</p>
-</div>
-<div class="section" id="device-pairing">
-<h3>2.6.4. Device Pairing</h3>
-<p>The API provides support for key agreement protocols that are often used for
-secure pairing of devices over wireless channels. For example, the pairing of an
-NFC token or a Bluetooth device might use key agreement protocols upon
-first use.</p>
-</div>
-<div class="section" id="secure-boot">
-<h3>2.6.5. Secure Boot</h3>
-<p>The API provides primitives for use during firmware integrity and authenticity
-validation, during a secure or trusted boot process.</p>
-</div>
-<div class="section" id="attestation">
-<h3>2.6.6. Attestation</h3>
-<p>The API provides primitives used in attestation activities. Attestation is the
-ability for a device to sign an array of bytes with a device private key and
-return the result to the caller. There are several use cases; ranging from attestation
-of the device state, to the ability to generate a key pair and prove that it has
-been generated inside a secure key store. The API provides access to the
-algorithms commonly used for attestation.</p>
-</div>
-<div class="section" id="factory-provisioning">
-<h3>2.6.7. Factory Provisioning</h3>
-<p>Most IoT devices receive a unique identity during the factory provisioning
-process, or once they have been deployed to the field. This API provides the APIs necessary for
-populating a device with keys that represent that identity.</p>
-</div>
-</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 current"><a class="current reference internal" href="#">2. Design goals</a><ul>
-<li class="toctree-l2"><a class="reference internal" href="#suitable-for-constrained-devices">2.1. Suitable for constrained devices</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#a-keystore-interface">2.2. A keystore interface</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#optional-isolation">2.3. Optional isolation</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#choice-of-algorithms">2.4. Choice of algorithms</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#ease-of-use">2.5. Ease of use</a></li>
-<li class="toctree-l2"><a class="reference internal" href="#example-use-cases">2.6. Example use cases</a><ul>
-<li class="toctree-l3"><a class="reference internal" href="#network-security-tls">2.6.1. Network Security (TLS)</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#secure-storage">2.6.2. Secure Storage</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#network-credentials">2.6.3. Network Credentials</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#device-pairing">2.6.4. Device Pairing</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#secure-boot">2.6.5. Secure Boot</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#attestation">2.6.6. Attestation</a></li>
-<li class="toctree-l3"><a class="reference internal" href="#factory-provisioning">2.6.7. Factory Provisioning</a></li>
-</ul>
-</li>
-</ul>
-</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"><a class="reference internal" href="conventions.html">5. Library conventions</a></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/goals.html'" />