česky | english
Back to Software Homepage - To Software Assessment Homepage
To Software Development Documentation Area
Bug#1464: ACME Protocol
This page relates to bug#1464 on the bugtracker.
Currently this is an area for brainstorming on how to implement the ACME protocol for CAcert.
Contents
Protocol Overview
The ACME protocol is primarily used by automated clients to register new domains and to request new server certificates. While it might also be suited to requesting client certificates this is not its primary focus.
Since creating certificates in a web browser has become considerably harder with the deprecation of key generation HTML tags, offering such a standard interface would open up the use of many existing tools for certificate creation with CAcert for our users. And it may allow the implementation of new tools which may allow more comfortable or less error prone approaches to some certificate related tasks.
Client instances / Accounts
ACME works with "accounts" for the client instances, which are dynamically created by the instances themselves. Each client instance creates a public key pair and sends the public part of the key to the ACME server. This way the server can verify that subsequent requests are sent by the same client instance.
Each client instance typically (but not necessarily) handles the certificates of a single server, requesting the initial one and renewing/re-issuing the certificate each time it expires.
These ACME accounts may be linked to an "external account", this is described in section 7.3.4 of RFC8555.
CAcert point of view
From the CAcert point of view these ACME accounts should probably be new objects in the database, which are then linked to CAcert user accounts using the "external accounts" mechanism.
The Organisation Admin's user interface of the CAcert website will probably have to be extended by a new menue item "Org ACME clients".1 Using this menu item an Org Admin should be able to create the MAC keys and key identifiers required by RFC8555. The CAcert ACME interface must then be able to link an ACME new account request to the CAcert user account with these credentials.
The CAcert user should be able to assign some kind of "access right" to each of his/her ACME account, for example:
- may register new domains for the CAcert user
may only use domains already registered with the CAcert account2
- may only create certificates for a specific host name
Authorisation for an ACME account must be revokable, so that a client using this account can no longer create certificates, and it must be possible to revoke all (non-expired) certificates issued by a specific ACME account.
During the first evaluation I did not notice critical issues which whould prevent the ACME interface to be used for "personal certificates" usable for S/MIME operation. But some additional research should be done before going into more details of this variant.
Alternative approaches
One simple approach would be to extend the Domains and OrgDomains database tables, which contain a record for each verified domain of a CAcert account, to include a MAC key and key identifier. This MAC key would then allow issuing new certificates for this specific domain.
Though this may be quick simple to implement, but it could not support many of the useful finetuning features, like restricting a MAC key to create certificates for only a specific host name or subdomain.
Another option would be to expand the DomainCerts and OrgDomainCerts tables, which contain one record for each issued server certificate. The MAC key stored in this table might allow a client to request a new certificate (or may be renew an existing certificate) for the same entity.
Though this variant would allow a fine "access granularity", we may run into problems with redundant data and "intuitive interpretation" of the data. One entity may already have several certificates assigned, which one of this record would be checked for the correct key? Each one3? Only valid/non-expired ones? Must the MAC key be copied to a newly issued certificate?
While we may get some nice features implemented in this approach I consider the "new table" approach presented in the previous paragraph as more intuitive, and therefor less error prone.
Legal considerations
Note that, from a legal point of view, by storing those MAC keys in an ACME client a CAcert user must accept responsibility for all actions of the ACME client! Taking into consideratikon that there may be fraudulent ACME clients, a CAcert user should have the possibility to restrict the allowed actions of a client.
The user must be prominently informed of this!
CAcert policy questions
DV certificates from CAcert?
Currently CAcert does not issue DV ("Domain Validated") certificates, the lowest of the "trust levels" currently in use by CAs4. DV certificates only verify the control of the domain, where CAcert always links certificates to a user account and has therefor always some link to the "real world entity" which requested the certificate.
A CAcert certificate is currently always linked to a user account. If CAcert wants to enter into competition with Let's encrypt5 pure DV certificates first have to be authorized by the corresponding policies!
Resources
https://tools.ietf.org/html/rfc8555 RFC defining the ACME protocol
https://letsencrypt.org/docs/client-options/ Overview on Client Implementations by let's encrypt
Footnotes
Of course this menu item also makes sense for the "normal" CAcert user, but I consider this more important for organisations... (1)
While I would not consider this as the most urgent feature to implement, it would be nice if we could have it, maybe in a second step. (2)
This might allow several keys access ot certificates for one entity, which would allow failback mechanisms (3)
Of course self-signed certificates are one trust level below that (4)
I doubt very much that this is a goot idea, but others may think different... (5)