Certificate chain for public SPs?

[mauromol]

This is not a real issue with the scripts provided by this GitHub project, but rather a request for clarification. I hope you can help me.

SPID specifications say that a public SP "may use self-signed certificates". Indeed, this should better be a "must use", since the procedure to request certificates to AgID currently don't support the public SP case, but only aggregators, private SPs, etc..

However, my question is another: since my company is going to provide the necessary infrastructure to support SPID for multiple public service providers, I prepared an internal CA to properly issue certificates. For better organization and flexibility, I ended up with the following structure:

• a self-signed root CA certificate
• an intermediate CA certificate used to issue certificates used by SPs; this intermediate certificate is issued by the root CA
• multiple certificates used by SPs (one for each of them), issued by the intermediate CA above

So, I believe my SP metadata would need to provide three <ds:X509Certificate> elements in its <KeyDescriptor>: one for the root CA, one for the intermediate CA and one for the actual certificate to be used to verify signatures (for metadata and authentication requests). However, doing some research on the Internet I understand that the SAML specification does not mandate how this should be done in practice, while the SAML 2.0 Metadata Interoperability Profile says some interesting things, among others:

One or more of the following representations within a element MUST be present:

• (child element of )

In the case of the latter, only a single certificate is permitted. If both forms are used, then they MUST represent the same key.

So this seems to suggest that muItiple <ds:X509Certificate> elements should be avoided. But even more interesting:

In the case of an X.509 certificate, there are no requirements as to the content of the certificate apart from the requirement that it contain the appropriate public key. Specifically, the certificate may be expired, not yet valid, carry critical or non-critical extensions or usage flags, and contain any subject or issuer. The use of the certificate structure is merely a matter of notational convenience to communicate a key and has no semantics in this profile apart from that. However, it is RECOMMENDED that certificates be unexpired. [...] Subsequent to accepting a metadata instance, a consumer MUST NOT apply additional criteria of any kind on the acceptance, or validity, of the keys found within it or their use at runtime. Specifically, consumers SHALL NOT apply any online or offline techniques including, but not limited to, X.509 path validation or revocation lists, OCSP responders, etc.

This seems to suggest that no check at all should be made on the certificates, including path validation. If I follow these recommendations, I'm inclined to try to specify just the "leaf certificate" of my certificate chain in my SP metadata: it's not self-signed, but issued by our internal CA (that won't be known by the IdP), however I expect the IdPs won't refuse it, unless it of course contains all the elements prescribed by the SPID advice n° 29 version 3.

One of the developer of OneLogin seems to suggest the same: https://github.com/onelogin/php-saml/issues/179#issuecomment-264506280 that is, most provider do not check the validity of certificates at all.

Any help and suggestion would be really appreciated. Thank you.

[psmiraglia]

This seems to suggest that no check at all should be made on the certificates, including path validation.

It seems so but, in my opinion, validation of certificates is a best practice that should be always performed.

If I follow these recommendations, I'm inclined to try to specify just the "leaf certificate" of my certificate chain in my SP metadata: it's not self-signed, but issued by our internal CA (that won't be known by the IdP), however I expect the IdPs won't refuse it, unless it of course contains all the elements prescribed by the SPID advice n° 29 version 3.

If we assume "optional" the certificate validation, the strategy I'm feeling to suggest is to include only the leaf certificate within the metadata and make the trust chain available (e.g. on your company website) for entities that are interested about the validation.

This is basically what happens within the eIDAS eID federation. If a member state uses certificates issued by an authority which is not globally recognized (e.g. local CA), the trust chain should be also distributed.