Skip to content. | Skip to navigation

Personal tools


You are here: Home / Wiki / Rpr-Email-20080812


From: Robert P Ricci <>
To: Leigh Stoller <>
Cc: GENI Development Mailing List <>
Date: Wed, 12 Mar 2008 17:59:46 -0600
Subject: Re: Private Keys


Okay, I went and read the paper you pointed us to (some parts more carefully than others.)

I thought it was a good paper that examined some pretty interesting
things. I know you're not proposing to use this model directly or
anything like that, but for the sake of clarity in discussion, let me
point out a few differences between their goals and ours: (this is also
to help make some of our goals and nongoals more explicit)

1) They are trying to delegate to entities who don't have an identity of
  their own. In GENI terms, this would be delegating to someone who not
  only is not known to a particular piece of GENI (ie. a particular CM),
  but doesn't have a GGID at all. I don't think we need to worry about
  delegation to people that don't have GGIDs.
2) They are focused on identity-based authorization: ie. who I am
    defines what I can do. So, combined with point #1, what they are
    doing basically amounts to 'let this person is as me, but with this
    possibly restricted set of permissions'. We've been talking about
    separate authentication and authorization, where I prove my identity
    in one step, and present credentials that are separate from my
    identity in another step.

Thus spake Leigh Stoller on Wed, Mar 12, 2008 at 02:08:35PM -0700:
> >Hmmm .. it seems to me that capabilities need to be signed, which
> >requires the signer to have a certificate, but not the creation of  
> >a new
> >certificate for the capability itself.
> Remember when we talked about how to prevent a capability from being  
> passed on, if the operation is unmediated?
I'd like look a little bit at the specific cryptographic operations that
occur in this process to get a better idea of what you and I are 
thinking of. I see a couple of places where there are choices, and I 
don't know, in some cases, which choice you're thinking of.

Let's say I want to delegate the right to create slices, which Leigh
gave me, to Mike.
So, I start with a capability that says 'leigh says rob can create
slices', and let's assume for a second that I am allowed to delegate it.
I would think my steps look something like this:

1) create a new capability saying 'rob says mike can create slices'.
    Note that at this point, it's not signed, so no one has any reason 
    to trust it.
2) include my original capability and the proof of it (whether this is  
    a signature or a certificate: choice 1) (together, these constitute
    a credential.)
3) sign the whole thing (or make a new certificate). The question here
    a credential.)
3) sign the whole thing (or make a new certificate). The question here
    is whether I sign it with my own key, or the key from my old  
    credential: choice 2

So, it looks like you are thinking of a certificate for choice 1, but
what do you think about choice 2? Clearly, if we're signing it with the
credential key, not user key, then the answer to choice 1 has to be

Also: Is the expression of whether I can or can't delegate this
capability part of the capability itself, or part of the credential?
(choice 3) It's not clear to me what all of the tradeoffs here are,
except for the fact that if it's part of the capability, we don't have
to worry about being able to graft it into the x509 certificate itself.

> The certificate is the only provable mechanism since its the chain  
> that says the capability was really passed on from the person with  
> the original right. Its also how you can revoke a capability from  
> someone in the middle of the chain.

You could certainly prove a signature: basically, you sign with your
public key, and provide the signer's certificate, which can be verified.
You don't have to make a new certificate for each signature. But, this
goes back to whether we think the delegation should be done by signing 
with the user key or capability key.

I hadn't though about the revocation thing, though, which certainly does
seem easier, or at least more understood, for a certificate.