SAML 2.0 SP metadata: Purpose and the use of certificate

Question

Here is the part of SP metadata.

Reference: Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0

...   
<md:KeyDescriptor use="signing">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:X509Data>
        <ds:X509Certificate>
        </ds:X509Certificate>
    </ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
<md:KeyDescriptor use="encryption">
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:X509Data>
        <ds:X509Certificate>
        </ds:X509Certificate>
    </ds:X509Data>
</ds:KeyInfo>
</md:KeyDescriptor>
...

Are there any benefits to choose same (or different) certificate in both signing and encryption certificate ?

What is the purpose of including signing certificate here ?

If the message is sent through https, a transport layer encryption is provided. Do we still need to include encryption certificate here ?

Hijack

Answer 1

In SAML 2.0 Web SSO's metadata providers typically declare the same certificate for both signing and encryption usage.

There are some use-cases where usage of different keys makes sense - e.g. when SP itself is not supposed to be able to decrypt data provided by IDP (e.g. nameID or attributes), but this is only done by the ultimate recipient of the Assertion; or when a different party provides content for creation of assertion than the party who actually creates the SAML messages - but those use-cases are rare and more relevant for other profiles than Web SSO.

The signing certificate is included in order to inform users of the metadata on how to verify messages provided by the issuer of the metadata. For example, when SP receives a message from IDP, it uses signing certificate defined in IDP's metadata in order to verify whether the message was created by the IDP and wasn't tampered with during transport.

You typically don't need to include the encryption certificate in case encryption is done on transport layer and you don't perform any encryption on message level (e.g. of whole message, assertion, nameID or attributes).

Dreadfully

That's not quite precise. Signing certificate is used by the IdP. But encryption certificates are provided by Relying Parties and the IdP uses the public key of an RP's public certificate to do data encryption. While signing is to prevent tampering, encryption is to make sure no other RP is able to use the very same token. And this sometimes makes sense, for example when different tokens are issued to different RPs. There is then one certificate from the IdP and possible optional multiple certificatrs from RPs. – Reparation

Signing certificates are used by both IDP and SP, not just IDP. Also, encryption certificates can be used by both IDP and SP - SP can send a SAML message (e.g. AuthnRequest) to IDP and use encryption certificate defined in its metadata to encrypt it, as well as IDP can send encrypted messages to SP. Encryption is used to provide message confidentiality, its primary purpose is not to prevent usage of tokens by other SPs - SAML has other techniques for prevention of delivery of SAML messages to unintended recipients - such as Audience and Destination fields. – Albata

True, true. However, your "providers typically use the same pair of certificate-key for signing and encryption" still bothers me. This sentence lacks a precise "signing responses and encryption of requests" (as signing and encryption of responses with the same key would make no sense). – Reparation

The question and answer are discussing is context of SAML metadata, therefore "use the same key" means "use within the SAML metadata document". The fact that you don't encrypt messages using your own key should be obvious from basic knowledge of public key cryptography, as in such case the encryptor would be the only entity able to decrypt the message. But I'll change the wording to not confuse anyone, thank you for comment. – Albata

It's actually been proven that you can subvert XML signatures and inject additional content while the packet is in transmission. I traditionally force Assertion encryption and maybe Response signing if I feel it's worth the warrant. – Iva