Using Two Credential's in relying-party.xml

Zmuda, Matthew R Matthew.R.Zmuda at
Wed Jan 25 17:21:26 GMT 2012

Ok I understand everything you are saying about relying-party.xml.

If understand correctly, from and IDP metadata standpoint it does not make sense to define a signing & encryption KeyDescriptor's. Only 1 KeyDescriptor <KeyDescriptor use="signing">

Is required, no need or purpose for additional

<KeyDescriptor use="encryption">

Thanks again,

Matthew Zmuda | IT Solutions Developer
DCTS - Online Channels - Authentication and Security

-----Original Message-----
From: users-bounces at [mailto:users-bounces at] On Behalf Of Cantor, Scott
Sent: Wednesday, January 25, 2012 11:24 AM
To: Shib Users
Subject: RE: Using Two Credential's in relying-party.xml

> I'm looking to use two separate certificates in the IDP metadata (one signing
> the other encryption).
> Do both of these certificates have to come from the same private key?

Certificates are like projections of public key credentials, they have nothing to do with the actual signing or encryption function. You aren't defining certificates, you're defining key pairs and certifcates that perform a function and are communicated to a peer in hinting structures like KeyInfo to identify the key. What certificate is used depends on the trust model in use and other factors.

But the IdP doesn't support decryption, so there is no support for an encryption credential. It might be config-legal, but won't do anything for you. It will be ignored AFAIK.

The multiple credential support is designed for handling different signing keys or certificates (that is, different projections of a given key) to different peers.

> Is it possible to use certificates from different private keys (ie singing from
> one private key, encryption from another private key)?

The whole point of dedicated key use is to use separate keys.

-- Scott

To unsubscribe from this list send an email to users-unsubscribe at

NOTICE: Confidential message which may be privileged. Unauthorized use/disclosure prohibited. If received in error, please go to for instructions.
AVIS : Message confidentiel dont le contenu peut être privilégié. Utilisation/divulgation interdites sans permission. Si reçu par erreur, prière d'aller au pour des instructions.

More information about the users mailing list