Initial proposal for a RESTful delegation service

Subsequently designated v0.1 of the draft standard -- GuyRixon - 13 May 2007

The delegation service generates a proxy certificate and matching, private key for use by other services in the same host. A client uses the delegation service when it needs those other, co-located services to act on behalf of a user.

The delegation service is defined to be a REST web-service. Therefore, it consists in a set of accessible resources each with a URI. There should be two kinds of resource: certificate-signing requests (CSRs) and actual, delegated credentials. For each delegation, the client gets a CSR, signs a certificate derived from that CSR and uploads the certificate to the service as a delegated credential. The private key matching a certificate is generated and retained by the delegation service; it is never exposed as a web resource. However, by implication, a resource is created and retained on the sever when a CSR is generated. This has implications for how web resources are arranged.

There is a master resource /delegations representing all delegated credentials. Getting this resource returns a list of current delegations. Posting a request to this resource generates a CSR for a specified subject and cancels any credentials previously held for that subject. The posted request must have these parameters:

• DN: the X.500 distinguished name (DN) that is the subject of the certificate;
• lifetime: the duration of validity of the certificate in seconds.

The lifetime of the certificate is counted from the point at which the service responds to the CSR request (the duration is converted to an absolute termination-time written in the CSR).

If the service accepts a request to /delegations then it must create a key pair. It must create new web-resources as follows:

• /delegations/(hash): an XML document linking to available resources to do with the given subject; (hash) is the MD5 hash of the DN in the posted request.
• /delegations/(hash)/CSR: a PKCS#10 CSR in base-64 encoding

The response to the posted request is a redirection (HTTP code 303: "see other") to the /delegations/(hash)/CSR request. The client then gets the CSR. The 303 code is preferred to 201 "created" because it better supports web browsers. Browsers will follow a 303 redirection but will do nothing with a 201 code.

Having got the CSR, the client creates a matching certificate and signs it with the user credentials. It then puts the signed certificate to the URI

• /delegations/(hash)/certificate

This completes the act of delegation. The client can now call the associated service that will use the delegated credentials. Those services can extract the credentials - both certificate and private key - from the delegation service using an interface that is an aspect of the implementation and not a part of the delegation standard. In a plausible Java implementation, the delegation service is a servlet in the same web application as the service receiving delegation. Hence, the two can exchange credentials via Java APIs rather than via the web interface.

If the client needs to revoke the delegation, it does so by deleting the resource /delegations/(hash). The service can and should delete /delegations/(hash) when the delegated credentials expire.

There is no risk to the service provider in accepting credentials from anonymous clients, and this usage does not put at risk the user's identity. Therefore, there is no absolute need for the client to authenticate to the delegation service. However, a denial-of-service attack is possible: an anonymous attacker can revoke or overwrite a valid delegation. Therefore, it is better if post, put and delete requests to the delegation service require authentication of the client (using the established, IVOA method). To use a set of delegated credentials, a service must be acting for an authenticated client so the installation as a whole is necessarily capable of authentication.

Points of uncertainty:

• Is the DN parameter to the posted request necessary? Should we just request the request to be authenticated and take the authenticated DN?
• What exactly is got from /delegations? What from /delegations/(hash)?
• Is it either useful or safe to put the private key on the web at /delegations/(hash)/private-key (assuming strong authentication of requests to get this resource!)?
• Is an MD5 hash a good way to represent DNs in the URI path?

-- GuyRixon - 05 Mar 2007