path: root/source
diff options
authorJan Dittberner <>2020-12-29 14:30:34 +0100
committerJan Dittberner <>2020-12-29 14:30:34 +0100
commit178dd980a05789a929eb684b044562b87e621f82 (patch)
tree41d436a951b924b7c11f7ab8e5bd13587e308438 /source
parentfe4d884ca959f1774a19847a27c43df91dd6b83c (diff)
Describe ideas for signer, testing and web app
Diffstat (limited to 'source')
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
+To fix the shortcomings of the current signer protocol we need a new
+implementation with better binary support, strong consistency checks and
+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:
+.. _msgpack:
.. 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
+We should not implement email handling ourselves. If we decide to use
+`Go`_ we should look at the `Gomail`_ package.
+.. _Go:
+.. _Gomail:
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
+.. _OAuth 2:
+.. _OpenID 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
+- 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::
+ Automated Certificate Management Environment
+ A protocol for verifying the ownership of Internet domains and issuing
+ X.509 server certificates. Specified in :RFC:`8555`
+ Application programming interface
+ ASN.1
+ Abstract syntax notation one
+ See
Definition from :rfc:`5280`:
@@ -15,10 +29,10 @@ Glossary
revoked certificate is identified in a CRL by its certificate serial
- Application programming interface
- ASN.1
- Abstract syntax notation one
+ Identity provider
- See \ 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