More detailed documentation of future ideas
parent
e97c8b5afb
commit
6183b05c3d
@ -0,0 +1,183 @@
|
||||
.. index:: ideas
|
||||
|
||||
============
|
||||
Future ideas
|
||||
============
|
||||
|
||||
Some ideas for future implementations have already be written in the
|
||||
:ref:`conclusions section <general-conclusion>` of the general observations.
|
||||
This section gives more insight into the rationale behind these ideas.
|
||||
|
||||
UTF-8 handling for everything
|
||||
=============================
|
||||
|
||||
The world today is not only made of anglo-american and western european
|
||||
countries. `Unicode`_ is the solution to support all languages of the world.
|
||||
UTF-8 is a binary representation of Unicode that is compatible with ASCII and
|
||||
a subset of ISO-8859-1.
|
||||
|
||||
.. _Unicode: https://home.unicode.org/
|
||||
|
||||
Implications
|
||||
------------
|
||||
|
||||
- database needs to be migrated but should be straightforward
|
||||
- reimplementation in the signer, signer_client, web application, test manager
|
||||
and probably CATS
|
||||
|
||||
Proper ASN.1 handling
|
||||
=====================
|
||||
|
||||
Current PKI standards like :rfc:`5280` or the `CAB forum's baseline requirements`_
|
||||
mandate the integrity of the `ASN.1`_ objects in certificates. These standards
|
||||
move towards UTF8String representation of names and have some strict validation
|
||||
rules that can only be implemented by handling ASN.1 directly.
|
||||
|
||||
.. _ASN.1: https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx
|
||||
.. _CAB forum's baseline requirements: https://cabforum.org/baseline-requirements/
|
||||
|
||||
Implications
|
||||
------------
|
||||
|
||||
- database migration or acceptance of old and new data formats
|
||||
- clean separation of DNs (Subject DN and Issuer DN) and extensions (especially
|
||||
SubjectAlternativeName)
|
||||
- reimplementation in signer, signer_client and web application
|
||||
- changes to the signer protocol
|
||||
|
||||
Cleaner separation between components
|
||||
=====================================
|
||||
|
||||
Separation of components improves the maintainability and reduces hard
|
||||
dependencies between parts of the system. Each data store (filesystem, database
|
||||
or message bus) should only belong to one component. All other components should
|
||||
access required data by using :term:`API`s provided by the application that
|
||||
owns the data store.
|
||||
|
||||
Implications
|
||||
------------
|
||||
|
||||
- implementation of APIs
|
||||
- decoupling via messaging (either publish/subscribe, queues or event streaming)
|
||||
- restrict access to data stores via file system permissions, ACLs in databases
|
||||
or network separation
|
||||
|
||||
Modern web application standards
|
||||
================================
|
||||
|
||||
To reach less technically affine people we need to implement a more modern web
|
||||
application. If properly implemented this will also improve access for people
|
||||
with disabilities.
|
||||
|
||||
We should try to implement some functionality as APIs so that they can be used
|
||||
via both the classical web browser as well es API clients like mobile
|
||||
applications or command line interfaces.
|
||||
|
||||
Implications
|
||||
------------
|
||||
|
||||
- rewrite the web application
|
||||
|
||||
Secure development practices
|
||||
============================
|
||||
|
||||
There are some established industry best practices for secure software
|
||||
development. Implementing security as an afterthought is costly (for us
|
||||
primarily in terms of time). Some documents that we should consider adopting
|
||||
are referenced in:
|
||||
|
||||
- https://en.wikipedia.org/wiki/Secure_by_design
|
||||
- https://en.wikipedia.org/wiki/Application_security
|
||||
|
||||
Implications
|
||||
------------
|
||||
|
||||
- consider during application rewrite
|
||||
|
||||
Continuous integration
|
||||
======================
|
||||
|
||||
We should aim for continuous integration of changes to avoid long living feature
|
||||
branches. Branches of contributors should be built and tested automatically as
|
||||
part of the review process. If we implement automated tests we could gain
|
||||
confidence that changes do not introduce regressions.
|
||||
|
||||
Documented and automated deployment
|
||||
===================================
|
||||
|
||||
The deployment of the software should be documented in form of step by step
|
||||
instructions, test procedure descriptions and checklists.
|
||||
|
||||
When these instructions are sufficiently complete we can automate the deployment
|
||||
and could also implement continuous deployment of test environments.
|
||||
|
||||
.. note::
|
||||
This would require a more sophisticated version control approach were we have
|
||||
integration branches for our test environments
|
||||
|
||||
.. note::
|
||||
Automated deployment of production environments is out of scope at the moment
|
||||
because it would probably break the required separation of responsible teams
|
||||
(software development, software assessment, infrastructure admin and critical
|
||||
admin).
|
||||
|
||||
.. blockdiag::
|
||||
:caption: Continous Integration / Deployment
|
||||
:desctable:
|
||||
|
||||
blockdiag {
|
||||
Checkout -> Build -> Test -> Deploy -> Configure;
|
||||
Checkout [description = "get data from code repository"];
|
||||
Build [description = "build a release artifact including all required resources like static assets, translation files, etc."];
|
||||
Test [description = "run test suite or ask people to manually install and test the release package"];
|
||||
Deploy [description = "put the release bundle on a target test or production environment"];
|
||||
Configure [description = "take the necessary steps to make the application work in the target environment"];
|
||||
}
|
||||
|
||||
Configuration
|
||||
-------------
|
||||
|
||||
Configuration should be separated from the actual code. Ideally configuration is
|
||||
done via a configuration management system and is stored in version control too.
|
||||
|
||||
It is a good practice to have the configuration repository separated from the
|
||||
code repository.
|
||||
|
||||
New signer protocol
|
||||
===================
|
||||
|
||||
Signer protocol with better binary support, strong consistency checks and
|
||||
testability
|
||||
|
||||
.. index:: signer
|
||||
|
||||
New signer features
|
||||
===================
|
||||
|
||||
Signer support for requesting CA certificates and GPG public keys used for
|
||||
signing to allow fully automated bootstrapping of the signer client and web
|
||||
application
|
||||
|
||||
New web application features
|
||||
============================
|
||||
|
||||
ACME support
|
||||
------------
|
||||
|
||||
Identity provider
|
||||
-----------------
|
||||
|
||||
Cross cutting concerns
|
||||
======================
|
||||
|
||||
.. index:: tests
|
||||
|
||||
Automated tests
|
||||
---------------
|
||||
|
||||
automated tests for critical functionality
|
||||
|
||||
.. index:: logging
|
||||
|
||||
Consistent logging
|
||||
------------------
|
||||
Loading…
Reference in New Issue