Validating a signature without intermediate certificate

Question

Is it possible to validate a signature only having an ancestor or root certificate in the hierarchy?

Disclaimer: I'm a newbie to the certificates handling so please forgive the naive terminology.

Consider the following situation.

• We have two parties (let's call them IdP for Identity Provider and SP for service provider) and some central certificate authority CA which is definitely trusted by both IdP and SP.
• CA has it's own certificate CertCA known to both IdP and SP (imported into IdP's and SP's keystore under some alias)
• Out CA issues one certificate for IdP (CertIdP) and one for SP (CertSP).
• IdP has CertIdP in its keystore and knows password for it so IdP can sign messages with CertIdP
• Same for SP/CertSP
• Now let's assume that SP does not know CertIdP and IdP does not know CertSP. They only know CertCA which was used to sign CertIdP and CertSP. (As I understand, we have a certificate hierarchy CertIdP --> CertCA <-- CertSP here-)
• IdP wants to send a signed message to SP. It creates a message and then uses CertIdP to sign it.
• SP receives the message signed by the IdP using CertIdP. As noted above, SP does not have the CertIdP, only the parent certificat CertCA.

My question is: Can SP validate the signature of the message signed by CertIdP only having its parent certificate CertCA?

Backstory, why want it.

We're implementing SAML-Based SSO with PicketLink. We're using PicketLink's SAML2SignatureValidationHandler to validate signatures. To achieve this, Service Provider (SP) needs to have IdP's certificate in its keystore. When a signed SAML assertion is passed to SP, this handler uses the IdP's certificate to validate the signature.

The process above works well, but we have some organisational concerns. This process assumes that SP has the IdP's certificate for validation. In case something changes, IdP's certificate must be replaced on the SP side. We may have a large number of SPs (hunreds when not thousands) so this is quite an effort.

Since both CertIdP and CertSP are issued by the same authority (CA) which is definitely trusted by both IdP and SP, we had the idea that we may use the CA's certificate for signature validation. If this works, this might eliminate the need to exchange certificates between IdP and SP. The CA's certificate is also very "long-living" so if only have to be exchanged once in eternity (eternity, in our case is around 10-20 years).

However I am not sure if it is technically possible to validate the signature signed with CertIdP only having the parent CertCA. Is it possible? Or are we on completely wrong track here?

If it's relevant, we're on Java/JBoss platform on SP side, IdP is a third-party software.

Update:

This is the signature I get at the moment from IdP:

    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" />
            <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
            <ds:Reference URI="#_...">
                <ds:Transforms>
                    <ds:Transform
                        Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" />
                    <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
                        <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#"
                            PrefixList="ds saml samlp" />
                    </ds:Transform>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
                <ds:DigestValue>r...=</ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>X...==</ds:SignatureValue>
    </ds:Signature>

Answer 1

it depends whether your SAML response contains the signing certificate <ds:X509Data>...</ds:X509Data> or just the public key <ds:KeyValue>...</ds:KeyValue> of it.

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" ...>
  ...
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>...</ds:SignedInfo
    <ds:SignatureValue>...</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:X509Data>
        <ds:X509Certificate>...</ds:X509Certificate>
      </ds:X509Data>
    </ds:KeyInfo>
  </ds:Signature>
</saml2p:Response>

vs.

<saml2p:Response xmlns:saml2p="urn:oasis:names:tc:SAML:2.0:protocol" ...>
  ...
  <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <ds:SignedInfo>...</ds:SignedInfo
    <ds:SignatureValue>...</ds:SignatureValue>
    <ds:KeyInfo>
      <ds:KeyValue>
        <ds:RSAKeyValue>
          <ds:Modulus>...</ds:Modulus>
          <ds:Exponent>...</ds:Exponent>
        </ds:RSAKeyValue>
      </ds:KeyValue>
    </ds:KeyInfo>
  </ds:Signature>
</saml2p:Response>

If the signing certificate is embedded, it may contain the AuthorityInfoAccess extension, which usually contains an http or ldap URL to the issuing CA certificate. Using these extensions from the signing certificate to the trusted CA certificate, you would be able to build the trusted certificate chain. (Note: If the CertCA is actually the direct issuer of CertIdP and CertSP you already have the required trusted certificate chain.)

However, if you only got the public key you need to have the signing certificate at hand to match the public key against. So then it comes down to a provisioning/distribution problem. You could provide a web service that returns the corresponding signing certificate for the requested public key. If the signing certificate was not found in the SP's local keystore it would contact the web service to retrieve the new CertIdP and add it to the local keystore. Keeping the local keystore is performance, availability and privacy relevant.