Shibboleth Developers

[Scott Cantor <>]

Chatted with Walter briefly on this, thought I'd distribute a little wider 
now that it's crystallized a bit. I've worked on some
extensions to the metadata schema to drive the trust evaluation at the SHIRE, 
which is the only spot that's completely under our
control (the rest is SSL stuff and currently handled somewhat under the 
covers).

My notion is to add a <shib:TrustList> element of type ds:KeyInfoType to the 
<shib:Sites> and <shib:SiteGroup> elements. A trust
list would contain a set of CA certificates and/or CRLs to use for that set 
of sites.

What I can do is add functionality to the interface we use to the metadata 
(the "mapper") that uses this PKI data to load OpenSSL
trust stores (called an X509_STORE) for sets of sites, in advance.

When a signature comes into the SHIRE, I either pull a certificate from the 
OriginSite and use it to hand-verify the document (with
no further checking), or I verify the crypto itself, and hand the certificate 
chain in the document up to the SHIRE. In that case, I
can verify the name in the certificate against the origin site name, and then 
fire up the verifier.

The verifier locates the proper X509_STORE for the incoming site (basically 
using the nearest enclosing TrustList in the metadata),
and uses OpenSSL to verify the chain against the CAs and CRLs in the store.

The advantage here is that the trust data can be centralized if need be in 
the signed file, and can be used more efficiently than a
flat file of CAs would be (I'm pretty sure direct loading of certs into the 
X509_STORE in advance should be much faster). Also, it
permits some immediate multi-federation trust options, at least apart from 
the SHAR/AA SSL step.

For example I can configure my OSU target thusly:

<Sites>
        <SiteGroup Name="urn:mace:InCommon">
                <OriginSite Name="osu.edu".../>
                <OriginSite Name="psu.edu".../>
                ...
                <TrustList>
                        <ds:X509Data>
                                <ds:X509Certificate>
                                Base64 InCommon CA Cert
                                </ds:X509Certificate>
                        </ds:X509Data>
                </TrustList>
        </SiteGroup>
        <SiteGroup Name="urn:mace:osu.edu">
                <OriginSite Name="medcenter.osu.edu".../>
                <OriginSite Name="alumni.osu.edu".../>
                ...
                <TrustList>
                        <ds:X509Data>
                                <ds:X509Certificate>
                                Base64 OSU CA Cert
                                </ds:X509Certificate>
                        </ds:X509Data>
                </TrustList>
        </SiteGroup>
</Sites>

Now I can trust both external and internal sites, but use a different CA for 
each set. I'll have to configure my SHAR with both CAs,
but the AA trust still flows somewhat from the original SHIRE step, so if I 
trust that part, I can trust the AA name/location to be
ok for now.

I've already added schema for <AttributeAuthority> definitions and certs as 
well, so post 1.0, we can fix the SSL parts and expose
that trust evaluation with some work on libcurl and in the AA code.

Astute readers will see that this sites file could not be centrally served by 
InCommon since it includes a second set of sites, but
it could be served and re-signed by, say, OSU. Or a sysadmin could even use 
XSLT to combine sites files from two external
federations into one.

I think this is all implementable in a couple of days, so unless there are 
major objections, I'll get going on it.

-- Scott

------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at 

    http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--