Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Fri, 16 May 2003, Scott Cantor wrote:

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

It does.  More below.

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

Right, I see that keyInfo can contain references to external keys, but
that doesn't achieve the separation I have in mind, which is to keep the
Shib/SAML metadata itself (site names, URLs, etc) independent of the
key/authority info used to validate the identities of those sites.  It
just seems to me that the key-management data simply reflects the limited
capabilities of the underlying PKI code, rather than necessary data to
make Shib/SAML work.

Let me sketch out the approach below.  Probably you've already got the
approach you've proposed implemented, but let me try to make this case
anyway.

I suggest that site elements should not have KeyInfo or TrustList elements
in them.

Instead, there would be distinct elements which I will call "KeyAuthority"
elements.  Each consists of one or more authority elements, defined via
ds:KeyInfo, identifying the key/cert which is to be trusted to verify
something, and zero or more sites-schema-defined named entities, strings,
about which these authorities are authoritative.  An instance might look
like (sorry, I'm not an XML schema guy, forgive me):

  <KeyAuthority>
    <authority>
      <ds:X509Data>
         <ds:X509Certificate>
         some CA cert
         </ds:X509Certificate>
      </ds:X509Data>
    </authority>
    <authority>
      <ds:X509Data>
         <ds:X509Certificate>
         some other CA cert
         </ds:X509Certificate>
      </ds:X509Data>
    </authority
    <named-entity>
       urn:mace:InCommon:osu.edu
    </named-entity>
    <named-entity>
       urn:mace:InCommon:washington.edu
    </named-entity>
  </KeyAuthority>

The above would be the case of a common CA (or set of CAs) for a
federation, etc.  Below would be the case of a direct key/cert for an HS:

  <KeyAuthority>
    <authority>
      <ds:X509Data>
         <ds:X509Certificate>
         SSL server cert
         </ds:X509Certificate>
      </ds:X509Data>
    </authority>
    <named-entity>
       handles.foo.edu
    </named-entity>
  </KeyAuthority>

which of course has more or less the semantics of a cert itself (excepting
dates and such), which is part of the win I'm looking for here.  If the
underlying trust-store of the target system ever has a way of saying
"trust this key for this name", then the above construct can go away,
without any side-effects.

Given the above, the mapping function should be easily able to figure out
which authority applies to an entity.  There could be a default set of
authorities.  I could imagine using regular expressions in the
named-entity things, eg "urn:mace:InCommon:*" to express authority over a
bunch of names (more like X.509 name constraints); or maybe using
SiteGroup for aggregation would be enough.

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

Right, the proposed scheme requires there to be some way for the
things-that-are-being-verified to be referred to.  Each site has a
name/URI, and so is easily referred to.  HSs and AAs have DNS names,
ditto.  Site-groups and <Sites> aggregations don't have names/URIs at this
point, perhaps they should.  I don't know enough about XLink and such kind
of references to know whether they'd be useful here.

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

That sounds fine.

 - RL "Bob"


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

    http://archives.internet2.edu/

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