Re: [saml-dev] Same certificate for https and SAML signing

["Cantor, Scott" <cantor.2@osu.edu>]

On 3/13/14, 11:38 AM, "Lucas, Mike" <Mike.Lucas@gwl.ca> wrote:

>To be clear, I think the problem with CA-signed certs isn't so much the
>CA-signed vs. self-signed characteristic. Rather, the problem is the
>"CA-trusted" vs. pre-shared characteristic. That is, if you decide that
>all certs must be pre-shared and configured into your system in order to
>integrate with you, you can avoid all the above validation (except
>checking for expiry). The simple fact that the cert was present in your
>configuration (database/keystore/whatever), under the issuer name, means
>you can trust it.

Yes, *if* you have a way to maintain that list other than manually. That's
the only point that's usually missed. It's not a free lunch to pre-share
keys, it simply makes everything easier, and the ways that you handle
revocation and key rollover are also easier in many cases than with PKIX,
but only if you do them. And the way you do that is metadata. There is no
other proposal on the table that addresses it.

>Also, keep in mind that because of #2 above, even with a CA-signed cert
>you still have to pre-configure the "name on cert" (certificate subject)
>into your configuration, so why not just pre-configure the whole cert? I
>think this is what Scott is getting at -- there is no way to just trust
>the CA-signed certs completely because there is no standard way to map
>"name on cert" to a SAML issuer.
>
>Note I'm not sure if/how SAML Metadata comes into the picture here, as
>we've never used it.

It's a requirement to use pre-shared keys, or you have no way to manage
the relationship or deal with compromise.

You can also use metadata to supply name mapping between certificates and
SAML entities, but what you don't have is a profile for doing that, or a
way to express the trust anchors, so that means the metadata can only be
safely used in combination with something else, or by extending it.

But I wanted to be clear: I am *not* saying it's reasonable to push keys
around and then move on. You can't ignore the things a PKI is designed to
do, you still should do them.

-- Scott