using cert in SP metadata for encryption
John Dennis
jdennis at redhat.com
Thu Nov 17 16:18:07 EST 2016
On 11/17/2016 03:39 PM, IAM David Bantz wrote:
> I've been given metadata for vended service that contains an X509
> certificate, but the IdP (v2) does not see it as an encryption key
> (sends a SAML status indicating failure to encrypt, with logs indicating
> no key encryption credential found for the entity).
>
> The vendor tells me they have "encryption turned on" and confirmed the
> metadata. The certificate in the metadata however is fully contained
> within <ds:Signature...>...</ds:Signature>. Can / should such a cert be
> used by the IdP to encrypt the SAML response?
Let's make sure you've got your terminology right and you're actually
talking about encryption and not signing.
Let's also make sure we're using the same terminology. Signing and
encryption are both performed using asymmetric cryptology which uses 2
keys, a public key and a private key. In the world of x509 the public
key is embedded in a certificate and is publicly exchanged. The private
key is normally just called the "key".
cert == public key
key == private key
Thus in either case it's the entity performing the encryption or signing
that needs the (private) key. Private keys are not part of a
certificate, a certificate contains the public key.
Assuming you've accurately communicated the error then what the error
means is the IdP cannot encrypt it's response to the SP because the IdP
does not have an encryption key. The IdP encryption key belongs to the
IdP, not the SP. Private keys belong to an entity and *must* be kept
private otherwise they lose all value because anyone with access to the
private key of key pair can spoof the entity.
Essentially you've got things backwards. The entity performing the
encryption is the entity which needs the key. The entity decrypting is
the entity which needs the cert (e.g. public key). Because metadata is
used to exchange *public* interoperability configuration information you
include the public key in the certificate in the metadata, not your
private key.
HTH,
--
John
More information about the users
mailing list