Page History

...

The InCommon Federation is based on the Explicit Key Trust Model, one of several possible metadata trust models. Consequently, the use of long-lived, self-signed certificates in metadata is strongly recommended. Certificates signed by a Certification Authority (CA) are allowed, and in most situations will work just fine, but the use of certificates other than self-signed certificates is discouraged. See the Background information and the Interoperability notes below for further discussion. The A separate article on Key Handling topic shows how to create self-signed certificates and how to handle the corresponding private keys.

All federation participants arewill beingtransition transitioned to *long-lived, self-signed certificates with 2048-bit keys* by the end of 2012. *The end is near.* See \[3\] for more detail.

Any certificates you want to use with your SAML software are uploaded via the administrative interface. Typically only one certificate is required but multiple certificates may be uploaded and used as needed. For instance, multiple certificates may be used to facilitate the controlled rollover of expired certificates or certificates with weak keys. For recommended guidelines on the rollover process, refer to the Certificate Migration topic.

...

InCommon conforms to the _SAML V2.0 Metadata Interoperability Profile_ \[2\] from OASIS. Participant site administrators securely transmit X.509 certificates and metadata to InCommon via the administrative web interface. InCommon signs the entire metadata file, securing the keys of its participants whether those keys are bound to self-signed certificates or certificates signed by a CA. 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 endpoint. As it is, the certificate is a convenient container for the public key, the critical element being that the key is bound to a particular entity in the metadata.

...