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