Future of CA ACLs and cert-request validation

The current controls governing certificate issuance authorisation are limited, falling short for a number of important use cases:

1. Limited operator authorisation

   Currently a single permission, "request certificate", controls whether an operator can issue a certificate, along with the ability to write the subject entity's userCertificate attribute. This check is waived for "self-service" requests and for host principal operators. (The request is still subject to CA ACLs, unless the operator has the "request certificate ignoring caacl" permission, and userCertificate attribute write access checks).

   A use case where current implementation falls short: only vpnadmins user group should be able to issue certs for hosts in vpnservers hostgroup (using VPN profile and CA), and only webadmins user group should be able to issue certs for hosts in webservers hostgroup (using HTTPS profile and CA). Currently, "request certificate" permission is required to request the cert, but having that permission means that the operator could request VPN or HTTPS certs regardless of group membership.

2. Lack of ability to enable/disable self-service

   For self-service requests (operator is subject), the "request certificate" permission is not checked. If a CA ACL allows a particular CA+profile to issue a cert to the subject, then self-service is unconditionally allowed. This is not good enough, e.g. if some kind of certificate, though appropriate for the subject, should only be issued by an admin.

   Proper operator authorisation (use case (1)) should encompass this, i.e. self-service is allowed when operator scope is a superset of subject scope.

3. No fine-grained authorisation for revocation.

   Currently revocation is an "all or none" permission. Customers should be able to delegate revocation permission to particular principals or groups, optionally scoped to particular CAs.

Related discussion: https://gist.github.com/frasertweedale/6093f2312d16b3958374cc15b55b4d63