Future ideas

Some ideas for future implementations have already be written in the conclusions section 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.

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.

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 APIs 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:

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).

Continous Integration / Deployment

Name

Description

Checkout

get data from code repository

Build

build a release artifact including all required resources like static assets, translation files, etc.

Test

run test suite or ask people to manually install and test the release package

Deploy

put the release bundle on a target test or production environment

Configure

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

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 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

New signer features

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.

New web application features

ACME support

The 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.

A rudimentary version of an 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.

Client certificate enrollment in browser

The ancient keygen tag is not implemented by modern browsers and needs a replacement to allow easy enrollment of client certificates for users that are not capable to use external tools. There is #1417 filed by affected users.

There are JavaScript libraries like https://pkijs.org/ and https://github.com/digitalbazaar/forge that support the cryptographic operations.

There are already two prototype implementations by Bernhard and Jan that could be integrated with the current or a new future web application.

Cross cutting concerns

Automated tests

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

  • …

Consistent logging

Our applications should log in a consistent format so that logs can be aggregated this is especially important with distributed applications.

Log information should consist of at least the following information

  • Timestamp (same timezone on all machines, ideally UTC)

  • Log level (the level definition should be consistent)

  • Source of the log (code file / module and if possible line)

  • Error code (if an error occurred)

  • Request identifier

  • Message

  • Traceback / stacktrace in case of unhandled errors