On 6/23/11 9:54 PM, "Sam Hartman" <[log in to unmask]> wrote:

>>>>>> "Cantor," == Cantor, Scott E <[log in to unmask]> writes:
>
>
>    Cantor,> That's where I bump the problem to metadata and assume the
>    Cantor,> issuer name can be used to obtain trusted information about
>    Cantor,> the issuer.
>
>Without a trust anchor, you can't trust the metadata.

That's a much different problem in scale, and those trust anchors don't
have anything to do with, say, SSL, which is where you end up getting
"ordinary" certs from. Those CAs need to be cut out of the model.

>2) the user enters it themselves.  Here, there is no standard protocol
>to find information about the issuer.

Yes, but if there are "known-good" or trusted sources of information about
issuers that do not have names like Comodo, those can be installed into
clients that can obtain issuer information from many different IdPs. For
example, a client in a computer lab at a university can trust a federation
that can provide any student from any of the federation members with
trusted issuer info for their IdP.

What you don't want is to require that the *IdP* get its cert from that
one issuer.

>If we were going to write such I think I'd prefer to simply write
>something to do leap-of-faith against the key in the cert we're first
>presented with. But I'd be interested in your input.

I have nothing against that model either, and think it should be supported.

>I definitely don't think we want some sort of global metadata that
>clients need to have in order to find issuers.

You have that regardless. With a PKI, that metadata is the certificates
issued by all the CAs you trust. The only difference is whether you're
overloading some PKI that wasn't actually designed for the purpose or not.
I would not dispute that if you can avoid commercial PKI, you can come up
with something more workable, but in practice people don't avoid it.

>  I think that would go significantly against our model.
>  I think none of these solutions handle
>revokation. (I'm not convinced SAML metadat has a good revokation story
>either.)

I think it works fine. If we revoked a key in InCommon, any Shibboleth or
simpleSAML SP using that metadata would know about within hours (or
whatever window they want, really).

(Note that nothing says SAML's involved at all, I'm using it as an
example. I'm sure that's obvious, just noting it for the record.)

If you mean revocation of the metadata signer, that's a different story.
Leap of faith is the only way you'll avoid trusting something you can't
change easily.

-- Scott