Shibboleth Developers

[Scott Cantor <>]

> I understand what you're getting at here and why, and it 
> makes sense, but it makes me a little nervous to mix this 
> CA/key data in with the rest of site definition.

Does your objection hold to the same degree in the more common aggregate 
case? I was assuming that for most purposes, the TrustList
would not be different for each site, but would be applied to basically 
everything in a group of sites (or more commonly the entire
list of Sites in a file).

> The TrustList element as you propose it kinda turns this 
> around, associating a CA with the data item to be validated.  

Well, somewhat, but it is intended to work at a higher aggregation level than 
"for this site, use X, Y, Z". It also could easily be
modified at some point to refer to CAs by reference and not by value. KeyInfo 
can carry cert names as well as certs. I'm not
inclined to build a KeyResolver infrastructure for 1.0 to look up CAs by name 
in an external store, but it's certainly possible
without a lot of work.

Done in that fashion, it would seem to more strongly resemble naming 
constraints, or at least achieves the separation you're talking
about.

> If this makes sense at all, perhaps all I'm asking in the 
> near term is for this info to be distributed/managed in 
> separate documents from the current site metadata.  Maybe 
> this is what Ken had in mind when he was talking about 
> separation between trust and ... whatever the other thing was.

Well, there has to be a connection between the site (or its group if you 
will) and the trust information to break the monolithic
approach apart. So there's some connection there by reference using a URI or 
an XLink or something like that in order to tie the two
together.

So I view it as an evolutionary step that could follow on what we do in 1.0, 
but using different KeyInfo semantics that offer more
indirection, while still preserving the same basic framework in the schema 
and the code. In 1.0, I might assume that KeyInfo
contains a list of X509Data elements, but later that could be generalized and 
handle a variety of KeyInfo content, or extensions
like XKMS that create the indirection.

A related note is that I have almost finished a complete revision of the 
entire interface between the core Shib library and the
metadata lookup classes so that it's pluggable. I can register different 
resolver types now(currently we use an XML file based
resolver), and they can be added to the system at runtime like the other 
dynamically loadable pieces. Multiple resolvers also work.
Each one is self-contained and can encapsulate all the logic about what the 
actual connection between the site metadata and the
trust metadata is.

So how it makes that connection is something we can change later; the 
metadata API just says "give me the X509_STORE for this origin
site", but it doesn't impose any rules on where you get 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--