Describe ideas for signer, testing and web app

2 files changed, 107 insertions, 12 deletions

diff --git a/source/future.rst b/source/future.rst
index 479b3cf..ad50410 100644
--- a/source/future.rst
+++ b/source/future.rst
@@ -142,20 +142,68 @@ 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.
 
+.. index:: signer
+.. index:: protocol
+
 New signer protocol
 ===================
 
-Signer protocol with better binary support, strong consistency checks and
-testability
+To fix the shortcomings of the current signer protocol we need a new
+implementation with better binary support, strong consistency checks and
+testability.
+
+The new signer protocol should:
+
+- use a proper framing mechanism (i.e. `COBS`_) with a clearly recognizable
+  frame separation byte (i.e. ``0x00``)
+- have strong consistency checks (i.e. CRC32)
+- have a well understood / documented payload format (i.e. `msgpack`_)
+  with documented message types
+- have control messages for resetting the connection, requesting
+  redelivery of frames or other control functions (we should look at what
+  existing protocols like PPP do)
+- support binary payloads (DER encoded :term:`ASN.1`)
+- support UTF-8 if necessary
+- allow clients to request meta data about the signer
+
+  - supported protocol versions
+  - used CA certificates
+  - used OpenPGP keys
+  - supported certificate profiles (with some information about their
+    supported key usages and audience)
+
+- provide a way to communicate changes between signers to allow high
+  availability this will need at least
+
+  - announcement of revocations
+  - announcement of new CA certificates
+
+.. _COBS: https://en.wikipedia.org/wiki/Consistent_Overhead_Byte_Stuffing
+.. _msgpack: https://msgpack.org/
 
 .. 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
+Signer support for requesting CA certificates and GPG public keys (see
+discussion in the previous section) used for signing to allow fully automated
+bootstrapping of the signer client and web application.
+
+The signer should support resigning of Sub CA certificates.
+
+Email handling
+==============
+
+All email functionality should properly quote message headers and construct
+proper MIME messages. This is relevant for both the signer_client and web
+application(s).
+
+We should not implement email handling ourselves. If we decide to use
+`Go`_ we should look at the `Gomail`_ package.
+
+.. _Go: https://golang.org
+.. _Gomail: https://pkg.go.dev/gopkg.in/gomail.v2
 
 New web application features
 ============================
@@ -163,9 +211,32 @@ New web application features
 ACME support
 ------------
 
+The :term:`ACME` protocol has been standardized in :RFC:`8555` and allows
+automated issuing of server certificates. We should provide this functionality
+and document its usage with existing ACME client software.
+
 Identity provider
 -----------------
 
+Our users provide us with identity information and our community verifies this
+information. We already allow to use client certificates issued by our CA to
+give users a way to authenticate using there CAcert verified user attributes.
+
+We could also provide our users a way to use their information in modern web
+authentication / authorization protocols like `OAuth 2`_ and `OpenID Connect`_.
+We would need to implement the necessary endpoints for authentication,
+authorization, user information retrieval and probably client registration.
+We will also need a user interface to revoke access tokens granted to
+applications.
+
+.. _OAuth 2: https://oauth.net/2/
+.. _OpenID Connect: https://openid.net/connect/
+
+A rudimentary version of an :term:`IDP` could be implemented separately and
+could just use information from the client certificates issued by our CA.
+
+We could use OAuth2 or OpenID Connect for our own infrastructure too.
+
 Cross cutting concerns
 ======================
 
@@ -174,7 +245,17 @@ Cross cutting concerns
 Automated tests
 ---------------
 
-automated tests for critical functionality
+All critical functionality should be covered by automated tests. This requires
+the code to be testable by using modern software development techniques like
+dependency injection. We need to have automated tests for at least the
+following:
+
+- signer protocol
+- user registration
+- verification of domains
+- verification of email addresses
+- assurance point calculation
+- ...
 
 .. index:: logging
 
diff --git a/source/glossary.rst b/source/glossary.rst
index ad38a21..ea90274 100644
--- a/source/glossary.rst
+++ b/source/glossary.rst
@@ -4,6 +4,20 @@ Glossary
 
 .. glossary::
 
+   ACME
+     Automated Certificate Management Environment
+
+       A protocol for verifying the ownership of Internet domains and issuing
+       X.509 server certificates. Specified in :RFC:`8555`
+
+   API
+     Application programming interface
+
+   ASN.1
+     Abstract syntax notation one
+
+       See https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx
+
    CRL
       Definition from :rfc:`5280`:
 
@@ -15,10 +29,10 @@ Glossary
         revoked certificate is identified in a CRL by its certificate serial
         number.
 
-   API
-     Application programming interface
-
-   ASN.1
-     Abstract syntax notation one
+   IDP
+      Identity provider
 
-       See https://www.itu.int/en/ITU-T/asn1/Pages/introduction.aspx
\ No newline at end of file
+        IDP is a term used in the description auf authentication and
+        authorization protocols. The IDP provides information related to a user.
+        The user usually has a way to approve or deny the use of his
+        information.
\ No newline at end of file