Shibboleth Developers

[Scott Cantor <>]

Well, to bring this full circle, shib2 is now running basically what RLBob 
asked for.

There is no trust data in the sites file, but I did make everything a named 
<SiteGroup>, and I build a list of the site name and
whatever groups it happens to be nested in (the point about multiple 
overlapping groups is well taken, but let's start somewhere).

There's a separate file (trust.xml) with a <Trust> container of 
<KeyAuthority> elements, each with a bunch of certs and a set of
Subjects (by name or regexp).

There can be multiple site and trust files, and for the XML-based provider, 
if the file is local, it will be reloaded on the fly any
time it's changed. Other providers for LDAP or XKMS, or whatever can be added 
in the future.

The POST validation process is:

Match the site name and the issuing HS against the site metadata.

Ask for certificates explicitly assigned to the issuing HS, and try each one 
in sequence to verify the signature. If verified, done.
If not,

Compare the subjectAltName DNS value or the subject CN in the signing 
certificate to the HS name.

Ask the site API to validate the certificate chain in the response.

The site API asks the trust API to validate the chain using its site name and 
any groups it's a member of.

The trust API locates each matching set of certificate roots in the trust 
file(s) and tries each set in turn until it finds one that
validates the chain or it returns failure.

That's roughly what the old code used to do, but is more flexible, obviously.

I probably won't have time to do CRLs, but the trust file should be able to 
hold them. OpenSSL is only so-so at dealing with them,
so I don't know that they'll help anyway.

-- 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--