From: stoller@flux.utah.edu
Subject: Stuff
Date: March 26, 2008 1:47:42 PM PDT
To: geni-dev@flux.utah.edu
So, here is a little update on where I have been for the last little
while. Seems like I have spent a lot of time but not made much
progress.
* I figured out how to use the xmlsig code. This is a nice library and
front end program (xmlsec) that can generate signatures in the
proper format as specified by the schema. It can also verify
signatures and also verify the certificate (chains) used to sign
them. Very handy. This was my foray into xml schemas for real and so
I did spend time learning that stuff. Useful.
* I then disappeared into globus. They have an implementation of
proxy/delegation certificates that I thought we might be able to
use. Sheesh, the source tree has 59000 files in it! Talk about
bloat. Anyway, I found the right stuff inside it and found two
problems; 1) the implementation allows for only two types of
delegations; everything or nothing and 2) it uses SAML, which was
another diversion into bloatation. After about two days of this I
decided that I did not want to hack this code or try to separate out
the tiny little parts we need from it. Too much pain.
* I then started thinking about the alternatives. I came up with an
approach that looks like the following:
<foo>
<credential>
<uuid>xxx-yyy-zzz</uuid>
<capabilities>
<capability>
<capability_name>frazzle</capability_name>
<can_delegate>1</can_delegate>
</capability>
</capabilities>
</credential>
<signatures>
<signature></signature>
</signatures>
</foo>
So, a credential is a set of capabilities (with a delegation flag on
each one). Attached to that is a signature. I did not bother to
include the guts of the signature, but it includes all kinds of stuff
from the xmldsig schema, including the x509 certificate used to sign
the data. In the case above, the signature is that of a trusted entity
(Emulab) since it has not been delegated from elsewhere.
* I still have to settle on the UUID above. I guess its really a GGID,
and in the case above it refers to the person who has the permission
(credentials) to do whatever. I think we also need to include the
GGID of the thing the credential refers to (GGID of the experiment,
node, whatever). Also maybe a type or some indicator of how to look
that GGID up (in which name server)?
* Okay, what about delegation. We have a couple of issues to worry
about. First is that we have to be able to verify that delegations
are valid (do not violate a previous capability that said that
capability could not be delegated). This is a lot like verifying a
certificate chain; start at the beginning and go through each set
till you get to the end. Second problem is that you need to sign
each new set of capabilities, and you have to include all the
previous capabilities in the signature so that you have proof that
nothing in the history has been tampered with. So what I came up for
this:
<foo>
<credential>
<uuid>xxx-yyy-www</uuid>
<capabilities>
<capability>
<capability_name>frazzle</capability_name>
<can_delegate>1</can_delegate>
</capability>
</capabilities>
<parent>
<credential>
<uuid>xxx-yyy-zzz</uuid>
<capabilities>
<capability>
<capability_name>frazzle</capability_name>
<can_delegate>1</can_delegate>
</capability>
</capabilities>
</credential>
</parent>
</credential>
<signatures>
<signature></signature>
<signature></signature>
</signatures>
</foo>
Its maybe hard to see, but the original capability set is contained
*within* the new one (look for the "parent" tag). There are also two
signatures, the original signature and a new signature that covers the
entire blob of data. To verify the above, the signatures have to be
valid, the certificate chain has to be valid, and the root set of
capabilities has to be signed by a trusted entity. This proves that
the leaf set of capabilities is valid if it has not been altered in
the middle and it conforms to the delegation rules.
* My next step was to take cue from Rob and generate a schema for it
(like he has done with the new ptop/to/vtop stuff for assign). Well,
I've never done this before either, and after an amazing amount of
screwing around, I actually came up with one! See the attached file
if you really care. The nice thing about this schema stuff is that
you can use the libxml2 package (via perl) to verify that an xml
file adheres to the schema, before you try and mess with it. Saves
on writing your own debugging code. The same library allows you to
access parts of the xml structure after it is parsed, although its
not as simple as XML:Simple makes it.
So I will stop here and let Rob (or anyone else who is still awake by
now) comment.
