Credentials

Credentials are authenticated documents which describe privileges held by a principal. (Currently, all ProtoGENI principals are either users or authorities.) Conceptually, they unambigiously identify the owning principal; a target ProtoGENI object to which the privileges apply; a list of the relevant privileges; and an assortment of cryptographic data which serves as secure proof of the authenticity of the credential.

Format

Credentials are externally represented as XML documents. The cryptographic signatures required on all authenticated credentials conform to the XML Signature Syntax and Processing specification, and any certificates contained within credentials obey the normal ProtoGENI certificate conventions, including the associated Base64 and DER encoding.

The credential schema describes the contents of credentials precisely. For purposes of this description, it suffices to understand that a base credential consists of an owner and target (each represented by a certificate), serial number and expiry time, a list of zero or more privileges (each of consisting of a string identifying the permission conveyed and a flag indicating whether that permission may be delegated), and optionally (in case of a delegated credential), a parent (which is of exactly the same base credential form). A signed credential (which is the form that all external representations must take) additionally includes a list of XML signatures (a signature must be present not only for the primary base credential, but also for all of its enclosed ancestors).

The wildcard privilege "*" may be used in place of any other privilege string.

For the detailed specification, please consult the schema.

Example

A simple credential might look like this:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<signed-credential>
 <credential xml:id="ref1">
  <type>privilege</type>
  <serial>12345</serial>
  <owner_urn>urn:publicid:IDN+emulab.net+user+gary</owner_urn>
  <target_urn>urn:publicid:IDN+emulab.net+slice+mytestslice</target_urn>
  <expires>2010-01-01T00:00:00</expires>
  <privileges>
   <privilege>
    <name>*</name>
    <can_delegate>1</can_delegate>
   </privilege>
  </privileges>
 </credential>
 <signatures>
  ---XML Signature elements (signatures and certificates) go here---
 </signatures>
</signed-credential>

Delegation

Delegated credentials behave fairly similarly to the base credentials described above. The major difference is that instead of a signature from the authority named in the target, any delegated credential is instead signed by the owner of the parent. (Ultimately, of course, a credential with no parent must be reached, and that one will be signed by the target authority as normal.)

Signatures on parents are not nested within those credentials themselves. Instead, all signatures must be concatenated into the list in the outermost child credential.

A concrete example of a delegated credential is available, along with instructions on how to use the ProtoGENI tools to create one.

Validating credentials

The following procedure should be followed before accepting any credential as proof of corresponding privileges. Naturally, all credentials must be syntactically correct (and validate against the credential schema); the following requirements describe restrictions which are necessary for semantic correctness as well.

For any credential to be honoured, the current time must be no later than that specified in the expires element of the credential. When issuing subsequent credentials under the authority conferred by an existing credential (e.g. when a slice credential has been presented to authenticate the issuing of a corresponding sliver credential), the expires element time of the consequent credential must be no later than the expires element time of the existing credential.

Validating the root

Any simple credential (one with no ancestors), including the ultimate root credential which is contained in delegated credentials, must be signed by a ProtoGENI authority whose certificate subject matches the authority in the target URN. (This certificate will be included in a signature element, according to standard XML Signature processing. Other certificates might also be enclosed, since it is necessary to verify CA certificates up to one of the ultimately trusted roots.)

The certificate subject is considered to match the credential target if and only if:

1. The subject URN in the authority's certificate has resource-type "authority".
2. The toplevelauthority field in the authority's certificate subject URN is identical to the toplevelauthority in the credential target URN. RFC 3151 defines transcription and equivalence of public identifier URNs.

Validating any delegation

If the credential has been delegated, then each delegation must satisfy the following:

1. The type field of the child must be identical to the type field of the parent.
2. The expiry time on a child credential must be no later than the expiry time of the parent.
3. The expiry time of the child must be no later than the current time.
4. A valid signature over the child credential, signed by the principal identified in the owner element of the parent credential, must be present in the signatures element of the outermost credential.
5. For credentials of type privilege:
   1. No privilege may be included in a child credential unless either a privilege with identical name or the privilege named "*" is present in the parent. In addition, the parent privilege must include the element <can_delegate>1</can_delegate>.

Validating subauthorities

Please note that Utah's ProtoGENI software does not yet support subauthorities. If a validator does not support subauthorities, it should reject any credential if either the authority certificate subject URN or the credential target URN contain one or more subauthority fields.

If the validator does process subauthorities, the following restrictions will apply:

1. The number of subauthorities specified in the authority subject and the credential target must agree, and each subauthority field must match (just as the toplevelauthority must).
2. Any authority certificate where the subject URN contains one or more subauthorities must have been signed by a CA such that the certificate issuer URN contains exactly the same toplevelauthority and subauthority fields as the certificate subject URN in exactly the same order, except that the very last subauthority in the certificate subject must not be present in the certificate issuer.