RE: [security-services] Trust management and validation via metadata

["Linn, John" <jlinn@rsasecurity.com>]

I think it's definitely important and appropriate to be able to leverage
PKIs as a means to establish trust between SAML entities.  I'm not fully
up on current details and intended usage for metadata, but would like to
inject an observation at the level of principle.  Fundamentally, I don't
think that a metadata object signed by an entity can be(come)
authoritative to specify a trust path that a verifier should accept for
that entity.  It can provide useful hints, and could even carry
certificates that comprise elements of that trust path, but validation
will still need to be performed relative to a policy and trusted root(s)
that the verifier obtains through other sources.  The trust file Scott
describes seems to represent a means to disseminate that sort of policy
information.  I think it could be useful for entity-supplied metadata to
be able to conveniently carry, name, or hint at information that a
validator might use to confirm the entity's trustworthiness, but don't
think this can replace the need for independent configuration of the
data and policies that a validator will apply.  

--jl

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu] 
Sent: Tuesday, March 08, 2005 12:00 PM
To: 'SAML'
Subject: [security-services] Trust management and validation via
metadata

As I mentioned on the last call, our project is looking hard at
consolidating some of our older work in trust management around the new
metadata schema (initially for SAML 1.x, but eventually 2.0 as well) and
the
basic problem we have is the lack of any place to communicate not just
keys
but key authorities. CAs if you will.

There's a quite a bit of text on this subject here:
https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/TrustManagem
ent

But in a nutshell, we plan to continue supporting a model where instead
of
distributing actual public keys in the metadata, we use a more
traditional
PKI in which we distribute the names of certificates that can be used
along
with the allowed certificate authorities.

We do this today at the federation level, by using our own CA to issue
InCommon certificates to participating providers and distributing our
own
trust file format that, loosely translated, says "Providers in the
InCommon
federation must use certificates issued by the InCommon CA", where the
actual CA is in the file. The metadata than contains only the key names
that
particular providers can use, and then the certificate is validated at
runtime in the usual PKIX (or something close) manner.

Now, there is no ds:KeyInfo child element that means "CA". The closest
is
the IssuerName/SerialNumber combo, and that's not the same thing since
it
still bumps the actual CA cert to some OOB exchange.

So what I was asking on the call is, is anybody else doing this, and is
there any interest in developing an extension element that would contain
ds:KeyInfo data that was specifically defined to be authorities for keys
issued to providers within the containing element. It would be something
usable at the role, entity, or entities level.

Example:
https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/MetadataExte
nsio
ns

Alternatively, what am I missing? Nobody uses any traditional PKI for
this
sort of stuff? I can believe that.

-- Scott


---------------------------------------------------------------------
To unsubscribe, e-mail:
security-services-unsubscribe@lists.oasis-open.org
For additional commands, e-mail:
security-services-help@lists.oasis-open.org