Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Credentialnotes


Credentials must be revocable independently of the GID lifetime and the certificate used to sign them. (Certificates can also be revoked, but that is a different matter entirely.)

A signed credential must contain enough information to allow the lookup of the credential revocation list of each authority that signed it.

Is there any security risk in making revocation lists public? At the very least, the UUIDs of all revoked credentials become known.

Instead of maintaining revocation lists, why not provide (additional?) signatures with short lifetimes? The advantage is that this greatly reduces load on the root: with revocation lists, every verifier polls the root authority for its revocation list every day (or however often). With short-lived signatures, however, only the immediate descendents of the root request fresh signatures daily. Verifications can be made without contacting any authority.

One possible problem is that key-signing authority is not necessarily related to credential-granting authority. Credentials are self-sufficient as far as the chain of signatures go, as each certificate carries enough information to verify its validity, but delegated credentials must carry enough information to locate the revocation list of each delegator, and in general this will be unrelated to both the associated key certificates and the component manager (or whatever) corresponding to whatever it is the credential authorises.

What happens when a credential verifier cannot obtain a current revocation list for some reason (e.g. disconnected operation as in GENI CFA 4.9, or network failure)? If credentials are refused, then no operation is possible, but if credentials are accepted then a simple DoS attack on the revocation list server turns into escalation of priveleges!

Crashes (see p. 20 of the GENI spec) are problematic with revocation lists; we don't want revocations lost during a crash!

In the SFA: the "Provisioning a Slice" section states "A credential can be delegated locally, without contacting the issuer of the credential." However, the "Registry Interface" section includes "A conservative callee is free to call the registry and confirm that the GID is still valid (has not been deleted)." How can the registry confirm that a delegated GID is valid when it was not even contacted since delegation?