X.509 Certificates in the InCommon Federation

As of January 2010, InCommon does not issue certificates signed by the InCommon CA. We will transition the entire federation to self-signed certificates over the next two years.

Requirements

InCommon sets the following security and trust parameters around certificates that are included in Federation metadata:

1. RSA keys with a minimum size of 2048 bits must be used for all new certificates introduced into Federation metadata.
2. No certificates with keys less than 2048 bits will be allowed in Federation metadata after December 2012.
   • All participants must migrate old 1024-bit keys out of metadata and upgrade to 2048-bit keys by December 2012.
3. We recommend that participants submit a new certificate with a new 2048-bit key every 3 years.
4. Expired certificates will not be accepted for addition to one's metadata. However, current certificates that do expire may be retained in the metadata at the discretion of the participant.
5. InCommon does not validate Subject information in self-signed certificates because this information is irrelevant to the federated security context. However, at its own discretion, InCommon will reject metadata submissions if that submission contains a certificate with fields that contain egregiously misrepresentated Subject information as decided by InCommon on a case by case basis. Generally, your subject information should express a somewhat reasonable relationship between the certificate and your organization.

Points to Consider for Interoperability

To increase the chances of your deployment interoperating:

• If the certificate will be used for TLS/SSL server authentication (e.g., an IdP's SOAP endpoint), make sure your certificate's CN (or subjectAltName) value matches the intended hostname. This will maximize the chances that your implementation will work. This TLS/SSL configuration is left to your discretion and responsibility. InCommon highlights this point as one that may likely cause problems if not met.
• Shibboleth does not check expiration dates of certificates, but this practice often causes interoperability issues with other software, and with some older (generally now unsupported) versions of Apache used in the deployment of the Shibboleth IdP.
• For key management, InCommon allows multiple certificates per end point at any time. You can log in to the site administration tool, select the particular endpoint, then choose the one or more certificates you want to associate with this endpoint. This is helpful for migrating from one certificate to another during a finite period of time.
• However, bear in mind that not every SAML implementation supports multiple keys properly and you may want to test this with any non-Shibboleth partners. For example, EZProxy supports metadata, but is known to ignore additional keys beyond the first.
• For those using the Shibboleth SP, the self-signed certificate generated during installation of the software (or subsequently using the keygen shell/batch script) is generally suitable for use within the federation.

InCommon No Longer Issues Certificates (as of January 2010)

As stated above, we are moving the federation toward self-signed certificates in the metadata. As your InCommon certificates expire, you should:

1. Submit a self-signed certificate containing a 2048-bit key.
2. For key management and migration, InCommon allows multiple certificates per end point at any time. Select the new certificate from your list of submitted certs, while keeping the old certificate associated with the endpoint for as long as your transition process requires. Before doing so, you may need to verify that non-Shibboleth deployments you interact with will accept metadata containing multiple keys.

If necessary, you may continue using the expired certificate. Shibboleth, when used with metadata of the form used by InCommon, does not enforce the expiration dates of certificates. However, other software often will check expiration dates, therefore, we recommend planning ahead and migrating to a self-signed certificate well ahead of your certificate's expiration.

Backgrounder: Security and Certificate Authorities

In the base SAML metadata specification \[1\], a certificate signing authority has no assumed relevance to the trust model that secures the interactions among a federation's participants. Participant site administrators securely transmit X.509 certificates and metadata to InCommon. InCommon signs the entire metadata file, securing the keys of its participants whether they are represented in the context of self-signed certificates or certificates signed by an authority. The critical element in the certificate is the public key, which is associated with the participant's "entityID." The other elements in the certificate are irrelevant for security and trust processing. Theoretically, if all the relevant software systems could accept a public key without a certificate wrapper, InCommon would only need to include the public key of each end point. As it is, the certificate is a practical shell for the public key, the critical element being that the key is bound to a particular entity in the metadata.

Furthermore, allowing self-signed certificates simplifies the work of participants who may be required to join multiple federations, or who support local systems that are not enrolled in the federation.

Third-party certificates signed by an authoritative CA are discouraged since they can create interoperability issues in certain cases, and lead to configurations that mistakenly rely on the certificate signer to establish trust in the certificate. Where necessary they can be accommodated because of constraints imposed on participants from other sources.

Where Do I Get My Certificate?

For those using the Shibboleth SP, the self-signed certificate generated during installation of the software (or subsequently using the keygen shell/batch script) is generally suitable for use within the federation.

The self-signed certificate generated during the installation of the Shibboleth IdP MAY be suitable, but this depends on your need for a TLS/SSL certificate and whether the hostname it deduces matches the one you expect to publish in your metadata. This will often not be the case, so use caution.

If you need to generate your own, an example of doing so using OpenSSL follows:

openssl req -new -x509 -days 1095 -keyout key.pem -out cert.pem -newkey rsa:2048 -subj "/CN=hostname.example.org"

References

\[1\] _Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0_ [http://saml.xml.org/saml-specifications]
\[2\] _SAML V2.0 Metadata Interoperability Profile_ [http://wiki.oasis-open.org/security/SAML2MetadataIOP]
\[3\] [X.509 Certificates in the Federation Metadata|http://internet2.na6.acrobat.com/p46467886/]: A technical webinar presented by the _InCommon Technical Advisory Committee_ (October 22, 2009)