shibboleth-dev - Re: Trust metadata for discussion
Subject: Shibboleth Developers
List archive
- From: "RL 'Bob' Morgan" <>
- To: Scott Cantor <>
- Cc: Shibboleth Design Team <>
- Subject: Re: Trust metadata for discussion
- Date: Fri, 16 May 2003 01:19:12 -0700 (PDT)
On Wed, 14 May 2003, Scott Cantor wrote:
> 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.
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.
In classic simple PKI (to coin a phrase) which I think is how 0.8 works,
there's a big bunch o roots (aka trust anchors), and an incoming assertion
verifies if a suitable chain can be found to any one of them, leading us
to limit the number of roots (to 1 at the moment for InCommon). In a PKI
that fully supported name/policy constraints, I think what a target would
do is still have its big bunch o roots and CAs, but name/policy
constraints would be defined so that only the right things verify. Thus
if origin foo.edu wanted to use Verisign, it would be OK, because the
target would include Verisign in its store, but set its contraints on
Verisign to permit it to validate foo.edu, but not permit it to validate
anything else. I'm sure this doesn't work in practice yet, and may never,
but I think the model is the right one: the relying party sets up its
validation machinery to do the right thing when asked to validate, as
independent of particular apps as possible.
The TrustList element as you propose it kinda turns this around,
associating a CA with the data item to be validated. This is probably
fine, given the state of the world, but it doesn't seem right to me that
it be included with the rest of a site's data. I can't quite put my
finger on it, but it seems to me that having a federation say "here's site
foo.edu's HS URL etc" is different than having it say "and here's the CA
you validate it with".
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.
- 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--
- RE: Trust metadata for discussion, (continued)
- RE: Trust metadata for discussion, Scott Cantor, 05/14/2003
- RE: Trust metadata for discussion, Steven_Carmody, 05/15/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/15/2003
- RE: Trust metadata for discussion, Steven_Carmody, 05/15/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/15/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/15/2003
- RE: Trust metadata for discussion, RL 'Bob' Morgan, 05/16/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/16/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/14/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/16/2003
- RE: Trust metadata for discussion, RL 'Bob' Morgan, 05/17/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/17/2003
- RE: Trust metadata for discussion, RL 'Bob' Morgan, 05/19/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/19/2003
- RE: Trust metadata for discussion, RL 'Bob' Morgan, 05/19/2003
- RE: Trust metadata for discussion, Scott Cantor, 05/17/2003
- RE: Trust metadata for discussion, RL 'Bob' Morgan, 05/17/2003
Archive powered by MHonArc 2.6.16.