Credential, TrustEngine and CredentialResolver key and certificate relationships

[Cantor, Scott]

On 9/10/13 4:08 PM, "Brian Reindel" <brian at reindel.com> wrote:

>In public and private key encryption, I would give the public
>certificate to the other party to load into their truststore, which
>they could use to encrypt messages to me. I would then decrypt with my
>private key. However, I suspect there is more going on here.

Signing is the reverse and that's much more important than encryption here.

>(1) If I have a Credential in the relying-party.xml used by a
>RelyingParty (defaultSigningCredentialRef), then what must I give the
>SP for this Credential to work (and what must they do with it)?

You give them metadata with your public key in it.

>(2) If I have a TrustEngine with a Credential in the
>relying-party.xml, then what must I give the SP for this to work (and
>what must they do with it)?

Nothing. That's for verifying signatures over metadata. The metadata is
what contains the public key of the SP (the parallel of #1)

>(3) If I have a CredentialResolver in the shibboleth2.xml, other than
>making sure a key name and the certificate appear in the SP metadata,
>what must I give the IdP for this resolver to work (and what must they
>do with it)?

You don't need a key name, but the answer is nothing. Giving them metadata
is it.

Metadata is how you exchange public keys. That applies regardless of the
purpose of the key. If you want to have separate signing and encryption
keys, you can, but that is beyond the capability of many people that have
a hard enough time with any of it already.

If you understand enough of any of this to know how SSL works, you give
your web server a key pair with the private key and a certificate. A
credential in the IdP or SP is usually the same thing, just not for SSL.

But you have a totally separate layer for verifying metadata, which
happens to reuse most of the same components because to do anything else
would be silly. But it is unavoidably confusing since they are very
differently used. A credential there is usually just a certificate or
public key loaded directly, to verify a signature created by a metadata
publisher, something that's neither an IdP nor an SP. It's the same as
loading trust anchors into the JVM for an LDAP server or something like
that.

Consider the most idiotic design imaginable: you load a public key or
certificate manually for every IdP you want your SP to accept signatures
from. This is, astoundingly, how virtually all commercial products work.
Shibboleth doesn't do that, it does that once, to verify metadata, and
then relies on the metadata for *everything* else.

There is absolutely no processing involving a public key that is done
(outside of verifying metadata) that does not itself rely solely on the
metadata to obtain the key(s).

-- Scott