Draft: Implement spec proposal 343 and add signing routines for draft-ietf-acme-onion documents

This MR implements issue #1414. Two new features are provided.

CAA records

An Onion Service in Arti can now have the following in its config to publish CAA records in its service descriptor, as per the format set out in prop-343. The values are validated according RFC 6844 § 5.1

[[onion_services."allium-cepa".caa]]
flags = "Critical"
tag = "issue"
value = "test.acmeforonions.org; validationmethods=onion-csr-01"

Document signing routines

The Arti RPC server is extended to include the following new commands:

• arti:x_acme_get_onion_service
• arti:x_acme_onion_service_name
• arti:x_acme_onion_service_csr
• arti:x_acme_onion_service_caa

These serve to offload the cryptographic operations from an ACME client to Arti itself. The current Certbot plugin for Onion Services implements these operations itself, however it was raised in the Lisbon meeting that implementing these operations in every client is tedious and error prone. It was suggested instead that Arti should implement these operations to offload the burden from ACME clients.

They are in the x_acme_ namespace as they are currently experimental.

arti:x_acme_get_onion_service

This is called against an Arti RPC Session Object ID, with one parameter: domain. The domain is a string representation of a DNS name - including .onion - and may include subdomains. If the Arti proxy knows of this Onion Service it will return its Object ID in the service field.

arti:x_acme_onion_service_name

This is called against an Onion Service Object ID, with no parameters. It returns the canonical string encoding of the Onion Service's root domain name in the service field.

arti:x_acme_onion_service_csr

This is called against an Onion Service Object ID, with one parameter: ca_nonce. The CA nonce is a Base64 encoded representation of the cabf-caSigningNonce { joint-iso-itu-t(2) international-organizations(23) ca-browser-forum(140) 41 } presented by the CA to the client. It will generate a CSR according to CA/Browser Forum Baseline Requirements Appendix B.2.b and sign it appropriately. The resultant CSR will be returned - Base64 encoded - in the csr field.

Note: this method is not exclusive to ACME. A CSR generated by it could also be used for any other issuance process e.g. the manual process used by HARICA. This is because the CA/BF BR do not tie an Onion CSR to ACME but allow it to be used for certificate issuance to an Onion Service in any circumstances.

arti:x_acme_onion_service_caa

This is called against an Onion Service Object ID, with one parameter: expiry. The expiry is the time length in seconds for the CAA document to be valid. The current CAA records of the Onion Service will be signed (as per draft-ietf-acme-onion) and returned in three fields: caa, expiry, and signature. The CAA field contains the concatenated textual representation of the Onion Service's CAA RRSet. The expiry field contains the UNIX timestamp at which the document expires. The signature field contains a Base64 encoded signature over the CAA RRSet and expiry - again as per the IETF I-D.

Client support for the new RPCs

The Certbot plugin has experimental support for these RPCs as of v0.3.0. If Arti is configured to put its RPC socket in the usual place then the following can be used to issue a certificate against a running Arti instance:

certbot --server https://acme.api.acmeforonions.org/directory certonly -d <domain>.onion --authenticator onion-csr --onion-csr-arti

If the Arti RPC socket is in a different location then --onion-csr-arti-connection-string can be used to specify the connection string e.g. unix:...