OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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

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.  


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

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
basic problem we have is the lack of any place to communicate not just
but key authorities. CAs if you will.

There's a quite a bit of text on this subject here:

But in a nutshell, we plan to continue supporting a model where instead
distributing actual public keys in the metadata, we use a more
PKI in which we distribute the names of certificates that can be used
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
trust file format that, loosely translated, says "Providers in the
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
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
the IssuerName/SerialNumber combo, and that's not the same thing since
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.


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

-- Scott

To unsubscribe, e-mail:
For additional commands, e-mail:

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]