Verify signature without intermediate certificates
Is it possible to verify signatures with only ancestor or root certificates in the hierarchy?
Disclaimer: I'm new to certificate handling, so please forgive the simplistic terminology.
Consider the following situation.
- We have two parties ( for the identity provider we call it the IdP and for the service provider we call it the SP ), and some central certificate authority CAs that are definitely trusted by both the IdP and the SP.
- The CA has its own certificate , CertCA , known to both the IdP and SP (imported into the IdP's and SP's keystores with some alias)
- Out CA issues an IdP certificate ( CertIdP ) and a SP certificate ( CertSP ).
- The IdP has the CertIdP in its keystore and knows its password, so the IdP can use the CertIdP to sign messages
- same for SP/CertSP
- Now, suppose the SP doesn't know CertIdP, and the IdP doesn't know CertSP. They only know the CertCA used to sign the CertIdP and CertSP. (As I understand, we have a certificate hierarchy CertIdP->CertCA <-CertSP here-)
- The IdP wants to send the signed message to the SP. It creates a message and then signs it with CertIdP.
- The SP receives the message signed by the IdP using CertIdP. As mentioned above, the SP does not have a CertIdP, only the parent certificate CertCA.
My question is: Can an SP verify the signature of a message signed by CertIdP only by its parent certificate, CertCA?
Backstory, why.
We are implementing SAML based SSO with PicketLink. We are using PicketLink's SAML2SignatureValidationHandler to validate the signature. For this, the Service Provider (SP) needs to have the IdP's certificate in its keystore. When passing a signed SAML assertion to the SP, this handler will use the IdP's certificate to verify the signature.
The above process is working fine, but we have some organizational concerns. This procedure assumes that the SP has the IdP's certificate for verification. In case of changes, the IdP's certificate must be replaced on the SP side. We probably have a large number of SPs (hundreds, not thousands), so it's quite an effort.
Since both CertIdP and CertSP are issued by the same authority (CA), which is absolutely trusted by both IdP and SP, we thought that the CA's certificate could be used for signature verification. If feasible, the need to exchange certificates between the IdP and SP can be eliminated. CA's certificates are also "long lived", so they only need to be exchanged once in case of permanence (in our case, permanence is about 10-20 years).
However, I'm not sure if it's technically possible to use just the parent CertCA to verify a signature signed with CertIdP. Is it possible? Or are we going the wrong way here?
If relevant, we're on a Java/JBoss platform on the SP side and the IdP is 3rd party software.
renew:
This is the signature I currently get from the 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>
It depends on whether your SAML response includes the signing certificate or <ds:X509Data>...</ds:X509Data>
just its public key <ds:KeyValue>...</ds:KeyValue>
.
<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>
and
<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 a signed certificate is embedded, it may contain the AuthorityInfoAccess extension, which usually contains the http or ldap URL that issued the CA's certificate. Using these extensions from signed certificates to trusted CA certificates, you will be able to build trusted certificate chains. (Note: If 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'll need a signing certificate on hand to match it. So it boils down to a configuration/distribution issue. You can provide a web service that returns the corresponding signing certificate for the requested public key. If the signing certificate is not found in the SP's local keystore, it will contact the web service to retrieve the new CertIdP and add it to the local keystore. Keeping a local keystore is related to performance, availability and privacy.