3

I'm new to SAML and am confused by the expected signature and trust process.

I am programming a SP and receive a signed samlp:Response from the IDP that includes the KeyInfo:

<KeyInfo>
    <ds:X509Data>
        <ds:X509Certificate>
            MIIC4DCCAcigAwIBAgIQRzFzcQiEKpFD2C+gNZ8cFDANBgkqhkiG9w0BAQsFADAsMSowKAYDVQQDEyFBREZTIFNpZ25pbmcgLSB0ZXN0Lmx1Y2lkYXV0aC5jb20wHhcNMTYwNTA2MDcyODM5WhcNMTcwNTA2MDcyODM5WjAsMSowKAYDVQQDEyFBREZTIFNpZ25pbmcgLSB0ZXN0Lmx1Y2lkYXV0aC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDqng7wxIkT7VpVJhQYgwWMngST4EhxWha+vI9/5V+D0nWZXp6MIMiFO7rv0n4+og7fdVXHjK9wL4cG9MVUMFpV8cxl7lmwKC/EomPbdsHZfCQ4QE/M+jHUDRoyeqSZgUO1oMigz65FzSdtRoM6A3TKasU5+ISttvGx66gkP5wuQUllBfDJxuVA+5qPVLas5/0s/CCyVbKPDqYwn/GMKsTc1ECy8oEeBOrfRzEsQrqlkLcoriMXYIRW92j4MWUTnz3Ce4zTGPldPl2ix/dVk02MoJEgK7NTDru+2yvo0QDIvzWWs0rltF26UdABqsiq+uuwYiKkGQpBldyjfqVvmwChAgMBAAEwDQYJKoZIhvcNAQELBQADggEBAKeywqRnNuBGaNB6k6wuDAK6Aknx28RXbJAMe9SkSAo6L16qbdRdL8JCGZCDRF7OI8GLMEZj+yStRPikEstBQYeOi+1OSDf6iqOr7LM/OURG3pNq/LUOdNJJcYUSuK3FPP4HSMOo6dOX5IHS+7OOh70CMg5dfdtjvHqb8ZsRUk30JX9nVcXXRO8Vqzgb7WjuVjGvz/zSR6Dy+f+N6UDerIauQxHPu81SasxEUE4R6pr/Tm80E6uoicp7VBtE8YGHBhag9c+rp/xLANJ+Oc0poKDvLr8odnlUvEgy5RQhqbPefQ9n8E5Pba2IA0w/tfsk0w/z2jNwgLzNCfJGyrGHiH4=
        </ds:X509Certificate>
    </ds:X509Data>
</KeyInfo>

I assume that the certificate is included so that I don't have to guess what certificate signed the response.

But this doesn't seem very useful right now. It doesn't appear that the certificate chain is included. So I can't really trust the response.

I suppose the certificate could be given me via a second, trusted out-of-band protocol, but that doesn't seem like the right solution, as that must be repeated every time the certificate expires.

If a X509 chain (e.g. SSL) is given this is a trivially easy problem to solve.

What is recommend way to verify trust for an X509 certificate, considering that the certificate may expire?

Paul Draper
  • 78,542
  • 46
  • 206
  • 285
  • You sign with the private key and you attach your public key so that the signature can be verified... – David Brossard May 11 '16 at 23:15
  • Possible duplicate of [SAML: Why is the certificate within the Signature?](http://stackoverflow.com/questions/1703301/saml-why-is-the-certificate-within-the-signature) – David Brossard May 11 '16 at 23:16
  • @DavidBrossard, the top answer says "That just checks that the message is from who it says it is. *You need an additional check that the message has come from someone that you trust.*", without addressing CA, chains, or expired certificates. – Paul Draper May 11 '16 at 23:18
  • True. Typically, you configure STSs in a circle of trust, i.e. you have exchanged public keys before and therefore the cert that you have in the SAML assertion has been issued by a CA that can be traced back to the public key with which your STS has been set up during the establishment of the federation – David Brossard May 11 '16 at 23:23

1 Answers1

3

I suppose the certificate could be given me via a second, trusted out-of-band protocol.

That's what SAML implementations typically do. SAML uses the certificate infrastructure as a "highly generic and extensible means of communicating key material. This specification takes no position on the allowable or suggested content of this element, nor on its meaning to a relying party. As a concrete example, no implications of including an X.509 certificate by value or reference are to be assumed. Its validity period, extensions, revocation status, and other relevant content may or may not be enforced, at the discretion of the relying party."

as that must be repeated every time the certificate expires.

Since the expiry is usually not enforced that doesn't matter. What matters is when keys change (key rollover). To handle that the certificates are typically loaded from metadata published by the Idp. Which means that in the end it is the TLS certificate of the metadata endpoint on the Idp that is the base for the trust.

There are also cases where TLS is not trusted enough (I've experienced it in health care) and where certificates are only exchanged through a secure out-of-band communications channel (such as in person meetings).

Anders Abel
  • 67,989
  • 17
  • 150
  • 217