Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Sat, 17 May 2003, Scott Cantor wrote:

> I think what you're proposing here is basically just the converse of
> what's there now, and what the application (Shib in this case) wants to
> know. I as a relying party don't want to ask the question "For this PKI
> object, what can it be used to verify?" but rather "For this system
> entity/purpose, what PKI object(s) do I verify with?".

At verification time, you actually are asking the question: "is there a
valid path from the to-be-verified object to one of my trust roots", where
"valid" includes conforming to policy constraints.  I think in practice
validation software can build paths in either direction.

But what we're doing here is expressing the policy, so the question is
whether it's better to express it in the object->root direction ("here's
my site, here's the key/CA to be used to verify it") or the root->object
direction ("here's a key/CA, here's what it can verify").

I think the message of the so-called "bridge" approach in PKI is that the
concept of "root" is not universal.  That is, unlike the conventional
hierarchy where there are a few roots and everyone knows about them, in
the bridge approach each RP is free to build relationships via
cross-certification and is more likely, given the choice, to rely on a
root that is near it administratively, and connect it to other authorities
via cross-certs that contain policy constraints.  Of course there isn't
much of this in use yet, but the reason we're working in that direction is
to get out of the limited box hierarchy puts us in.  I think the bridge
approach is also consistent with more sophisticated approaches like SPKI
that make authorities of all kinds into policy roots.

So my main point here is that putting keys and CAs into the sites file
mixes stuff that is universal (in the per-federation sense) with stuff
that can and should be per-RP.  Obviously a federation will make
suggestions about what CAs to rely on to verify what, and given the
current primitive state of things sites will take that as authoritative,
but I'm quite certain this will evolve in the direction of more
generality.

My other concern with putting keys/CAs into the sites file is how
aggregation would work.  As you've said "SiteGroup" provides a general
grouping that could be used for various purposes.  The history of groups
is that as soon as they're used much you need to separate group definition
from object definition, because objects need to be in multiple groups for
multiple reasons.  So if a SiteGroup has a CA attached to it for
verification purposes, and is also used for grouping in a UI, there will
be conflict as the two definitions diverge.  My suggestion to create what
I might call "verification policy groups" (keys/CAs plus objects) makes
that kind of group explicit.  It also permits RPs to define those groups
on their own if needed without having to muck with other kinds of site
definitions.

> The one issue I see that creates a bit of a slippery slope design-wise
> is the language used to describe what it is that an "Authority" is to be
> used for. That is, it's not likely that a "name" or URI is sufficient in
> the abstract, especially if it's just a DNS name. Is it a HS? An AA or
> SHAR?

Well, any discussion of policy reveals that all possible things have to be
expressable because someone might want to base policy on absolutely
anything.  If, in our world, we can say that all objects are uniquely
named, then they shouldn't have to be typed as well, at least for a while.

> > 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.
>
> Right, I guess the slippery slope is that certs are really complex for
> reasons that we all understand. They theoretically are supposed to
> support statements about what it is that a key/name binding is valid for
> (key usage). I don't want to try and design all that. Maybe SAML will
> someday, by defining new condition and statement types.

Quite so, which is why I'd like to express things in such a way that as
(if) PKI sophistication grows, these expressions can be subsumed.

> If I think I can get away with just using a name or a regex and not some
> kind of "purpose" vocabulary, then it might be doable.

I think name/regex should work for quite a while.

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