...
- 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.
- 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.
- 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 egrigiously 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:
...
- 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.
- Submit a self-signed 2048 bit certificate as soon as is practicable.
Wiki Markup Here are instructions for creating a self-signed cert.\[link\]
- For key management and migration, InCommon allows multiple certificates per end point at any time.
...
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.
"If web servers and SSL could deal with bare keys, we'd be fine."
Disclaimers
...
What's left on the ToDo List prior go Going live:
- Disclaimer in the metadata itself
- Disclaimer check box upon submission: Talk to Legal.
- 1st of a set of quarterly tech sessions to handle questions. Schedule this for Aug 27th?
Do we need an additional FAQ or is this sufficient?
- "If web servers and SSL could deal with bare keys, we'd be fine."