CAcert Code Development list.

[Jan Dittberner <jandd AT cacert.org>]

TLDR: I agree with most of what 
hostmaster+cacert-devel AT ip6.li
 wrote but
come to different conclusions.

Am Fri, Feb 05, 2021 at 02:00:51PM +0100 schrieb 
hostmaster+cacert-devel AT ip6.li:
> Am 03.02.21 um 16:53 schrieb Jan Dittberner:
> > All these ideas are nice and fine but after working with the code base and
> > our non-existent development and application deployment processes for a 
> > few
> > months I see no realistic chance of improving the situation without a full
> > rewrite.
> 
> Hi Jan,
> 
> I can follow your considerations and I tried to understand and rewiew some
> parts of code provided at https://git.cacert.org/cacert-devel.git/ My
> opinion is not to use that legacy code for an production environment
> anymore, but this opinion may be caused by my prejudices regarding cgi and
> old fashioned php...

agreed.

> > Preconditions for a rewrite would be:
> > 
> > - specification of what we need (role: requirements management) and how it
> >    will look like (user interface/interaction design)
> 
> Maybe CAB Forum baseline requirements or BSI TR-03145 provides some ideas
> for required processes of a PKI. Interfaces should support these processes.

TR-03145, CAB BR and the PKI RFCs provide the framework for the (small) PKI
part of a CA and would help to specify these. The remaining CAcert specific
stuff like

- user registration
- user information management
- assurance
- web of trust
- organization assurance

That is a big part of what differentiates CAcert from other CAs is not
covered by these documents. We have some of this documented in our policies
but these are not requirements documents that are fit to be implemented. We
would at least need to break all these sources down into small, testable and
implementable parts.

From my point of view these should be described with a goal, a possible
implementation idea, acceptance criteria and a test idea each and should be
small enough to be implemented by a single developer and understood by a
different developer that does the code review.

> > - ideas how to test whether the software fulfills this (role: test
> >    management, document: test specification)
> Automated tests would be very helpful and are mandatory for a working CI/CD
> pipeline. At least there should be some rules, when pull requests are
> accepted.

100% agreed. I tend to say "if it has no test it does not exist" which would
mean we have no existing code if taken to the extreme :-)

> > - properly documented deployment processes (idealy automated)
> Sources and scripts stored in Git (matches perfectly requirements regarding
> reviews and change tracking). E.g. Jenkins for automated tests, image
> building, dependency checks and at least deploying on Kubernetes?

We have the tools but not the build and deployment code or documentation.
Self operated Kubernetes is nothing I think is realistic for us (see below).

> > - properly working code reviews (needs enough peopel with knowledge of all
> >    involved tools and languages)
> So it may be a good idea to use really main stream languages and tools. Used
> libraries should also be well known and should provide well known security
> features. It would be really embarrassing for CAcert if solution would
> suffer an injections, cross site scripting etc.

See below.

> > - idealy some automated process to get feature/bugfix branches or pull
> >    requests to systems where manual and automated tests could check them
> Self hosted Gitlab? It provides everything from Git, Issue tracker and
> CI/CD.

We have Jenkins, Git and could do this with our existing infrastructure, we
just need someone to build all the build and deployment automation as well
as the tests required to make a good CI/CD pipeline from these parts.

> By idle curiosity I tried to build a CAcert like solution on EJBCA community
> edition. HSM was build with a Smartcard-HSM USB token. Result was: It should
> do that job regarding most aspects.
> 
> In most cases it is not a good idea to reinvent the wheel. EJBCA provides a
> ugly GUI, but on the other hand it provides a good SOAP interface. SOAP
> interface authenticates with client certificate and provides a solution for
> roles and authorization. Not every SOAP consumer should be allowed to do
> everything on every CA.

The SOAP interface would need to be put behind firewalls and would still be
more open to attacks than our current offline signer that is not reachable
by other means than a serial line with a custom protocol which is a good
idea. Those CAs that have gone out of business and were not involved in
shady practices (like issuing certificates that they should not have issued)
or failed due to bad business decissions have failed due to compromising
their signers via some network access that they thought to have secured.

> My proposal:
> 
> * Use EJBCA (Kubernetes) with Postgresql and a HSM as "backoffice".
> * Use a Spring Boot application as interface between EJBCA SOAP interface
> and users.
> * For eye candy a certificate empowered Angular solution talks with
> REST/GraphQL interface of that Spring Boot service. REST interface should be
> well documented, so interested people can build their own interfaces.
> Security must not depend on client side executed code.
> * Everything is running in a Kubernetes environment.

That moves the complexity and missing resources from development to an
operations team. We operate such infrastructure with a full time team of
multiple system engineers to keep Kubernetes, the underlying VM
infrastructure and Gitlab in a good shape (read properly setup, configured,
running, monitored and updated). Self hosting something like this
professionally with a small spare time team is completely unrealistic.

Using EJBCA as is would move a lot of the critical stuff that we have on the
offline signer (certificate policies in form of openssl files), private keys
or the required smart card pins in case of using smart cards to an online
system which needs to be heavily secured.

So you replace one scarcity of people (developers) with another (highly
skilled operations).

Working on EJB software is not a lot more fun than working on a custom code
base and I would not touch EJB code in my spare time. I have done it for a
few years.

If we would have enough skilled Java developers I would try to focus on
building a good solution with an understandable code base with them. My
current proof of concepts use Go because I find it easier to start for
people who are not in the software industry for a lot of years. But I have
no strong feelings against Java and agree that BouncyCastle provides a good
starting point for PKI software as does the Go standard library packages.

Providing a good user interface for registration, self-service, assurances
and interfaces like ACME for automated certificate issuing will be possible
in both languages (and others like Python, Rust, ...) if we have enough
skilled people. Some parts could be done using Angular or React if we find
enough good frontend developers with enough time.

> I build a dockerized EJBCA, so it should not to be rocket science to build a
> set up for Kubernetes, but I am in same situation as Jan, I am doing that in
> my spare time.
> 
> Back to originally subject of this thread: In EJBCA I need to change maximum
> certificate life time in entity policy only (Admin GUI).

Yes, and then a policy/CPS change (at least for now) and a critical system
engineer that performs the change.


Kind regards
Jan

-- 
Jan Dittberner - CAcert Infrastructure Team Lead
Software Architect, Debian Developer
GPG-key: 4096R/0xA73E0055558FB8DD 2009-05-10
         B2FF 1D95 CE8F 7A22 DF4C  F09B A73E 0055 558F B8DD
https://jan.dittberner.info/

Attachment: smime.p7s
Description: S/MIME cryptographic signature