Keystone/X509Subjects

The current signing mechanism for Keystone tokens makes no use of the Subject field of the Certificates. Instead, a single set of certificates: CA cert and signing_cert, are fetched from the Keystone configured in the middleware/auth_token.py config section of the applications configuration file. A better approach would allow multiple, independent signers. For the sake of an OpenStack deployment, it is going to still be required that all of the Keystone certificates be signed by the same CA certificate. We may remove that rstriction in the future.

The mechanism to confirm the identity of the signer is to match the Subject field with the entity responsible for signing the payload of the message. Since we wish to extend the mechanism to both services and end users, the mapping needs to be flexible enough to indicate which group the signer comes from.

IETF PKIX (latest version RFC 5280) is a well accepted profile for certificates. From section 4.1.2.4, the following fields must be supported.

   country (countryName, C),
   organization (organizationName, O),
   organizational unit (organizationalUnitName, OU),
   distinguished name qualifier (dnQualifier),
   state or province name (stateOrProvinceName, ST),
   common name (commonName, CN) and
   serial number (serialNumber).

We need three fields to indicate: 1. User or service 2. If Service, what kind of service 3. Which Endpoint of the services.

The OU Field is the obvious candidate for the Service type, and the Common name for the endpoint. However, the Common Name should probably be a Fully qualified domain name, not a UUID,

A Subject would then be composed of something like: Subject: C=US, ST=Maryland, L=Pasadena, O=OpenStack, OU=Nova-API, CN=nova15.openstack.freeipa.org/service=nova/endpoint_id=26880817-642e-4934-b066-63f076a72164

For RPC Message Signing, a similar mechanism has been propsed. The essential point there is that each and every Hypervisor should also be able to use a signing cert to confirm its identity. Thus, the field should match the values that come back from `nova hypervisor-list`