X.509 Certificate Usage in ProtoGENI

ProtoGENI makes heavy use of X.509 format certificates to implement its public key infrastructure. This usage falls into three major categories:

1. Each member of a ProtoGENI federation behaves as a certification authority (CA), and accordingly holds a self-signed CA certificate. (These root certificates are assumed to be well-known throughout the federation, and it is the responsibility of the Clearing House to distribute current root certificates and certificate revocation lists (CRLs) to all members.)
2. All XMLRPC transactions are performed over a TLS (a.k.a. SSL) private, reliable, and authenticated channel. Both of the two peers -- the ProtoGENI service and the accessing user -- must authenticate their identities, by presenting a certificate which ultimately derives its authority from one of the CAs described above.
3. Every credential object includes at least one certificate. Essentially, the certificate portions of the credentials provide authenticity, while the remainder describes permission and policy information.

Certificate Representation

Unless otherwise specified, ProtoGENI certificates are transferred using X.690 ASN.1 DER (Distinguished Encoding Rules) syntax and Base64 data encoding. In particular, this convention applies whenever certificates are present in XMLRPC requests and responses, as well as when enclosed in credential objects.

Certificate Conventions

ProtoGENI certificates follow the standard X.509 format (v3), and additionally impose the following restrictions:

OIDs

ProtoGENI currently makes use of the following unregistered OIDs:

2.25.305821105408246119474742976030998643995

indicates an XMLRPC server corresponding to this revision of the API. (Note that this OID is derived from the UUID e61300a0-c4c5-11de-b14e-0002a5d5c51b.)

Those or other OIDs might be registered in the future, in which case implementations should still continue to accept the unregistered equivalents to maintain compatibility.

Names

DistinguishedName

The DistinguishedName type (as used for the subject and issuer fields) must obey the following conventions when used in ProtoGENI certificates:

1. the organizationalUnitName, if present, should be a human-readable name of the form domain.object. domain should describe the ProtoGENI federate with authority over the object named, and name should be unique within that domain.
2. the commonName, if present, should be a UUID in the hexadecimal digit string format given in RFC 4122, and generated in accordance with that specification.
3. an optional emailAddress attribute may be included, which should correspond to an e-mail address for the named user (in user certificates) or an administrator with responsibility for the object (in all other objects). This address should be considered informational only; it is not intended for use as a primary identifier.

Note that use of the subject and issuer fields and DistinguishedName type will become deprecated in the future. It is currently recommended that implementations should populate them in generated certificates (to maintain backward compatibility), but ignore them when processing certificates which include GeneralName replacements.

GeneralName

The GeneralName type (as used for subjectAltName and issuerAltName) obey the following conventions:

1. All objects should be described with exactly one uniformResourceIdentifier, in the urn namespace as specified by the GMOC Proposal "Use URN as GENI identifiers" (version 0.2).

It is recommended that all newly generated certificates contain this identifier.

Other information

A certificate whose subject is a ProtoGENI authority (i.e. XMLRPC server) should present the URL of its XMLRPC interface in the authorityInfoAccess extension, using the OID 2.25.305821105408246119474742976030998643995. New OIDs may be introduced in later revisions of this specification. Older certificates did not conform to this convention, and for backward compatibility, implementations may interpret a uniformResourceIdentifier in the subjectAltName extension if the authorityInfoAccess is not present.