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>

Antibaryon

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.

Ganymede

At the moment I get only SignedInfo and SignedValue (please see the update in the question). But what you're saying is that if I have the X509Data with the certificate then I could validate it using the CA cert, right? – Antibaryon

I've just learned that the <ds:KeyInfo> element is optional in the xmldsig schema as well as in the SAML 2.0 core standard. Yes, you just have to get the signing certificate, whether via <ds: X509Data> or via other means depends on the use-case. The approach with a centralized provisioning mechanism works also w/o the public key info, e.g., via a well-known URL that provides the current validation certificate. – Ganymede

@Antibaryon you will always need the certificate that was used to do the signature to verify it. The verification can't be done with only CA cert because you don't know if the signature has been made using certificate issued by this CA or any other CA. If you can, set your IdP to put signing IdP certificate in the SAML in the <ds:KeyInfo> element. – Intervenient

Thank you! Awarded the bounty as this was the first - and correct answer. – Antibaryon

Answer 2

I'll start with some small introduction - the verification of digital signatures is done in two stages

• first signature verification - which checks that the signature value is actually corresponding to the content it protects and that the content therefore wasn't tampered with
• trust verification - check that the signature was made by someone trusted by the verifier).

Verification of a digital signature requires posession of the public key whose corresponding private key was used to create the signature. There's no way around this.

But there's one use-case for verification of trust which allows usage of CA certificates - and it should be helpful for your case.

It works so that you only include your CA (and possibly intermediate CA) signing certificates in the metadata generated for your SPs and IDPs. You then include the precise leaf key (issued by the CA) used to create the signature as part of the SAML message (in KeyInfo element inside the Signature). The SP/IDP is then able to verify that the leaf key (which was unknown to it beforehand) is trusted by constructing and verifying Certification Path using the CA certificates it already has.

It's useful for rollovers of keys (e.g. when they expire) - as SP and IDP can change their signing key without need to notify the other party. SAML products sometimes call this feature anchored or PKIX trust mode.

Please note that this approach doesn't work for digital encryption, as encryption requires beforehand knowledge of the precise leaf key of the other party.

Bellaude

Answer 3

The short answer is "No." If you only have the CA's certificate but not the certificate of the IdP or SP you cannot validate the signature of IdP or SP.

The longer answer: To validate the signature of the IdP by the SP, the SP first has to identify the correct public key associated with the IdP. Validation involves comparing the public-key-encrypted signature value with the hash of the content and checking that they are the same. Without the public key of the IdP the SP cannot perform this operation.

Suppose the SP has a public key that makes the validation above work, and it now wants to validate that this public key in fact belongs to the IdP. In order to do this, it needs a certificate that contains the public key and the name of the IdP, with a signature from a trusted entity, in this case the CA. Since you don't have this, you can't validate that the signature was performed by the IdP.

Sevenup