• Leigh B Stoller's avatar
    Reorg the credential checking code, and add Geni chain checks. · dd5c6601
    Leigh B Stoller authored
    From: Leigh Stoller <lbstoller@gmail.com>
    Date: Wed, 22 May 2013 13:49:33 -0700
    Cc: instageni-design@geni.net
    So far we have been pretty loose about checking to make sure the
    certificate chains obey the Geni rules. These rules include checking to
    make sure that only approved entities can sign particular kinds of
    credentials. For example; only something known to be a Slice Authority
    should be allowed to create a slice and return a slice credential.
    The other check we have been lax about, is verifying that the URN namespace
    is consistent along the chain from CA to the target. For example, a chain
    that starts in Utah:
    should not be able to sign anything outside its namespace. That is, Utah
    should not be able to sign a user or slice credential like:
    This is made more complicated when we introduce subsa certs along the way,
    where Utah signs its SA cert and that signs a project slice. In this case
    the chain would look something like:
    There are also scoping rules; A subsa like:
    should not be able to sign:
    The entire cert chain is require to verify this. The CA roots are in the
    bundle, and the intermediate certs should be enclosed in the signature
    section of the XML document.
    We have to make the same check against the user certificate after apache
    verifies the chain. For apache (or any SSL server) you have to load the
    chain, and as I mentioned in earlier email, this is easy with perl and
    python based clients.
    With all that said, we do not plan to start rigorous enforcement of the
    first check above, and for the second class of checks, we just want to
    enforce a simple prefix check until we get our subsa house in order (since
    we don't even conform properly yet!).
GeniCM.pm.in 179 KB