Page History

...

1. Self-Signed
2. InCommon Certificate Authority (Phasing out by August 2011)
3. With a justification, InCommon may also accept certificates from a third-party Certificate Authority (CA).

...

1. RSA keys with a minimum size of 2048 bits for all new submissions. We will still allow current InCommon certs at 1024 and but will migrate all participants from old certificates out of the metadata as they expire, and upgrade them to 2048. All certificates in the federation must be upgraded to 2048 key sizes by the end of August 2011. We recommend that participants submit a certificate with a new key every 3 years. Security problems in 10 years? Policing, requiring?
2. Expired certificates will not be accepted. However, expired certificates may be retained in the metadata at the discretion of the participant. Shibboleth does not check expiration dates of certificates, but this practice may cause interoperability issues with other software.

...

Points for You to Consider

1. Think more about our recommendation/requirement about using the same key for signing and encryption.

In the case of certificates used for SSL server authentication:

1. A CN or subjectAltName matching the intended hostname(s) Required. Your server names have to be correct. To increase your chances to work with other products, here is some more advice. Fine to have suggestions. Best practices to maximize the chances that things will work.

The SSL requirements MAY be left to the discretion and responsibility of federation participants; InCommon merely highlights the requirements that are likely to cause problems if not met.

To increase your chances of your deployment interoperating with other products:

1. Make sure your self-signed certificate's CN and subjectAltName match the intended hostname. This will maximize the chances that your implementation will work. This SSL/TLS configuration is left to your discretion and responsibility. InCommon highlights this point as one that may be likely to cause problems if not met.
2. For key management, InCommon allows multiple certificates per end point at any time.

  InCommon Will No Longer Issue Certificates Beginning September 1, ** 2009 **

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

1. Continue using the same certificate. Shibboleth does not rely on expiration dates of certificates. Some software may check expiration dates, therefore, we recommend the following.
2. Submit a self-signed 2048 bit certificate.
3. For key management, InCommon allows multiple certificates per end point at any time.

Backgrounder: Security and Certificate Authorities

In the profile of SAML metadata recommended by the Shibboleth Project, the signer of individual certificates has no relevance to the trust model that secures the interactions between federation participants. Participant site administrators securely transmit digital 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 the 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. Because the fields in the certificate are not relevant to any runtime processing, InCommon will not impose any requirements on certificate fields, *(other than to monitor the subjects for obvious or aggregious misrepresentations??)*

...

"If web servers and SSL could deal with bare keys, we'd be fine."

Disclaimers

\[SC: No, we shouldn't check any certificate content other than what's listed above or can be used to identify cryptographic flaws (e.g. weak keys)\] (!)

...