Third-Party Certs

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. With a justification, InCommon may also accept certificates from a third-party Certificate Authority (CA).

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 for all new submissions. We still allow current InCommon certs that are 1024. However, all participants must migrate old 1024-bit certificates out of the metadata and upgrade 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 2048 certificate with a new key every 3 years.
2. Expired certificates will not be accepted. 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.
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. See also "Points to Consider" below.

Points to Consider

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 as soon as is practicable.

   Here are instructions for creating a self-signed cert.[link]

   
3. For key management and migration, 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.

Futhermore, 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.

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

1. Disclaimer in the metadata itself
2. Disclaimer check box upon submission: Talk to Legal.
3. 1st of a set of quarterly tech sessions to handle questions. Schedule this for Aug 27th?

Communication Plan

• Announcement next week about Oct 22nd:
  • o    Go live with Service
    o    Webinar date
    o    Two line summary on HomePage and within architecture of the website
    o    Announce this to incommon-participants Tues at 9am??: Announcing
    •    A chance to discuss technical issues with the TAC and Ops
    •    Self Signed Certs
    •    SAML2 and Shib 2 migration issues.
    •    Self Signed Certs page. Made Public with Correct Dates. On the wiki.
    •    Adobe Connect. Use the IM chat facility and the Shared Desktop facility to talk through the web pages:
    o    https://spaces.at.internet2.edu/display/InCCollaborate/SAML+2.0+FAQ
    o    https://spaces.at.internet2.edu/display/inctac/Third-Party+Certs
    o    https://spaces.at.internet2.edu/display/SHIB2/IdPUpgrades
    •    Talk with TechSupport about setting up the magic recording black box for Adobe Connect
    •    After event announcement about the recorded event and pointers on the web.
    •    Potential post production to create evergreen content??
    •    FOPP and CP/CPS related. (John)

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