The Incommon Federation wiki has moved.

Please visit the new InCommon Federation Library wiki for updated content. Remember to update your bookmarks.

Click in the link above if you are not automatically redirected in 15 seconds.



You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 33 Next »

X.509 Certificates in the InCommon Federation

InCommon accepts X.509 server certificates from the following certificate providers:

  1. Self-Signed
  2. InCommon Certificate Authority
  3. InCommon discourages but will also accept certificates from a third-party Certificate Authority (CA). Be forewarned that there are potential pitfalls with this approach (see the Backgrounder section below for more detail).

(info) Beginning January 2010, InCommon will no longer issue certificates signed by the InCommon CA (unless someone seriously objects and needs us to for some good reason). We will transition the entire federation to self-signed certificates over the next 2 years. This will not affect levels of security and should actually help interoperability. Other national-scale federations have implemented this practice and have found it extremely useful for the community of participants.

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 must be used for all new submissions. We still allow current InCommon certificates that carry 1024-bit keys. However, all participants must migrate old 1024-bit keys out of the metadata and upgrade to 2048-bit keys by December 2012. We recommend that participants submit a new certificate with a minimum key size of 2048 bits created with a new key every 3 years.

    (info) No certificates with keys less than 2048 bits will be allowed in federation metadata after December 2012.

  2. 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. Shibboleth does not check expiration dates of certificates, but this practice may cause interoperability issues with other software. We recommend that participants submit a certificate with a newly-generated key every 3 years.
  3. Because the fields in the certificate are not relevant to any runtime processing or security in the federated context, InCommon will not verify or impose any requirements on certificate fields, with one caveat. At its own choosing, InCommon will reject metadata submissions if that submission contains a certificate with fields that contain egregiously misrepresentative Subject information as decided by InCommon on a case by case basis. Generally, your subject information should express somewhat reasonably to you and others a relationship between the certificate and your organization. This is up to you. Again, InCommon does not validate Subject information in self-signed certificates because this information is irrelevant to the federated security context. See also "Points to Consider" below.

Points to Consider for Interoperability

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

  1. Make sure your self-signed certificate's CN (or subjectAltName) value matches the intended hostname, for TLS/SSL purposes. 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.
  2. 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.

InCommon Will No Longer Issue Certificates Beginning January 2010

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 certificate containing a 2048-bit key.
  3. 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.

Backgrounder: Security and Certificate Authorities

In the base SAML metadata specification (saml-metadata-2.0-os), 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.

This approach is supported by the SAML set of specifications. References are here for Metadata for the OASIS Security Assertion Markup Language (SAML)
V2.03 <http://saml.xml.org/saml-specifications> and SAML V2.0 Metadata Interoperability Profile <http://wiki.oasis-open.org/security/SAML2MetadataIOP>.

Example: Generating a Self-Signed Certificate using OpenSSL

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

What's left on the ToDo List prior go Going live:

  1. Disclaimer in the metadata itself(warning)
  2. Disclaimer check box upon submission (warning)

Communication Plan(question)

  • Announcement next week about Oct 22nd:
#trackbackRdf ($trackbackUtils.getContentIdentifier($page) $page.title $trackbackUtils.getPingUrl($page))
  • No labels