Keystone/user-certs

There are three different types of Public key values that the user Object should be able to store.

1. A Public Key for Open SSH
2. A Client certificate for SSL
3. An SMIME SIgning Cert

Adding these to SQL is probably trivial, as we can always shove them into the "extra" field, but for LDAP we are a little more constrained. Each is supported by a different RFC Schema.

• The client cert comes from RFC 4523: attributeTypes userCertificate which is in objectClass pkiUser. This is an auxiliary class and can be added to an object after it is created.
• The signing cert comes from RFC 2798: attributeType userSMIMECertificate which is in objectClass inetOrgPerson. This object class May also have userCertificate. THis class is marked STRUCTURAL and must be created as the user Object.
• There is no public RFC that addresses storing Public Keys in LDAP. Instead, there is a generally accepted approach using a public key attribute.
  • https://code.google.com/p/openssh-lpk/
  • The OpenLDAP schema is here: https://openssh-lpk.googlecode.com/svn/trunk/schemas/openssh-lpk_openldap.schema
  • FreeIPA also produces a schema: https://git.fedorahosted.org/cgit/freeipa.git/tree/install/share/60basev3.ldif
  • Both store the key as (OID=1.3.6.1.4.1.1466.115.121.1.40) transparent 8-bit bytes.

Thus the user object will have three optional values:

1. sshPublicKey
2. userCertificate
3. userSMIMECertificate.

By default, these will be the values for the backend as well, with the ability to override performed in the config file.

The trickier part is in performing the objectClass modifications. Right now, user is defaulted to: inetOrgPerson which will suffice for userCertificate and userSMIMECertificate. Adding on the SSH key would be non-standard, and might involve adding an auxiliary class to the User Object. In the case where the installation has changed the class for User to something that does not support userCertificate or userSMIMECertificate, we either will not support that value, or allow the user to map to a different attribute.

The X509 Certificate data is likely to be quite lengthy, and probably should not be returned unless explicitly requested. Thue GET /user/{userid} will not return these values. Since a certificate has its own Mime type, it makes more sense to explicitly request the certificate data directly. A user might have multiple certificates of each type, as they are stored as a collection. So GET /user/{userid}/userCertificates will return the collection of URIs for the user certificates and GET /user/{userid}/userSMIMECertificates will return the collection of URIs for userSMIMECertificates. The individual certificates will then be returned via /user/{userid}/userSMIMECertificate/{id} Where the ID is a unique identifier for the certificate.

Since Public Keys are much shorter, they can be returned with the User Object as per any other attribute.